Attached is the response from John Shields. He obviously takes strong exception to the proposed comments. I think that we need to resolve this for the next language version, if at all possible, so we need to meet to discuss this. Perhaps Peter could chair the discussion? Also, it might be beneficial if John and/or Francoise or other VHPI members could attend to help us reach consensus. One small correction to John's response. Although Ajay did indicate that he was unhappy with the VHPI decision, the note was written by me and any failure to be objective lies with me. When can we meet? Let's start with Peter's availability and work from there. I would ask John Shields to provide a use case in which the "double indeterminacy" is not an issue, so that we can resolve the apparent misunderstanding. Chuck Swart -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
attached mail follows:
Hi Chuck, I am sorry but I find this flawed. first, your comment in the first paragraph may be a representation of a perceived problem, but also speaks to a profound misunderstanding of the intent of the callback. I know it came from Ajay and I think Francoise should have that information. She may wish to discuss it with him. For you not to state a balanced view calls to question the ability of the ISAC to evaluate the specification in this area. Your judgment as the "double indeterminacy making the callback potentially less useful" is particularly unbalanced. I also find the analysis flawed. It misrepresents the VHPI position and hides rationale in its summary, and shows some misunderstanding of, or ignoring, the purpose of the callback. I can accept the misunderstanding. It is the LRM strategy to approach this problem by specifying VHDL resumption in this way, and to be silent about non-determinism. It is an artificial point in the simulation cycle that indeed has healthy non-determinism with no bad behavior inherent in exploiting it. Too bad non-determinism is a dirty word. Fine, you said it a different way. But then it is incumbent upon the author not to hide the real rationale that VHPI had. It is a disservice to any who would wish to review and understand this in proper perspective. That part disturbs me. I presume that, in part, is why some ISAC reviewers see this in a bad light. IMHO, your comments only make it worse in some noble attempt to appease someone. The LRM text revision itself is well done, given the considerations. The note in 8.1 could have reflected that VHPI callbacks match the optimized behavior (which is the intent and has value), but instead it is just cast as fact and left to perceive whether that is a flaw. It is OK, but not great. If you want to appreciate the change, read the isac analysis and your comments, accept them as expert opinion, and then you almost have to view this as flawed decision. If you believed that, you should have pushed it back. I trust you will convey to the ISAC my disappointment in the way this has been done. Regards, John Chuck Swart - MTI wrote: > The attached comment will be added to the analysis of this IR. Please > review this ASAP and > let me know of any changes you wish to make. I am including the most > recent version of the IR also. > > Chuck Swart >Received on Thu Mar 27 15:40:49 2008
This archive was generated by hypermail 2.1.8 : Thu Mar 27 2008 - 15:40:52 PDT