Accellera’s Chair, Shishpal Rawat, talks about the expanding Accellera-IEEE relationship, the need for portable stimulus and why SystemJava would be difficult.
By John Blyler, Editorial Director
During our talk at DVCon2016, Shishpal Rawat, Accellera Systems Initiative Chair, presented an update on the organizations recent activities. This update focused on the status of current standards including portable stimulus and a new UVM-SystemC library, Accellera’s expanding relationship with the IEEE via the Get program and the global expansion of the DVCon events. For the purpose of this article, I’ll focus on two topics. First is the differences between specifications and implementation, which is helping to define the relationship between the IEEE Standards body and Accellera. The second topic is the newest standards effort in the Portable Stimulus Working Group. What follows is a portion of that interview. – JB
Blyler: Yatin Trivedi, the General Chair for DVCon 2016, recently noted that the Universal Verification Methodology (UVM) is both a documented standard specification and a proof of concept library. That separation of specification documents and implementation is the new way that Accellera is working with the IEEE. Please explain this separation between the standard as a document and the standard as an implementation.
Rawat: UVM 1.2 is a new developing standard that Accellera has donated to the IEEE. It has not become an official IEEE standard yet. The standard itself has two aspects: One is the specification which includes a class library. The other is the implementation of the standard which deals with the proof of concept, that is, a typical implementation. Both the specification and the implementation need to match each other although at this stage there is sometimes a slight give and take to make sure things are right.
Blyler: This seem like an interface issue?
Rawat: Yes. Sometimes we have to do some experimentation with the software itself, which is what the working group actually does. The goal for Accellera is to have the proof-of-concept software ready at the same time as the specification is approved.
Blyler: Will the implementation proof-of-concept reveal something that needs to be adjusted in the standard?
Rawat: Sometimes, but we would like the specification to be the driver. Otherwise, it becomes very difficult. So we expect UVM Working Group to finish all of its work by mid-2016. Hopefully, the proposed IEEE standards can be balloted, voted upon and approved quickly to become an IEEE standard by the beginning of 2017.
Blyler: Let’s move on to the Portable Stimulus Working Group (PSWG) activities. What’s happening there?
Rawat: The PSWG is currently evaluating contributions to assist in defining a portable test and stimulus specification language that can be used to generate stimulus throughout the design process. The PSWG is our newest effort. It’s trying to use stimulus generated in the early design phase later in the verification phase. There are many tools and technologies that exist today. All have their own way of generating stimulus. Can we create a language that allows us to write once but use many times in these environments as we step through the various phases of simulation and the design processes?
Blyler: What would that language look like?
Rawat: It would be a specification language with generators to deal with different environments like simulation, emulation, virtual platforms and post-silicon. The initial scope for the PSWG will be to define a portable test and stimulus specification language that can be used to generate stimulus for multiple target implementations.
The Portable Stimulus Working Group intends to have a draft standard specification in early 2017.
Blyler: A few years ago, I talked with Dennis Brophy – past Accellera and IEEE Standards Chair – about the need for a Java interface as many new college graduates don’t know C/C++. Since most of the Accellera standards have C extensions (like SystemC) to you foresee any issues in the future?
Rawat: As you know, SystemC is an attempt to augment C to bring it into the domain of hardware. Software typically runs sequentially, one statement at a time. Hardware is different. In hardware, you have a variety of elements that all must work concurrently. They all do something at a given point in time, whether you want them to or not. That is why the (design-verification) language must mirror the hardware behavior. In the future, somebody will still have to learn a hardware description language (HDL) if they want to design chips. If you want to have a Java interface for the HDL, then someone would have to put the effort to make it HDL friendly. That would be a lot of effort.
Blyler: So we shouldn’t expect “SystemJava” any time soon?
Rawat: Probably not. SystemC is an attempt to make C more hardware oriented using class libraries, concurrent signals, and so on. Concurrency is the biggest challenge. That is the real difference between sequential software versus concurrent hardware. Unless you are able to model it accurately, you would end up with incorrect operation of your device. It is very difficult to take the traditional software engineer and turn them into a hardware engineer.
Blyler: Someone will have to learn a HDL at some point.
Rawat: Yes, someone must know it. You have to be able to model concurrency and simplify it (hide it) for the hardware programmer.
Blyler: Thank you.