Some SystemC Perspectives - An Interview with Vincent Motel

I sat down with Vincent Motel recently, a long time Cadence employee, and one of several experts on the past, present, and future opportunities of using SystemC. The following interview provides some interesting glimpses into the original motivations and directions of Cadence and SystemC, and provides Vincent's unique perspective on the language, technology, and customers who use SystemC solutions.

Steve: How long have you been involved in the SystemC domain?

Vincent: I started to work on customer projects related to SystemC in 2002. It was the early days of TLM modeling and use of SystemC for verification. I have developed various kinds of SystemC models for and with my customers. Also, I have worked on the Cadence SystemC simulator from its introduction: I support the users, and participate in the specification and testing of the tool.

Steve: Where and why is SystemC successful?

Vincent: First, it was the language that, once standardized by the Open SystemC Initiative (OSCI), allowed the joining of many efforts on C-based system level design. The more system level languages become standardized the more is adopted by the users. The main milestones were the OSCI TLM 1.0 (standardization of the transaction transport layer), SystemC Verification (SCV - an attempt to bring advanced verification features to SystemC), and now OSCI TLM 2.0 (standardization of the TLM payload for memory address-mapped systems). The efforts of the OSCI working groups are still on-going.

Over the years, the industry in general gained a lot of experience around SystemC, which is now a very well established language.

From what I see at Cadence customers, SystemC is used primarily for TLM modeling. It allows very efficient and quick development or assembly of high-level models of the hardware. Not only the models simulate much faster than RTL, but they're ready months before the RTL and silicon, which allows early software development and validation. Also, the hardware visibility in a TLM model can be much better than in a board. A few years back that was the vision of a few SoC and EDA companies, but now it's everyday reality for many SoC software and firmware developers. A challenge was of course to develop a critical mass of SystemC models that can be re-used, to make the modeling effort realistically low. Now such models abound, either in-house in large companies or in cooperative projects.

Then, some customers are tempted to take the benefits of those SystemC models when building verification environment, usually freely mixed with advanced verification IP such as OVM compliant eVCs or UVCs. That's the main reason OVM multi-language methodology and verification/simulation technology capability is critical for them.

Steve: What is so special about SystemC?

Vincent: We all understand SystemC has constructs to model hardware (hierarchy, concurrency), and that it is especially designed for a higher level of abstraction than usual HDLs (mainly TLM). But there is more: as SystemC is basically a set of C++ classes, it is C/C++, so it's the same language as the high-level algorithms, and the same language as the software part of the system, whose importance is continuously growing. It makes the integration and refinement of a C algorithm easy. The same applies to the software: at a very high level an algorithm looks the same if it's a piece of software running on a processor or if it's a model of specialized hardware. That allows experimentation of the hardware-software partitioning. Once the processor cores are committed, they can be modeled in various ways in SystemC: the software source code can be kept wrapped in SystemC (host code execution techniques), or a generic software emulator, a specific ISS can be integrated in SystemC, it's usually relatively easy.

Technically, a C++ based language like SystemC has another advantage: it gives immediate access to all that can have been developed for C/C++, either open-source of pre-compiled. In that way, it's a language that is of the same nature of the EDA tools themselves, so that in some applications, SystemC can be used not only for the model, but for a part of the specific tooling and flows required with the models. Many specific applications or flows can be developed more easily in SystemC than in any other hardware language. For example, I have included non-trivial parsers based on lex&yacc in several SystemC applications, or added analysis of simulation results based on graph algorithms, easy to implement in C++. Also, you don't need a specific C API (like VPI and VHPI of HDLs) to access the SystemC constructs, or traverse the hierarchy : that's built-in the language. Many models and applications can benefit from that.

Steve: What are the main challenges for the SystemC users?

Vincent: The remaining difficulties are not so much with learning SystemC itself, but with the abstraction level where it is used. Architecture exploration or design at transaction level is difficult, because TLM models are intrinsically functional, it is very hard to make them suitable for architecture analysis. To model the factors of the performance, such as arbitration in SoC interconnect or memory sub-system, you need quasi-cycle accurate timing, and that usually requires quasi-register-level models, for sure models much more detailed than usual functional TLM. Realistic power estimation at architectural level is also very dependent on the timing. However, I have participated in successful architecture analysis projects based on a mix of RTL, cycle accurate SystemC models, transactional traffic generators and performance monitors.

Even without time, in the functional domain, synchronization of untimed models seems to be a difficult problem, software developers have to be careful that their virtual prototype presents a correct system synchronization behavior. But a well crafted virtual prototype can help produce robust software quicker than on a physical board.

Steve: Tell us about the Cadence technology that you support

Vincent: NC-SC was the first simulator which allowed easy simulation of SystemC together with HDLs. Over the years, many many features have been added. And now as Incisive Enterprise Simulator, it is clearly the most powerful SystemC solution on the market. It gives access to the huge potential of the original ncsim multi-language simulator, including comprehensive interfaces to all the other languages and a close link to emulation. But the value is also in the many SystemC-specific features, especially for the visualization, analysis and debug of the simulations. We have added features such as PSL for SystemC, functional coverage, reset, save and restart like for the HDLs, advanced transaction recording and analysis capabilities, and many debug features, some of them are similar to the HDL debug features (waveforms, schematic...), some others are really SystemC-specific, like the multi-thread process debugger. Now that OSCI TLM2.0 is available, we can continue to develop TLM2-specific features. Ease of use is another interesting aspect: the invocation tools (ncsc_run and irun) hide all the complexity of C++ compilation and link.

Overall, it can dramatically change the SystemC experience, compared to the use of the OSCI reference simulator.

Steve: What are the new, exciting technologies that you see around SystemC at Cadence?

Vincent: The introduction of C-to-Silicon Compiler last year, after a long and solid maturation, adds a new dimension to the potential of the SystemC language. SystemC models are no longer just reference models, they can become the starting point of the automated implementation flow.

Also, my customers seem to be quite interested in the Multi-language OVM, which I have studied in detail. OVM mixed the best of the eRM and TLM worlds for SystemVerilog originally, now ML OVM generalizes TLM to e also, and enables TLM connection between whatever in e, SV and SC. That brings the interoperability between those languages at a higher level. And that can be the driver for even more flexibility and re-use in the verification environments, especially for the customers who invested a lot in SystemC TLM models. Probably the only way to make the productivity gains required for verifying next generations of SoCs.

Vincent Motel is a Principal Services AE at Cadence Design Systems, working on customer site on SystemC and TLM related projects. He joined Cadence in 2000, and worked in customer support and VCAD services, first in the area of digital implementation, then in functional verification and system-level design. Prior to that, he worked on synthesis and formal equivalence checking projects as a contractor for European semiconductor companies.

Vincent earned an engineering degree from the Ecole Nationale Supérieure des Télécommunications (Telecom Paris).

Steve Brown