The Benefits of a Common Methodology for Emulation and Prototyping

Recently Cadence presented a webinar Benefits of A Common Methodology for Emulation And Prototyping. The two presenters were Michael Young, who is the product manager for the Palladium emulation product line, and Juergen Jaeger, who is the product manager for the Protium product line.

They started by pointing out that software dominates development cost and schedules. You can't sell your silicon without the software, and as a result, delay to software delivery delays time to revenue, so starting software development as soon as possible is crucial. As a thought experiment, perhaps using emulation and prototyping reduces time for software integration from 75 days to 15 days. If the annual revenue for the product is $100M then two months is $18M. "You can buy a lot of emulation and prototyping for that".

So if you have access to both, when should you use Palladium emulation and when should you use Protium prototyping?

Basically, emulation is used to debug your design (chip) and prototyping is used to debug the software. It is not a hard-and-fast split since you can run software on an emulator and can do some debugging on a prototyping system. Emulation has better hardware debug facilities, but prototyping runs the code faster. But Palladium and Protium also have a lot in common, with a common compiler, common debug, and common hardware interfaces (SpeedBridge), accelerated VIP, and more. Protium is 3-5X faster than Palladium at a lower cost per gate.

So the typical way to use the systems is to rebuild the design every night for Palladium when the RTL is not yet stable, whereas with Protium, once the RTL is stable, rebuild once every week or two. The build takes longer (since it involves an FPGA place and route) but it is the highest performance way to run the software until you have silicon (and even actual silicon can be far from ideal as a debug platform).

So you end up with a development cycle like in the above picture, where Palladium is in yellow, Protium is in blue, and both together is blue+yellow = green.

So you need a common methodology to get the best of both worlds, but with an seamless transition between the two worlds. This is why Cadence calls Palladium and Protium together the "dynamic duo".

When you transition from Palladium to Protium, you get to reuse the existing Palladium environment, including clocks, memory models, scripts, AVIPs, SpeedBridge interfaces, and so on. However, you can still easily return to Palladium for detailed debug when hardware issues come to light during software development. There is a common compiler front end so there is no need to learn new tools and flows. There is identical language coverage and even new capabilities and fixes are available simultaneously on both platforms.

Palladium Z2

Let's give Michael the stage for a deeper dive into the capabilities of Palladium Z2.

• High performance emulation
  • Up to 1.5X faster runtime over Z1
  • Up to 3.5X higher host interface bandwidth
• Fastest and predicable compile time, billion gate designs in 10 hours
  • Massive parallelized modular compiler for fast model build
  • Shares the compile technology as Z1
• Best-in-class debug with FullVision 2.0
  • Up to 2X trace debug samples
  • Best-in-class runtime triggers without re-compile
• Scalable capacity
  • 2X over Palladium Z1
  • User granularity: 8 MG to 1152 MG per rack
  • Scalable to 18.4 billion gates
• Enterprise-class emulation
  • Ready for cloud-based users (Cadence also provides Palladium Cloud, which I guess the trendy way to describe would be "emulation as a service")
  • 144 concurrent users per rack
  • 22+ use models
  • Complete virtualization of interfaces
  • Advanced job re-allocation

There are many different use modes for Palladium. The above diagram shows three:

• Simulation acceleration, using it as a faster Xcelium
• Virtual emulation, where the testbench runs on an x86 (typically) server and drives the RTL in the emulator through virtual interfaces
• In-circuit emulation (ICE), where real hardware interfaces such as PCIe or USB (SpeedBridge) are used

Debug is easy with Fullvision. You can view any signal without any impact on emulation speed. Deep probes can record up to 80M samples, and if that is not enough you can turn on Infinitrace and then you are just limited to how much diskspace is available. There is save and restore, which can be used to restart an emulation later, or to boot and operating system and then be able to start from there with lots of different test cases. You can also hot swap from Xcelium (simulation) to Palladium (emulation). SDL (state description language) lets you specify multi-level complex trigger conditions and so use design events to detect scenarios. Assertions, code, and functional coverage are scored in Palladium but then can be viewed in software (either Xcelium or vManager).

Protium X2

Juergen pointed out that Cadence is relatively late to prototyping, which is bad because we are late, but good because we starting with a clean slate. Protium S1 (desksite) was introduced in 2017, X1 (enterprise rack) in 2019, and X2 earlier this year.

Prototyping has a reputation for being hard and time-consuming to bring up. But Protium comes up quickly in days not weeks or months, along with all the debug capabilities. Another issue has been mapping memories into FPGAs but we have eliminated that where we map all memories into Protium directly. The same SpeedBridge adapters as work with Palladium also work directly with Protium.

There are lots of features for debug too. It is no longer necessary to compile in probes, any signal can be viewed at any time without recompilation. Memories can are handled specially so can be accessed through the "back door" so they can be loaded or examined without having to go through the design itself.

Of course, standard interfaces (like JTAG) to industry-standard debuggers are all in place. Software engineers don't think in terms of waveforms but in terms of breakpoints, watchpoints, and the like.

Protium supports muti-user functionality. Even the biggest designs tend to start with smaller IP blocks and subsystems. The granularity is a single FPGA giving up to 12 concurrent users per blade. Any combination is possible, such as one user running a large design and several others running smaller blocks. Obviously, you need to have enough capacity in total, but that is the only restriction. You can "clone" a design and run it in multiple FPGAs without recompilation.

Shared Solutions

• EDKs and SpeedBridge Adapters
  • Physical connection to real-world interfaces
• Virtual Solutions
  • VirtualBridge, AVIP, Hybrid, Virtual Debug
  • InfiniBand-based link to virtual interfaces
• Memory Model Portfolio (MMP)
  • For all on-chip and off-chip memories
• Job Scheduler and vManager
  • Manages workloads across platforms
• Both Palladium and Protium work with our recently announced Helium Virtual and Hybrid Platform. See my post Announcing Helium, Hybrid and Virtual Platforms with Multiple Gears for details on that.

But not everything is shared:

• Palladium only:
  • Dynamic Power Analysis with Joules
  • Code and functional coverage
• Protium only: native interfaces
  • Highest throughput
  • “breaks” congruency

More Bugs Per Dollar Per Day

Other technologies are available. Palladium and Protium are part of the overall verification solution, and work seamlessly with vManager (verification management), Indago (debug), VIP and System VIP (verification IP), and Perspec (PSS) Portable test and Stimulus Standard).

Using the whole portfolio results in finding more bugs per dollar per day, which is the whole point of verification.

Sign up for Sunday Brunch, the weekly Breakfast Bytes email.