Brian, I actually scanned the earlier parts of the document and I don't see the content of chapter 1 & 2. Once you get a better access to the web, please check this out. Further more, I downloaded the SCE-MI 2.0 DPI version you posted on the Web which was supposed to match the version I sent you with correct formatting. However I noted that the version posted blends text that was already deleted with revised text. To illustrate my point look at the first chapter: In final viewing mode my document looks like this: Compliant subset of the SystemVerilog DPI C Layer The SCE-MI 2 standard defines a subset of a DPI compliant SystemVerilog / C Layer and a subset of DPI data types supported by the SCE-MI 2 standard. That subset conforms to the DPI C Layer as described in Annex F of SystemVerilog LRM IEEE 1800-2005 (see reference []). As such, the SCE-MI 2 specification development process can leverage the existing proven, and formally specified SystemVerilog DPI standard. Your chapter in final viewing mode looks like this: Compliant subset of the SystemVerilog DPI C -Layer The SCE-MI 2 standard constitutes defines a subset of a DPI compliant SystemVerilog DP/ I C -Layer in terms ofand a what subset of DPI data types are supported by the SCE-MIi 2 standaadrd. That subset must exactly conforms to the DPI C -Layer as described in Annex FE of SystemVerilog LRM IEEE P1800-2005 Draft 3 (see reference []). As such, the SCE-MI 2 specification development process can be "fast-tracked" by leverageing the existing proven, and formally specified SystemVerilog DPI standard. My explanation is that this has to do with how cut and paste worked for you. My take is that unless you accept all changes first, cut and paste will copy both the deleted text and the new text creating the above mix. I think I now understand what John meant when he saw "some deterioration of spelling and grammar from the draft". I think John's comment was quite polite as the document as posted on the web is in shambles. Let me suggest I do the following. a. I will accept all changes in the document I sent before and create a clean document. b. I will fix the formatting to the best of my ability c. I will modify my numbering to start at 5. d. I will update the document with some of John's comments using track changes. e. Only once we converge on the changes, you'll address the remaining formatting issues. Regards, Shabtay >-----Original Message----- >From: Brian Bailey [mailto:brian_bailey@acm.org] >Sent: Tuesday, October 03, 2006 4:10 PM >To: Shabtay Matalon; 'John Stickley'; 'Brian Bailey ' >Cc: itc@eda.org >Subject: 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 \_ >>________________________________________________________________ > > >Received on Tue Oct 3 16:54:46 2006
This archive was generated by hypermail 2.1.8 : Tue Oct 03 2006 - 16:54:56 PDT