Home > Community > Blogs > Industry Insights > in circuit acceleration a new ic verification use model
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more convenient.

Register | Membership benefits
Get email delivery of the Industry Insights blog (individual posts).


* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

In-Circuit Acceleration – A New IC Verification Use Model

Comments(0)Filed under: Industry Insights, Palladium, SystemC, virtual platforms, verification, Incisive, Verification IP, VIP, acceleration, emulator, multi-core, debugging, ICE, in-circuit emulation, System Development Suite, FPGA prototyping, Virtual System Platform, Verification Computing Platform, Palladium XP, RTL simulation, IC verification, software deveopment, AVIP, development platform, rapid prototoyping, in-circuit acceleration, accelerated VIP, virtuaul prototypes, simulation acceleration

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:

  • With simulation acceleration, the design typically runs on the hardware while the testbench and the debugging run on a workstation. Acceleration speeds up an existing simulator such as Incisive Enterprise Simulator, and provides all of the advantages of RTL simulation, including constrained-random test generation, metric-driven verification, and in-depth debugging. Downside: it's not as fast as in-circuit emulation.
  • With in-circuit emulation, the entire design and verification environment is generally running in hardware. This includes both the hardware in the emulation "box" as well as real-world hardware hooked up with rate adapters such as the Cadence SpeedBridge Adapters. Speeds range up to 4 MHz, fast enough to run real applications. Downside: large amounts of debug data can be generated in emulation, and it may be necessary to return to simulation acceleration to do root-cause analysis.

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:

  • Virtual System Platform has an open processor abstraction API layer that eases multi-core software debugging
  • Incisive offers 10X faster low-power elaboration and early access to black-boxing to speed simulation turnaround time
  • In addition to in-circuit acceleration, Palladium XP offers enhanced Common Power Format (CPF) acceleration support, and dynamic power analysis in acceleration mode
  • Rapid Prototyping Platform has capabilities that further reduce the bring-up time for FPGA prototypes

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.

Richard Goering



Leave a Comment

E-mail (will not be published)
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.