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

Hi Per,

First the main thread tying all your comments is around HVL.

HVL was introduced to avoid extending the spec to SystemC specifically
(actually based on your proposal). In my opinion if we don't clearly
define our intent to extent SCE-MI use model beyond SystemVerilog and C,
we should not define any extensions at ITC and suffice with choosing the
DPI subset mandated by SCE-MI 2.0. Any requests to broaden what's
considered undefined in the SV LRM for SystemVerilog and C should be
submitted to the SV working group.

I think that the reason that we are allowed to define what is considered
undefined in the SV LRM is because we are extending the user model to
HVLs beyond the scope of the SV LRM. 

If we chose not to take this path, EDA vendors will provide their
proprietary extensions and their modeling guidelines as they deem
necessary in their implementation and user code working in one
environment will surely break with another and vise versa. 

On other topics you made some good comments, but given where we are in
the review phase, let me suggest that you actually insert your proposed
changes in the language I sent. 

I hope that my responses bellow will clarify my intent to allow you
recommend specific language changes (similarly the explicit inline
changes I proposed to John's pipes section).

Thanks,

Shabtay

>-----Original Message-----
>From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of Per
Bojsen
>Sent: Wednesday, October 25, 2006 10:10 AM
>To: itc@eda.org
>Subject: 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.
[Shabtay] See above. This needs to be discussed

>
>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?
[Shabtay] Definitions can be added if choose to keep these chapters. 
>
>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?
[Shabtay] The key point is that simulation time (other than delta time)
cannot elapse. 

Please propose how to replace 'immediately'.
>
>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?
[Shabtay] Good question. The intent here is to allow a model using both
scemi pipes and DPI to call exported functions. W/o this sentence the
HVL model will not be allowed to call an exported function unless the
current call chain is initiated from an imported function. 

I think that the later could be defined, but is too restrictive. For
example the C side can receive an error embodied in the message an may
want to interrogate the HW side using an exported function. W/o stating
the above, such a call is not allowed.


>
>Also, the term `simulation run time' is vague.  I assume you mean
>after elaboration?
[Shabtay] Obviously it is after elaboration. But I think that DPI
imported function calls can only happen after the user issued a run
command. The key point is that you cannot call exported function before
an imported function call is allowed.

Maybe you or others can propose a better term. 


>
>> 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.
[Shabtay] My intent was indeed undefined as I don't want to enforce
error checking. I agree with you comment and I'll fix this. 
>
>> 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.
[Shabtay] I am open to suggestions on replacing the word 'linking' with
another term. 
>
>> 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.
[Shabtay] Here is the compete list we agreed upon. Are you proposing
that I include the 5 missing?

  svScope svGetScope(void)
  svScope svSetScope(const svScope scope)
  int svPutUserData(const svScope scope, void *userKey, void *userData)
  void *svGetUserData(const svScope scope, void *userKey)
  const char *svGetNameFromScope(const svScope scope)
  svScope svGetScopeFromName(const char *scopeName)
  int svGetCallerInfo(char **fileName, int *lineNumber)
  const char *svDpiVersion(void)
  svBit svGetBitselBit(const svBitVecVal *s, int i)
  void svPutBitselBit(svBitVecVal *d, int i, svBit s)
  void svGetPartselBit(svBitVecVal *d, const svBitVecVal *s, int i, int
w)
  void svPutPartselBit(svBitVecVal *d, const svBitVecVal s, int i, int
w)
>
>Per
>