SystemC, Ten Years Later…

10 years. It’s almost hard to believe, but it has already been a decade since the birth of OSCI. The Open SystemC Initiative was officially launched in September of 1999. A few months later, SystemC v0.91 was released. I remember my genuine curiosity when I downloaded the source files and built that first version of the simulator. The promise was great: after all, wasn’t this called “system” C?

But quite rapidly it became apparent that what I had installed was just an HDL in C++. I could write RTL and cycle accurate models, but SystemC didn’t do much for me in terms of system modeling. Quite understandably many designers challenged the value of doing RTL in C++. The gap between the promises and the reality didn’t help SystemC in its early days.

When launching version 1.0, OSCI also announced soon to follow v1.1 with enhancements for “true system-level design” and support for RPC (remote procedure calls) to model abstract communications. But what followed were short lived experiments and it wasn’t until 2003 and the SystemC 2.0.1 LRM that more solid foundations were established.

Preparing Recommendations

So where do we stand today with SystemC? And after all these years of maturation, how and what do people use the language for?

At the 46^th Design Automation Conference in San Francisco, the North American SystemC User Group (NASCUG) held its 11^th semi-annual meeting. Along with the traditional presentations, the organizers this year experimented with a clever “clicker” system allowing real time surveying of the audience. The results of this survey were very interesting.

When asked what SystemC was used for, more than 130 respondents put system modeling and virtual prototyping clearly on top, at 30% and 23% respectively. These hefty percentages seem to indicate that after these many years, SystemC is finally used for what is was initially conceived.

But even more interestingly, the same survey showed that very few (only 7%) are using SystemC for high-level synthesis. Is this a surprise? Probably not, in the light of the following data. When NASCUG organizers asked about the levels of abstraction primarily used, the results came as follow:

An impressive 81% said to use SystemC above register-transfer and cycle accurate levels. This is quite inline with the previous question, as indeed TLM - whether untimed, loosely or approximately timed - was developed to help with system modeling and virtual prototyping. And with SystemC HLS tools typically requiring designers to write cycle accurate models, the dismal usage of SystemC for synthesis is confirmed by the low usage of cycle accurate abstraction (13%).

Looking beyond the NASCUG survey, this trend was recently confirmed by Gary Smith’s latest Market Trends report. This report typically looks at individual product market share. But from there, it is rather straightforward to derive language market share by summing the the products synthesizing from the same input language.

Over the past 3 three years, the share of SystemC synthesis tools has suffered a constant decline, falling from 28% in 2006 to 20% of the ESL synthesis market. In parallel, the cumulated market share of ESL synthesis starting from pure C or C++ rose from 42% to 65% of the market.

Should we conclude that SystemC isn’t the right language for synthesis? Not exactly. As a language, SystemC spans multiple abstraction levels. Clocked or cycle accurate models required by the current generation of SystemC synthesis tools are too complicated to write and verify and moreover, they don’t play easily with TLM views, which is how the majority uses SystemC. In contrast, pure C/C++ is much simpler and naturally fits with a SystemC TLM approach. So it’s not really a surprise if, in its vast majority, the industry is using pure C/C++ as the ESL synthesis language. 

The full “2009 Market Trends” report is available from Gary Smith EDA.

More Blog Posts

Preparing Recommendations