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. >Received on Wed Oct 4 15:41:22 2006
This archive was generated by hypermail 2.1.8 : Wed Oct 04 2006 - 15:41:27 PDT