RE: feedback SV DPI section of the document - SCEMI 2 chapters 1 & 2

Hi Guys,
    I have spotty access at the moment, but I think that should already have
been extracted and put into the earlier pieces of the document. If not, then
please let me know and I will work on it. I thoughts I had extracted all of
the introductory material when I did the split. If I moved something that I
shouldn't have, then we can decide what should be shifted back.

Best regards,
Brian

-----Original Message-----
From: owner-itc@server.eda.org [mailto:owner-itc@server.eda.org] On Behalf
Of Shabtay Matalon
Sent: Tuesday, October 03, 2006 3:31 PM
To: John Stickley; Brian Bailey 
Cc: itc@server.eda.org
Subject: RE: feedback SV DPI section of the document - SCEMI 2 chapters 1 &
2

Brian, John,

I am back today and started working on the comments John sent last week.

I think that section 1 & 2 fell through the cracks as I simply worked on
the DPI section 3 named "Detailed Description of the DPI Proposal for
SCE-MI 2" assigned to me. I thus assumed that chapters 1 & 2 do not
belong to me but haven't validated this assumption in the intro
sections.

I can definitively add these chapters to chapter 3 (if you want me to),
but I don't have the "before split-up" version of these chapters in word
format. 

Can one of you provide me chapters 1 & 2 in word format?

As to John's comment "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." Again, I was working on the version that was posted on
the web. Can one of you provide me with the draft provided to Brian
before the split-up?

Any explanation why the one posted didn't contain the latest grammar
fixes?

Thanks,

Shabtay

PS. I'll respond to the technical comments later, but wanted to resolve
the above first.


>-----Original Message-----
>From: Brian Bailey [mailto:brian_bailey@acm.org]
>Sent: Monday, October 02, 2006 7:00 PM
>To: 'John Stickley'; Shabtay Matalon
>Cc: 'Bryan Sniderman'; 'Edmund Fong'; 'Per Bojsen'; Jason Rothfuss;
>'itc@eda.org'
>Subject: RE: Feedback of feedback Re: New draft 1.15 of SCE-MI pipes
>section of SCE-MI 2 working document
>
>Informational text: When the document becomes a complete and final
standard,
>all informational text would need to get moved out of the formal
definition
>and put in the earlier sections of the document which is meant to be
>explanatory. However, we had agreed that for now it makes more sense to
>keep
>the explanations with the formal definitions so that the motivation
behind
>things can be easily seen.

>-----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.
>
>-------------------------------------------------
>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             \_
>________________________________________________________________