The Power of "New Media"
Update - Birds of a Feather

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