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 Michael McNamara, chief executive officer of Adapt IP; Bill Neifert, chief technology officer at Carbon Design Systems; Raik Brinkmann, 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 High Level Synthesis. 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. Alberto Sangiovanni-Vincentelli 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.”