Date: Thu Mar 15 2007 - 09:44:57 PDT
Brain, John, Sorry, I noted this email only now and it's too short of a notice to set an alternative. Let's plan on voting on the 22nd . Brian, Maybe you could incorporate the 2 typos (formatting and Jason's name) in the mean time (items 1 & 4 in the attached). John, Per, It would be nice if you guys could comment on my questions (items 2 & 3 in the attached). Maybe this requires a very simple clarification that could be easily inserted. If it boils to a long discussion, we can post it as the first IM for SCE-MI 2.1 or SCE-MI 2.0 non-DRAFT, whatever we name it. Regards, Shabtay ________________________________ From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of Brian Bailey Sent: Thursday, March 15, 2007 8:06 AM To: itc@eda.org Subject: RE: tomorrow's meeting Given that it would be very difficult for Cadence to set up a call and to distribute the information in such a short time, I think it better to delay the meeting until next week. Does anyone have difficulties with Thursday 22nd March? Best regards, Brian ________________________________ From: owner-itc@server.eda.org [mailto:owner-itc@server.eda.org] On Behalf Of Stickley, John Sent: Wednesday, March 14, 2007 11:57 PM To: brian_bailey@relay1.mentorg.com Cc: itc@server.eda.org Subject: tomorrow's meeting Brian, Sorry for the late notice but I will be flying tomorrow at the time of the meeting. Given that we had set this date for a formal committee vote of approval of the spec, I submit, in advance, a vote of 'yes' for Mentor. I don't know if this constitues a valid "absentee" vote or not. If not, perhaps we can try to postpone the voting meeting until next week. If Cadence wants to host the call tomorrow, perhaps we can still accomplish the goal of completing the vote this week. Again, apologies for the late notice. -- johnS -- This message has been scanned for viruses and dangerous content by MailScanner <http://www.mailscanner.info/> , and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner <http://www.mailscanner.info/> , and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
attached mail follows:
Hi Brian, I reviewed the release candidate for SCE-MI 2.0 and would like to report on few minor things. Regretfully I have gotten to these only today, but my take is that none of these are important enough to delay the vote slated for tomorrow. The spec is still a draft and we can add clarifications or make changes as we go. 1. Page 92 - some of the properties are indented relative to the other (as if sub-bullets). I assume this is simply a formatting error when inserting John's latest updates. 2. Section 5.7.4.1. - Page 100 - The spec says that (I underlined). The (*scemi_pipe_c_notify_ok_to_send)() and (*scemi_pipe_c_notify_ok_to_receive)() functions are programmable callbacks that are denoted here as function pointers rather than actual functions. They are called from within the infrastructure to notify the application that there is potentially room to send at least one message, or there is at least one message to receive, respectively...In other words, if an input pipe has room for at least one element the C side is notified that it is OK to send. If an output pipe has at least one element that can be read, the C side is notified that it is OK to receive. It is clear what the callbacks mean but I am sensing that the spec is missing a definition as to when exactly the callbacks should be called. For example, each time that an element is received on the HDL side, it makes room in the buffer to send a new message. So potentially this could be interpreted that each time that some room is made, the ok_to_put callback is called. On the other hand, It might be interpreted that only once a receive() is called and the buffer is empty, the callback will be called once at that time. And last, it may be that we intended for this "when decision" to be entirely left to the implementing such that it could be called at any time that the implementation chooses to as long as the callback is called when there is still room in the buffer. Can one explain how this section is supposed to be interpreted? 3. Section 5.7.4.3 - Page 107. Notes: This section may provide a "hint" to the question above as it says Transaction pipes are designed to guarantee deterministic time advance on the HDL side. Specifically to ensure this, if an attempt is made on the HDL side to do a blocking read on a starved pipe, all simulator time advance on the HDL side will naturally be stopped (just as it does during a 0-time imported function call) until the C side is yielded to and has a chance to replenish data in the pipe. From the HDL perspective, this will happen in 0-time, also just as for imported function calls. This ensures that all input pipe reads are done at the same times from simulation to simulation. If the C side does not replenish the pipe when yielded to, a deadlock will naturally result. But my comment is relates to: This property also holds true for all non-blocking pipe operations on the HDL side. There are no non-blocking pipes operations on the HDL side in SCE-MI 2. What was the intent of this sentence? 4. Please take a note that Jason's last name mentioned in SCE-MI 2.0 contributors list is misspelled. It should be Rothfuss (and not Rothfus) Thanks, Shabtay _____ From: Brian Bailey [mailto:bbaileyconsulting@comcast.net] Sent: Monday, March 05, 2007 10:51 AM To: 'Stickley, John'; Jason Rothfuss; Shabtay Matalon; 'Per Bojsen' Cc: 'Russell Vreeland'; 'Bryan Sniderman'; 'Edmund Fong' Subject: Release candidate Please find attached a release candidate for SCE-MI 2.0 If you find any issues or problems please let me know as quickly as possible so that we do not jeopardize our vote on the 15th. Thanks to everyone for their efforts Brian Helping companies improve their verification efficiency Brian Bailey Brian Bailey Consulting NEW ADDRESS <http://maps.yahoo.com/py/maps.py?Pyt=Tmap&addr=20444+S.+Jasan+Drive&csz =Oregon+City%2C+OR+97045&country=us> 9100 SW 161st Ave Beaverton, OR 97007 <mailto:brian_bailey@acm.org> brian_bailey@acm.org <http://brianbailey.us> brianbailey.us tel: mobile: Skype ID: 503 352 4336 503 753 6040 brian_bailey NEW PHONE
