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 ninth question: "Are there more standards that are needed to fuel SystemC adoption?"

Question #9: Are there more standards that are needed to fuel SystemC adoption?

How a TLM-driven flow improves productivity

Nagendra Gulur Dwarakanath (TI): An emphatic yes! We do need more comprehensive IP model development standards that encapsulate IP configuration, analysis, debug, and non-memory-mapped busses.

Marc Schmitz (STEricsson): A TLM standard.

Ravi Venugopalan (Sonics): Standards are never enough. Having said that, I have enough standards to adhere to and live with. Other than ease of integration and elaboration, I cannot think of other standards that may help SystemC adoption.

David Beal (Virtutech): TLM-2.0 only specifies a memory-mapped bus and it is designed for buses with similar communication styles. Missing are transaction-level expressions of any other interfaces inside a chip, and all off-chip IO and network interfaces. Standards to enable more dynamic configuration and reconfiguration of a system are also needed.

Brian Bailey (Independent Consultant): So far we have seen adoption for software verification and system verification, but I have not seen too many people using it for performance analysis. Part of the reason for this is that timing models are not adequately defined by TLM 2.0. A synthesizable subset of SystemC has just been put out for review and we also need a similar subset for TLM. Without it, we are limited by only being able to handle synthesis a block at a time.

Steve Brown (Cadence): The transaction definitions for standard protocols are needed to enable healthy IP eco-systems to emerge with good interoperability. The methodology for TLM synthesis is not yet done, though it shows promise. It needs to handle untimed TLM, and not just the clocked modeling of pin accurate behavior available with RTL.

Andreas Ropers (ARM): SystemC and TLM-2.0 do not address the configuration, control, and inspection (analysis) of IP blocks. That is the reason for proprietary solutions and causes overhead when it comes to the integration of models from different vendors. The new OSCI working group CCI (configure, control, and inspection) will address these issues. The SystemC/TLM ecosystem also needs to standardize hardware bus protocol extensions to TLM-2.0.

Patrick Sheridan (CoWare): The introduction in 2008 of the OSCI TLM-2.0 standard for model interoperability was a significant milestone for the industry, enabling alignment within companies and across supply chains on this standards-based modeling methodology. This is fueling significant adoption of SystemC virtual platforms. Additionally, a complementary effort launched by OSCI in 2009 is the Configuration, Control, and Inspection (CCI) working group. Standard interface definitions in this area will enable models to be more easily reused across tool environments, further improving the ROI for model development.

Frans Theeuwen (NXP): In order to build SystemC prototypes that are compatible with the hardware design, both the virtual prototype and the hardware design have to be created in an automated way, starting from one "golden" description. IP-XACT is the relevant standard for this.

Shabtay Matalon (Mentor): The industry will increase SystemC adoption when TLM 2.0 will address all interoperability requirements between SystemC TLMs and SystemVerilog Verification components.

Laurent Ducousso (STMicroelectronics): YES! TLM2 is a must, but it is limited to low levels of system description. We need more, especially regarding software.

Question #8 | Introduction/Overview | Question #10