Open side-bar Menu
 EDACafe Editorial
Peggy Aycinena
Peggy Aycinena
Peggy Aycinena is a contributing editor for EDACafe.Com

Accellera Systems Initiative: team effort & SystemC Library 2.3

July 19th, 2012 by Peggy Aycinena

This week, Accellera Systems Initiative is announcing a new version of its SystemC library, Version 2.3 to be exact. There hasn’t been a new version since way back in 2005 with Version 2.1 (albeit 2.2, a bug-fix release, was published in 2006), so this is the culmination of a lot of hard work.

I spoke by phone with Accellera Systems Initiative Language Working Group Chair David Black, Senior Member of Technical Staff at Doulos, on July 17th.

Black explained, “The purpose of Version 2.3 is to reflect the latest version of IEEE Standard 1666 – to fundamentally demonstrate new features introduced into the SystemC standard, which includes TLM 2.0, previously an OSCI-only standard and now part of the IEEE standard. Interested parties can download the SystemC 2.3 library from the Accellera Systems Initiative website. This download includes several bug fixes, the latest TLM 2.0 and new SystemC features”

I asked Black who has participated in this work, and how often they meet. He said, “The Language Working Group of Accellera Systems Initiative includes all of the major EDA vendors – Cadence, Mentor, Synopsys, and Forte – and service providers such as Doulos and Circuit Sutra – and various members of the industry such as Intel, TI and STMicro, with everyone contributing a perspective.

“I am the Co-Chair of the SystemC Language Working Group along with Andy Goodrich [Forte Design Systems] and took over my position from Mike Meredith [also with Forte]. Key contributors also include Tor Jeremiassen [TI], John Aynsley and Alan Fitch [Doulos], Bishnupriya Bhattacharya [Cadence],  Jerome Cornet [STMicroelectronics],  Dr. Torsten Maehne [UPMC], Pat Sheridan and Bart Vanthournout [Synopsys], and Philipp Hartmann [OFFIS], along with many others.

“It’s a very international group that meets by phone approximately once a month, working around the time-zone shifts between our various locations. Most of the work, however, is done through emails – lots of emails!

“If we do see each other face-to-face, it’s usually at DAC. There have been attempts to meet up at other conferences, but DAC seems to be the best meeting place, particularly for our international contributors.”

I asked Black how the process of vetting new contributions is handled by the Working Group.

He said, “It’s really an all-volunteer effort. If a new feature is to be added, somebody contributes it, we discuss it, and look for consensus. It doesn’t need to be unanimous – although that’s usually the outcome – but we try to come to a point where we can all agree and then we take a vote.

“All of the members of the standards committee give serious consideration to the issue of when to release a new standard, as doing so has impact on EDA tool readiness as well as customer adoption and assurance of compatibility to earlier versions of the standard. As a team, we democratically decide to release the new standard when there is a sufficient body of changes and improvements to warrant the release.”

Black added, “All of this work is about standards. The Accellera merger with OSCI that created the Accellera Systems Initiative is all about standards; the SystemVerilog standard benefits from what’s going on in SystemC, and vice versa; and the UVM standard has picked up some things from SystemC – particularly where TLM 2.0 has been incorporated in the UVM standard. We are all working to higher levels of abstraction, and influencing each other’s thinking.”


Alternatives to SystemC …

What if people don’t want to use SystemC, I asked.

Black said, “Well, it depends on what you’re trying to do. There are multiple purposes for SystemC – it’s an electronic system level language for working at higher levels of abstraction, it’s used by architects trying to do experiments on a proposed design, by folks trying to model their systems and understand whether a bus might lock up before committing to a particularly architecture, and it’s also used to create virtual platforms for use by software teams.

“Yes, there are other solutions available. For instance, MATLAB is used for algorithmic development, and SpecC, although that’s not really around much anymore. And, some companies are still writing their own C or C++ models.

“However, the advantages of SystemC is that you can purchase tools from the EDA vendors that help with design entry and debug. They also will integrate the model into the rest of the design flow. Because of TLM, you can also buy, share, and sell models of IP. And there are even vendors selling tools that will synthesize RTL from SystemC, tools known as high-level synthesis tools.

“Of course, no one is being forced to use SystemC. But if you do, some vendors will even offer you models that they’ve already written – processor models, or Ethernet components, or USBs for instance – and many people would prefer to use something already written. Also, many universities are teaching SystemC techniques in the classroom, usually at the graduate level, so the user base is expanding.”

Black acknowledged the reluctance by some to move to higher levels of abstraction for synthesis: “It’s pretty clear that if we’re planning to design highly complex systems over the next ten-to-twenty years that exhaustively describe that entire hardware system in a register transfer language, it’s not going to scale to this level. There will come a time when higher levels of representation will become popular and necessary, just as we’ve seen RTL’s replace gate-level netlists and C replace assembly code as the complexity of systems has increased over time.”

I mentioned my visit last week to MathWorks in Massachusetts, and Ken Karnofsky’s comment that MATLAB is better suited to high-level design because it’s built on a top-down abstraction perspective, rather than bottom-up.

Black responded: “I’m not sure I agree that SystemC is a bottom-up perspective language. In fact, it’s a based on the multi-paradigm language C++.

“SystemC uses many of the object oriented and generic programming concepts of C++, and allows engineers to express very complex things. Actually, the biggest complaint is that C++ has too many constructs.

“Also, it’s an issue that MATLAB is not a standard. Yes, it’s an industry standard, but it’s proprietary. It’s not like SystemC where there are many folks spending time working to make it a better design environment, short of the MATLAB folks themselves. Our standard is open to the entire community, benefiting from contributions from both academics and industry.”

I also noted my visit to MIT last week, where a team of researchers is developing a hugely multi-core project using Bluespec.

Black responded: “BlueSpec offers a number of benefits in terms of its focus on representing hardware at a higher level of abstraction. But as we know, the number of software developers far exceeds the number of ASIC/FPGA hardware designers and this is the area in which the ability of SystemC to represent virtual platforms really offers a distinct advantage.

“As with any emerging paradigm shift, companies will continue to use a variety of solutions concurrently that could include MATLAB, Bluespec and SystemC/TLM-2 among others.”


Tags: , , , , , , , , , , , , , , , , , , , , , , ,

2 Responses to “Accellera Systems Initiative: team effort & SystemC Library 2.3”

  1. Jack Donovan says:

    I think a point to be made is that SystemC can be leveraged for most tasks in the SoC design process (High Level Synthesis, Early Software Development, Performance Modeling, Functional Verification, and others). All the alternatives can perform one or two of the SoC design tasks, but none of the alternatives do all the tasks, or even a majority of the tasks.
    Cheers, Jack

  2. Mike Bradley says:

    Matlab bottom line strength (M language), is crunching matrix’s, with a very friendly way to express the code. There are also nice math functions (FFT, etc.) to make it even easier to perform these calculations.
    But this is all algorithmic stuff. They have expanded the usage arena with Simulink, which allows you to connect multiple blocks of M code, and some parameterizable library blocks. This makes for good control diagrams, high level communication, etc.
    But how in the world are you going to simulate/evaluate the tradeoff of multiple CPU’s and different busses in Matlab? You can’t. How can you ensure memory bandwidth is sufficient in Matlab? You can’t.
    In other words, Matlab is a level of abstraction above ESL/SystemC. Hence Ken Karnofsky’s comment that “Matlab is better as its built from a top-down abstraction”.
    Matlab struggles to tie the abstract to implementation. Conversely, SystemC and SystemVerilog stuggle to become abstract without losing their ties to implementation.

Leave a Reply

Your email address will not be published. Required fields are marked *



Internet Business Systems © 2019 Internet Business Systems, Inc.
25 North 14th Steet, Suite 710, San Jose, CA 95112
+1 (408) 882-6554 — Contact Us, or visit our other sites:
TechJobsCafe - Technical Jobs and Resumes EDACafe - Electronic Design Automation GISCafe - Geographical Information Services  MCADCafe - Mechanical Design and Engineering ShareCG - Share Computer Graphic (CG) Animation, 3D Art and 3D Models
  Privacy PolicyAdvertise