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
ESL and silicon IP are regarded as two different topics, but in reality they are closely intertwined. This occurs in two significant ways. First, the availability and interoperability of transaction-level modeling (TLM) IP will be a crucial enabler of ESL-based flows. Secondly, IP reuse is perhaps the biggest advantage of such flows. While these statements may appear obvious in retrospective, they do raise several interesting questions.
In a Tech Trends article for the Aug. 25 ChipEstimate.com newsletter, I wrote about two ESL-related events at the recent Design Automation Conference (DAC) at which panelists talked a lot about IP modeling. Specifically, they talked about the availability (or lack thereof) of third-party TLM models, the use of SystemC TLM models in virtual platforms, the need for high-level synthesis of TLM-based IP, the not-fully-solved problem of SystemC model interoperability, and what to do about legacy RTL models in virtual platform environments.
Without interoperable, TLM models of silicon IP, it will be difficult to construct virtual platforms, employ high-level synthesis, or move verification to higher levels of abstraction. This gives rise to the first interesting question – who will develop these models?
I think the answer varies. Many large semiconductor companies will internally develop SystemC TLM models of their own IP. But will commercial IP providers offer TLM models? There are a few solutions – for example, ARM offers Fast Models, which are instruction-accurate models that can run in SystemC TLM 2.0 wrappers.
RTL models, however, will be with us for a long, long time, especially for “commodity” IP. Thus, there will be a need for design and verification environments that can handle a mix of TLM and RTL models. Emulation will be helpful because it can accelerate legacy RTL models to acceptable speeds.
A second interesting question: What is IP model “interoperability,” and are we there yet? At a virtual platform panel at the Design Automation Conference, panelists noted that the Open SystemC Initiative (OSCI) TLM 2.0 standard is a good start, but more is needed. For example, debug interoperability is lacking. Standard model interfaces could allow simulations that span abstraction levels, and “best practices” for model development could be helpful.
If we can answer these questions about model availability and interoperability, then we can build TLM-based flows that allow a new level of IP reuse. That’s because TLM-based IP does not lock one into a given micro-architecture. By employing scripts with a high-level synthesis tool such as Cadence C-to-Silicon Compiler, you can reuse the same IP block in a number of different micro-architectures. But now we are running into another interesting question – how will this reuse capability impact the way IP is provided?
We’re at an inflection point. It is time for silicon IP providers to start thinking about what lies beyond RTL.
Some good questions here! Gary asks who owns the RTL synthesized from SystemC provided by an IP vendor. One could ask the same question about who owns the gate-level representation synthesized from an RTL soft core. In either case, it seems to me, the IP vendor would have to be paid for what they provide, be it a SystemC model or a Verilog/VHDL RTL model.
Warren's point about "who pays" is well taken -- if customers aren't willing to pay for TLM-based IP, no one will provide it. However, I think it's too early to conclude that demand won't be there. As for formal verification, Calypto offers sequential equivalence checking that works with HLS tools including C-to-Silicon Compiler. We are indeed in the early stages of ESL and TLM-driven design, but it won't be that way forever -- and user and vendor companies who are willing to be a little bit ahead of the curve may have a big advantage in the long run.
Great article Richard, and I think it points out the real trouble with the ESL as it relates to IP, which seems to me to be a combination of business and technical factors.
On the business side, the market has yet to demonstrate willingness to pay extra for ESL views of IP, so the question of "who pays?" remains until customers are willing to fund that. The second point here is that while its true that "TLM-based IP doesn't lock one into a given microarchitecture", at least today it locks one into an EDA flow. That's anathma to many customers.
On the technical side, the lack of formal verification from SystemC to gates is very problematic in insuring that a tool bug doesn't generate a bad-logic bug. RTL and GDSII IP for all its imflexibility is at least a known quantity where bugs can be clearly identified in the code, not the tool. (Maybe that's more properly in the business category of issue!)
It seems to me that we are at the early stages of how ESL and IP are going to co-exist and that block-based design is safe for a long time.
Would a silicon IP provider's paranoia be justified if they were to provide an ESL model of their module, say in SystemC, and an evaluator put that through Cadence C-to-Silicon or another HLS tool, yielding a new implementation that works as well or even better than their original component? Is that synthesized part still the IP provided by the vendor or something wholly new, belonging to the evaluating customer/prospect?
My guess is that since the original SystemC was provided by the IP vendor, they still have to be paid for their IP even if the RTL is different from that in the deliverable bundle. Or no? :)