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
Since I've complained in the past that electronic system level (ESL) means little more than "anything above RTL," anything that can provide more insight into just what is above RTL is welcome. I have found some clarification through five levels of modeling abstraction described in TLM-Driven Design and Verification Methodology, a Cadence-published book I have blogged about in the past. (The latest news is that the book is now available through Amazon).
So far as I can tell, the five levels of abstraction listed here pretty much cover the hardware and system design space from Matlab to RTL, emcompassing most of what people mean by "ESL." Since the fifth level is RTL, which is well understood, I'll just focus on the top four here. I should note that these levels are mostly orthogonal to SystemC transaction-level modeling (TLM) coding styles such as loosely timed (LT), approximately timed (AT), and cycle accurate (CA). In this scheme RTL is the first completely cycle-accurate modeling level.
1. Pure Functional Level
At the highest level of abstraction, the design goal is to choose an algorithm that meets all functional requirements, and the verification goal is to ensure functionality is correct. This level is typically used by systems architects and algorithm developers using C/C++ models or tools like Matlab. Models are untimed computational blocks. These models are not useful for hardware designers, but some code is potentially reusable at the next level.
2. Functional Virtual Prototype (FVP) Ready
Virtual prototyping allows early software development using TLM models. The SystemC TLM 2.0 standard is increasingly applied at this level. Computational blocks remain untimed, but it may be necessary to define some timing at interfaces. Models expose such features as the hardware/software boundary and concurrency.
3. HLS-Ready TLM Level
This is the highest point of abstraction that allows entry into high-level synthesis (HLS). Obviously, models need to be synthesizable, and should be optimized for quality of synthesis results (rather than simulation performance). While computational blocks may remain untimed, communication blocks also need to be modeled, and this typically involves LT or AT coding styles. Specific requirements at this level vary from one synthesis tool to another.
4. HLS-Ready Signal Level
At this level, the external transaction-level interfaces of a block are refined to the signal level. Protocols are cycle-accurate but the computational blocks are unchanged. This refinement can be accomplished with synthesizable communication design IP.
The Next Challenge
With these modeling abstraction levels in view, we have a clearer map. Now we need to connect the dots. The next challenge is to avoid having to re-write and re-verify models at every level of abstraction. For this reason, the TLM methodology outlined in the book uses a single verification environment to span multiple levels of abstraction. This methodology is reflected in the "refine and reuse" approach, described in my earlier blog, that Cadence and TSMC used to build the verification portion of ESL Reference Flow 11.
Much more remains to be done. One current problem is that SystemC TLM 2.0 is not synthesizable. However, we're not going to have a coherent ESL (or TLM or whatever term you choose) methodology if we don't clarify what we're talking about.
Gary -- that's very true. We are still a long ways from real system-level design, especially when you consider all the areas EDA has never addressed. And the list of considerations goes on and on. With the iPhone 4, somebody should have modeled not only the packaging and the antenna, but the hand that holds the device.
We keep forgetting that this doesn't really cover system level design. There are always mechanical considerations to deal with and often other areas, for instance fluids, bio, chemical and optical, that need to be designed before the entire system is completed.
Richard, I expect you'll get to this eventually (unless you already have and I've just missed it) but I hope you follow this post up with a view of the top-down validation/verification flow from the same book (also mentioned in bailey's and grant martin's "ESL Models and their Applications"). I think that's the point where the verification guys can start getting excited about the innovation in esl and how it can being meaningfully applied in functional verification.