SystemC Evolution Day 2017

As a follow-up to the first SystemC Evolution Day in May 2016, the SystemC user community met again right after DVCon Europe 2017 for the second edition of this full day technical workshop to discuss the evolution of the various SystemC standards. With more than 60 participants, the Accellera-sponsored event was sold out again, with representatives from over 25 companies and academic institutions in attendance.

The main objective of the SystemC Evolution Day series is to identify areas in which to align and accelerate the different SystemC standardization initiatives within Accellera and work towards solution proposals for standards inclusion. The discussions were centered around four in-depth technical sessions in the fields of SystemC checkpointing support, register inspection and debug, datatypes, and protocol modeling for high-level synthesis. During the open wrap-up session, additional topics were discussed such as clock/reset/interrupt modeling, parallel/distributed simulations, and others. The material and presentations are shared with the Accellera SystemC Working Groups for follow-up discussions.

With the continuing success of this workshop format and the very positive feedback from the attendees, the organization committee is exploring options to further enhance the format for future editions of the SystemC Evolution Day.

#1 Checkpointing and SystemC – How Can We Make Them Meet?

Checkpointing is a useful feature of computer system simulators from at least the mid-1990s. Among other uses, checkpointing is used to transfer the state of a system between fast and detailed simulators; to save time in workflows by not redoing work like booting a system; as a collaboration tool between developers; and as a way to undo bad changes to a target system. Checkpointing is on the list of features being considered by the SystemC Configuration, Control, and Inspection Working Group (CCIWG).

Checkpointing has proven tricky to implement in SystemC, mainly because it constrains how models are written — models have to be able to save and restore their state. To support moving checkpoints across hosts and between models at different abstraction levels, it should be possible to restore into a different implementation of the same model. Saving and restoring the entire state of a process or a virtual machine image achieves only part of the goal. There is a significant body of research available on checkpointing for SystemC that offer insights and ideas.

In this session, we will look at the current understanding of checkpointing and how it can be implemented in SystemC. We want to discuss how an implementation can be made practical and get the input from the language design, modeling, tool building, and user communities on checkpointing for SystemC. As one starting point for the discussion, we will present a checkpointing library that we have developed at Intel in cooperation between the Simics team and SystemC users.

#2 Standardization around Registers – What’s Needed?

As the CCIWG finally wraps up its work on configuration, one of the next topics on the group’s charter is “registers.” There are several aspects of this: What do users expect from register libraries? What actually needs standardizing? What advantages standardization brings to registers?

Different organizations have different register modeling libraries, and different users will certainly have different experiences and requirements. Some proposals for standardization probably need revisiting as SystemC itself has evolved (and with the addition of CCI). Meanwhile, all of the current proposals are old (dating back at least five years in most cases). What’s missing is the experience of users today and what is really needed from a user perspective.

This topic session will present some of the proposals for standardization around registers, and we hope to elicit feedback from the user community — to ask the question, "What is the next evolutionary step for registers?"

#3 SystemC Datatypes - a Community Discussion

Over the last fifteen years, SystemC users and EDA companies have been using the standard datatypes in different ways, either using the proof-of-concept library as is, or internally customizing it, or completely re-implementing the standard datatypes for simulation speed or synthesizability issues.

The SystemC Datatypes Sub-Working Group has been chartered to incorporate many of these improvements (and more) by defining an advanced set of SystemC datatypes, suitable for all SystemC modeling domains from algorithmic models to synthesis.

The goal of this interactive session is to engage the broader user community in the process of improving the datatypes. We will first discuss the various use models and issues of the current standard datatypes. We will then discuss two possible paths forward: (a) improving the current datatypes while keeping the existing API or (b) defining new datatypes with a slightly different API and backward compatibility.

#4 Throughput Accurate Modeling and Synthesis of Abstract Interfaces

Organizer: Andres Takach (Mentor Graphics, a Siemens Business)

Modeling and synthesis of abstract interfaces is not addressed in the current SystemC Synthesis standard. The standard covers signals and ports, but has no mention of the scheduling rules that are required for synthesizing the correct cycle accurate protocol. Ideally communication can be expressed in SystemC at a higher abstraction level, but with pin and protocol accurate interfaces so that it can model interactions with timing sensitive blocks such as arbiters and memories.

Encapsulation of a protocol as a C++ class with methods to perform transaction-level operations such as get/read and put/write is a key way to raise the abstraction of an interface. High-level synthesis can treat the behavior in such operations as cycle accurate to preserve the intent of the protocol. While this encapsulation is elegant, it does not solve a fundamental problem that we would like to model the interaction of different ports that are being accessed from a process (SC_THREAD or SC_CTHREAD) as being concurrent. While it is possible to write behavior in a thread that handles multiple ports, this becomes a cross product of the sequential behavior of each protocol making it non-scalable and non-modular. It also reduces the freedom to schedule the port accesses to be initiated in different cycles.

Unless we can model concurrency in the access to various ports within a thread, the SystemC model runs at a slower throughput than the desired hardware would. While still functionally correct/equivalent for latency-insensitive designs, this does not accurately model interactions with arbiters, etc.

This in-depth session covers the topic of modeling of abstract interfaces and how it relates to high-level synthesis of that model. The interactive discussion aims to explore approaches that could lead to proposals for expanding the SystemC Synthesis standard in this area.

After the technical sessions, an open discussion session will be used to summarize the next steps for further progressing within the relevant Accellera SystemC Working Groups by the Accellera members on the session topics as well as additional opens brought up during the closing discussion. If you would like to become an Accellera member to participate in the working groups, information on how to join can be found at here.