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: Everyone looks at IP-XACT and says it’s a good first try, but it’s not enough. What’s next?
Black: System RTL is basically a register abstraction description. IP-XACT has some elements of that. I did some informal interviews with companies supporting IP-XACT in that area. Some companies have custom formats, some have spreadsheets, and everyone has something a little bit different. But it’s clear that for many years we’ve always had this issue of designing registers and every company has its own tools. Something has to happen to improve that, and IP-XACT has to begin addressing what’s going on in the ESL world, as well. Engineers don’t need to be designing common register patterns over and over again.
Meredith: In my experience, almost every large semiconductor company has a tool set for some meta data description or script or spreadsheet that defines registers and something that produces documentation or RTL. The semiconductor industry has more experience in this area than the EDA industry. There is a real need for the folks in the semiconductor industry who build and use those internal tools to engage in this standards activity. It will move forward a lot faster if the people sitting at the table have already done it once.
Sarkar: It’s getting better, but it’s still bad. Every company has their own set of tools. Whoever works with IP-XACT should address this.

SLD: What’s going on with TLM 2.0? What’s missing?
Meredith: What’s well in the works is CCI libraries and APIs that sit on top of TLM 2.0 to provide interoperability for tools to configure models. So you can have one model and have it work in a number of different ways, depending on what the testbench or tool wants it to be. What’s the size of the cache in that model, for example? That’s an activity that is well underway. We anticipate seeing results pretty soon.

SLD: TLM runs from architecture to verification. We’re hearing much more concern about exploring tradeoffs. Will that be part of the standards effort?
Meredith: For maintaining multiple configurations and comparing them, that’s not an area that’s ripe for standardization yet. It may be an area that needs tooling more than standardization.
Black: There’s a lot of configurability and features in UVM that address that area. Those two groups need to get together and discuss where there might be some commonality. With TLM 2.0, the use case model that was adopted was memory-mapped buses, but if you look deeper it’s possible with some additional work to map it to networking and a lot of other areas.
Alsop: We looked at TLM 2.0 integration about a year ago. There were some aspects of it that made sense. But if you look at the real thrust of TLM, it’s to get your performance models right. Those aspects of integration with UVM did make sense to us.

SLD: There’s a lot of confusion in the industry about SystemC versus C++ versus C. Can these worlds be brought together?
Meredith: One of the places where these languages intersect is in the movement from a model that’s been developed by an algorithm or an architecture group, usually in C or C++, into an implementation in SystemC for high-level synthesis or some verification activity. One of the main issues there is it’s usually accompanied by a large body of legacy modeling—whole libraries and data types. Trying to make those worlds work together is very much a case-by-case challenge because the modeling environment in C at one site is very different from the modeling environment for C at every other site.
Alsop: We’ve been working at Intel over the past year on that specific issue—taking C++ modeling of our architecture performance model and trying to figure out a way to refine that to something that can work with HLS. We’re trying to figure out how to re-use it by HLS, but at the same time still be able to use it for performance modeling. The tradeoffs are tough. We ended up writing our own classes. We’d like to see some support in the synthesizable subsets.

SLD: Will UVM work with ESL tools and standards?
Black: UVM will have to do something to adapt to ESL because there’s a different set of problems there. But there may also need to be some changes to adopt that.