Cadence® system design and verification solutions, integrated under our System Development Suite, provide the simulation, acceleration, emulation, and management capabilities.
System Development Suite Related Products A-Z
Cadence® digital design and signoff solutions provide a fast path to design closure and better predictability, helping you meet your power, performance, and area (PPA) targets.
Full-Flow Digital Solution Related Products A-Z
Cadence® custom, analog, and RF design solutions can help you save time by automating many routine tasks, from block-level and mixed-signal simulation to routing and library characterization.
Overview Related Products A-Z
Driving efficiency and accuracy in advanced packaging, system planning, and multi-fabric interoperability, Cadence® package implementation products deliver the automation and accuracy.
Cadence® PCB design solutions enable shorter, more predictable design cycles with greater integration of component design and system-level simulation for a constraint-driven flow.
An open IP platform for you to customize your app-driven SoC design.
Comprehensive solutions and methodologies.
Helping you meet your broader business goals.
A global customer support infrastructure with around-the-clock help.
24/7 Support - Cadence Online Support
Locate the latest software updates, service request, technical documentation, solutions and more in your personalized environment.
Cadence offers various software services for download. This page describes our offerings, including the Allegro FREE Physical Viewer.
Get the most out of your investment in Cadence technologies through a wide range of training offerings.
This course combines our Allegro PCB Editor Basic Techniques, followed by Allegro PCB Editor Intermediate Techniques.
Virtuoso Analog Design Environment Verifier 16.7
Learn learn to perform requirements-driven analog verification using the Virtuoso ADE Verifier tool.
Exchange ideas, news, technical information, and best practices.
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.
It's not all about the technlogy. Here we exchange ideas on the Cadence Academic Network and other subjects of general interest.
Cadence is a leading provider of system design tools, software, IP, and services.
Get email delivery of the Cadence blog featured here
When Intel engineers were asked to verify one of the company's largest Many Integrated Core (MIC) designs, they faced a quandary. On one hand, they wanted the visibility and debug features provided by their Specman e language simulation environment. But they also wanted the much faster speeds provided by emulation. A recorded presentation at the Cadence web site shows how they were able to accomplish both, using essentially the same code base.
The presentation, titled "Common Specman Based Simulation and Emulation Solution," was one of 30-plus customer and partner presentations at the EDA360 Theater in the Cadence booth at the Design Automation Conference (DAC 2012). Audio recordings and slides from most of the presentations are located here, and a previous blog post lists the titles of the available presentations.
Blake French, MIC testbench architect at Intel, began the presentation by nothing that the Specman simulation environment provides strong visibility and debug features. But due to the size of the MIC design, simulation times were very long. Emulation is very fast but debugging is difficult. "We came to the conclusion that we wanted the best of both worlds," he said. "We wanted all the visibility and debug capability of our simulation based environment, yet we wanted the run times of our emulation environment. So our goal was to do that using the same source code."
Given that the simulation environment was primarily written in e, and emulation used C/C++ or Perl, this was a challenging task. Intel engineers wanted all the visibility, debugging and coverage features provided by simulation. They decided, however, that they would tolerate a 50% slowdown in the emulation platform if they could obtain all the visibility they wanted. After all, simulation runs in the Hz range, and emulation is many times faster in the KHz range.
French provided a very detailed description of how Intel transitioned a simulation-based environment to a verification environment that also runs in emulation hardware. The main point is that temporal activity needs to be stripped from the testbench and moved to the hardware itself. This is because temporal "while" loops - which may be in the hundreds or thousands in a testbench - generate a great deal of activity that the kernel is going to have to manage in software. Thus, if temporal statements are left in a software testbench, emulation will be slowed dramatically.
It's a simple concept but the implementation took a number of steps, as French described along with coding examples. Ultimately, a packet monitor handles procedural activities, and there are no temporal statements remaining in the testbench. Module binding is used to sample the hardware, and a dynamic event linker routes information to the testbench. Intel used the Direct Programming Interface (DPI), which is supported by most EDA vendors, to communicate between the hardware and the device under test (DUT).
But even though Intel was able to transition most of its testbench code to an acceleration compliant environment, it still wasn't quite good enough at first. With extensive profiling, engineers found that 15-20% of the testbench time was spent in the Specman kernel. That's because the kernel was still trying to schedule activity as if temporal constructs were present. Engineers were able to eliminate this overhead so that during emulation, the kernel is called for garbage collection only.
French shared some performance data at the end of the presentation. He noted that "emulation live" performance (where hardware and simulation are running in lockstep) ranges up to 60 KHz, while "emulation post process" performance (hardware running alone) ranges up to 120 KHz. "The bottom line is that we were successful in combining our e based simulation environment in a fashion where it can be used for both emulation and simulation, and for the most part we're using the same code base," he concluded.
If you'd like to see the details of how this transition was accomplished, you can "attend" the half-hour audio presentation here. There are some good questions at the end, so I suggest staying for the whole presentation.