Design Feature: September 2, 1996

So-called portable logic blocks, or "soft cores," are an integral part of today's high-complexity chip designs. Used in ASIC- and application-specific standard-product-based systems, soft cores help you shorten design cycle times, comply with industry-standard system specifications, and interface with other system components. However, soft cores are not a panacea for all design problems. They have limitations and design complexities that require you to understand how to use them before you can design them into your system.

The "soft" in soft core refers to a lack of geometric boundaries for a logic function. A soft-core description is commonly at a behavioral or register-transfer level (RTL) and almost always is in a hardware-description language (HDL), such as VHDL or Verilog. Some vendors offer soft cores in gate-level or netlist descriptions, which the vendors often encrypt to protect their intellectual property. You use a synthesis tool for a behaviorally described soft core to create a gate-level representation of the design, also in an HDL, and target it to a specific technology.

Behaviorally described soft cores have no physical attributes, and you can design them in chips spanning a range of process technologies (process feature sizes). The more advanced, or smaller, technologies typically result in higher chip speeds. You also often have a choice of design implementation with a specific core: cell-based, gate array, and, most recently, FPGA (see box, "Looking ahead").

Cell-based chips offer the highest performance and lowest unit cost but have high up-front NRE costs, have long product-turnaround times, and often require a relatively high minimum production commitment from a silicon foundry. Gate arrays yield a faster finished prototype but have lower performance for a given technology and higher per-chip cost. FPGAs are the most expensive on a per-piece basis and have the lowest performance but have the fastest time to prototype, critical for many systems with short life cycles.

In contrast, you define hard cores at a physical level and use them for a technology and design implementation. Hard cores are predefined blocks with accurate timing specifications that you "drop" into a chip. Vendors, on the other hand, design soft cores to meet minimum performance specifications over a range of technology implementations, even though core performance varies across technologies. The well-defined timing parameters of hard cores make them more applicable for timing-critical applications, such as high-performance processor engines and high-speed I/O functions. You can also implement analog portions of mixed-signal chips as hard cores.

Figure 1 shows the relationship between models, which you use to verify a design, and cores, which represent the actual design. When you undertake a soft-core-based design, you need not only a behavioral or an RTL description of the desired logic, but also a core model to simulate the logic's behavior and a test program, or testbench, to verify the core after you implement it in a technology. If you are designing a chip with cores that must comply with industry standards, such as PCI and Universal Serial Bus (USB), you may find it useful to have a compliance-test environment, or suite, which the core vendor designs and verifies. A core described in Verilog or VHDL is not automatically synthesizable. If you are using a soft core at the behavioral level or RTL, get a synthesis script from the core vendor to use when you synthesize the core to a gate level (see box, "Just what are synthesis scripts?").

Many reasons exist to use a soft core from a supplier rather than develop one in-house. Near the top of the list is that somebody may have already developed and verified what you need, letting you implement the logic in a chip much faster than if you have to develop the function yourself. This approach is especially attractive if you consider the other items you need with the core: a synthesis suite, a testbench, documentation, and the like.

A soft core's technology independence is also a valuable commodity. You may want to implement a new design in an FPGA for proof of concept and early design verification and then move to a gate array or cell-based chip for lower cost. If you implement logic as a hard core, you need to redesign and reverify the logic for each targeted technology. A soft core, on the other hand, requires just simulation and timing verification after synthesis to a target technology—a much faster option. The same situation applies if you want to migrate to a smaller technology for cost reduction or performance improvement.

Compliance with industry standards, such as MPEG-II for video or PCI for networking, is another good reason to consider soft cores from third-party providers for your design. Along with guaranteeing that the core meets required interface and performance criteria, core vendors offer predefined Verilog and VHDL core models for design verification. Core vendors also often provide test and compliance tool suites to help you verify core-based chips in systems. For example, both Sand Microelectronics and Virtual Chips offer a range of PCI and USB core products and test environments that model a real system. Sand features the PCI Performance Analyzer (PPA) tool for capturing, processing, and displaying PCI-system-performance parameters (Figure 2). You use PPA along with Sand's PCI-bus-level models to verify PCI protocol and compliance and to optimize performance before committing your design to silicon. PPA's graphical interface lets you view statistical data, such as number of burst transfers and burst lengths; performance data, such as read/write transfer rates and bus usage; and PCI-bus protocol and timing violations. This capability allows you to compare simulations and fine-tune your design for best performance.

Virtual Chips' USB Test Environment performs a similar function for USB-based applications, checking for compliance and functionality. You use it for any system with a single host and any number of hub and function models. Figure 3 represents a user-input PC peripheral, such as a mouse or joystick. The host model initiates bus transactions to devices, ensures transaction completion, and reports transmission errors and protocol violations. You specify the transaction sequence with programming-interface commands, which perform normal USB operations and create error conditions for verifying whether the system correctly handles these errors. The hub model establishes upstream and downstream connectivity, detects device attachment and detachment, and reports transmission or protocol errors from either host or function devices. The function model supports control, bulk, interrupt and isochronous transactions and USB-specified setup commands. The model also reports endpoint status and transmission and protocol errors.

Core-based chip-design issues

If you want to use soft cores in your chips, you have a number of choices. You can get a core directly from a third-party supplier and depend on that supplier's support during ASIC development. If you design an FPGA chip, you work directly with the FPGA vendor, using one of its soft cores and implementing it on your target device. You also can work with an ASIC supplier, using a combination of hard and soft cores. Some ASIC vendors, such as GEC Plessey (Scotts Valley, CA), Hitachi America (Brisbane, CA), IBM Microelectronics (Essex Junction, VT), Lucent Technologies (Allentown, PA), and Toshiba America (San Jose, CA), offer cores developed by themselves and some licensed from a core vendor.

ASIC companies often develop cores to complement their own intellectual-property blocks. Examples of such blocks are peripherals that work with a company's internally designed µPs. In addition, an ASIC company may license other functions, such as bus-interface blocks and memory controllers, from core companies. You probably cannot get source code for these cores from an ASIC vendor; you go to a different foundry for fabrication. Instead, these vendors often synthesize to a target process and provide gate-level netlists and test vectors. Not having source code may be a disadvantage if you want to do detailed debugging of your design or go in and make your own core modifications. Without source code, you must pay an ASIC vendor for additional modifications.

Because soft-core models lack interconnect parasitic-delay information, they also lack accurate timing information. Instead, the vendor supplies either a behavioral or bus-functional model. Some vendors, such as VAutomation, provide sample timing data for a technology. A bus-functional model simulates the core's behavior at the pins without modeling the core's internal configuration. You use the bus-functional portion to model interactions and command sequences between the core and external circuitry. To guarantee operation over a range of technologies, core vendors design their products as synchronous, timing-predictable logic blocks. Behavioral or RTL simulation verifies functionality, but not performance. You can check timing performance only after you synthesize the core to the gate level for a target technology. Then, you use ASIC-vendor-supplied estimated timing delays for that technology. These estimates give you an idea of chip performance with that core. Only after place and route and back-annotation of interconnect parasitics do you have a basis for accurate timing simulation (Figure 4).

Core testability

Testing a soft core brings up unique problems for both core vendors and designers. Tom Boldt, director of sales and marketing, of Logic Innovations notes that core suppliers should validate that their products at least comply with industry-standard specifications and provide acceptable simulation on an accompanying testbench. Vendors should also implement and prove the design in silicon. However, soft cores have flexible technologies and implementations, and you must provide a means for testing them in your design.

When a core is in HDL format, it needs a testbench to go with it. The testbench defines how a test program exercises the core logic's nodes after you embed the core into a chip and test the entire chip. Like the chip, the testbench should provide high fault coverage for the core. Check with core suppliers about what fault coverage they provide. At a gate-level representation, test-vector suites provide the same function: exercising the core with high fault coverage.

If you design a chip using one or more soft cores from a core vendor or an FPGA or ASIC company, remember that cores are not off-the-shelf components. Their complexity and process/design-implementation flexibility mean that, when designing a core-based chip for a target process, you probably need design assistance from the core provider or licensee. Most core vendors and ASIC and FPGA providers that offer cores understand that the core business involves service as much as actual products.

When using a predefined soft core, you trade off design time and compliance to industry standards for high performance and more detailed understanding of the core's logic. Shrinking design time resulting from shortened product life cycles is making soft-core-based design a fast-growing and important part of system-on-a-chip design. Thus, the trade-off is not only desirable, but often necessary. Otherwise, you might face the task of designing all the logic for a 1 million-gate chip from scratch.

References

1. Lipman, Jim, "Solving the configurable, core-based-chip puzzle: EDA tools put it together," EDN, Oct 26, 1995, pg 81.