1005EF4-Eve.doc

Keywords: emulators, platform, embedded

Editorial Feature Tab: Digital – Hardware Emulators

@head:Hardware Emulators Evolve to Meet ESL Demands

@deck:Platform-specific emulators give designers the flexibility to migrate to different target environments for more fully integrated hardware-software integration.

@text:Using a hardware emulator throughout the entire design process increases productivity. It also allows software engineers to work at the same level of abstraction as hardware designers.

Currently, process technology is shrinking device sizes while increasing the number of transistors. As a result, engineers are finding that product-development time is too short to develop new circuits that use all available silicon on the die. Integrated circuits (ICs) have grown to such a degree of complexity that they merit the label of systems-on-a-chip (SoCs). In addition, semiconductor production is now driven by consumer demand. Consumers require new products or versions of a product every few months. It’s impossible to meet these market conditions by implementing all of the functions in hardware.

To solve the problem of short development time, the electronics industry is reusing hardware designs and implementing functions with embedded software. The assumption is that programmers develop software at a higher level of abstraction. They can debug and modify programs more rapidly than hardware designers can modify circuits.

Frequently, software modifications are more localized. Compared to hardware changes, they have less impact on the whole design. When using deep-submicron design rules, modifying a portion of the hardware implementation often impacts the entire design because of power, noise, and timing issues. These issues are more difficult to find and resolve than logic errors. They also inject greater schedule unpredictability than can be realistically tolerated. Generally, modifying embedded software doesn’t present these types of problems.

Electronic-design-automation (EDA) vendors propose an approach based on a continuous refinement process of the hardware portion of the system. Using EDA tools, engineers develop an architectural design representing the proposed partitioning of the system. To validate the architecture, they develop a model using transaction-level (TL) modeling languages like SystemC or SystemVerilog. Or they can use an instruction-set simulator (ISS), which often is written in C, that models a processor. When modeling digital signal processors (DSPs), additional languages are available. Such languages include SPW from CoWare or MATLAB from The Mathworks. Verifying a system modeled in a number of languages becomes difficult. It also limits the choices of the verification environment, possibly restricting the team to use just one EDA vendor.

The execution speed of a software model is lower than the actual hardware. As the complexity of the circuitry increases, that speed ranges from an optimum of 10 million instructions per second to as low as 20,000 instructions per second. As long as the hardware model is at a high enough level of abstraction to provide acceptable execution speed, software development can proceed. But TL models often fail to provide sufficient details to support the complete development of the associated software. Further, an ISS model is difficult to develop and typically doesn’t provide a true representation of the processor’s internal architecture. Software engineers--especially those developing real-time applications--need an accurate representation of the hardware circuitry in order to verify their work.

Once the team has validated the specification and chosen the architecture, hardware and software development can proceed in parallel. Hardware designers continue the implementation by increasing the number of details. They describe the hardware at the register transfer level (RTL) using traditional hardware design languages (HDLs), such as Verilog or VHDL. At this point, the software developer is all but left out of the process. Executing software using RTL models of the hardware is time consuming. The simulator has to execute many hardware steps for every instruction cycle. The vast majority of the hardware behavior also is irrelevant to the software flow. In addition, the interfaces that allow software programs to be simulated together with hardware described in Verilog or VHDL are inefficient and often non-standard.

Software engineers must contribute to the validation process by using features that were provided to cater to hardware engineers. They are therefore at a disadvantage. Even if the TL models are sufficient for software development, problems of discontinuity could arise. After all, software development continues at the architectural level while hardware development proceeds at RTL and maybe even at the gate level. Although this methodology supports development parallelism, it does little to allow functional system verification.

Hardware designers also have changed the modeling language that they work with once they leave the architectural level. As a result, implementation errors can occur simply due to the different semantics of the languages. Because of the inadequate tools available to them at RTL, software engineers cannot contribute to finding these errors. They must continue to work at the functional level. In addition, programmers cannot verify any real-time software module that requires actual timing information, as the architectural-level models are untimed.

SoC Verification Via Emulation

To address this problem, designers have used hardware emulators to debug software with the hardware modeled at the gate level. Companies have built project-specific emulation boards using commercial field-programmable gate arrays (FPGAs), which also are called rapid prototyping boards. Or they’ve invested in emulation products sold by EDA vendors. In general, rapid prototyping boards execute embedded software at one or two orders of magnitude faster than commercial emulators. They do suffer their own set of drawbacks, however.

When more than one FPGA is needed to host the circuit under test, the custom boards that are developed for project-specific purposes require considerable time to map the design. The more FPGAs, the tougher the mapping process. This task is exacerbated by the lack of hardware debugging facilities offered by commercial emulators. Tracing a mapping problem without access to the guts of the FPGA may turn into a nightmare. Often, it leads to flat-out failure. New approaches to this mapping and debugging process have drastically reduced the required time from weeks and months to days.

In addition to supporting software development, commercial emulators can be valuable tools to validate the design architecture. Engineers can verify their designs using a mixture of TL models, RT- and gate-level modules, and the embedded software. Figure 1 shows how an emulator can support a mixed-level (TL and RTL) verification environment.

The availability of a reusable product model based on emulation also is important for the product families that differentiate one version from the next based on new hardware and/or software. Slow execution speed makes it inefficient to use the product’s software model. It’s easier to add the hardware circuitry within the emulator and verify the additional circuitry within the verified model of the existing product. Adding new software modules is another benefit that’s derived from the existence of the product model on an emulator.

The ease of use is even greater in a product like ZeBu (for Zero Bugs) because it separates testbench software from embedded software (see Figure 2). Software developers have immediate access to all internal signals. They can make better decisions with respect to interfacing the new functionality with the existing modules. In addition, debugging is easier than it would be if they had to rely on an architectural system model or signal levels found only at the device pins.

Platform-Based Design

To take advantage of embedded software, designs must incorporate either a microprocessor or a microcontroller. The availability of intellectual-property (IP) cores of both types has supported this approach. In recent years, wired and wireless applications have represented the majority of electronic-product introductions. As a result, DSPs--both as standard cores and company-specific IP--are now present in a large percentage of application-specific-integrated-circuit (ASIC) and FPGA designs.

Often, a DSP and microprocessor are found on the same die for products intended to provide high-end functionality to the market. The architectures of SoC devices that are intended to serve a specific application are similar. In fact, they could contain a set of common cores complemented by custom hardware and software modules. Engineers have labeled the collection of common cores a “platform.”

A hardware platform is a system that provides an architecture consisting of both hard and configurable functional blocks. Those blocks satisfy a set of constraints in order to allow product customization within an IC. Platform-based design offers many advantages. Development time is shorter, as only a portion of the hardware needs to be developed. In addition, companies can produce a family of products by reusing the platform and modifying the embedded software and small portions of the hardware circuitry.

Manufacturing predictability is increased because a significant portion of the IC has proven manufacturability. Historical yield figures are available. Software engineers benefit because they become familiar with the architecture and can reuse portions of code. In spite of these advantages, however, significant obstacles remain for both system designers and software designers when dealing with a platform.

Simulating the functioning of a platform using software models is time consuming and often impossible due to the absence of a model. All of the problems associated with custom design are present. At times, such problems become even more complex in the case of platform-based design. Although core providers are increasing the quality of their products, designers often find that a core’s software model isn’t as accurate as they need it to be. Some platforms use a couple of dozen cores. Having to link the entire platform to verify a portion of the new hardware or software significantly degrades the simulation speed.

This process is particularly inefficient when packaged silicon implementations of the platform exist. If designers can mount the packages containing the platform in the emulator, they have access to the platform without suffering any significant degradation in simulation speed. Such emulators, like ZeBu, allow designers to mount existing cores within the emulator. Plus, they still have enough room to support the development of product-specific hardware.

Platform-based design provides a new opportunity to use emulators to accelerate both hardware and software development. Designers can take advantage of the features of an emulator beginning with the architectural exploration of the design. This approach allows the entire engineering team to have full access to the design--no matter what the module’s level of abstraction is.

To minimize chatter, architects can view the communication pattern between various modules and refine the partitioning. Or they can change the implementation of a function from hardware to software or vice versa. By using an emulator that’s compatible with the simulator, engineers maintain the freedom to use any modeling language that they need to use. In addition, software engineers can develop software for a particular piece of hardware and see the impact it has on the rest of the design--regardless of its level of abstraction. Verification engineers can reuse testbenches as the module moves from one level of abstraction to another.

When reusing a platform, remember that cores are already available in silicon. As a result, the best way to simulate a platform is to utilize the actual silicon using an emulator. As the industry converges on a few platforms, emulator companies can begin to offer platform-specific design-under-test (DUT) boards for emulators. It also will be possible to customize the firmware in the emulator. As a result, platform-specific functions will be provided to facilitate the development of hardware and software that are specific to the application supported by the platform. If the platform contains a DSP, for example, the emulator may come equipped with a version of MATLAB to support the rapid development of DSP algorithms.

One factor holding back the growth of the IP market is the inability of potential users to evaluate a specific IP core without entering into a contract with the vendor. The ability to plug a core onto an emulator board and quickly execute an evaluation using a test circuit will provide customers with the information they need. It also will protect the vendor’s IP rights.

A platform-specific emulator is similar to the development systems that were sold by microprocessor suppliers before the introduction of the general-purpose workstation. A quarter of a century ago, engineering teams wouldn’t develop software for a specific microprocessor without using its development system. Those systems were specific to both a vendor and--in most cases--one microprocessor.

The advantage of an emulator is its flexibility. By changing the board that contains the platform, engineers can move to a different platform with little overhead costs. This change in methodology will help EDA companies expand their market and further integrate hardware and software development.

Gabe Moretti is the Editor of gabeoneda. Formerly an editor with EDN Magazine, Gabe has covered the EDA industry for many years. Moretti holds a Bachelor of Business Degree from Whittier College and a Master of Sciences Degree in Computer Sciences from the University of California, Los Angeles.

+++++++++++

Captions:

Figure 1: This diagram illustrates the emulation-based hardware/software co-verification environment.

Figure 2: Here, the ZeBu hardware platform architecture is shown including the co-verification and compilation flows.