I’ve always wanted to use the British English word “bespoke” in a blog and Cadence Group Director of Product Marketing for the System Development Suite Frank Schirrmeister has now given me that opportunity with his EDPS forecast on system-level EDA circa 2015. According to Wikipedia, “bespoke” means “an item custom-made to the buyer’s specification (personalized or tailored)” and that’s pretty much the situation for system-level EDA. The software enablement platform you use to develop system software early in a design depends on your particular needs. As Schirrmeister said, “No one size fits all.”
Here’s a graphic from Schirrmeister’s presentation depicting the six choices you have when selecting a platform for developing system software:
The good news is that you have several such platform types to choose from. That’s also the bad news. You must select one or more platforms depending on how far along the SoC design is, how much money you can afford to spend on a development platform per developer and how many developers you have, how much time you have to develop the software before the scheduled first product release (is there ever enough time?), etc.
A very familiar platform appears on the left of the graphic—the SDK or Software Development Kit. These kits are usually available for popular software operating platforms such as the Apple iPhone and iPad and Google’s Android. Software Development Kits tend to run on PCs and servers and they get their speed by ignoring a lot of the hardware details, insulated by API calls. If you are using an existing hardware platform such as an Apple iPhone, an Android-based mobile phone, or an Apple iOS- or Android-based tablet, then it’s likely you have access to an SDK. Otherwise, you probably do not. Target platforms usually need a critical mass of developers or at least an expected critical mass of developers before someone will go to the trouble and expense of developing a standard SDK.
You can get nearly the same sort of terrific performance from a virtual platform using behavioral models for large blocks of hardware even before the RTL for that hardware is written. This high level of hardware abstraction delivers the good execution speed and the fact that the virtual platform is entirely based on software makes it possible to ship such a platform anywhere in the world in seconds over the Internet. Try doing that with hardware. An example of such a platform is the recently introduced Xilinx Zynq-7000 EPP Extensible Virtual Platform, based on Cadence Virtual System Platform technology (see “Want to start writing code for the two ARM Cortex-A9 processors on the Xilinx Zynq-7000 EPP right now? Virtual Platform makes it possible”).
If you want super-accurate hardware simulation then you want RTL simulation, which should be familiar to every seasoned SoC Realization team. However, the accuracy comes at the price of execution speed and the resulting SoC simulation is likely to be slow—perhaps no more than a few thousand simulated clock cycles per second. When you’re simulating multicore processor SoCs running at hundreds of MHz, your simulations are likely to be slow—but very accurate.
You can boost RTL simulation with acceleration emulation, which can take the form of an accelerator box such as the Cadence Palladium series of accelerators/emulators. These accelerators throw specialized hardware at the RTL to achieve two to six orders-of-magnitude speed improvement over straight RTL simulation and can get even complex designs to run at MHz speeds on the accelerator box.
Many companies have long used custom FPGA prototypes to model SoC designs before tapeout. You can now get standardized FPGA boards that “plug” into existing verification environments, which saves months of project time over the development of custom FPGA designs. One such example is the Cadence Rapid Prototyping Platform.
Once you have silicon, you can use it to develop a full-speed development platform for software. This is the sixth alternative shown on the right in the above graphic. It’s the most accurate approach—nothing’s more accurate than the actual silicon—however this approach postpones much of the software development to the end of a project, which is often not feasible for the initial release of a product.