RE: Some review feedback on the DPI chapter

Hi Per,

See my responses to your comments. Regretfully I understand you'll miss
the meeting today, as the SystemC/DPI (or C/DPI) link issue needs some
discussion.

>-----Original Message-----
>From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of Per
Bojsen
>Sent: Thursday, October 05, 2006 9:09 AM
>To: itc@eda.org
>Subject: 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] Actually the 060907 version is the one I sent. Note the String
is not mentioned in Table 2. The data types in Table 1 are presented
just for reference in the informative section.

Where do you see string being proposed in this document for SCEMI 2? 
>
>> [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?
[Shabtay] I am opposing to it in 2.0 but open to revisit this in 2.1.
>
>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] Good information. Let me look into it and also consult if
necessary with some SV experts at Cadence. I am taking the action to get
back to you on that.
>
>> [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] Not clear what language you want me to change in version 3
section 5.5 as far as nesting goes. My only dilemma left is if we should
discuss recursion or not as my last paragraph still mentions it. I can
keep it and restore the title, delete it, make it informative, etc. 
>
>> [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.
[Shabtay] If we stay within your proposed C boundaries we need to stay
within the SV DPI spec which is too restrictive. But if we extend it, we
need to be specific on the language/ threading package and whether it is
part of the simulation kernel. Based on my understanding the use model
cannot be universally extended to any threading package/language that
integrates with C.
>
>> 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.
[Shabtay] See above. But this topic deserves a discussion.
>
>Per
>
>