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

Hi Shabtay,

> HVL was introduced to avoid extending the spec to SystemC specifically
> (actually based on your proposal).

My proposal was indeed to remove mention of SystemC from the spec,
but I did not intend for it to be replaced with HVL.  The problem
with the term `HVL' is that it is ill-defined.  For instance, does
`HVL' include plain old C code?  I suspect not, otherwise it is
not much of a restriction :-)

 > In my opinion if we don't clearly
> define our intent to extent SCE-MI use model beyond SystemVerilog and C,

So I wasn't proposing not to clearly define the extension.  I was
simply proposing to do it without introducing terms like `HVL'.
What I think we should do is to characterize the extension based
on only SystemVerilog and C in such a way that it allows the SystemC
usage we intend, but without getting into SystemC and HVL specific
details.  It would go something like this: an exported task may be
called from an imported context function; an exported task may also
be called from any non-context function when SystemVerilog is in
certain event regions, e.g., active or NBA.  Here, the simulation
vendors can provide input as to which regions are safe to include.
Let me know why such an approach to characterizing when exported
tasks/function can be called is not feasible, if it isn't.

I suspect it would be easier to characterize this without mentioning
HVL than defining precisely what we mean when we say HVL.

> 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. 

Fortunately, I was not proposing this at all.

>>   * 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.

What were you intending, though?  Were you including plain C/C++ in your
HVL definition?  If not, then your text actually prohibits plain C/C++
code from calling exported functions/tasks.  Since an HVL such as
SystemC can call C and C++ functions which in turn can call epxorted
tasks, we need to deal with that case as well.  So this introduces the
notion of call chains.  Your text also did not include zero-time tasks, BTW.

> [Shabtay] The key point is that simulation time (other than delta time)
> cannot elapse. 
> 
> Please propose how to replace 'immediately'.

Ah, it did not even occur to me that `immediately' referred to
simulation time . . .  This should probably be changed to use terms
such as `time advancement'.  Here is an attempt at rephrasing your
text for 5.7:

   DPI exported functions and non-time consuming tasks can be invoked
   outside a DPI-C context call chain only when SystemVerilog is in
   one of the following event regions: active, inactive, NBA, observed.
   Any call of a DPI exported function or non-time consuming tasks
   outside a DPI-C context call chain when SystemVerilog is not in
   the named regions leads to undefined behavior.

The actual list of event regions supported must be discussed and
checked with the simulator implementors.  I am sure this has plenty
of holes, but it should illustrate the concept that I am proposing.

BTW, your included comments in blue said that your text for 5.7
prevents calling imported functions from exported functions.  I
don't see how that is prohibited, because text only talks about
restrictions on calling exported functions.  In any event, this
restriction should already be in place in another section, right?

> 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.

We can avoid explicit mention of the pipes if we use the approach
I'm proposing.  On the other hand, if I'm using plain old C and
no VPI/PLI nor other vendor specific APIs, the only way to get
to C is to call an imported function from SystemVerilog, right?
A blocking send or receive call from the C side needs some thread
switching capability, but under the hood, the execution will go
back to the SystemVerilog side and eventually return to the C
side again via an imported call.  So it seems that adding specific
language for pipes here is redundant and unnecessary.

> [Shabtay] Obviously it is after elaboration. But I think that DPI
> imported function calls can only happen after the user issued a run
> command.

A `run command' is part of a simulator implementation and not something
we can refer to in the spec.  Some simulators may not have run commands.
We should use the terms the Verilog and SystemVerilog standards use.

> [Shabtay] I am open to suggestions on replacing the word 'linking' with
> another term.

I don't think the paragraph that uses this term is even necessary.
Once we carefully characterize what we support in terms of only
SystemVerilog and C, we will not need this paragraph.

> [Shabtay] Here is the compete list we agreed upon. Are you proposing
> that I include the 5 missing?

Actually no.  Instead we should state that this section is
referring only to those utility functions that have the problem,
i.e., those that deal with contexts.  The other utility functions
are not affected since they are trivial and do not affect or
manipulate contexts.  The way you phrased it, it could easily
be misunderstood to disallow those other trivial utility functions.


Per