Home > Community > Blogs > Industry Insights > esl and silicon ip two sides of the same coin
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more conveniennt.

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

Email

* 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: *

ESL And Silicon IP -- Two Sides Of The Same Coin

Comments(3)Filed under: Industry Insights, ESL, chip estimate, TLM, System C

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.

Richard Goering

Comments(3)

By Gary Dare on September 1, 2009
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? :)


By Warren Savage on September 9, 2009
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.

By Richard Goering on September 9, 2009
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.

Leave a Comment


Name
E-mail (will not be published)
Comment
 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.