RE: supporting DPI in VHDL - possible scenarios for implementation

Hi Per,

 

Please review my notes embedded in the email. I yet think that now is
the time to focus on SCE-MI 2.0 for SystemVerilog first as after several
months of email and verbal discussions, we only clarified the issues (as
your big picture email reflects), but haven't come a bit close to
solving them for Verilog and VHDL.

 

Sorry for my delayed response due to vacation and the need to do the
usual email catch-up following that.

 

Shabtay

 

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

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

>Sent: Wednesday, October 19, 2005 7:33 AM

>To: itc@eda.org

>Cc: bojsen@zaiqtech.com; itc@eda.org

>Subject: RE: supporting DPI in VHDL - possible scenarios for
implementation

> 

>Hi Shabtay,

> 

>I'd like to look at the bigger picture of defining a function based

>interface for VHDL and traditional Verilog (by that I mean all Verilog

>versions prior to SystemVerilog).  You have been unwilling to agree

>to the function based interfaces proposed by Mentor for VHDL and

>Verilog on the grounds that you do not know of a way to implement them

>without source code regeneration.  For the sake of argument, let's

>assume the worst case: it is indeed not possible to avoid source code

>regeneration of some form.  Then it seems to me that there are two

>conflicting goals/principles at play here:

> 

>  1) The principle that SCE-MI 2.0 should have a uniform interface

>     across all HDL languages (modulo syntax, of course).

> 

>  2) Your principle that source code preprocessing/regeneration is

>     bad.

> 

>As you have pointed out you view (2) as just as important as (1).  You

>put forward a concern for user's ease of debug as a motivation for (2).

>You also agreed that (1) is desirable.  Correct so far?  

[Shabtay] Yes, I agree so far.

 

Let me take

>it a little further.  It seems to me, you are implicitly arguing that

>users are willing to give up (1) because of (2).  Or more concretely,

>you seem to be saying that users will not be interested in a function

>based interface for VHDL if the implementation has to preprocess

>their VHDL code and source level debugging is affected.

> 

>Let's consider two classes of users: (a) IP developers, (b) end users:

> 

>  a) If we do not have (1), IP developers that intend to support more

>     than one HDL including SystemVerilog would be forced to develop

>     and maintain at least two different software sides.  

[Shabtay] I don't think that this is a negative as you describe. It is
possible that variations could be addressed using localized 'ifdef's
sprinkled in few location in the SW side code and users will have to
specify which HW side HDL is being used. The SW side API can be made
very close or maybe could be unified. It is too early to tell due to the
fluidly of the Mentor proposal in many areas at this time.

 

You could

>     argue that they could use the macro-based interface which would

>     be the same accross all HDLs, presumably.  However, this is

>     unlikely as IP developers that want to offer a simulation only

>     solution would be more likely to prefer SystemVerilog DPI as it

>     does not require a third-party library.  I predict this would

>     lead to very limited support of VHDL and traditional Verilog by

>     IP vendors.

[Shabtay] My data is somewhat different. I think that it is yet to be
seen what IP vendors will prefer to choose.

 

>  b) If we do not have (1), end users that use VHDL or traditional

>     Verilog would be forced to write their software side in a way

>     that would not carry forward to SystemVerilog DPI or even a

>     future VHDL DPI.  Yes, their code would continue to be supported

>     for some time by SCE-MI implementations, but they would not be

>     able to bring their code up on standard SystemVerilog or

>     VHDL-with-DPI simulators.

[Shabtay] End users, if these are not IP developers, are quite shielded
from the interface used inside the transactors. I am not sure I
understand your point here.

> 

>Here is how I see the evolution of the function based interfaces on

>simulators over the next few years: traditional Verilog will go away

>as it will be superceded by SystemVerilog, i.e., the new Verilog.

>VHDL will gain its own DPI which will then make the current

>attribute style proposed by John obsolete.  So over time the code

>regeneration issue disappears.

> 

>Given such a roadmap I would expect users to prefer chosing the path

>that has a better change of longevity, i.e., function based interfaces

>based on DPI, regardless of having to deal with inconveniences such as

>code regeneration in the short term.  Of course, there are a host of

>other reasons for users to prefer function based interfaces such as

>functions being more natural from a software development perspective

>than macros.  Russ can probably list a few more.

[Shabtay] Even if I agree with your roadmap, and assume that this is the
trend for the next 3 years, I disagree that longevity should take
precedence. Nothing prohibits us from making incremental changes in
SCE-MI that are compatible with market actual progression rather than
predicting on how it will involve. We need to support customers with
solid solutions in the next 3 years and I'm afraid that code
regeneration is NOT an option for Cadence.

> 

>I would suggest that we survey the user population out there and

>ask them what they would choose:

> 

>  i)   Function based interfaces on all three HDLs possibly with the

>       inconvenience of code regeneration on VHDL and traditional

>       Verilog.

> 

>  ii)  No code regeneration required, but at the cost of no function

>       based interfaces on VHDL and traditional Verilog.

> 

>  iii) Don't care because I am not planning on using any new SCE-MI

>       2.0 features.

> 

>Unfortunately, our sample of users, at least the ones participating

>regularly, is too small to get any meaningful answers, so we have

>to go with what we think is reasonable as a committee.

[Shabtay] Actually, believe it or not, we have investigated many of
these attributes with some of our key customers. I was surprised that
the value placed on functional interface was so low given that the
objectives we set could be met with instantiation based approach. This
also applies to some SystemVerilog customers and not only to these using
only VHDL or Verilog 2001.

I cannot disclose who the customers are and would leave it to customers
who wish to be involved to decide what they wish to convey on the
reflector.

 

Given that, and given that we are already on a path where the majority
on the committee would like to pursue a DPI function-based API for
SystemVerilog, the best solution I believe we should pursue at this time
is to work on SystemVerilog first, release this work in SCE-MI 2.0 as
soon as possible and evaluate how customers would be receptive to it. We
should defer the issue of functional API for Verilog and VHDL to SCE-MI
2.1 time frame and bring the most viable solutions to the table at that
time.

 

>Per

> 

>--

>Per Bojsen                                Email: <bojsen@zaiqtech.com>

>Zaiq Technologies, Inc.                   WWW:
http://www.zaiqtech.com

>78 Dragon Ct.                             Tel:   781 721 8229

>Woburn, MA 01801                          Fax:   781 932 7488

>