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 twelfth, and final, question: "What is needed for an IP eco-system to develop based upon SystemC?"

Question #12: What is needed for an IP eco-system to develop based upon SystemC?

Problems with today’s design and verification flow

David Beal (Virtutech): An ecosystem would minimize the specific-modeling required by organizations to enable enhanced re-use and standardization of device-specific models. However, to best leverage that ecosystem, two things should happen. First, further definition and specifications should be applied to TLM. Second, developers should remember that TLM models written in SystemC do not have to comprise 100% of that model. Instead, they can fulfill just a few critical elements, devices, or capabilities within a non-SystemC based model that offers higher performance and other features (e.g. reverse execution, checkpointing, full system stop, etc.) for software developers.

J.C. Yeh (ITRI): Open Standards.

Brian Bailey (Independent Consultant): A viable marketplace needs sufficient potential customers willing to pay enough to support a supplier. It is as simple as that. For many IP providers today, this is just an additional model that they will start to deliver. For some, it is possible that a new market will be created which is for really "squishy cores" – this is softer than soft – meaning that they are intended to be used with high-level synthesis.

Steve Brown (Cadence): There are both design and verification IP that will be developed in the eco-system. Design IP will be TLM components such as building blocks or for interface synthesis such as for the AXI bus. This design IP enables users to focus on TLM creation for their design; it also supports standard components without requiring the user to reinvent what can be commonly shared in the industry. Verification IP will emerge based on the Open Verification Methodology that supports advanced functional verification of TLM designs, driving stimulus and measuring coverage for the particular standard such as the AXI. In addition, there is a need for IP for simulation transactors from TLM to RTL, to support verification if RTL in the context of the TLM SoC, or to support legacy RTL IP.

In order for IP to emerge a methodology must be established to describe the architecture of these components, how they work together, and the standards by which IP should be developed. Various protocol working groups need to start considering the TLM use model, and how TLM IP can speed adoption of their standard, in ways that RTL IP doesn't make sense, or isn't as effective.

In addition there must be some change in the processor IP eco-system. They need to be readily available for the various use models of a SystemC->RTL flow. Customers need models that are accurate and maintained to the specification of the processor providers.

As the main IP suppliers develop their IPs using SystemC as their entry point for their own design process, that IP will proliferate through design teams, and will create a general movement of all IP to be provided at that level of abstraction.

Andreas Ropers (ARM): First, it is the availability of abstract models alongside the RTL of the IP. This can either be achieved by providing synthesizable SystemC blocks or to make both abstraction levels available at the same time. Second, tools need to deal with both representations so that the user can quickly switch between abstraction levels. Third, a broad set of IP blocks needs to be available in SystemC/TLM so the designer can use this methodology for the entire design. A last step is considering the use of these abstract models in order to automatically synthesize the implementation. Initially this is expected to happen partially only, because some people do not consider SystemC as the entry point for abstract design.

Patrick Sheridan (CoWare): 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. Internal IP developers and commercial suppliers of IP models should continue to adopt these standards to and provide these deliverables to their customers as a standard practice.

Frans Theeuwen (NXP): It is crucial that models developed on a higher level of abstraction will work together if they are used in a virtual prototype of a complete SoC. TLM 2.0 is a good step to ensure interoperability, but still, it is possible to create incompatible TLM2.0 IP models. Solving this will be key.

Shabtay Matalon (Mentor): IP provides need to first provide SystemC TLM 2.0-compliant TLMs with loosely-timed (LT) level accuracy for key processors, busses, and peripherals as the core minimum. To address all ESL use models (including performance and power optimization), they need to provide TLMs with approximated-time (AT) and ideally add a TLM power model. An important addition to the IP eco-system are Verification IPs that operate at the TLM 2.0 level for standard protocols. We believe that having IP and semiconductor companies adopt SystemC and TLM 2.0 in their own design flows will significantly help in driving SystemC based methodology into the entire industry design chain.

Laurent Ducousso (STMicroelectronics): Rules for architectural exploration and system performance assessment; and a development flow for the system, hardware, firmware, software... that demonstrated value regarding reduced time-to-market, reduced cost, increased quality, increased productivity...

Nagendra Gulur Dwarakanath (TI): We will probably need to do a couple of things. First: fix the big gaps in the standards. Second: develop a catalog of use-cases and map them to model requirements. Third: develop tools and infrastructure to unify flows – architecture modeling, design synthesis, TLM level design verification, and virtual platforms.

Ravi Venugopalan (Sonics): Tool support for debug and verification of the SystemC IP. Increase the ease-of-use with regard to integration, elaboration, and debugging systems for performance.

Question #11 | Introduction/Overview