RE: supporting DPI in VHDL - possible scenarios for implementation

Hi Shabtay,

> “The vendor can modify their compiler so that the empty procedure is
> automatically replaced directly with generated native code that hooks
> into an infrastructure implementation that directly communicates to C
> using whatever VHDL foreign language interface (FLI) that is supported
> by that vendor.”

This was your quote of John's proposal.  Note that it says the vendor
*can* modify their compiler.  This implies a choice not a mandate.
John is simply pointing out some possible optimizations an
implementation can take advantage of.

> Please define which vendor you are referring to; simulation vendor or
> acceleration/emulation vendor?

The only vendors we are interested in in this committee are SCE-MI
vendors.  In this case John is talking about SCE-MI vendors that also
happen to be simulation vendors and who are interested in providing
an integrated solution, i.e., essentially a simulator with builtin
SCE-MI support.

> As to a simulator vendor; he has nothing to do with SCE-MI, and it is
> not reasonable to require him to change a compiler which BTW was not
> required in SCE-MI 1.1 and when using in general a macro based
> approach.

And he is not required to do anything to support SCE-MI in 2.0 either.
The SCE-MI 2.0 implementation can be provided as a third-party addon
that runs on top of the simulator.

> Russ indicated that quite a “mini-IFLC” can generate EEE-compliant
> VHDL code (and I assume Verilog 2001 code). If this is as simple as
> that, can you take your source code example with DPI import and export
> declaration, use your proposed attributes based approach and empty
> function calls, and show in Verilog 2001 that the library that you
> generated by the infrastructure linker (implementing the communication
> channels underneath) can be instantiated from the empty function calls
> w/o modifying the source code or modifying the simulator compilers?

What do you mean when you say `w/o modifying the source code'? Is this
your `no code-regeneration' requirement or are you simply stating that
the source code should not have to be rewritten by the user before
it can be passed through the infrastructure linker?

> Can you show how you implement transaction communication between the
> HDL and C environments for import and in particular export function
> using standard API in simulation? For the latest, if you want to show
> how you implemented this on top of SCE-MI macros, this will also prove
> the point.

This is easy to do but it won't satisfy your `no code-regeneration'
requirement.  After all, replacing function calls with SCE-MI macros
and associated infrastructure is going to require some modification
of the HDL code.  I assume you are aware of that so is code regeneration
actually OK?

Per