Re: mantis items 1456 and 1488 from sv-cc committee -

Hi Shabtay,

> /SCEMI 2 extends the scope of the SystemVerilog DPI use model by 
> allowing Hardware Verification Languages (HVL) linked with the C side to 
> call DPI exported functions. /

I don't think it is a good idea to use the term `HVL' in the spec.
The DPI part of the spec should talk about only SystemVerilog and
C.  We should write it such that any conclusions about how a particular
HVL can be integrated follows from the rules that govern SystemVerilog
and C.  I think this is fairly straightforward by referring to the
event loop of SystemVerilog and making statements such as the DPI
utility functions may not be called before elaboration and after
the simulator or emulator has finished the run.

If we use the term `HVL' we have to answer a bunch of questions
such as:

   * What is an HVL?
   * Is C an HVL?
   * Is C++ an HVL?

etc.  It seems like a can of worms to me.

> DPI exported functions can be invoked from HVL only at simulation run 
> time if the HVL call was made immediately after an imported function 
> call or immediately after an implicit or explicit flush in a SCE-MI 2.0 
> pipe that was initiated from the HDL side.

It is not clear what it means for a DPI exported function to be
called `immediately' after an imported function.  Taken literally
this seems to mean that the very first thing an imported function
would do is to call an exported function and that would be the only
allowed way to call exported functions.  Clearly that is not what
you meant.  So I assume it is OK to have some code such as if
statements, for loops, etc., before the exported function is called.
But what about call chains such as imported function F is called
which calls a C function G which calls H which eventually calls
an exported function.  Is that allowed?

Can you explain the reasoning behind the clause about pipe flush?
Also, is it the pipe or the flush that is initiated from the HDL
side?

Also, the term `simulation run time' is vague.  I assume you mean
after elaboration?

> Calling exported functions 
> from HVL under any other conditions is prohibited and may result in 
> undefined behavior.

If we say the call is prohibited we don't need to say it results
undefined behavior, but we may have to either implicitly or
explicitly state that it leads to an error being reported if that
is what we want.  If we don't want to specify that such usage be
detected as errors we should instead just state that the result
of calling exported functions/tasks when not within the boundaries
of what we support is undefined.  We do not need to say it is
prohibited.  I think if you state it is prohibited you're also
obligated to do violation checking.

> While SCE-MI 2 allows HVLs to call exported functions subject to the 
> above restrictions, it does not mandate the linking of any particular 
> HVL to the C side for an implementation to be SCE-MI 2 compliant. It is 
> up to vendors and users to decide which HVL if any will be linked to a 
> SCE-MI 2.0 C side implementation.

I think term `linking' is potentially misleading here because it
can easily be confused with software linking (the process that
turns compiled objects into a library or executable).  I don't
think this section is necessary especially if we follow my suggestion
of not using the term `HVL' in the first place.

> DPI utility functions can be called from HVL only at the simulation run 
> time if the HVL call was made immediately after an imported function 
> call or immediately after an implicit or explicit flush in a SCE-MI 2.0 
> pipe that was initiated from the HDL side. Calling DPI Utility functions 
> from HVL under any other conditions is prohibited and may result in 
> undefined behavior.

In this section HVL must include plain C which is another reason
why the term `HVL' is misleading.

> The DPI utility functions that can be called from HVL subject to the 
> above restrictions are/:/[SM1] <#_msocom_1> //
> 
> svGetScope()
> svSetScope()
> svGetNameFromScope()
> svGetScopeFromName()
> svPutUserData()
> svGetUserData()
> svGetCallerInfo()
> 
> Any other DPI utility functions cannot be called from HVL.

This is too restrictive.  There are a bunch of other DPI utility
functions that are supported as well.

Per