If you work in the field of #ASIC or #SoC verification, you know all too well that traditional simulation techniques fall far short of expectations. Standard simulations often can’t detect bugs in complex systems involving firmware, software, and hardware in a reasonable amount of time.
Now, projects frequently use block-level simulation, exhaustive emulation cycles, and FPGA-based prototyping.
There are two primary architectures that can be used for emulation. Both use custom ASIC designs or field-programmable gate arrays as their foundation for emulation, but they both serve the same purpose. In addition, an FPGA platform is always used for prototyping.
As each approach addresses unique problems, many projects use both FPGA prototyping and emulation.
Comparatively, FPGA-based platforms are faster than emulation and less expensive per gate, but they are limited by the FPGA architecture.
Due to the complexity of the compilation cycles and the debugging process, FPGA-based platforms typically have a lengthy bring-up time, and you must begin with a relatively stable design snapshot. Any problem discovered in an FPGA system results in yet another lengthy cycle of compiling and place-and-routing. When debugging on an FPGA platform, it is often necessary to specify which signals you wish to monitor. Any time the signals to follow are modified, a new place-and-route cycle must be compiled and added. It increases the amount of logic space required and has an effect on both the machine’s processing power and its overall efficiency. This is a problem when the design is immature and re-compilation is required for debugging.
When the FPGA is up and running, it provides a fantastic environment for writing software, but unlike ASIC-based systems, debugging can be a real pain.
Platforms based on application-specific integrated circuits (ASICs) offer the advantage of CPUs designed specifically for emulation. There is no need to recompile or deal with timing issues, physical place-and-route cycles, or debugging.
When shopping for a system, customers can get the most bang for their buck by purchasing from a vendor that offers both dedicated ASIC-based and FPGA-based options.
The Preferred Methodology Combining the two worlds
Time to market is an important consideration in addition to discovering bugs that can’t be captured by conventional simulation. Time spent locating difficult-to-find bugs can be minimized by beginning preparations for tapeout earlier.
At the outset of a project, simulations are typically used for testing.
Developing code is favored by software/firmware teams over FPGA development by the majority of customers. However, the bring-up cycles can take a few weeks to a few months if the FPGA route is taken before the design is stable enough. Additional debug/re-compile/place-and-route cycles can also have a major impact on the software development schedule.
Emulators are highly recommended as they allow for rapid iteration during the debugging process. The design will be more refined before being ported to the FPGA platform in this way. As software engineers join the emulation effort, the design team can continue debugging the emulator while also extending its use to faster, cheaper-per-gate FPGA-based systems.
The Cadence Protium X1 Enterprise Prototyping Platform is an FPGA-based system, and the Cadence Palladium Z1 Enterprise Emulation Platform is a CPU-based emulation system; together, they form what Cadence calls “the dynamic duo.” Very large-scale integration (VLSI) projects benefit from the quickest turnaround when both platforms are used.
Questions and considerations to help you choose the right platform for your project
When looking at a whether you need an FPGA-based platform or an emulation platform, here are some important points to consider:
- The number of processors needed to compile your design in an hour, and how many megabits per second (Mb/s) you need to process 200 million gates.
- Dimensions of your system-on-chip (SoC). How many gates does it have? Millions? Hundreds of millions? It’s possible to cut costs by using only an FPGA-based system if your design can fit into a single FPGA or a small enough array that your engineering team can handle. Because design iterations and development take more time and effort as design complexity rises, an emulation system may be a good option when working with large designs.
- Find out how many groups or people can use the equipment simultaneously. In most cases, users are able to acquire enough capacity for running a single full-chip simulation. There are times, however, when only a few of the blocks that make up a subsystem are actually being used. The number of simultaneous runs is proportional to the granularity of the smallest cluster.
- Whether or not USB, PCIe, Ethernet, or other real-world devices will be connected to the emulator. You can choose between Cadence SpeedBridge Adapters and Cadence VirtualBridge Adapters. Real-world testing yields more accurate results thanks to the SpeedBridge Adapters’ use of physical hardware components that run at real speeds. These adapters connect the emulation system, which operates at a much reduced speed compared to the real world, to the actual hardware components. In order to bridge the two worlds, appropriate wait states must be applied in each protocol. The transactor in VirtualBridge Adapters expedites communication between the user’s DUT in a Palladium emulation platform and the host workstation.
- How easy it is to switch from simulation to emulation or an FPGA-based prototyping system. A key consideration is whether the debugging process will be more difficult on an FPGA-based platform or an emulation-based platform.
- Determine how many emulation cycles will be needed, how long regression runs will take, how much time will be spent debugging, how much performance hit might result when capturing signals, how much data can be logged, whether changing signals require re-compilation, whether you can capture full visibility of your design, and how much data can be logged.
- Is it helpful to release the machine and debug offline if we can hot swap between emulation and simulation? Think about how simple it is to initiate and cancel signals.
- Find out how many alterations and modifications must be made to the original design before it can be run on the platform of your choice.