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
By supporting SystemC model interoperability, the Transaction Level Modeling (TLM-2.0) standard from the Open SystemC Initiative (OSCI) was a watershed event in the development of ESL flows. But it was not the final answer. At a recent virtual platform panel, participants noted that TLM-2.0 is a good start, but much more remains to be done. For example, panelists talked about debug tool interoperability, configuration and control, model interfaces, and defining “best practices” for model development.
To discover what more needs to be done with respect to model interoperability, I recently sat down with some of Cadence’s SystemC experts. We talked about what TLM-2.0 has accomplished, and what still remains to be done.
First, some background. In 2005, OSCI introduced TLM-1.0, which defined a standard set of APIs for transaction-level communications. This standard, however, didn’t define the content of those communications. TLM-2.0 defines the content of transactions with a “generic payload” that describes the necessary data structures. TLM-2.0 was announced in July 2008.
“TLM-2.0 has done a pretty good job of addressing interoperability, at least for memory-mapped busses,” said Neeti Bhatnagar, engineering director at Cadence. She noted that TLM-2.0 processor IP is beginning to appear, although there’s still a lack of other types of IP. EDA tools are supporting TLM-2.0 as well. For example, Cadence in May announced an expanded verification solution that natively recognizes TLM-2.0 constructs in order to automate debug and analysis without requiring any model instrumentation.
Neeti said there are currently two main types of users for TLM-2.0. Most commonly, this standard is used for virtual platform development, where designers use the “loosely timed” (LT) TLMs defined by the standard. The other use is architectural performance analysis, which generally involves more accurate “approximately timed” (AT) models.
Now that TLM 2.0 is available, we are beginning to see areas where additional standards or interoperability guidelines may be needed. For example, some users are interested in cycle accurate modeling using TLM 2.0.
“TLM-2.0 defines cycle accurate but doesn’t say too much more about it,” noted George Frazier, senior member of consulting staff. Neeti said there seems to be some interest right now in using cycle-accurate models with TLM-2.0, and some users are trying to figure out how to do so for more accurate performance analysis, but it is really loosely timed modeling that has seen the most proliferation and interest.
Neeti also observed that although processor models are becoming available in TLM-2.0 wrappers, each processor model has its own software debugger. There is no standard debug API for processor models, and processor debug tools are not interoperable in a standard way.
TLM 2.0 allows temporal decoupling where a process can run ahead of the simulator to provide a significant increase in simulation performance. When users plug together models from different vendors to assemble virtual platforms, it could be challenging to fine-tune temporal decoupling across all the processes in the system to arrive at the necessary accuracy-versus-performance tradeoff. “Things could get tricky because models are not running in lockstep,” said Bishnupriya Bhattacharya, senior member of consulting staff.
CCI provides the “next step”
In February 2009, OSCI introduced the Configuration, Control and Inspection (CCI) working group. This group seeks to develop “instrumentation standards” for models from different providers, making it possible to configure and control models and simplifying system-level debug and analysis. According to the OSCI announcement, the group is considering configuration parameters, register characteristics, power and performance data probing, command interfaces, save/restore, and other issues related to configuration, control and debug. (Cadence already supports save/restore for SystemC as announced in May as a part of the expanded verification solution).
Bishnupriya put it this way. “TLM-2.0 is about model-to-model interoperability. CCI is trying to accomplish the next step, which is model-to-tool interoperability. One of the first few areas it’s looking into is how you can make parameters part of the model definition, as opposed to being tool specific.”
The CCI working group is still gathering requirements, and the full scope of what it will consider is not yet determined. There has been little coverage of CCI in the trade press. But anyone interested in ESL flows should keep an eye on this evolving effort. It may help define the next level of SystemC model interoperability.