Re: Some review feedback on the DPI chapter

Hi Shabtay,

some comments to your comments.

> [Shabtay] Not in the version I originally sent. I think you were still
> looking at the current corrupted version. 

No, I was looking at the 060907 version from the previous dates column
on the web site.  This version is definitely different from the
corrupted version.  Hmm, how many versions are out there?

> [Shabtay] I reviewed the IM several times. My language addresses Russ
> requirement but leaves the flexibility to vendors to provide variety of
> options. But if you want to define a common default, we could define
> that X and z will be coerced to 0 and 1 respectively.

If that is what setting the B value to 0 gets, then that sounds good.
What do other committee members think?

Re: time-consuming tasks:

> [Shabtay] I suggest that we revisit this for SCE-MI 2.1. For now this is
> as far as I can go.

I was afraid you would say that.  But it needs to go on the record.  You
are saying categorically no to supporting time-consuming tasks in 2.0?

Re: whether to support non-time-consuming tasks

> [Shabtay] See my reply to John. 

Following the "trust but verify" principle, I was perusing the SV standard
to check your assertion that functions are a superset of non-time
consuming tasks.  To my suprise I discovered that the syntax for
functions allow wait statements.  In Section 12.3, p. 155 of P1800 it
is shown that a function definition can have zero or more
function_statement_or_null in its body.  If you read further in
appendix A it turns out that function_statement_or_null can be
a function_statement and a function_statement is just a statement
which includes wait, see Section A.6.3, p. 532.  Does this mean that
functions can be time consuming as well?  Unless I overlooked something
it looks like the syntax allows it.  So if this is the case we need
to add prohibitions against time consuming functions as well assuming
Cadence is categorically opposed to supporting time consumption in
exported functions/tasks.

`Old' Verilog did not have the void return type of functions.  For
that you would use a task.  So for people that are porting Verilog
code into a SystemVerilog DPI testbench it would be convenient if
we supported tasks.

> [Shabtay] The first paragraph caused confusion as my intent was to
> mention that recursion is not allowed. But thinking about this, this is
> already defined by DPI. As to the rest of the section, the intent is to
> define minimum level of nesting in SCEMI 2 but not prohibit vendors who
> wish to provide more than one level.

If that is what the committee agrees to I still think we only need to
say that trying to call an imported function from an exported task
leads to undefined behavior.  Before doing this we need to agree to
depart from the SCE-MI 1.x principle of specifying undefined behavior
in.  BTW, SystemVerilog does not follow this principle and states in
multiple sections that undefined behavior can result if users do
certain things, so there is definitely plenty of precedence for this.

> [Shabtay] This issue deserves a discussion. I don't think we can extend
> DPI support to any unrestricted threaded application and to SystemC that
> is not running on a shared simulation kernel.

Well I am actually saying the opposite.  All we should be talking about
is interfacing to C.  SystemC is C++ and can interface with C trivially.
Hence, SystemC will work with DPI.

> Even if the above can be
> done, it needs to be tested before such language is inserted to the
> SCEMI 2 spec.

What language is being inserted?  I was suggesting to remove SystemC
specific language.

Per