It is said that everything in EDA takes 10 years to become adopted. SystemC is more than 15 years old and remains on the horizon. How broken is it?
In order to perform architectural exploration, performance analysis and optimization, early validation of software, improved productivity in hardware development and many other tasks, the industry needs a viable virtual prototype. That requires a suitable language in order to express necessary concepts at a high enough level of abstraction so that sufficient amounts of simulation can be performed.
The industry thought it had found the answer with SystemC, but even though that language is now well over ten years old, it has not seen the necessary amounts of investment or adoption and few of its problems have been solved. Will SystemC even get its act together? That was the focus of a panel at DVCon this year, and while many of the panelists were eager to see its problems resolved, none of them seemed to know the right path forward.
A couple of times during the panel, work within Accellera was described as glacially slow although nobody faulted Accellera for this, they admitted that there was just not enough interest in expending the effort to get the necessary work done. At the same time, panelists described large groups of interest at the Japan SystemC users group, so it would seem that there are multiple disconnects around this language.
Panelists , chief executive officer of ; , chief technology officer at Carbon Design Systems; , president and CEO of OneSpin Solutions; Victoria Mitchell, director of worldwide heterogeneous programming within Altera and the panel was moderated by Bryon Moyer. What follows are the key points of that panel.
Neifert pointed out that SystemC can be a wonderful methodology in the ESL space but barriers to more widespread adoption exist. “Missing standards keep IP from flowing freely between companies. TLM2 was a start but not enough and many of the necessary standards were never finished.” He then spoke of the elephant in the room. “The biggest problem is that there is no way to make money from it. It gets integrated into other offerings and nobody can charge anything for it.”
Mitchell agreed about the problems with standards. “SystemC is a standard that is not finished. In addition to compatibility issues between IP, there are compatibility problems in a flow perspective.” She noted that while design capture and simulation are important, “we must also look at the usage of SystemC to create virtual platforms for early software enablement. This improves time to market, and while we are making progress it is still not there. It is difficult to do performance analysis and difficult to do regression testing. So, while SystemC has a lot of potential, my request is to improve interfaces and interoperability and extend it beyond architectural modeling into software and system performance.”
According to McNamara, a user of SystemC today and a developer of the early Chronologic Verilog simulator: “We had the opportunity with VCS to produce a tool implemented the way we wanted it from the ground up. With SystemC the same process needs to occur. The standards body produces a definition. A bunch of people then need to use the language in anger. You, as a user, want to have someone that you can pay money to make it better. If there is no one to accept the check, you get frustrated. This is the problem with open source. You need a robust market that can make money and provide improvements.”
Brinkmann said people will adopt SystemC if it provides a productivity gain. “For modeling and hardware design it is not happening yet. In the last couple of years there has been progress on . What is missing is the ecosystem around SystemC that can handle verification and debug. Formal verification is not there even though we are attempting to raise the level of abstraction for verification. Ecosystems are needed for IP and verification.”
It was clear that while all of the panelists wanted to be supporters of SystemC, they were also frustrated. Sadly there were no representatives from the large EDA companies to explain their side of this problem. McNamara was prepared to put on his ex-Cadence hat and said, “When I was in Cadence, the need to supporting everything for everyone was hugely expensive. once said that methodology is a way to restrict freedom. This makes life easier, and as an EDA vendor you might want a small set of flows that you can validate, test and improve — but as a consumer, you want to support whatever I do.”
But the problems are not just a lack of tools. “We don’t have a clear direction about what kinds of SystemC you should write to be useful for various tools,” Brinkmann said. “When we get this sorted out, things will improve, but right now, the application isn’t there.” This problem has been on the table for a long time and is one of the standards that was described as glacial.
Another standard that the panelists called for was CCI (command and control interface). Mitchell said that “this enables you to switch methodologies, flows or EDA provider. CCI needs to be completed and the tool vendors support it.” Neifert pointed out that he had worked on this over 10 years ago and the standard is still not there.
Even if CCI existed, “you still have a fundamental problem with TLM2,” said Neifert. “The way I describe TLM2 and hand it off to you – there is no guarantee it will work. We have all extended it in different ways. We need standardization on the modeling of the protocol.” Neifert explained that he had even tried to create a defacto standard and give it away. “That was not sufficient to get over the hurdle.”
The panel drifted into a discussion about the strengths and weaknesses of SystemC basically being related to the fundamentals of the language. On the plus side, the language is expressive enough to be able to describe anything. The biggest point on the negative side is that of debug. McNamara tried to put on a brave face. “We need to focus on debug. The average selling price of an HDL simulator is not that high. What they pay for is the analysis seat that interacts with the engineer. In the early days we charged a lot of the regression engine and that allowed us to invest in the debug engine. Virtual prototyping is creating value and you need to find ways to add further value.”
Mitchell was not quite as positive. “If you can plug together pieces – well, it doesn’t work in SystemC and you need to be able to build executable specs and use these things. The performance of the overall simulation might be great but if you don’t understand where the timing constraints or race conditions in the system are, it is not that useful.”
With any discussion about SystemC there are always good conspiracy theories. On this panel it was provided by Brinkmann. “If the established EDA vendors went and made it faster, it would take away revenue from RTL simulation. This means they are not motivated. That leaves little companies to step up and fill the gap.”
An audience member asked about work on a UVM for SystemC. McNamara pointed out that the creation of UVM did consider SystemC and that his company uses it to verify its models today. Mitchell took the idea a step further saying that for every increase in hardware “there is a 10X increase in software, so the concept of providing a methodology for verification of software is interesting.”
 |
 |
 |
 |
 |
 |
 |
 |
 |  |
Mmmm????!
SystemC working great in its present form for us. We use it for SW early prototyping, architectural exploration, and even some HLS. It’s served us well for … 8-9 years or so.
Are you confusing an evolving and expanding standard for an useless or unusable one?
The point is that it is not useless or unusable, it is that it is not well supported and the tools available have not been on a par with the tools available for other languages. The acceptance and increasing adoption of SystemC for virtual prototypes, and to a lesser extent HLS, is beginning to make the investment from EDA vendors worth it. At the same time, the needs of the industry are changing in a way that none of the existing languages can serve the industry well.
Just off the top of my head, in a minute or so of thought, a few vendor tools that support SystemC: Platform Architect, CtoSi, Vista, Catapult (optionally at least).
Perhaps part of it is the built-in reference simulator. That is, perhaps it’s hard to make money on SystemC if everybody goes for the no-frills-but-free built-in simulator.
Exactly. As Mac said, it is often the case that a simulator doesn’t get much money, but that money does pay for the investment into analysis tools and that is where most of the value is today for Verilog sales. With a virtual prototype, a new set of analysis tool is required. While some of them are available for free from the software community, those that interact with the hardware often need new types of analysis, such as performance and power analysis.
Sounds like a “lesser of evils” argument. As far as the tools go, SystemC and SystemVerilog are about the same complexity, but NC & VCS etc. are not real compilers like Gcc & LLVM. If the users were smarter they’d organize getting it all on Gcc/LLVM and working properly.
LLVM seems to present a very nice opportunity to create a set of open source HLS tools. All of the infrastructure is there from the parsers to the optimization framework.
Yes, very broken. All the abstractions are bad, and the implementation is dysfunctional. If you want to go the C++ route for HW design I had a go at that –
http://parallel.cc
– for which I made sure my C++ parser could read the SystemC headers (a very painful exercise).
VHDL and SystemVerilog are also broken, so there’s still plenty of opportunity for new approaches.
With RTL we got two new languages: Verilog and VHDL. For ESL we got a library for C++. At the outset ESL has been hampered by lack of suitable language constructs. (Or should I say the lack of expressing ESL functionality in a concise manner.)
On top of this, the motivation for SystemC (at least initially), was free/cheap alternative to Verilog/VHDL. That failed, and SystemC was reborn with TLM 2.0.
Thus our ESL language lacks proper language focus, and is based on C++ with a free simulator. So, how can the industry properly invest in this area?
There are thousands of RTL engineers whose companies are willing to pay good $$ for simulation. The software engineering community balks at spending a couple thousand dollars for any tool. They are used to “rolling there own”, etc. Additionally the number of users for ESL is less than RTL or software engineering, further putting price pressure.
Creating a proper and effective ESL language would cost millions of dollars. But, it seems users have been enamored with “free C++, SystemC, and OSCI”. And would rather put up with SystemC limitations, or use other methods, rather than fund a true ESL simulation environment.
In RTL we started with a proprietary Verilog language that was so successful it spawned offshoots like VHDL. In ESL we have the inexpensive “freeware” solution which prevents proper innovation.
Electronic design IMO, does not lend itself to the freeware model of other industries (e.g. web based tools). The market is too small and the technical issues too large. The only way to get a proper solution is for companies to invest real $$, which in turn will be recouped by sales to users.
Just my 2 cents worth…
Unfortunately, startups have almost dried up in EDA as the time to exit and the amount they get at exit is not favorable for investment. So investment must either come from the established EDA companies, the universities or the industry.
If the situation becomes dire enough, large systems houses may have to tackle it themselves, but you can bet your life they wont then donate it to the industry until it has become old hat. They will keep it as a competitive advantage.
This of course is also the reverse of the situation that created EDA in the first place.
This. Exactly this. The best minds of a generation (or two) have now been focused on getting people to look at ads (Google, Facebook, etc.) for a good dozen years. VCs expect much quicker payback times than they can get from EDA so they don’t fund nascent EDA companies. An EDA startup can take 5 to 10 years or more to get to revenue, whereas some of these web startups get revenue within the first year.
You can turn C++ into a perfectly good ESL and do it cheap using the LLVM/gcc compiler chains. However, RTL is just a bad abstraction level to work at, and you really want to bump up to the next level, then hardware design and “manycore” programming look like the same problem.
Really you have to use C++ because programmers won’t use VHDL and Verilog.
Unfortunately most EDA companies don’t seem to have people that understand parsers and compilers beyond old lex/yacc stuff, and aren’t likely make the leap.
One more comment: Where is academia on this? Normally a professor would cobble together a solution with a few grad students, then sell it or form a company to product-ize it. I’ve not heard of any such activity. Interesting if anyone has.
I would also be interested to hear if any universities are using SystemC. Personally, I expect they either use Verilog, or languages such as OpenCL, Java or Python.
A lot of problems in EDA are now outside the scope of academic projects.
However there is still funding for tools/research where EDA is not doing a good job. Sandia Lab’s Xyce simulator is an example of that and it will probably have more long term positive impact than SystemC.
It is great to see some work in the area of analog simulation and especially applying multiprocessors to it. Maybe it will stimulate some additional work in digital simulation.
I’ve worked on both sides of the fence: hls software development on one side, working with hardware engineers on the other. I’m currently on the “software support for the hardware folks implementing DSP-ish algorithms” side of the fence. And trying to convince them that HLS is viable is very difficult. They seem plenty happy with SystemVerilog and very skeptical of SystemC. I find that I’m creating custom code generators for them where I can take in equations and spit out Verilog modules and then these Verilog modules get plugged into the larger system.
I think SystemC is too far away from the RTL for the hardware folks I’m working with. SystemC is basically C++ with some special libraries to represent hardware concepts plus a runtime. Given that it depends heavily in C++ templates I really wonder what a hardware person does when they’re suddenly faced with pages and pages of C++ template errors?
Right – SystemC exposes the runtime innards of the language, which is code that the designer never wrote. It is also complex code and needs to be hidden. But that would require a special purpose compiler that understands the semantics of what is being modeled and then a special purpose simulator.
Hi Matthieu,
Excellent article that you have written on SystemC. I come from an FPGA background so my comments should be interpreted as such.
I agree with your exposition regarding low level SystemC RTL design as well as HLS strategies and in my view this includes model based design philosophies like Simulink, which Mathworks is pushing really hard in the FPGA market. In my experience it takes longer in these languages/environments to get to functional RTL simply because of the fact of the extra overheads placed on engineers to write and debug the software code due to, but not limited to, all the new obfuscating syntactical sugar added to the language to make it possible to describe RTL constructs; and then to try and get a grip on the real RTL issues in a non existing/poor debugging environment.
With regards to HLS avoid it like the plague because the productivity gain is illusory in these ‘new’ languages. If you really need to do HLS then do the next best thing: write high level VHDL behavioural models with all the advantages already going for it (modern synthesis tools do a pretty descent job on these high level behavioural models).
See for example: www(dot)gaisler(dot)com/doc/vhdl2proc(dot)pdf. I don’t necessarily condone his high level approach but this serves as an example of what can be done in an HDL.
There is a huge difference between modelling hardware systems and designing hardware systems.
Regards,
Joe
It is September, 2021. Is it sill worth entering into virtual prototyping using C++ and SystemC.
I have been working as a software developer in Automobile for past 4 years. I recently found an opportunity to work in this domain. Is it still worth the time? How are the growth prospects and is there a future with SystemC?