WP_Term Object
(
    [term_id] => 15
    [name] => Cadence
    [slug] => cadence
    [term_group] => 0
    [term_taxonomy_id] => 15
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 598
    [filter] => raw
    [cat_ID] => 15
    [category_count] => 598
    [category_description] => 
    [cat_name] => Cadence
    [category_nicename] => cadence
    [category_parent] => 157
)
            
14173 SemiWiki Banner 800x1001
WP_Term Object
(
    [term_id] => 15
    [name] => Cadence
    [slug] => cadence
    [term_group] => 0
    [term_taxonomy_id] => 15
    [taxonomy] => category
    [description] => 
    [parent] => 157
    [count] => 598
    [filter] => raw
    [cat_ID] => 15
    [category_count] => 598
    [category_description] => 
    [cat_name] => Cadence
    [category_nicename] => cadence
    [category_parent] => 157
)

Palladium’s Little Brother Protium

Palladium’s Little Brother Protium
by Paul McLellan on 07-17-2014 at 8:00 am

 Today, Cadence announced Protium, a new FPGA prototyping platform for software development. During development of an SoC, the most appropriate methodology changes. In the early days, developing RTL, the primary tool is simulation. Then, as the blocks get bigger or as the whole chip starts to come together, typically simulation runs out of steam. Time to switch to emulation using Palladium. Then, once the RTL is pretty much stable, it becomes attractive to use FPGA prototyping, which is where Protium comes in (I guess the name is a hybrid of prototype and palladium). Protium can then be used for software development and debugging. Protium is not really intended for hardware debugging. If a hardware issue is detected then it is best to fall back to either emulation or simulation where the debug tools are much more powerful.


One problem with FPGA prototyping is that bring up can be a challenge, typically measured in months. This severely detracts from the usefulness of the FPGA prototype since software development can’t really get going during this period. With Protium, Cadence have put a lot of effort into making this process much smoother, bringing what used to be a 3 month process down to 2 weeks. They actually use the Palladium front-end integrated compile engine (ICE). Halfway through the compilation there are then two possible routes to take the design: into Palladium to verify the FPGA functionality, or into Xilinx’s compilation flow to actually create the FPGA bitstreams to program Protium.


Protium comes in various configurations. It is based on Xilinx Virtex-7 2000T FPGAs. There are two baseboard options, either 2 or 4 FPGAs. One or two boards can be used per chassis giving the following configurations:

  • 2 FPGAs: 25M gates (single board)
  • 4 FPGAs: 50M gates (single board)
  • 6 FPGAs: 75M gates (dual board)
  • 8 FPGAs: 100M gates (dual board)

There are two 150pin daughtercard connectors per FPGA, up to 8 per board, with 1.8V signalling at speeds of up to 1.25Gbps. Bulk memory daughtercards can be added for DDRx, SRAM, flash, SD card etc, or custom memory cards. There is also SpeedBridge product interface capability, that handles the speed mismatch to buses such as PCI.

This fully automatic flow gives a prototype that runs at 3-10MHz. With manual guidance and adding memory cards (instead of implementing the memory in the FPGAs themselves) the performance is in the 10-30MHz range. And by doing a lot more manual work, guiding the FPGA partitioning and synthesis, mapping the clock directly and so on, the performance can be over 100MHz, although this is a slower and more manpower intensive process, roughly equivalent to how FPGA prototyping had to be done in the past.

So Protium is 4X faster bringup than the first generation FPGA prototype system, has 4 times the capacity and 3 times the memory. Compile times using Palladium/Xilinx flow is 5X faster.


Cadence announced a second addition to the system development suite, to address low power verification of power-shut-off domains, voltage scaling domains and so on. This allows verification to be done using either simulation or emulation using Palladium. There is full support for power policy being expressed either in Si2 CPF or IEEE 1801 (UPF). Simulation can be used with a full 0/1/X/Z signal model to check for corruption, and check isolation and retention. Palladium can be used for system validation and analysis, measuring average and peak power in the context of running a software load.


More articles by Paul McLellan…

Share this post via:

Comments

There are no comments yet.

You must register or log in to view/post comments.