• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Blogs
  2. Breakfast Bytes
  3. Protium and Palladium 1st=
Paul McLellan
Paul McLellan

Community Member

Blog Activity
Options
  • Subscribe by email
  • More
  • Cancel
Protium
Palladium
embedded software
Emulation

Protium and Palladium 1st=

6 Jan 2020 • 5 minute read

 breakfast bytes logo We just finished 2019, of course, so it is time for annual "Best of 2019" lists. Over at John Cooley's DeepChip there was a tie at #1...between the Protium X1 platform and the Palladium Z1 platform.

I said that the winners were Protium X1 and Palladium Z1, but actually we only announced Protium X1 a couple of months before DAC. Technically it is "the crazy fast Palladium compiles for Protium" that is #1a on the best-of list, although many of the quoted users talk about the whole hardware/software system.

  I called John up last weekend to get a little more color. He told me that he was totally blind-sided by the result. Actually he added rather more color than I can use in a blog post! Some of his long-time readers harassed him about it since the fast compile of Protium ended up being #1, but it didn't even occur in the top 10 on his annual Cheesy Must-See List (which, if you attend DAC, you should totally read beforehand...and probably even if you don't attend).

John had a nice analogy about Protium's fast compile:

People use Palladium right off, for hardware debug. But software guys want something faster, but historically the compile time is the big challenge. It can literally take weeks. Protium has this unfair backdoor. It's like having a VIP pass at Disneyland. You can wait in line for two, three hours. Or, with your unfair VIP pass, you can skip the line. This is the FPGA prototyping equivalent of a VIP pass. If it runs in Palladium, you can skip the line and it will run in Protium immediately without waiting.

Palladium

 Palladium and Protium have been designed from the start to operate together. During the development of a block on an SoC, or the whole SoC, or a whole system of interconnected SoCs, the RTL changes, obviously. I'm going to assume we are talking about an SoC here, just to keep this post simple. During development,  the RTL goes from not-written-yet, to unstable, to stable enough to let the software developers run their software on it.

Palladium is designed to be most useful when the design is not yet stable, and the focus is on debugging the SoC RTL, in effect debugging the hardware with all the usual verification methodologies such as UVM. Naturally, simulation and formal verification can also be used to complement emulation, but the focus of this post is on emulation. Palladium is obviously a fast emulation box, designed to reside in the data center (17" rack form-factor) and other features to make physical access unnecessary. But an important aspect is the very fast compilation time. Since emulation is used when the RTL is not completely stable, getting changes into the emulator quickly is paramount.

For details on Palladium Z1, see my post Palladium Z1, an Enterprise Server Farm in a Rack. If you don't have enough demand to justify purchasing your own Palladium Z1, Cadence also makes it available through Cadence Cloud—see my post Palladium Cloud.

Protium

 Protium has been designed to be more useful for software development and debugging, once the design is fairly stable. The focus is on running the software load very fast, with clean interfaces to software debuggers. You load up the design perhaps once every few days, and then run lots of software. When you are ready, you take the next RTL drop and load that up, and run all the software again. You can do hardware debug in Protium, it is just that the cycle to find an error, fix the RTL, get the design into Protium, and run the software again is slower than with Palladium.

Protium X1 is also designed to be housed in the data center, scalable all the way from a single rack containing a single Protium blade, up to 32 racks, each containing eight Protium blades. Each blade contains six FPGAs, and the system has been designed so that it can be shared at the granularity of a single FPGA. For details, see my post Protium X1: FPGA Prototyping for the Enterprise.

When I said that Protium was designed to be used with Palladium, I didn't just mean that they can live in the same data center. The Protium compiler uses the same front-end as the Palladium compiler. It also uses the same SpeedBridge interfaces, which are ways to connect the emulation or prototyping to real hardware interfaces such as PCIe, USB, or Ethernet, and process real-world traffic on emulated or prototyped hardware running the real software binary.

In John's piece, he considers using much of the same compiler, and thus reducing the time required to get a design brought up in Protium, as "cheating":

HOW PROTIUM CHEATS: The one outlier in this table is Protium. It has two different "initial ramp compile times" If you take your RTL straight into Protium, that first initial ramp is 4-6 weeks. But if you port a Palladium design into a Protium, your initial ramp is only 24 hours. This is how FPGA-based Protium cheats!

That initial ramp time of "4-6 weeks" is actually the time for the previous version of Protium (the S1). Scalability for large designs at speed is much higher in X1, so designs have to be cut down less when coming from Palladium. But by DAC only a few lead customers such as NVIDIA had experience with the X1.

Palladium and Protium Together

It is actually appropriate that both Palladium and Protium combined should be recognized, since it is the combination of the two of them that is so powerful. The same input rules, much of the same compiler, the same speedbridges, the ability to use verification environments from Palladium with Protium, and so on. But there are differences. Palladium is easier to bring up but runs slower. But it has complete visibility. Protium is trickier to get working, but when you do it runs really fast. But has limited debug (for hardware) so is most suitable for software debug. The picture sums it all up.

More Details

John Cooley's Deepchip (or click on the image at the top of the post).

John's page specifically about Protium compile being #1a. If you read this page, there are lots of stories from real users. Since they are anonymous, I don't feel comfortable quoting them here. But also note that all the quotes from users are about the Protium S1, the previous generation, not about Protium X1, the current generation announced last May.

John's page specifically about Palladium being #1b. Many of the quotes here are also about the previous version (the Palladium XP), although some are about the Palladium Z1 which has been out since 2015. Some comments are even about older (15 year older!) versions of Palladium. Once you buy a sports car, you keep driving it.

The Palladium Z1 product page. The Protium X1 product page.

 

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