Recently, I got together with a bunch of folks to discuss the current state-of-play with regard to the use of SystemC and Transaction Level Models/Modeling (TLM). Here are the discussions relating to the sixth question: "What are the inhibitors of SystemC or TLM for mainstream usage?"

Question #6: What are the inhibitors of SystemC or TLM for mainstream usage?

TLM1 refresher - Abstraction levels

Shabtay Matalon (Mentor): The main inhibitors are:

• The C++/SystemC learning curve for RTL users
• The high level of modeling effort required
• Lack of a sufficient TLM 2.0-based IP eco-system
• Lack of sufficient reuse of TLMs as RTL testbench components.

However, many of these inhibitors are being gradually addressed with improved TLM 2.0 offering from IP providers, better automation in modeling by ESL tools, and better reuse methodology.

Laurent Ducousso (STMicroelectronics): They are efficient at the virtual prototype level, but there are still limitations with regard to high-level synthesis (HLS) flows, and there remain limited commercial model offerings. A quick summary would be as follows:

• Existing tool capabilities (in the context of our development)
• Today optimized for datapath or control
• Cannot handle full design today
• Multiclock domain limitations
• Need to handle functionality and system performance concurrently
• Limited SystemC debug/profiling capabitilies
• SOC assembly , SystemC vs RTL open
• Verification methodology and flow not efficient as design today
• RTL to ESL path
• Co-simulation needs improvement
• RTL – SystemC : Cause and effect approach is needed
• Need to have a way to handle ECO
• Equivalence checking is a must
• Third-party IP is still delivered at RTL level

Simon Davidmann (Imperas): Often the greatest impediment to SystemC/TLM-2.0 adoption is the organization itself. The key pieces of software are dependent on the hardware: operating systems, drivers, bare metal applications. Software engineers don't have the knowledge of the hardware to build the required models, and hardware engineers know too much, and include too much detail in the models. Too much detail slows down the simulation of the software, to the point where it's deemed unusable for software development. (Maybe, as happened with the development of the verification engineer job description as RTL verification became critical, there will be a new engineering job description emerging for hardware-dependent software development, someone that is a cross between a firmware development and a verification engineer.)

Nagendra Gulur Dwarakanath (TI): There are a couple of issues here. One: IP and SoC design teams must embrace SystemC as the dominant language for IP specification, development, and verification. Until and unless that metamorphosis happens, mainstream adoption of SystemC will remain stinted. Two: EDA and ESL tools must find ways to innovate and differentiate while staying 100% compliant to the standards.

Marc Schmitz (STEricsson): Even though it is based on C++, the SystemC language is not simple...

Ravi Venugopalan (Sonics): Integration and elaboration of multiple SystemC models is a challenge. Each tool has its own set of integration guidelines and there is no one standard flow that all the tools follow to integrate and elaborate models. There is also resistance to add yet one more language and API into today's already vastly complicated process of Silicon IP development. Most companies are not ready to buy into the cost of adopting one more new languages into their flows.

David Beal (Virtutech): Slow performance; also lack of fully standardized interfaces, functions, and platform-level communications (e.g. networking, etc.).

J.C. Yeh (ITRI): A big issue is the immaturity of the top-down system design flow (hardware/software partitioning to hardware-software co-simulation to high-level synthesis to verification to/...).

Brian Bailey (Independent Consultant): We have mentioned the problem of models in the past. This is now gone and I believe that ESL adoption will accelerate because of that. Almost every company that has put an ESL methodology in place is seeing huge gains from it, and this is with parts of the methodology not yet being well supported by tools. When we get better tools, adoption will accelerate even faster.

Steve Brown (Cadence): Customers need several components for a complete solution, and most haven't invested in the evaluation of existing solutions to know what is available. Customer education about SystemC modeling and methodology is going to be a key requirement to grow SystemC adoption.

The primary inhibitor has been a link to today’s RTL implementation and verification solution. Effective High Level Synthesis and TLM verification solutions now address this problem.

Equivalence checking from TLM to RTL needs to be as robust as for RTL to gates. TLM design and verification IP needs become prevalent, which may require IP companies to shift to a "soft IP" strategy. Industry protocols need to have a TLM transaction definition to enable IP development and interchange. Debugging tools need to operate at the abstraction of transactions. High level synthesis needs to handle both data path and control so full SoCs can be synthesized.

Andreas Ropers (ARM): TLM-2.0 offers the concept of transaction level modeling which needs to be applied to all IP blocks in a consistent way. The integration of legacy components, especially RTL components, seems to be complicated when it comes to debug accesses (more general, the nonintrusive inspection of the design under test). This is something that needs to be addressed by EDA companies to leverage the benefit of TLM-2.0 also for RTL designs. At the same time, IP creators need to deliver abstract models alongside their RTL, which is not yet state of the art.

Patrick Sheridan (CoWare): Access to IP models is still an important enabler. The strong industry alignment on SystemC TLM-2.0 standards for model interoperability is increasing model supply, increasing model reuse, and improving the overall ROI for model development. Leading IP suppliers, like ARM and Synopsys, are shipping SystemC TLM-2.0 models today. CoWare supports these and a range of CoWare Model Library IP in our environment, enabling interoperability with the CoWare SCML and TLM-2.0 models used by our customers.

Question #5 | Introduction/Overview | Question #7