RE: feedback SV DPI section of the document

Hi John

Here is my feedback to your comments. I am not sending the modified
version yet as I am working on Per's comments and need to look deeper at
one of your comments.

Shabtay

>-----Original Message-----
>From: John Stickley [mailto:john_stickley@mentor.com]
>Sent: Tuesday, September 26, 2006 2:14 PM
>To: Shabtay Matalon
>Cc: 'itc@eda.org'
>Subject: 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.
[Shabtay] I think that all the above is in Brian's use model section. 
>
>-------------------------------------------------
>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.
[Shabtay] SV functions are superset of SV 0-time tasks. Thus I see no
need to support 0-time tasks.
>
>-------------------------------------------------
>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.
[Shabtay] Fixed.
>
>-------------------------------------------------
>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.
[Shabtay] Fixed. Let's review the changes.
>
>-------------------------------------------------
>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.
[Shabtay] Same as above.
>
>-------------------------------------------------
>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."
[Shabtay] OK
>
>-------------------------------------------------
>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.
[Shabtay] I'll look into this.
>
>-------------------------------------------------
>Section 5.8 last paragraph
>
>This statement, "This would retain at a minimum ..."
>is vague. What do you mean here ?  Please
>be more precise.
[Shabtay] Not in my original version. 
>
>-------------------------------------------------
>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.
[Shabtay] Added these.
>
>-- johnS
>
>______________________________/\/            \     \
>John Stickley                   \             \     \
>Mgr., Acceleration Methodologies \             \________________
>Mentor Graphics - MED             \_
>________________________________________________________________