In the DC Comics world, the "Dynamic Duo" are Batman and Robin. In the Cadence product world, they are the Palladium and Protium platforms. Or Palladium Z1 and Protium X1 to give their last names, too. The Palladium Z1 provides emulation, and Protium X1 provides FPGA prototyping. But like Batman and Robin, Palladium and Protium work closely together to fight crime in Gotham City and...no, wait, they work closely together to run large software loads on your hardware before you tape out the design, and release the software.

The hardware inside Palladium and Protium is very different. Palladium is based on a custom-designed SoC. Protium is based on Xilinx FPGAs. Both are designed to be rack-mounted within a data center, and accessed remotely. Previous models of both products were in a different physical configuration, accessed more directly by the users. By making the Dynamic Duo rack-mounted, shareable, and remotely accessed, they are both truly enterprise-level products.

Another thing that they have in common is a compiler that is largely common until the back-end. This means that if a design runs in Palladium then it runs unchanged in Protium. The compiler is also very fast. For a modest design of 200M gates, it compiles for Palladium in under an hour. It takes longer for Protium since there is an FPGA place and route involved, too. From 2-20B gates, it is obviously slower, but still a lot faster than getting a design into an emulator used to be.

One challenge with emulation and FPGA prototyping is how you interface the SoC being exercised to the outside world.  You would like to be able to exchange Ethernet packets, or connect a USB device, or something similar with other types of interfaces. This is another area where Palladium and Protium have something in common: the SpeedBridge adapter. There are SpeedBridge adapters available for a wide range of communication technologies such as Ethernet, PCIe, SATA, SCSI, USB, video, audio, and more. With a SpeedBridge adapter, you can exercise your SoC with real-world traffic, and ensure that the drivers all function correctly handling data from real-world hardware. For example, the diagram below shows a test setup for a 5G mobile design.

If you use Protium in a push-button manner, just compiling the code that ran in Palladium, then it will run the same design 3-5X times as fast. A small design that fits inside a single FPGA can run at 100MHz. A billion-gate monster design spread across multiple racks can run at 5MHz. You can often get further speedup in Protium by investing a little time to black-box certain blocks, and perhaps exert some influence on how a large design is partitioned across FPGAs, boards, and racks.

There's a sense in which it is up to you how you use Palladium and Protium if you have access to both. I'm assuming that you are designing a large SoC which also has a significant software load, probably involving an operating system such as Android or Green Hills' Integrity. The big picture strategy is to use Palladium to debug the RTL and Protium to debug the software. The tradeoff here is that Protium runs a lot faster than Palladium, but the compile process is slower.

As a result of this difference in compile speed, it makes sense to use Palladium early in the design cycle when the RTL is not stable, since a new RTL drop can be compiled and tested quickly. It makes little sense to involve software development until the RTL is close to stable. It is very inefficient and frustrating for the software developers when every "software" bug might actually be a bug in the RTL I went through something similar decades ago working with an unreliable compiler. Whenever I ran into a weird bug, I just assumed it was not me, it must be the compiler. Occasionally it was, but mostly it was just me writing bad code. But the effect of an unreliable compiler was to significantly slow down the speed at which I could debug my own code.

Later in the design cycle, when the RTL is mostly stable apart from the occasional corner case, then a good plan is to do regular RTL drops and compile them for Protium. The software development team can then use Protium to test and debug their software. It runs fast. Almost certainly not as fast as the real chip, but even when the real chip is eventually available, the full observability of the SoC internals means that it is often a more attractive software debug environment for subtle errors on the hardware/software interface.

Here is NVIDIA's Narendra Konda, Director of NVIDIA's hardware lab, which you get to see in the video below. Here's the important quote for the topic of this blog post:

Palladium emulation technology provides a perfect debug platform, while the Protium FPGA technology provides the speed and throughput necessary for our software team to execute millions of lines of software stack.

Today's Trivia Question

I jokingly said at the start of this post that Palladium's last name was Z1. Everyone knows that Batman's real name is Bruce Wayne. But what about the other half of the Dynamic Duo. What's Robin's real name? I thought I knew the answer from when I read some of the comics when I was a kid, but looking at Wikipedia, I find the answer is far more complex than...well, a billion gate design.

Robin's real name originally (1940) was Dick Grayson, the answer I already knew. But Dick Grayson became Nightwing, and the new Robin's real name (1983) was Jason Todd. But he got killed off (readers didn't like him and in a poll voted for him to die). The third Robin was Tim Drake (1983). But he eventually resigns (who knew you could resign as a superhero?) and the new Robin is his girlfriend Stephanie Brown. But she doesn't last long in the role, and Damian Wayne, Bruce Wayne's son, became Robin.

Each one of these names has a massive Wikipedia page that tells you far more than you could possibly want to know. I think that the only conclusion that you can draw from this is that there are way too many comic book nerds who are also updating pages of Wikipedia. But you already knew that.

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