SystemC Evolution Day 2017
Workshop on the evolution of SystemC standards
Wednesday, October 18, 2017
SystemC Evolution Day is a full-day technical workshop on the evolution of SystemC standards to advance the SystemC ecosystem. This is the second event after a successful first edition in May 2016. In several in-depth sessions, current and future standardization topics around SystemC will be discussed in order to accelerate their progress for Accellera and IEEE standard’s inclusion.
SystemC Evolution Day is intended as a lean, user-centric, hands-on forum bringing together the experts from the SystemC user community and the Accellera Working Groups to advance SystemC standards in a full-day workshop.
Date / Time: October 18, 2017 (day after DVCon Europe 2017) | 8:30 - 17:00
Location: Technical University of Munich, City Campus | Arcisstraße 21, 80333 Munich, Germany | Campus Map
Organization Team: Philipp A Hartmann, Intel; Oliver Bell, Intel; Martin Barnasconi, NXP; Matthias Bauer, Infineon; Thomas Kruse, Infineon
Registration is required, but free of charge. Register here >
|08:30 – 09:00||Welcome coffee|
|09:00 – 09:15||Introduction|
|09:15 – 10:15||#1: Checkpointing and SystemC – How Can We Make Them Meet?|
|10:15 – 10:45||Coffee break|
|11:45 – 12:15||#2: Standardization Around Registers - What's Needed?|
|12:15 – 13:30||Lunch break|
|13:30 – 14:30||#3: SystemC Datatypes - A Community Discussion|
|14:30 – 15:30||#4: Throughput Accurate Modeling and Synthesis of Abstract Interfaces|
|15:30 – 16:00||Coffee break|
|16:00 – 17:00||Wrap-up & Open Discussion on SystemC Standards|
There are four in-depth technical sessions for directly discussing of new ideas and suggestions within the SystemC community. You are invited to contribute during these sessions.
#1 Checkpointing and SystemC – How Can We Make Them Meet?
Organizers: Jakob Engblom, Håkan Zeffer, Eric Nilsson, Philipp Hartmann, and Trevor Wieman (Intel)
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?
Organizers: Mark Burton (GreenSocs), Jerome Cornet (ST Microelectronics)
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
Organizers: Fred Doucet (Qualcomm), Andres Takach (Mentor Graphics, a Siemens Business)
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 www.accellera.org/about/join.
Registration is required, but free of charge. Register here >