feedback SV DPI section of the document

Shabtay,

Here's my feedback on the DPI section of the document.

-------------------------------------------------
It was missing all of chapters 1&2 of the original revision 1.11
working document that I gave to Brian before he split things up.
These sections had some high level intro material.

Is this a separate document now ?  It seems to me these
sections should have been part of yours but perhaps not.

Most of this was informational anyway but it seems
to me we should carry it along for as long as we choose
to carry the informational text.

-------------------------------------------------
Section 5.1.1 paragraph 1
Section 5.1.2 paragraphs 1&2

In these paragraphs, there appears to have been some
deterioration of spelling and grammar from the draft
I gave Brian before the split-up. Seems like we should
restore this text from what was in there.

-------------------------------------------------
Removed informational sections

The document is missing 2.1, 2.2, 2,4, 2.5, 2.6
which were informational sections in the draft
given to Brian before the split up.

Although these are informational, again, it seems
like we should carry them along.

-------------------------------------------------
Removal of section 2.3 (of pre-split up draft)

The non-informational section 2.3 of the draft
before the split-up was removed. Although short,
this section gives a nice intro overview into the
concept of DPI function calls - with accompanying
diagrams.

-------------------------------------------------
Section 5.3

I see where you've placed a restriction on calling
tasks of any kind. I forget whether this is what
we decided or simply to restrict calling of
tasks that consume more than 0-time.

Seems to me we ought to allow calling of imported/exported
tasks that consume no time. We can discuss in
more detail in a meeting.

-------------------------------------------------
Section 5.5

I'm confused here. You're first saying you cannot
call imported functions from exported functions.

But then you're saying SCE-MI does not impose
any restrictions in supporting additional levels
of recursion.

Seems like we should have it one way or another.
The language is too ambiguous and complex here.

-------------------------------------------------
Section 5.7, last statement, 2nd paragraph

This is confusing:

"Calling these during the model creation phase
before simulation model is sane may result in an
error or undefined behavior."

Please be more specific here. I think your second
informational paragraph clears it up  somewhat.
In fact, I would say make this normal rather
than informational.

Use of the term "sane" is a bit vague. Let's
find a more precise term.

-------------------------------------------------
Section 5.7, last paragraph

Again, should we reconsider only putting this
restriction on time consuming tasks but allow
for 0-time tasks ?  Let's discuss in meeting.

-------------------------------------------------
Section 5.8 paragraph 2

After this statement,

"There are functions to allow the user to retrieve and
manipulate the current operational scope."

for completeness it might be nice to add this statement,

"There are also functions to associate an opaque user
data pointer with an HDL scope. This pointer can then
later be retrieved when an imported DPI function is called
from that scope."

-------------------------------------------------
Section 5.8 paragraph 5

This is the paragraph starting with,

"DPI utility functions can be called from SystemC only ..."

I see your intent here. I think you're trying to prevent
the use of scope related calls before the entire design
hierarchy (both SystemVerilog and SystemC)is elaborated,
to prevent accidental references to scopes that have not
yet been elaborated and may not yet be known.

By preventing such calls from an sc_module constructor, you're
guaranteeing this cannot happen.

Generally I think this is reasonable although our current
examples do allow this because they assume HDL hierarchy
has already been elaborated at SystemC construction time.
It may be this is not a valid assumption for all platforms.

If we do place this restriction, I suggest that you
be more specific with your wording. If I'm not mistaken,
"start of simulation phase" has a specific callback or
sc_module virtual method in SystemC. You should specifically
name it here and give an example of its use.

-------------------------------------------------
Section 5.8 last paragraph

This statement, "This would retain at a minimum ..."
is vague. What do you mean here ?  Please
be more precise.

-------------------------------------------------
Section describing use of utility functions in non-context
imported DPI functions.

As discussed with the meeting, I'd like to propose
that we add a specific section defining which
utility functions we allow to be called from non-context
imported DPI functions.

The ones I suggest are:

svGetScope()
svGetUserData()

I don't see any point in allowing the others. But adding
this would add a great deal of usability to the use model.

-- johnS

______________________________/\/            \     \
John Stickley                   \             \     \
Mgr., Acceleration Methodologies \             \________________
Mentor Graphics - MED             \_
________________________________________________________________