Experts At The Table: The Future Of SystemC

By Ed Sperling
System-Level Design moderated a discussion about the future of SystemC with Thomas Alsop, corporate design solution expert at Intel; Ambar Sarkar, chief verification technologist at Paradigm Works; Mike Meredith, vice president of technical marketing at Forte Design systems; David Black, certified training instructor at Doulos. Here are some of the key outtakes of that discussion.

SLD: What’s going on with SystemC behind the scenes?
Black: The SystemC working group is starting back up. Quite a few companies are interested in making it more compatible with modern platforms. There is also interest in UVM and other areas of coverage.
Meredith: There isn’t activity yet in the working groups, but people are starting to bring information to address coverage in verification. There is certainly an appetite for a UVM-like methodology inside the SystemC verification framework. That’s an area where we will see some activity in the future.
Sarkar: What people would like is better coverage, along with UVM.
Alsop: I’m on the committee at Intel that’s looking at high-level synthesis capabilities. New capabilities we want to see over the next year are things directed at HLS. Some of the verification methodologies we’re implementing in relationship to HLS involve better coverage. We’re working with EDA vendors on better constraint solvers and better random generators. We have a very vested interest in UVM and maybe we could create a UVM environment around SystemC, as well.

SLD: There have been rumblings about a SystemC verification group. Is it really happening?
Meredith: There was a SystemC working group in OSCI some years ago. The activity died down for a few years, but last fall there was a new call for membership. It is starting up again.

SLD: Any idea when something will come out of this group and what it might be?
Meredith: When is a crystal-ball question. But in terms of what’s going to come out of it, initially they’re looking at updating the existing library to work within the context of the new standard as a first obvious step. From there it could include better coverage.

SLD: We’ve all seen what happens when standards efforts go wrong. Will there be multi-language support out of SystemC.
Alsop: Intel, and even some of the other companies working with the UVM committee, really want to see multilingual support for SystemC. There are some behind-the-scenes efforts where we’re trying to get end users to look at the spec and what kind of infrastructure or framework we want to place around this. We’re still trying to get our hands around what the spec will look like. The good news about the merger between Accellera and the Open SystemC Initiative is that it will help a lot with collaboration across different committees. We’re not sure if this will enable work on a new subcommittee that will work on ML and bring in numbers and help from across different committees, or whether it will do this under one of the existing committees. But it is definitely one of the things being investigated.
Black: A lot of EDA companies have their own private interfaces across the boundaries. For example, with TLM 2.0 there are some proprietary implementations. It seems to me that the boundary between SystemC and System Verilog has to be crossed and standardized.
Meredith: Another area where the multilanguage issue is prevalent is in the analog space. With the Accellera systems initiative there is SystemC AMS and Verilog activity. There is definitely some movement, not toward a single language solution, but toward getting these languages to work together.
Sarkar: A similar problem to UPF/CPF came up with the coverage stuff. There are so many domains of coverage that there is a problem of how you deal with it in the first place, and then how do you get access to the data afterward. We have to define a common coverage data model and then choose an API. In this case, it may be C, which is the lowest common denominator. That approach may not work for everyone, though.

SLD: What’s the relationship between SystemC and UVM?
Alsop: I’ve had lots of discussions with vendors about this. The issue right now is there is no standard mechanism for interaction. One of the things we want to enable is IP re-use. That requires any connections—whether it’s TLM connections or other communication protocols across languages that need to happen—it has to happen in a standardized way. If you have IP that’s communicating with some other block, we want the industry to provide IP that already has the communications embedded into it. When you acquire IP you want it to just automatically start communicating with other IPs. So how does SystemC interact with UVM? Long-term we want to set up a framework that enables that.
Sarkar: The fact that we’re using TLM is a big step toward that. System Verilog now works with TLM and SystemC works with TLM. That means both communities need to come together and help out. That’s one area.
Alsop: We have different data types to support. How do you do that? What subset of TLM has evolved and how do you support it? That has to be dealt with.

SLD: There’s another standard out there called the Unified Coverage Interoperability Standard (UCIS). How does that fit into SystemC?
Sarkar: There needs to be something common across both. The good news is there are a lot of common goals. We don’t want to solve the problem two different ways and then try to bring it back together. We are coming up with a standard, and it has a very good start. But we have to be able to capture coverage and use it with the same content. That’s what this enables.
Meredith: Do you anticipate people building environments where some of the verification is done in System Verilog and some is done in SystemC and then you try to accumulate coverage across all of that?
Sarkar: Sometimes you don’t have a choice. Whether you want to do it in one environment or another, you have to deal with different methodologies when you’re talking about emulation or formal verification. But we have tools to make sure you are covered, regardless of which one you’re using.
Alsop: There are a lot of religious wars among designers. At Intel we see a growing use of SystemC. We think we’re still in the infancy here. SystemC has been around for a while for verification, but now designers are moving to a higher abstraction language. That’s still in its infancy. But once designers get hooked into a language and know how to use it, they stay with it. Then there’s also performance. When you’re trying to do certain things in System Verilog it’s slower than SystemC.
Black: There’s another effort going on. A lot of folks are interested in parallelization of SystemC. It’s a matter of distributing your simulation across machines, which is not a trivial task. It doesn’t matter whether it’s System Verilog or SystemC. Both languages need to do that. There are a lot of people talking about that right now.