RE: SCE-MI 2.0 HDL Support (Re: Meeting minutes 050825)

Hi Shabtay,

> I rephrased 'old Verilog' to 'Verilog 2001' as I disagree with naming it
> 'old Verilog'.

Ok, you knew what I meant.  Although, this leads to another little
wrinkle: have we actually decided that we are supporting *only*
Verilog 2001 and not older versions?  The same goes for VHDL.  I suppose
we should only limit ourselves if it makes a difference.

> - The choice of HDL should be transparent to the software side, i.e.,
> the user should be able to use Verilog 2001, SystemVerilog, and VHDL
> interchangeably without having to rewrite the software side 
> 
> [Shabtay] - Very important goal that should be attempted, but one that
> cannot override the other principles.

I think this goal should have very high priority and therefore should
override most other principles where they conflict.  When you said
`the other principles' were you just referring to the principles you
commented on or are there others you have in mind also?  Could you
list which ones you believe should not be overridden by this goal?

Note, SCE-MI 1.1 has this property already.  Note, SCE-MI 1.1 supports
SystemVerilog inherently via the Verilog subset.

> I expect that a modern reusable transactor will be composed of proxy
> model and BFM pairs modeled in coordination.

An IP vendor that wants to support 2 or all 3 HDL languages would see
the benefit of being able to use the same software side with all
versions of the hardware side.  I strongly suspect that most IP vendors
would be less inclined to support VHDL if they had to develop another
software side for it.  This is purely based on the Verilog/VHDL market
share ratio and the fact that there are solutions allowing Verilog
models to be used in VHDL environments.

> If single SW side interface for all 3 languages could not
> be created or if this will present too much of a tradeoff (mainly for
> SystemVerilog users), I would support the notion of slightly different
> SW side APIs for each HDL. 

Well, yes, if it turns out we cannot achieve the goal I stated, then
we'd be forced to accept a less than optimal solution.  Luckily, this
is not an issue since a function based interface can be created for
all three languages.  Most of the committee believes this.  I know you
are still analyzing this.  Hopefully we can convince you so we can
put this to rest.  It is probably worthwhile getting to an understanding
of why you think it might not be possible to define a function based
interface in old Verilog/Verilog 2001 and/or VHDL.

> "- Transactors containing BFMs in different languages can co-exist in a
> single verification environment."

The best way to allow for this is to make the software side agnostic
about the language used on the HDL side.  Basically, the software side
should not have to know what language the hardware side is written
in and vice versa.  Then it is easy to accomodate mixed-language
environments.

> - All three languages should have support for a function based interface
> based on SystemVerilog DPI
> 
> [Shabtay] - Disagree.

Is it correct to assume you are disagreeing that the only common
software interface the committee should pursue is the function based
interface?  You are not disagreeing that we should support the
function based interface on all three languages *if* it is possible
to define it, correct?  You are simply leaving a door open to other
interfaces in case the function based interface does not carry over
to old Verilog and/or VHDL?  I think this is an important point.  Please
let me know if you are completely opposed to a function based interface
on old Verilog and/or VHDL no matter what.

> - Avoid a hybrid approach
> 
> [Shabtay] - Disagree.

I think this disagreement is the same as the one above, correct?

> - If we decide to add the new macros Cadence is proposing they
> should be available in all three languages
> 
> [Shabtay] - Agree. But I'd like to emphasize that Cadence is not
> insisting necessarily on its proposed macros.

Can I assume you are saying that *if* the function based approach turns
out to be viable on all three languages *then* Cadence will drop its
proposal to add a new macro based interface (not necessarily as
described in the Cadence proposal, but macros of some sort)?

So is it fair to say that the only real disagreement we have at 
this point is whether it is obvious that a function based interface
with a common software side can be defined for all three languages?

> - SCE-MI 2.0 function interface extensions to `old' Verilog and VHDL
> should be expressible entirely within the legal syntax of those
> languages
> 
> [Shabtay] - Agree if you mean is that "SCE-MI 2.0 function interface
> extensions to SystemVerilog, Verilog 2001, and VHDL should be
> expressible entirely within the legal syntax of EACH language".

That is indeed what I meant.  Note, the Mentor proposal has all along
followed this principle.  Earlier, John was proposing to use special
comments (that he called pragmas) to indicate the imported and exported
functions in old Verilog and VHDL.  This is completely valid syntax.

> I would add that the Infrastructure Linker should not conduct
> source to source translation with complete code regeneration. Having the
> IL use standard design analysis technology (such as VPI) and create some
> extra library that will be added to the source is acceptable. 

This is an implementation concern.  The standard does not need to say
anything about whether an implementation needs to translate source or
use VPI to do the job.  I can't imagine a specification that would
require source translation in all possible implementations.  In other
words, it is always possible to implement the standard without
source translation.  On the other hand, there are probably ways to
write the standard such that using VPI to implement the IL would not
be possible.  It certainly seems worthwhile to ensure we do not go
down that route.  John's new proposal to use attributes would solve
this.

Per