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

  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.

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.

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.

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