With today’s technologies, you can have both options, prototype and emulate.

As emulation methodologies become more popular and affordable for a variety of different-sized SoC/ASIC projects, the question arises as to why emulation should be used in areas where high-speed prototyping is still the main hardware verification technique performed. The first consideration is speed.

Those familiar with the subject know that FPGA prototyping can provide the fastest design verification. Of course, there’s a cost issue due to a longer design setup time and larger engineering effort. This is changing as setup tools are improving and becoming easier to use. However, getting to the highest speed still requires more time. Some companies even design their FPGA boards in-house per design spec to achieve the highest prototyping speed. This makes the process even longer, yet, combined with software partitioning tools, it certainly delivers the best speed results.

Transaction level interface

Another issue is the interface level for the verification process. To switch to emulation, you must move from bit-level to transaction-level interfacing. This involves developing a transaction-level testbench and transaction to bit-level bridges called transactors, requiring new engineering skills (and time to learn them).

Fortunately, emulation vendors provide a library of ready-to-use transactors for the most popular interfaces and develop custom transactors when needed. The testbench issue is solved naturally. As UVM methodologies are already in use in many SoC projects, the move to emulation is seamless. The UVM testbench in its nature is also transaction-based. If there are transactors available to connect it with a design emulated in hardware, the move to emulation is nearly painless. Perhaps more importantly, the design itself can be tested in the same manner, using the same set of tests that were used for simulation.

In addition to the obvious benefit, whereas the use of emulation decreases the verification process time significantly, tests in simulation and emulation are also easily traceable. This helps hardware verification teams cooperate with design teams, a process which, until now, has proven to be difficult in prototyping.

Losing control

Controllability of design setup is another controversial subject. The prototyping setup requires that users control the partitioning and timing constraining processes, both of which are time-intensive, yet the user retains control of the process. Conversely, emulation offers setup tools that automate all or most of the process, leaving prototyping users with a loss of control and feeling.

The solution lies in offering the user the ability to tune the setup process, even for emulation mode, at least in the areas influencing speed of tests execution. Knowledge of the design may give outstanding results with regards to emulation speed. This is, of course, a compromise between what engineers are used to and what’s possible to control in the emulation setup process.

JTAG debugging

SoC design is driven by the processors that are debugged and controlled via JTAG-based debuggers, making the JTAG interface the primary verification hub for prototyping. The JTAG cable connects the prototyping board with a host PC and a processor debugger. This requires a physical cabling connection, which is slow and hard to duplicate when needed, but gives hands-on control over the interface.

This traditional approach can also be used for emulation, but it can be extended even further. Once a virtual JTAG transactor is available, there’s no need for cables between the board and host PC debugger. Through this transactor type, it’s possible to have multiple debugging interfaces, all based on the emulation infrastructure, which are magnitudes faster than a JTAG interface. This solution is much more flexible than traditional JTAG interface debugging.

When to choose emulation

Only when SoC development is complete and the RTL code is ready can it be implemented for prototyping verification. This means that the hardware portion of the SoC has to be complete. Unfortunately, this is quite late, particularly for software teams waiting for the development platform or for design teams that have verified the project in simulations and require feedback quickly via hardware-based testing. Clearly, there’s a gap between what’s available and when it’s needed.

With emulation, software developers and hardware designers needn’t wait for the completed design. Separate modules and subsystems can be verified and tested with different types of testbenches, such as SystemC testbenches, virtual platforms, or popular UVM transaction-level testbenches. Emulation not only enables development teams to begin their work earlier in the process, it allows the SoC to be verified at the block level before SoC level verification begins, making this last stage easier and shorter. By taking it one step further and integrating a virtual platform often used by software teams with a hardware emulator, it’s possible to begin the whole SoC verification early in the process while incrementally increasing the number of subsystems implemented in the emulator.

Click to enlarge.

The future of verification

The need for speed, interfacing, and debugging requirements are slowly merging the methodologies of prototyping and emulation into one. In terms of speed, it’s not necessary to run the entire SoC at the highest speed levels; some sections are required to be in the fastest clock domains and others, such as those that require extensive debugging, may work slower. Such fast domains are processor built-in subsystems and/or high-speed external interfaces such as Ethernet or USB. These enable the space to connect the two worlds of prototyping and emulation into one with the benefits of each.

As the methodologies of prototyping and emulation begin to penetrate each other, the borders between them (and the argument for one methodology over the other) begin to disappear. An ideal verification solution for modern SoC projects is in fact a hybrid hardware-software verification environment that provides the highest speed where needed, software interfacing flexibility, and debug functions where required.

Aldec will teach a series of classes on this topic at DAC. Or, see the company’s web site for more information.

Zibi Zalewski is the General Manager of Aldec’s Hardware Division. He has worked in the EDA industry for over 19 years and is an expert in hardware-based verification methodologies covering emulation, prototyping and safety-critical solutions. His prior experience includes several roles in the industry as a developer, QA engineer, FAE, and project and product manager. Zibi received his Masters of Science in Electronics and Telecommunication from the Gdansk University of Technology, Poland.