RE: supporting DPI in VHDL - possible scenarios for implementation

Hi Shabtay,

> Item 1 - You stated that “Modifying the simulator compiler is not
> required” – My response is quite simple. Good, show me how you do it
> on Verilog 2001 simulator. I don’t see it.

One possible implementation is to layer it on top of SCE-MI 1.1.  There
are three cases:

1) Imported function calls.  Replace each imported function call with
an input port, output port, and a clock control macro.  Map all input
arguments to the message of the output port.  Map all output arguments
and the return value to the message of the input port.  Stop the clocks
using the clock control macro when an imported function call happens.
Send the output message to the software side and wait for the input
message.  The input message carries the return values and the output
arguments.  When the input message arrives, start the clocks again
and continue on.

2) Exported function calls [zero time by definition since it is
a function]: Use an input port to carry input arguments to the
exported function and to indicate when the function should be
invoked.  Stop the clock using a clock control macro when the
input message arrives.  At the end of the call, send the output
arguments and any return value to the software side using an
output message and start the clocks.

3) Exported tasks [may be non-zero time]: This is an extension of
(2) but is a little more tricky as the clocks need to be allowed
to run during the execution of the task.  Now, only stop the clock
while communicating with the input and output ports, that is, stop
the clocks while waiting for the dual ready handshake to complete.

Since the above is based on SCE-MI 1.1, it is trivially backwards
compatible with SCE-MI 1.1.

The infrastructure linker analyzes the HDL source and finds all
the imported and exported calls and can do the work to insert
the appropriate infrastructure as described above.

> Item 2 - No code regeneration – Each API dictates the methodology by
> which the models (transactor) need to connect to the interface
> (function-based or macro-based). You are telling me that I need to
> emit new code in SCE-MI 1.0 (or macro based approach for Verilog and
> VHDL). Please explain why? To my knowledge, once I have created set of
> files that connect to SCE-MI macros, I can link in other files that
> which constitute the “guts” (by instantiation) w/o touching the
> original files. Is this correct or not? If not, why not?

This is not correct because the macro interfaces as defined in SCE-MI
1.1 are missing the infrastructure connections required to implement
items such as uclock and ureset.  This is especially a problem in VHDL.
Also, somewhere you need to add the global clock generation and reset
infrastructure.  For instance, all the ready for clock signals must
be considered at once to determine when to stop and start the cclocks.
Show me how to add this infrastructure without emitting some code and
without modifying some of the user's code.

There are a few key points that we seem to be stumbling on here:

1) Shabtay's no code regeneration requirement.  So far I have not heard
a compelling argument for why this should be a requirement.  The only
semi-compelling argument I've heard so far is that users might be
inconvenienced by having to run the infrastructure linker before
compiling their source code, and if the infrastructure linker is
implemented using something like VPI, they'd of course have to compile
their code twice.  However, that can easily be remedied by writing
a simple wrapper script around the simulator that takes care of those
details.

2) The function based approach requires code regeneration, but the
macro based does not.  While I think I agree with Shabtay that some
degree of source code regeneration/pre-processing is required for the
function based approach, I do not agree that it is not required for
the macro based approach.

Shabtay, is your opposition to the function based approach solely
based on the opposition to code regeneration?  If not, could you please
list what other reasons you have for opposing the function based
approach in VHDL and regular Verilog?  For VHDL, I guess one other point
is that what we would be standardizing on would be an interface that
is surely different from any DPI-like interface that might be added to
VHDL in the future.  But on the other hand, I do not think we can wait
for the VHDL committee to add something like that.  I think it would
be quite useful to have an interim solution based on the attributes
which we can then deprecate once VHDL-DPI becomes available.  I doubt
that will be within the next 5 years, though :-)

Thanks,
Per