Shabtay, I've created a revision 1.19 that has 2 fairly simple changes in response to your feedback below (shown with change tracking since 1.18) Please look this over to see if you're happy with it. We still have a disconnect on your 4.3.3.2.2 comments. I think this needs to be discussed at this week's meeting. I agree some more clarification is needed here but let's make sure we all have the same understanding of how it works before I add this. Right now I don't think we do. For now I've kept the terminology "automatic flush-on-eom". While I agree it is slightly more verbose, I also think it is more precisely descriptive and is worth the extra verbosity in the few places where it is mentioned. -- johnS Shabtay Matalon wrote: >Hi John, > >I reviewed your latest revision 1.18 and here are my comments. > > > >>-----Original Message----- >>From: John Stickley [mailto:john_stickley@mentor.com] >>Sent: Monday, October 02, 2006 2:55 PM >> >> > > > >>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 >> >> >[Shabtay] Your intro still contains "For variable length messaging and >streaming extensions, a special facility is built over the DPI >standard." I suggested deleting this as SCE-MI should not define that >the facility should be implemented over DPI. > > >>---------------------------------------- >>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. >> >> >[Shabtay] OK. > > >>---------------------------------------- >>4.1.1.1 scemi_pipe_c_handle() function >> >>- Removed bytes_per_element, input_or_output >>- Made separate accessors for them >> >> >[Shabtay] Great. > > >>---------------------------------------- >>4.1.1.1 1st sentence >> >> >[Shabtay] I think this is 4.1.1.2 > > >>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. >> >> >[Shabtay] What I said is that "The HDL-side of the API can be declared >using the SystemVerilog interface construct as follows. Given that pipes >are built-in library functions, it is up to the implementation to decide >how to declare these as long as their semantics are consistent with the >enclosed." > >We need to convey that the SCE-MI 2 pipes does not mandate the use of SV >interfaces by the implementation, but rather for it to be compatible >with SV interfaces. We need to find the wording to convey that here. If >this is too verbose, please propose alternative wording. > > > >>---------------------------------------- >>4.1.2 entire section >> >>- You suggested taking it out. >>- I made it informational - may want to revisit this. >> >> >[Shabtay] OK. > > >>---------------------------------------- >>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. >> >> >[Shabtay] This message needs to be captured in the spec. > > > > >>---------------------------------------- >>4.3.3.2.2 1st sentence >> >>Hmmm. I don't think I agree with your comment. >>I believe the wording is correct. >> >> >[Shabtay] Let me suggest that you say "until all in-transit messages >have been consumed by the consumer on that pipe". The wording "on that >pipe" will tighten this. > >I also made a comment that that the following is incorrect: " The >automatic flush-on-eom mode has no effect for non-blocking pipe >operations. If a call is made to scemi_pipe_c_try_send() or the HDL >try_send() function on pipes which were enabled for automatic >flush-on-eom mode, no attempt is made to flush the pipe. Implicit >flushing only pertains to blocking data send operations on pipes. > >I see no reason what automatic flush-on-eom mode setting has to do with >whether you use blocking on non blocking calls. > > >>---------------------------------------- >>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. >> >> >[Shabtay] I think this is the same issue as above. > >Note: I proposed simplified terminology naming "Automatic flush-on-eom >mode" as auto-flush mode. The earlier is way too verbose. Any comments? > > >>---------------------------------------- >>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. >> >> >[Shabtay] Actually the motivation for the ok_to_put and ok_to_get events >has nothing to do at this point with threading interface. It is added >for ease of modeling on the HDL side. > > >>Also, it introduces additional complications as passing event >>references to/from functions, as far as I can tell, not possible in >>SystemVerilog. >> >> >[Shabtay] Need to check on that as I think you should be able to define >events as data members of an interface or module and access them >hierarchically. > > >>---------------------------------------- >>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] Given Brian's comment, let's leave these as informative. > > > > > -- 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 Tue Oct 10 13:34:24 2006
This archive was generated by hypermail 2.1.8 : Tue Oct 10 2006 - 13:34:28 PDT