Hi John, Here is what I suggest for the wording. I keep this as you wrote it. The HDL-side API is fully defined by the following two SystemVerilog interface declarations. I add the following informative text (which is going to stay in the spec). The HDL-side API can be implemented as a built-in library, but it must allow the user to use the API with a syntax that is exactly compatible with the SystemVerilog interface declarations as described below. I hope this wording settles this issue along what you have intended to write bellow. Making it informative resolves the dispute if this should or should not be included in the SCE-MI 2 spec. Regards, Shabtay >-----Original Message----- >From: John Stickley [mailto:john_stickley@mentor.com] > > > > The HDL-side API is fully defined by the following two SystemVerilog > > interface declarations_. Although an implementor of the SCE-MI 2 > > standard direct built-in library in place an interface to provide the > > API_, it must allow the user to use the API with a syntax that is > > exactly compatible with using the interfaces as described below. > > > > > >The reason I'm having a hard time wording this is because >I'm having a hard time understanding why wording is >necessary in the first place. > >The interface shown makes in clear in no uncertain >terms what is required by the implementor. However >the implementor choses to provide this interface >is their business. Is this not true for the entire standard ? > >Why do we need special wording here ? > >Perhaps it would be best for you to propose wording >other than what you originally proposed (in response >to revision 1.17) as: > >"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." > >I don't like using the word "declare" here. The declaration need >not change from what is shown in the spec. This shows the user, >again, in no uncertain terms, what functionality they can >expect of the interface. > >I would rather replace "declare" with the word "implement" >or "define" in your suggested statement. > >But if we replace it with "implement" then it is >kind of one of those "goes without saying" type >of things. Is it really worth putting that >in the specification ? > >In other words, it is implied that it is up to >the implementation how to implement the entire >SCE-MI 2 specification. So why do we need to state >it ? > >-- johnS > > >> Thanks, >> >> >> >> Shabtay >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> *From:* John Stickley [mailto:john_stickley@mentor.com] >> *Sent:* Tuesday, October 10, 2006 1:38 PM >> *To:* John Stickley >> *Cc:* Shabtay Matalon; brian_bailey@acm.org; Bryan Sniderman; Edmund >> Fong; Per Bojsen; Jason Rothfuss; Russell Vreeland >> *Subject:* Re: Draft 1.19 of SCE-MI pipes section of SCE-MI 2 working >> document >> >> >> >> OK and here's the version with the document and without itc.org >> in the cc list. >> >> Brian, please post revision 1.19 to superceed 1.18. >> >> Again, only 2 changes (marked with change tracking) since 1.18. >> >> Thanks, >> -- johnS >> >> >> John Stickley wrote: >> >> Ooops, resending with a much improved subject line ! >> >> 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 ><mailto: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 ><mailto: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 Tue Oct 24 15:35:44 2006
This archive was generated by hypermail 2.1.8 : Tue Oct 24 2006 - 15:35:57 PDT