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: owner-itc@server.eda.org [mailto:owner-itc@server.eda.org] On Behalf Of John Stickley Sent: Monday, October 02, 2006 2:52 PM To: Shabtay Matalon Cc: brian_bailey@acm.org; Bryan Sniderman; Edmund Fong; Per Bojsen; Jason Rothfuss; 'itc@eda.org' Subject: Feedback of feedback Re: New draft 1.15 of SCE-MI pipes section of SCE-MI 2 working document Shabtay, I've incorporated most of your feedback into my document. I'll send the updated revision 1.18 as a separate e-mail. Where I did not quite agree with your feedback or needed to add clarification, please read the specific feedback comments below. These were based on the marked up revision 1.17 that you sent to me. -- johnS ---------------------------------------- 4.1 Last sentence I'm not sure I agree that the specification should impose this requirement. I would prefer to leave this statement out. ---------------------------------------- 4.1.1.1 scemi_pipe_c_handle() function - Removed bytes_per_element, input_or_output - Made separate accessors for them ---------------------------------------- 4.1.1.1 1st sentence I'm not sure I agree with your rewording here. It is too verbose and possibly unnecessary. My concern is that it might lead to more confusion on the part of the implementor. The interface declaration states quite precisely what is required by the implementor. Just as with function declarations, there is no need to use terms like "can be declared as". It either is or isn't. Whether it is a C-side function declaration or a function declaration in an HDL pipes interface, there is only one way to declare a function. Once specified, it precisely tells the user how to use the function and tells that implementor what interface he/she is required to provide. ---------------------------------------- 4.1.2 entire section - You suggested taking it out. - I made it informational - may want to revisit this. ---------------------------------------- 4.2 1st sentence Again, I think your use of the word 'illustrated' here leads to ambiguity. I reiterate what I said above that the interface declaration defines quite precisely what is required by the implementor. Now, if an implementation choses to use something other than an actual interface that's fine, so long as its use is syntax compatible. Which, as we discussed, should not be a problem here. ---------------------------------------- 4.3.3.2.2 1st sentence Hmmm. I don't think I agree with your comment. I believe the wording is correct. ---------------------------------------- 4.4.1.1 comment about "subject to its autoflush setting" What do you mean by this ? I'm not sure what automatic flush-on-eom has to do with this statement. ---------------------------------------- 4.4.2 your comment about missing ok_to_put, ok_to_get events This was left out intentionally. This is because these are used mainly to support a generic threading interface in the C side which is not needed on the HDL side since the threading system is known. Also, it introduces additional complications as passing event references to/from functions, as far as I can tell, not possible in SystemVerilog. ---------------------------------------- 4.7, 4.8 - your comment to move to appendix These are informational. Why do we need to move them to the appendix ? In general does all informational text need to move to the appendix ? I see no harm in leaving all informational text where it is until such a time as we decide to remove it altogether. Shabtay Matalon wrote: > Hi John, all > > Just before laving for my trip, enclosed is the SCE-MI pipes section of > SCE-MI 2 working document with Cadence suggested modifications, > enhancements and comments. > > Regards, > > Shabtay > > PS. I'll send an email to the reflector, but wanted to be sure that this > gets through > > > >>-----Original Message----- >>From: John Stickley [mailto:john_stickley@mentor.com] >>Sent: Wednesday, August 16, 2006 7:28 PM >>To: brian_bailey@acm.org; Bryan Sniderman; Edmund Fong; Shabtay > > Matalon; > >>Per Bojsen; Jason Rothfuss >>Subject: Re: New draft 1.15 of SCE-MI pipes section of SCE-MI 2 working >>document >> >>Gents, >> >>Regarding the notice I just sent out on the >>reflector, here's the document itself. >> >>You'll see change tracking enabled. >> >>To get a clean copy, just accept all the changes >>or turn off highlighting. >> >>Brian, when you get a chance, can you replace the >>copy at the web site with this ? >> >>Thanks, >>-- johnS >> >> >>John Stickley - personal wrote: >> >>>ITC Techies, >>> >>>I have a new draft of the SCE-MI pipes section of the >>>SCE-MI 2 working document. >>> >>>This draft incorporates the following updates: >>> >>>- New pipe interface objects based on input from Cadence >>> and other discussions with the committee >>> - This layers objected oriented, user friendly interface >>> objects over both the C++ and HDL endpoints of >>> a basic SCE-MI transaction pipe. >>> >>> - On the C++ side, the interface objects are defined with >>> a class. On the HDL side the interface objects are defined >>> with SV interfaces. >>> >>>- General proofreading an clarification of existing wording >>> throughout the document. >>> >>>- Modifications to require that bytes_per_element is statically >>> specific so that it is known at HDL compile time for >>> any given channel. >>> >>>All changes were done with MS word highlight tracking so that >>>you can see all changes since draft 1.13. >>> >>>I will send the updated document to Brian so he can post >>>it on the web. >>> >>>-- johnS >>> >> >>-- >> >>This email may contain material that is confidential, privileged >>and/or attorney work product for the sole use of the intended >>recipient. Any review, reliance or distribution by others or >>forwarding without express permission /\ >>is strictly prohibited. If you are /\ | \ >>not the intended recipient please | \ / | >>contact the sender and delete / \ \ >>all copies. /\_/ K2 \_ \_ >>______________________________/\/ \ \ >>John Stickley \ \ \ >>Mgr., Acceleration Methodologies \ \________________ >>Mentor Graphics - MED \_ >>17 E. Cedar Place \ john_stickley@mentor.com >>Ramsey, NJ 07446 \ Phone: (201) 818-2585 >>________________________________________________________________ -- This email may contain material that is confidential, privileged and/or attorney work product for the sole use of the intended recipient. Any review, reliance or distribution by others or forwarding without express permission /\ is strictly prohibited. If you are /\ | \ not the intended recipient please | \ / | contact the sender and delete / \ \ all copies. /\_/ K2 \_ \_ ______________________________/\/ \ \ John Stickley \ \ \ Mgr., Acceleration Methodologies \ \________________ Mentor Graphics - MED \_ 17 E. Cedar Place \ john_stickley@mentor.com Ramsey, NJ 07446 \ Phone: (201) 818-2585 ________________________________________________________________Received on Mon Oct 2 19:00:13 2006
This archive was generated by hypermail 2.1.8 : Mon Oct 02 2006 - 19:00:18 PDT