How to Choose the Right Emulation and Prototyping Platform for Your Project ?

If you are in the #ASIC or #SoC verification business, you are probably well-aware that standard simulation methods are barely enough. Finding complex system bugs that involve firmware, software and hardware can be impossible to detect in a practical timeframe with standard simulations alone.

Instead, it’s very common today to see projects using block-level simulation and exhaustive cycles of emulation and FPGA-based prototyping.

For emulation, there are two main architectures. One is FPGA based, and the other is based on custom ASIC designs as the building block for the emulation system. Additionally, prototyping always uses an FPGA platform. 

Many projects utilize both FPGA prototyping and emulation, as each solves specific challenges. 

FPGA Platforms

FPGA-based platforms are typically faster than emulation and cheaper per gate, but they have some FPGA architecture constraints.  

The bring-up time on an FPGA-based platform is usually quite significant, and you can only start from a relative stable design snapshot because compile cycles and debug are not trivial. Since FPGA systems require compilation as well as place-and-route cycles, any issue found triggers another long cycle of compile and place-and-route. Depending on the FPGA platform used, debugging often requires defining the signals you want to track. Each time you change the signals to track, you have to re-compile and add a place-and-route cycle. It also takes more logic space and affects the machine capacity as well as performance. This can be a painful situation, especially when the design is not mature enough and debug requires constant re-compilation.

When the FPGA is finally running, it’s a great platform for software development, but debugging can be more difficult on an FPGA compared to an ASIC-based system. 

ASIC-Based Platforms

ASIC-based platforms provide the benefit of tailored CPUs for the purpose of emulation. There are no timing issues to handle, no physical place-and-route cycles required, and re-compilation is not required for debugging.

Vendors that choose to offer both dedicated ASIC-based systems and FPGA-based systems allow customers to enjoy the best of both worlds.  

The Preferred Methodology—Combining the two worlds

Other than finding bugs that can’t be captured with standard simulation, there is also the aspect of time to market. Getting activities done earlier results in faster readiness for tapeout while allowing time to identify bugs that are hard to find.  

When beginning a project, testing is usually done via simulations.

Most customers prefer their software/firmware teams to develop code over an FPGA. But if the FPGA route is taken before the design is stable enough, the bring-up cycles can take weeks to months. Additionally, the software development debug cycle can take a serious schedule hit by forcing additional debug/re-compile/place-and-route cycles.

The recommended process is to start with an emulator, enabling a much faster turnaround time for debug iterations. This ensures the design is more mature before porting it to the FPGA system. The design team can then continue debugging on the emulator—with software engineers joining the emulation effort as well—while expanding the usage to FPGA-based systems that are running faster and are cheaper per gate.

Without further adieu, let me introduce what Cadence calls “the dynamic duo”—a combination of the Cadence Protium X1 Enterprise Prototyping Platform, an FPGA-based system, and the Cadence Palladium Z1 Enterprise Emulation Platform, a CPU-based emulation system. Using both platforms enables the fastest turnaround time for very large-scale integration (VLSI) projects. 

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 time it takes to compile your design and the number of CPUs required to compile 200M gates in an hour.
• How large your SoC is. Is it billions of gates, millions of gates or less? If your design is small enough to fit into one FPGA or is a small enough array that your engineering team can handle, you might be able to save money by using just an FPGA-based system. The larger the design, the more complex and time-consuming the iterations and development around it become, and in this case, you should consider moving to emulation system. 
• How many different teams/individuals need to utilize the machine in parallel. Users generally obtain capacity that allows them to run at least one full-chip simulation at a time. However, there are times when partial subsystem blocks are being run, which doesn’t take the full capacity. The size granularity of the smallest cluster determines how many different runs you can do in parallel to fully utilize the machine.
• Whether you will connect the emulation to real external devices like a USB, PCIe, Ethernet or other devices. Depending on your preference, you should look into Cadence SpeedBridge Adapters or Cadence VirtualBridge Adapters. SpeedBridge Adapters are physical hardware components that run at real speeds and are more accurate in the real-world testing of the design. These adapters serve as a bridge between the emulation system, which that runs much slower than the real world, to real hardware elements. This process is usually done by applying relevant wait states in each protocol to allow bridging between the two worlds. VirtualBridge Adapters consist of a transactor that enables high-speed transactions between a user’s design under test (DUT) running in a Palladium emulation platform and a host workstation.
• How seamless it will be to port a design from simulation to emulation or to an FPGA-based prototyping system. In particular, you’ll need to anticipate whether it will be more challenging to perform debugging on an FPGA-based or an emulation-based platform. 
• How much time will need to be spent on regression runs, how much debugging is required, possible performance hits that might result when capturing signals, how much data can be logged, whether changing signals require re-compilation, whether you can you capture full visibility of your design, and finally, how many emulation cycles will be required? 
• When debugging, whether hot swapping between emulation and simulation is useful to release the machine and debug offline. You should also consider whether you can easily force and/or release signals.
• How many design changes and adaptations you will be required to do—if any—to enable the original design run on your chosen platform.
• What tools you have for debug already, and how emulation performance will be affected—if at all—when running with signals. Factor in whether you can you perform debugging on the fly.  
• What tools you have to track the project and whether automation capabilities will help and are available.
• Whether or not you will need to save a design state and restore it multiple times.
• You would probably want to generate massive amount of meaningful random tests for your emulation or FPGA platform. Here’s a link to a previous article I wrote on this topic that explains how to do that.  

For further read, I would recommend two blog posts that do a good job of capturing the user experience for emulation and FPGA-based prototyping and an interview touching the X1 prototype system.

To sum up:

In this article, I’ve offered an overview of the available emulation and prototype architectures. We looked at what’s important when considering whether to use an emulation or a prototyping system. I would love to hear what users have to say, so if you are one, or if you have any questions, please drop me a note below.

And I wish you successful bug hunting!