RE: supporting DPI in VHDL - possible scenarios for implementation

Hi Shabtay,

> Your proposal is based on using clock control SCE-MI 1.1 in
> simulation.

I showed you one possible implementation to answer you challenge
to show an implementation that does not require modifying the
simulator compiler.  Do you at least agree that implementing
a function-based interface on top of SCE-MI 1.1 as outlined is
possible without modifying the simulator compiler?  You do not
have to like the solution to agree :-)

> Such an implementation now forces us back into viewing time
> progression on the HW side by only using cycle stamps.

Strictly speaking cycle stamp is the only concept of time that exists in
SCE-MI, so this is not a new issue.  

> This imposes significant restrictions on the user.

I disagree about the restrictions being significant.  The whole purpose
of SCE-MI is to provide a fast transport layer from a software-based
verification environment into a simulation engine that in general will
be some sort of hardware accelerated engine, but may also be a software
simulator.  If you look at the whole range of engines out there, on most
of them only cycle stamping (counting clock cycles) makes sense as a way
to measure time.  SCE-MI users will be aware of this.  IP vendors that
write portable models will be aware of this, because they should/will
use the SCE-MI API only and there is no GetSimTime() call in SCE-MI.
So the biggest problem really is that your waveforms may look funny
depending on how the SCE-MI 1.1 subset is implemented.

It has been stated before that it is possible to implement SCE-MI 1.1 on
software simulators in a way that takes care of this problem, i.e., that
allows waveforms to be viewed such that periods where cclocks are
stopped appear as zero simulation time.  This is the root of your
problem with using SCE-MI 1.1 as a foundation for implementing a
function-based interface, right?

> Any trace data and any system tasks that uses time will see a
> different time from the one reported by cycle stamp.

I don't believe SCE-MI supports system tasks let alone system tasks
that use time, so the real problem is how waveforms appear.

> Practically, the simulation use model will be highly restrictive.

Actually, it will be no more restrictive than running on any emulator
with SCE-MI.  So is this unacceptably restrictive?  Given that the
goal of supporting SCE-MI on simulators is to allow development and
debugging of SCE-MI-based environments that will run on emulators
eventually, I don't think so.  

> Neither the macro based approach across all HDLs that Cadence proposed
> in the past nor the existing DPI based proposal for SystemVerilog
> imposes such a restriction on the end user.

Actually they do in part due to the backwards compatibility with
SCE-MI 1.1.

>  Why would we impose it only on Verilog and VHDL users?

Well, do not forget that what we are talking about here is just one
possible way of implementing the function-based interface in Verilog
and VHDL.  There are other ways that do not use SCE-MI 1.1 clock
control.  For instance, instead of replacing the function calls with
SCE-MI 1.1 infrastructure you can replace it with some PLI-based
infrastructure without any clock control mechanism.  Calls happen
in zero time solely by virtue of having the simulator thread wait
for the results from the software side.  I see now that it was a
mistake to show you a SCE-MI 1.1-based solution; I had assumed that
using SCE-MI 1.1 would be a nice basis due to it being well understood.

Regardless, any vendor that wants to implement SCE-MI 2.0 on a
simulator must address the SCE-MI 1.1 subset and hence deal with the
clock control issues you talk about.  But that is an issue completely
separate from whether a function-based interface has any merit on
`old' Verilog and VHDL.  Do you agree?

> We need to distinguish between modifying user’s source code and
> mandating that users comply with a certain methodology. Independent of
> the API that is being used, users will have to build transactors,
> define the hierarchies and make connections to certain API resources
> in a certain way. Everything that you have described so far falls into
> the methodology of using the SCE-MI 1.1 API and none requires
> regeneration of the user’s environment.

I would agree with you but I bet that we would not be using the same
definition of `regeneration of the user's environment', then.  For
example, in VHDL to make a SCE-MI 1.1 environment simulatable you need
to connect both user-visible SCE-MI 1.1 infrastructure as well as
implementation specific infrastructure from the guts of the macros to
whatever central block does the clock control, for instance.  This
could entail adding ports to macro instances, adding extra signals to
the user blocks that instantiate macros, threading these signals up
and down the user's hierarchy, and adding one or more implementation
specific blocks to the user's hierarchy.  Does this constitute
regenerating the user's environment?

> Different implementation can do different things. The macros “guts”
> for example could be fully generated by the infrastructure linker or a
> parameterized library may be linked in.

This is of course irrelevant to what happens to the code that
instantiates these macros.

> The strongest reservation I have to modifying users’ code is the
> implication on debug. [...] It is not acceptable to modify their code
> (even if we state that the modified code is equivalent) and ask users
> to debug a modified code regenerated by our application. Do you still
> think that this is acceptable to simulation users?

Oh, yes, I definitely disagree with you here.  Anyone who is used to
C/C++ programming is familiar with this.  The code that the compiler
sees is a pre-processed (or regenerated, if you will) version of
the code the user wrote.  This is nothing new.  It is up to the
implementation to make the impact on debug as small as possible.

> But I have not seen yet a proposal for a functional bases API that its
> implementation meets these principles.

You did not really answer my question, so let me rephrase.  The
function-based interface proposals you have seen so far fail to
meet your principles.  Is it correct that the only principle they
fail to meet is the `no code regeneration' principle?  If not, what
other principles do they fail?

I'd like to note that your `no code regeneration' principle has not
been agreed upon by the committee.

> Now, it is my understanding that you also support Russ idea to focus
> on SystemVerilog for SCE-MI 2.0 and deal with Verilog and VHDL for
> SCE-MI 2.1.

No, I do not agree with this as stated.  I do agree that we should
probably focus on SystemVerilog for a while, but I do not agree that
we should drop `old' Verilog and VHDL from 2.0.

> Should we then stop discussing this at this point and focus on
> SystemVerilog for SCE-MI 2.0?

No :-)  I'd like to see your macro proposal so I can evaluate your
claim that it fulfills your principles by myself, for instance.

Per