Last year Cadence introduced the System Development Suite, a set of four connected hardware/software co-development platforms. Today (May 15, 2012) Cadence is announcing a new release of the System Development Suite that is highlighted by a new verification use model called in-circuit acceleration. Here's a brief look at this new technology, which combines some of the best attributes of simulation acceleration and in-circuit emulation.
In-circuit acceleration is available now based on the Palladium XP Verification Computing Platform and the Incisive Verification Platform, two key elements of the System Development Suite. (The suite also includes virtual prototyping and rapid FPGA prototyping, both of which have been improved in the new release. Moreover, Cadence today is announcing acceleration and emulation support for some of its verification IP).
The Palladium XP has supported both simulation acceleration and in-circuit emulation since its 2010 introduction. While they're closely related, acceleration and emulation are two different environments with different models and capabilities. Here's a quick overview of each:
In theory you would run acceleration first, and then move everything into hardware and run emulation with real-world hardware from there on. In practice there's some back-and-forth between acceleration and emulation modes - for example, if you find a bug during emulation, you may need to go back to simulation acceleration to analyze it.
This back-and-forth movement is not easy. As shown in the diagram to the right, acceleration and emulation use different types of models, ranging from transaction-level models with simulation acceleration to real hardware for emulation. Time-consuming re-modeling may be necessary to move back and forth between environments. Further, you may need to reproduce a bug found in one environment when you turn to another.
The Best of Both Worlds
What if acceleration and in-circuit emulation could be brought into a single verification environment, one that preserves the best of both? That's the idea behind in-circuit acceleration. According to Frank Schirrmeister, group director of product marketing for the Cadence System and Software Realization Group, "in-circuit acceleration combines the best of both worlds by bringing you the speed of in-circuit emulation and real-world connectivity together with a very advanced debug analysis capability."
So what runs where? According to Schirrmeister, you have the flexibility to choose where to put the components. Some teams might run analysis and debug on the host workstation, using it only as needed to "snoop" into the acceleration domain for root cause analysis, and run everything else in hardware. Others might run a processor model or perhaps even the testbench on the host, although this will involve a performance/accuracy tradeoff. The point is that you can determine which portions of the design and the verification environment are running in acceleration or emulation at any given time.
There are some interesting consequences to this flexibility. One is that you don't need to provide all the components of the design separately in the acceleration and emulation environments. If you're using a hardware model, you don't have to re-model it in SystemC or RTL in order to analyze a bug. Secondly, if you find a bug during in-circuit emulation that needs further analysis, you don't have to reproduce it in acceleration. Third, you can now access capabilities of RTL simulation - including advanced checking, monitors, assertions, and debugging - while running with the speed and using the real-world connectivity of in-circuit emulation.
In-circuit acceleration doesn't mean that simulation acceleration and in-circuit emulation go away. "There is a clear need for simulation acceleration when a majority of the testbench is on the host, and there is a clear need for in-circuit emulation when you're executing the design with real world application loads," Schirrmeister said. "In-circuit acceleration really augments these technologies with the additional ability to split your design in a very smart way."
The technology behind in-circuit acceleration includes the ability to split the design into acceleration and emulation clocking "domains," allow signals to cross those domains, bind models at various abstraction levels to the domains, add instrumentation and analysis for system-level verification, and hot-swap models in Palladium XP with Incisive simulation. No Palladium hardware changes are needed.
A Broader Vision
There's a broader vision behind in-circuit acceleration. When the System Development Suite was announced last year, the close connections between the development platforms were perhaps its greatest differentiator. For example, the Virtual System Platform can run Incisive RTL models, and the Rapid Prototyping Platform uses the same front end as Palladium XP. But Cadence wants to go much further and develop a single, heterogeneous development solution with different engines, as depicted below.
So what are those improvements to individual platforms? In brief:
Finally, accelerated VIP (AVIP) is now part of the Cadence Verification IP Catalog. This opens a new frontier for VIP by providing typical speedups in the 100X to 1000X range. And, yes, it works with in-circuit acceleration as well. For more information on AVIP, see Pete Heller's Functional Verification blog post.
Further information about the new System Development Suite release is located here.