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

Hi Per,

 

My notes interspersed.

 

Shabtay

 

>-----Original Message-----

>From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of Per
Bojsen

>Sent: Tuesday, September 20, 2005 7:12 PM

>To: itc@eda.org

>Subject: 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.

[Shabtay] We would be satisfied if it at least addressed the latest
versions of Verilog and VHDL.

> 

>> - 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?

[Shabtay] Simply, it should not override any of the principles I listed.

> 

>Note, SCE-MI 1.1 has this property already.  Note, SCE-MI 1.1 supports

>SystemVerilog inherently via the Verilog subset.

[Shabtay] Agree.

> 

>> 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.

[Shabtay] I didn't state that defining a function based interface in old
Verilog/Verilog 2001 and/or VHDL is impossible. John's latest proposal
doesn't meet the principles I outlined. If there are other proposals
that do, we should evaluate them.

> 

>> "- 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.

[Shabtay] Good goal if it can be reconciled with all other principles. 

> 

>> - 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? 

[Shabtay] Correct.

 You are not disagreeing that we should support the

>function based interface on all three languages *if* it is possible

>to define it, correct?  

[Shabtay] Correct if defined such that it meets the principles that we
have outlined. The latest attributes proposal does not meet these by our
analysis conveyed in my previous email.

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?  

[Shabtay] Correct again.

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.

[Shabtay] I already addressed.

> 

>> - 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)?

[Shabtay] Currently there is no viable function based approach for all 3
languages. I don't see a reason to address your question as we don't
have means to contrast the macro based approach against a viable common
function based approach.

> 

>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.

[Shabtay] I responded to this in my email responding to John.

> 

>> 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.

[Shabtay] We do not think that it does. Review my previous email to John
as to why.

> 

>Per

> 

>