Higher performance, shorter time-to-market, and lower manufacturing costs are all improvements that can be expected thanks to the integration of microprocessors and programmable logic devices (PLDs). On that bumpy road to ever-higher integration, microprocessors and PLDs have evolved separately, but along similar lines.
The drive for increased microprocessor performance has led to devices with wider data paths capable of handling longer instructions. On-board memory caching, better clock rates, and more efficient logic operations have increased speed. Simultaneously, processors have become more complex. To deal with that complexity, designers are using high-level languages such as C, C++, and Java. The processors often come with on-chip debugging tools, like the Background Debug Mode, Enhanced JTAG, and N-Wire, in order to support those languages.
At the same time that those microprocessor advances were occurring, improved process technology resulted in PLDs that were larger, faster, and cheaper to make. While geometries continued to shrink, the size of the die remained relatively constant, so it became practical to add more elements, such as on-board RAM. As with microprocessors, great-er integration has meant memory embedded in PLD architectures. Just as increased complexity has led to the use of higher-level languages in the design of software for microprocessors, complexity in PLDs has resulted in hardware description languages (HDLs) becoming the de facto means of developing PLD designs. PLD applications have grown larger and more intricate, resulting in on-chip debugging tools.
The parallel development of microprocessors and PLDs arises from the fact that both devices employ logical operations to solve a set of problems where, within the range of functionality of the device, the exact combination or configuration of operations changes with the user's individual application. In general, operations that require the highest performance need direct hardware implementation, while less stringent performance requirements can be met with the slower sequential functioning of a microprocessor. It should be no surprise, then, that the next logical evolutionary step is the integration of microprocessors and PLDs.
In 1999, PLD development reached a point where it was possible to design a PLD that had a soft-core processor embedded in it. Both the price and performance of this unit were on a par with board-level devices. By this quantum step in integration, performance is enhanced through the elimination of on-chip/off-chip delays. Power consumption is reduced, and the smaller die and reduced manufacturing expenses all work toward lowering overall cost.
Now, 32-bit RISC processor cores are available for programmable logic. These cores are ideal for use in many embedded systems applications because of their ability to achieve higher integration, greater flexibility, and shorter time-to-market. This is the development that enabled Altera to introduce the first soft-core RISC embedded processor optimized specifically for programmable logic.
Soft Cores Versus Hard Cores
One of the considerations that a systems designer has to face when using an embedded processor PLD is whether to use a soft or a hard core. In some applications, soft-core processors, or portable logic blocks, have many advantages over hard cores. Flexibility is the main advantage, as a soft-core processor has configurable parameters that enable a variety of application needs to be met. If you buy an off-the-shelf solution, there will be tradeoffs between your design goal and what's precanned in the off-the-shelf product. You may end up paying for peripherals that you don't want, or you might wind up with larger peripherals than necessary for the specific task. In both situations, one would be wasting silicon as well as wasting money. But with a soft core, you receive and pay for only what you want.
In basic hard-core technology, the standard methodology for building configurability into hard cores is to design in the desired functionality and then use registers and multiplexers to select which functionality is used for a specific application (called run-time configurability). That is, when the system boots up, it programs the registers to provide the needed function. With soft cores, configurability is built in at compile time. So, hardware is conserved because the features that aren't going to be used won't be implemented.
The configurability of the soft core also makes it easy to implement changes, which can dramatically shorten PLD design-cycle times. For example, a USB core is used for a variety of applications where each has its own characteristics. This means that each must be configured individually. If, like in a hard core, one had to design every application separately, costs would escalate.
Configurable parameters means that a designer can make fundamental performance area tradeoffs. For example, in Altera's Nios soft-core processor, the designer can choose either a 16- or a 32-bit data width (Fig. 1). Additionally, the designer can decide whether or not to use barrel shifters, which allow multibit shifts in a single clock cycle; m-step, which is a special instruction that does the add and shift in one clock cycle; and the size of the register file, which maps interrupt routines. If an application requires a lot of multibit shifts, from a performance point of view, it would make sense to implement a barrel shifter, even though it might raise your costs and require a larger chip. On the other hand, if the application doesn't require many multibit shifts, then the barrel shifter could be eliminated to achieve a smaller, less-expensive core. This provides a degree of flexibility to how fast your processor performs for a given application, versus how much of the chip it consumes. These factors, in turn, impact cost.
Sometimes in an off-the-shelf processor, the designer is stuck with a canned peripheral included on-chip that may not offer all of the functionality that's needed. Using a processor based on programmable logic, a customized peripheral can be built with precisely the necessary functionality—no more, and no less. Be aware, however, that soft cores have design complexities that must be understood before designing them into your system.
A soft-core description is usually designed at a behavioral or register-transfer level (RTL) in a hardware-description language such as VHDL or Verilog. Some vendors offer soft cores in gate-level or netlist descriptions. A synthesis tool is used to create a gate-level representation of the design (which is in an HDL too) and target it to a specific technology.
Behaviorally described soft cores have no physical attributes and are appropriate for chips spanning a range of process technologies. Furthermore, one can often choose to implement a design with a specific core—cell-based, gate array, or PLD.
Because the market for high-density programmable logic chips is growing, PLD vendors are partnering with third-party core vendors so that the design of core-based PLDs may be done in the same way as the design of core-based ASICs. The tradeoff is that PLDs generally cost more per unit than ASICs with comparable numbers of gates. But, PLDs have a faster time-to-market for proof of concept. Another advantage of PLDs is that there isn't the NRE cost that exists with a comparable ASIC.
Hard cores are designed at a physical level. They are predefined blocks with timing specifications for a particular technology. Soft cores, on the other hand, are designed to meet minimum performance specifications over a range of technology implementations, even though core performance varies across technologies.
Hard-core logic needs to be re-designed and reverified for each targeted technology. A soft core, on the other hand, is technology independent. It requires only simulation and timing verification after synthesis to a target technology, which is another aspect that speeds development time.
When you try to solve all of your problems with the processor, everything depends on how sophisticated the processor is and how fast it runs. A programmable logic framework, though, offers the option of taking sections of code, which would be executed sequentially in a processor, and executing them in parallel in the PLD. This is done by offloading them to smart peripherals. For example, the Data Encryption Standard (DES) can be implemented in a software loop, but a dedicated DES peripheral can execute encryption at a far faster rate. So once again, tradeoffs can be made between what's done with the microprocessor and what's done in discrete hardware. The ability to take pieces of a solution that previously were performed in software and move them to hardware profoundly impacts performance.
It's usually preferable to use a soft core from a supplier rather than develop one in-house. For one thing, a vendor may have already developed the core that you need, which saves you development costs. Also, the vendor normally provides a synthesis suite and a test bench, as well as the documentation. When you don't have to do these things in-house, it dramatically speeds development time.
Another reason for considering soft cores from third-party vendors is the assurance that they are in compliance with industry standards. Core vendors also offer predefined Verilog and VHDL core models for design verification.
A soft-core-based design requires an RTL description of the desired logic, a core model to simulate the logic's behavior, a test program to verify the core, and a synthesis script. Plus, for cores that must comply with industry standards, you need a compliance-test environment that the core vendor designs and verifies.
Pressure to shrink design time to cope with shortened product life cycles is making soft-core-based design a rapidly growing and sometimes essential part of system-on-a-chip design. But, predefined soft cores require that you be willing to trade performance for shortened design time and compliance to industry standards. The tradeoffs have to be balanced against the alternative of designing all logic from scratch.
If you buy a core from a vendor, the complexity and process/design-implementation flexibility of soft cores means that you might need design assistance from the core provider or licensee. Most core vendors provide service as well as products.
Soft-core models lack interconnect parasitic-delay information and, therefore, lack accurate timing information. The vendor might provide sample timing data for a technology. In addition, the vendor may supply a bus-functional model that simulates the core's behavior at the pins between the core and external circuitry without modeling the core's internal configuration.
Core vendors design their products as synchronous, timing-predictable logic blocks in order to guarantee operation over a range of technologies. Because behavioral or RTL simulation doesn't verify performance, you can check timing performance only after synthesizing the core to the gate level for a target technology. Then you use vendor-supplied, estimated timing delays for that technology. Accurate timing simulation can be done only after place-and-route and back-annotation of interconnect parasitics.
After you have chosen and configured your processor, decided on the peripherals and provided peripheral stubs, and picked any custom peripherals that you're going to create for this design, you face the task of implementing the internal bus structure that glues it all together. It's important that these elements be automatically generated to eliminate the chance of human error and ensure that everything will work together.
A good system design tool will generate the common elements to connect all of the peripherals to the processor, including the chip-select decoder, data return multiplexer, interrupt controller, and wait-state generator. The Nios soft-core processor for the APEX product line, for example, has a wizard included in the Excalibur development tool kit that automatically configures the peripheral bus module. It generates HDL, instantiates and connects all of the peripherals to the processor—whether they are canned or custom—and creates the necessary glue logic.
The wizard automatically generates wait states, interrupt control, variable bus sizes, and address decoding (Fig. 2). For instance, the user can indicate which peripherals interrupt the processor. For each one that does, the wizard automatically assigns an address in the interrupt lookup table and generates the corresponding interrupt control logic. Bus size converters are employed to adapt 32-bit peripherals to 16-bit configurations as necessary. This kind of functionality doesn't just dramatically shorten the design cycle. It also assures that the logic is correct the first time.
Soft-core processors present unique testing challenges. Core vendors should implement and prove the design in silicon and also prove that their products comply with industry-standard specifications. In addition, they should provide an acceptable simulation on an accompanying test bench. But because soft cores have flexible technologies and implementations, designers must provide a means for testing them in their particular designs.
For cores in HDL format, a test bench defines how to exercise the core logic's nodes after a designer embeds the core into a chip and tests the entire chip. A test bench should provide high-fault coverage for the core. At a gate-level representation, test-vector suites provide the same function of exercising the core with high-fault coverage.