The Palladium Z1 is an enterprise-level emulation system. If you don't already know about it, you can read my post Palladium Z1, an Enterprise Server Farm in a Rack . The Protium platform is an FPGA prototyping system. If you don't know about it, you can read my post Palladium's Little Brother Protium . In some ways, the Palladium and Protium environments are complementary. Emulation is slow compared to an FPGA prototype, but the FPGA prototype lacks the visibility that you can have with emulation, especially if you didn't realize that you needed to monitor a particular signal (because that requires a full recompile to add another probe, about 12 hours for a 65M gate design). So why not use both? Riad Ben Mouhob of Microsemi presented their experience doing just that at CDNLive Silicon Valley. The basic idea is to run on the Protium platform as much as possible for the tasks for which it is applicable, like regressions that do not need debug switched on while executing. This yields higher throughput since it is faster than the Palladium platform. In contrast, the Palladium emulator is a very powerful resource with lots of advanced use models like low power analysis and verification, gate-level acceleration, verification acceleration, and so on, so you want to optimize emulation bandwidth to the most valuable use models and offload the ones that FPGA-based prototyping can address. Here's the basic flow: Starting at the top with the design, you can either go down the left-hand side for the Protium platform, or the right-hand side for the Palladium environment. The basic idea is to run on the Protium platform as much as possible since it is much faster than on the Palladium environment. The Palladium environment is a very powerful resource, but there is never enough emulation available so it has a high opportunity cost. As a result, it should only be used when necessary. When a problem is found, the decision point is in the diamond in the middle. If more probes would help keep the design on the Protium platform, then the design needs to be recompiled. If more probes are not going to help, then the design can be moved into emulation where you have full visibility (but the design does not run as fast as in the Protium environment). One of the keys to making this flow work is that the Protium compilation flow uses about 80% of the Palladium flow. This means that the same design can run on either without modification. Getting a design up and running on a traditional FPGA prototyping platform used to require 3-4 months and extensive alteration to the RTL. It was simply not practical to use until the design was final or very close. There were other issues too, such as the availability (or lack thereof) of daughtercards for interfaces such as PCIe, USB, and DDRx, plus limitations on the number of clocks. The Protium platform fixes those issues: Shares a common front-end flow with the Palladium environment, making build maintenance easier No RTL modifications are required Does not need manual intervention for timing closure like in traditional FPGA prototyping Users can generate as many clocks as they need Large variety of peripherals and memories to connect the design to a realistic environment Can use traditional on-chip debug tools, or port the design back to the Palladium environment Has memory backdoor access compatible with Palladium scripts to dump firmware into memory without having to "run" the design to get the memory load in Below is the actual environment that Microsemi used. Just in case it is not obvious, the Protium and Palladium platforms are in the top center (the Palladium emulator is the tall box, while the Protium platform is to its left with its side off).The green lines show how the Protium system connects, the blue lines how the Palladium environment connects, and orange lines are more than one hop away so that they are the same for both systems. The Palladium environment is also invaluable for performance analysis. It has cycle-accurate design performance that matches post-silicon results. It thus produces accurate performance numbers before tapeout and avoids costly re-spins. The Protium platform is best just for running regressions, with the design moved back to the Palladium environment for detailed RTL analysis of any issues. I should also point out that you can get even more performance out of the Protium system by doing hand optimization in the classic way. Cadence calls this black-boxing. Any block that has been hand-optimized is marked like a don't-touch block in synthesis and doesn't need to be re-mapped. So the user can get higher performance by investing the time and effort, rather than using the automated flow. Riad's final conclusions were that the Protium platform helped to very quickly offload Palladium Z1 usage. Using the Palladium and Protium environments together allowed a very fast bringup, a very efficient SoC debug, and quick firmware development. Next: Perspec Modeling Previous: Omnia Simulation in Tres Partes Divisa Est![]()
![]()
↧