On SystemVerilog VIP Interoperability

As I mentioned last week, Verilab is now a member of Accellera.  I've been involved with the newly formed Verification IP Technical Standards Committee.  One of the first objectives of the committee will be to create a Design Objectives Document, otherwise known as a DOD.  Some possible objectives of the committee were presented yesterday during the weekly TSC conference call which spawned an email thread between some of the participants (including myself).  The issue being - what is the scope of the committee?  Is it to come up with a common methodology to be used by all vendors?  Is it to create an API to be used to allow communication between competing methodologies?  Or, is the purpose of the committee more basic than that? 

One concern that came up is whether the issue of SystemVerilog language support between simulators would be addressed.  As many of you are painfully aware, each of the EDA vendors has selected a subset of the SystemVerilog language to implement.  Some vendors have implemented numerically more features than others, but I'm not sure that any one vendor has an implementation that could be considered either a subset or a superset of any of the others. The problem as I see it is that even if a standard library definition or API could be defined such that the final interoperability solution ran on all simulators, chances are good that any VIP implemented on one simulator would have to be customized in order to be ported to another.  In my mind that undermines the whole intent of having a standard for interoperability.  Now, if a vendor wants to implement some cool new features that are not part of the SystemVerilog spec (such as AOP or support for covariant return types) I have no problem with customizing VIP accordingly to take advantage of them.  I do have a problem, though, if the cool new features being referred to are really part of the standard itself. 

Perhaps I've got it wrong though.  Maybe what people really care about is the methodology itself and are ok with ifdef'ing their way around incompatibility issues on the language side.  Or not.  How does this work on the C/C++ side?  I know that gcc and Microsoft Visual C++ each have advanced features not found in the other, but when you look at the core language and the standard template library, could you easily write generic code that would work with both or would you expect to include significant customizations (again, forgetting about advanced compiler features or differences between Windows and UNIX/Linux platforms)?

I'd really appreciate feedback from readers on this - I'll be sure to pass along any comments to the rest of the TSC.

Comments

[Shalom Bresticker]

One needs to remember that unimplemented features of the language are largely temporary. Each vendor chooses to implement language support according to some order of priority due to their limited resources. These priorities are determined in large extent by user demand. It is more a question of time.

When the SV language standard was developed, it also was not yet supported by the vendors. The standard dictated to them what to do. If one only looked at what is currently supported, nothing would ever progress.

I think that if a standard methodology is supported, that will cause the vendors to move to support it. It is the lack of a standard that perpetuates the differences.

[JL Gray]

Thanks Shalom. I guess there are some possibilities here:

1) A reference verification methodology library is created to be the standard, and that single source of reference code is meant to run on all simulators. Vendors must support all of the constructs used by the library. (still probably a subset of the SV language). If I was an IP vendor or someone interested in using multiple simulators I'd want to stick with this subset.

2) A reference API is created that defines what the underlying library should look like, but no reference implementation is created. Vendors simply have to support language features needed for the header files of the library. Other key features of the language may go unsupported in some simulators. Again, an IP vendor would want to take advantage of the shared subset of language support, but that subset is potentially much smaller.

3) A mechanism for communicating between libraries is created, but libraries themselves are not merged. Simulator vendors may or may not choose to even support compilation of the competing library.

Option 1 probably causes the vendors to support a much more common subset of the language than the others.

Option 2 does better, but there may still be a lot of pain remaining migrating between environments.

Option 3 provides a mechanism to communicate but it may not help much because the existing libraries can't run on some simulators. Of course, if the source code and appropriate licenses were available to the EDA vendors they could (and presumably would) update their simulators to support language constructs used by the other methodologies.

I get your basic point though - that eventually all of the vendors will converge on a common set of features they support. I'm just wondering if the process can be sped along somewhat via the Accellera effort.

JL

[Dustin Johnson]

The biggest difference in your example of C/C++ compilers is that for the most part the compilers have a large set of shared functionality. The biggest issue in the SV tool support is that the shared functionality of the tools isn't comparable enough to reasonably mandate a set of required functionality without possibly alienating one of the existing major methodologies. Regardless of existing methodologies, the committee should be able to analyze the SystemVerilog specification in it's current state and determine which sections are required for good reusable VIP in hopes of fostering interoperability. However, isn't this the whole point of having a SV standard already?

If we had proper interoperability, then the gcc/vs comparison would hold as you could potentially use preprocessor or other design practices to port VIP between simulators and methodologies. Any kind of abstract 'drop-in' VIP support is going to require OOP practices, so it'd be a good starting point if we had (full working) templated class support across simulators.

[Mike Mintz]

On the c/c++ side, it took 20 years of pain before we had something approaching a common standard. And that was with cfront as a reference implementation. And millions of programmers.

Nowadays, it's pretty simple to write portable c/c++. Truster's (my company) open source verification library runs on both gcc and MSVCC (and many versions of those compilers).

Note that while many companies do write portable applications (like all the simulator vendors!), the software industry has almost no IP. That should tell us something.

SV is much more complicated. First we do not have millions of programmers demanding a common set. Second, the language is still in major evolution. Take a look at the e-mail of the SC-EC, SC-BC, et. all. Third, their are political forces at work.

To attempt anything beyond a "standard test suite" is premature. I worked with Ada, and they had a conformance suite that all compilers had to pass to use the Ada name.

A common methodology can be done. Trusster has an SV implementation that runs on three compilers. And yes there are ifdefs in there.

Hope this helps.