Mellanox: Using Palladium ICA Mode

At CDNLive Israel, Yaron Netanel of Mellanox talked about his experience with Palladium ICA mode. ICA stands for in-circuit acceleration.

One basic way of using Palladium is in-circuit emulation or ICE. In this method, the DUT is modeled on the Palladium emulator, and it is connected to real hardware via one or more SpeedBridge interfaces. There are several pluses to this approach, in particular that the real hardware behaves accurately without a huge investment in modeling. However, it isn’t ideal for remote access where systems may need to be rebooted. However, It is a way of working that will never go away, since eventually you will always want to run the DUT in the most accurate environment that you can.

Then there was simulation acceleration mode, where the DUT runs on the Palladium emulator, as always, and the testbench runs on the host. Note that the software here is the testbench, not the software load that will eventually run on the DUT silicon.

Both of these approaches suffer from some restrictions. Yaron jokingly pointed out that you always have everything you need, right? For the ICE approach, of course:

• You have all the SpeedBridges interfaces you need
• You have an infinite amount of any hardware that you need, plus all the cables
• You don’t mind buying and maintaining all that hardware
• You don’t need any software capabilities like assertions, $display

Or for the simulation acceleration approach:

• You have mature virtual transactors for all the interfaces you need
• They can all connect to synthetic as well as real-world traffic
• They all support wire-speed performance
• You have all the licenses you need, and all the hosts that you need

Or, just maybe, some of that is not true!

This is where the hybrid approach called in-circuit acceleration or ICA comes in. It combines both approaches at the same time with both hardware and software targets.

This flexibility gives several advantages, in that it is not a requirement to model everything in both places. If you’re using a hardware model, you don’t have to re-model it in RTL in order to analyze a bug. But, if you find a bug during in-circuit emulation that needs further analysis, you don’t have to reproduce it in acceleration. Further, you can access all the features of RTL simulation for advanced debugging with close to the speed of in-circuit emulation.

The table below summarizes the differences between the three different methodologies.

One challenge is synchronizing across the whole emulation environment. Running virtual software targets requires the clock to stop for hardware/software synchronization. There are two problems with this. One is just the reduced emulation speed. But the more serious one is that some targets, such as PCI Express (PCIe), do not work if the clock stops. If you use Palladium’s “dynamic targets mode”, then the target can run without clock stop but it also kills the simulation and virtual targets won’t work. The solution is to use GFIFO and SFIFO to reduce the impact on software target’s performance.

In summary, ICA gives you the best of both worlds:

• Connection to hardware targets via speedbridges
• Connection to software and software targets
• DUT can run at high speed
• Dynamic hardware targets are supported
• A single IXCOM flow is used for the whole system
• More flexibility, can satisfy more needs

– See more at: https://community.cadence.com/cadence_blogs_8/b/breakfast-bytes/archive/2016/09/23/mellanox-debugging-complex-flows-using-indago#sthash.UMllkJiD.dpuf