SV-Champions Meeting 7/8/04 Karen Pieper Phil Moorby Stu Sutherland Tom Fitzpatrick Brad Pierce Karen pointed everyone's attention to the IEEE patent policy slides. Karen noted that the meeting was being held during the week of July 4th because of the need to meet before the IEEE P1800 SVWG meeting on 7/11/05. We discussed the current list of ballot issues and wordsmithed the suggested remedies that can be found at: http://www.eda-twiki.org/sv/sv-champions/reballot_05_07_08.htm The champions recommend all of the suggested remedies (as wordsmithed) with no opposed or abstains. On the scheduling issue (Mantis 794), it was noted to the editor that all arrows in Figure 9-1 are intended to be black, none gray. Tom notes he will not be able to attend Monday meeting, and authorizes Karen to report about 1364 for him at Monday meeting. New action items ----------------- AI: Karen to forward Stu e-mail from SV-AC chair about a semicolon typo. AI: Brad to review implementation of Mantis item 623, which is still 'Acknowledged'. AI: Francoise to review implementations of Mantis items 485 and 510, which are still 'Acknowledged'. AI: Brad to open Mantis items for the four items in issues spreadsheet that don't have them yet. AI: Brad to close Mantis item 679. V-LRM 'Acknowleged' issues that need to be reviewed --------------------------------------------------- Mantis 313, 576, 669, 700, 702 Stu moves to adjourn. There are no further scheduled Champions meetings.--=_mixed 00652C158625703B_Content-Type: text/html; name="reballot_05_07_08.htm" Content-Disposition: attachment; filename="reballot_05_07_08.htm" Content-Transfer-Encoding: quoted-printable
Standard Editorial Comment Suggested remedy Proposed Change Champions vote
1800 This document uses "us" as the symbol for "microsecond" in lieu of the SI symbol. That is understandable due to the lack of the Greek letter mu in most coding character sets and such situations are addressed in IEEE Std 260.1. However, it is not clear in this standard that this is the reason for its use and the text of the standard certainly is able to represent the Greek letter mu.  Please add a note at an appropriate place in the standard to this effect. Perhaps clause 3.5 would be a satisfactory place to explain the need to use "us". Adding such a note would do much good in reinforcing the understanding that "us" is acceptable for coding but not for textual material, such as seen in the body of the standard. Editor to amend note from P1364 Table 19-1, and add it in Section 3.2 immediately following Syntax 3-1.  In section 30.8.7, change "allows us to filter" to "allows filtering of". Champions recommend
1800 This entity votes to DISAPPROVE P1800/D5 for the following reason:  The P1800/D5 makes several changes to the event scheduling algorithm from P1800/D4 ballot draft.  One of these changes removes the iteration from the Reactive region back to the Active region.  Another change adds a PLI Pre-postponed region after the Reactive/Re-inactive regions that does iterate back to the Active region.  The purpose of this PLI Pre-postponed region is to provide a PLI synchronization point AFTER the events from all previous regions have been evaluated.  This PLI synchronization point is analogous to the PLI Post-NBA region, which provides a PLI synchronization point for ALL events in the regions prior to that point.   This entity will change its vote to approve the P1800 standard if an iteration to the Active region is added between the Reactive/Re-inactive regions and the Pre-postponed region.  This change needs to be effected in Figure 9-1 and in the algorithm in 9.3.1 of P1800/D5. http://www.eda-twiki.org/svdb/bug_view_page.php?bug_id=0000794  The gray in the picture is an indication of the blue in the prior version.  It is not intended to have a meaning.  
(cont from 3 above)The change of removing the iteration from the Reactive region back to the Active region PRIOR to the PLI Pre-postponed region means that any events caused by program blocks and assertion pass/fail statements will NOT be executed before the PLI synchronization point.  Since a program block will likely change signals such as clock and reset, this means many hundreds, possibly thousands of events will be left pending execution when the PLI Pre-postponed synchronization point is reached.  This does not provide the proper and necessary synchronization for PLI applications. 0 0 Champions recommend
1800 In the code example for module "sub", two of the hierarchical paths are not correct.  The paths reference instance "s1" instead of "ebus".
 Correct the hierarchy paths:

   Top.s1.Q = i.True;
should be
   Top.ebus.Q = i.True;

   Top.s1.I = 0;
should be
   Top.ebus.I = 0;
 Correct the hierarchy paths:

   Top.s1.Q = i.True;
should be
   Top.ebus.Q = i.True;

   Top.s1.I = 0;
should be
   Top.ebus.I = 0;
 Champions recommend
1800 The last line of subclause 20.6 mentions the construct "forkjoin extern".  This should be "extern forkjoin". Change the last sentance of 20.6 from:
"Such multiple task definitions are allowed by a forkjoin extern declaration in the interface."

To:
"Such multiple task definitions are allowed by an extern forkjoin declaration in the interface."		 Change the last sentance of 20.6 from:
"Such multiple task definitions are allowed by a forkjoin extern declaration in the interface."

To:
"Such multiple task definitions are allowed by an extern forkjoin declaration in the interface."		 Champions recommend
1364 In the previous ballot, John Scott cast the coordination ballot for SCC 14. His sole comment was on the use of "us" as the symbol for "microsecond", in lieu of the proper symbol. He asked that this be rectified or that a note explaining the need to use "us" be inserted.

I found the note the WG inserted in this 628 page document below Table 19-1. Alas, that does not help the reader who sees, for example, Table 17-10 before seeing Table 19-1. We at SCC 14 are quite aware that circumstances sometimes require extraordinary measures --- hence our material on this in IEEE Std 260.1. Computer coding certainly pertains.

It is not clear to me, however, that all the instances of "us" in this document represent what would appear in computer coding; some of the tables contain what would appear to be explanatory material that does not itself appear in computer code and thus should be capable of using proper symbology.

Further, the note that was inserted was found well past where it was needed and it did not provide a rationale (e.g., "...due to lack of the Greek letter mu in coding character sets...").
suggested_remedy = 1. Please do a keyword search for "us" (whole word, case sensitive) and evaluate each instance. When not part of a coding script fragment, emend to use the correct symbol.

2. Please insert a note very early in the document to provide a verbose comment on this matter, explaining that within coding fragments, "us" must be used in lieu of the proper symbol "due to ...". The concern that drives this request is that we do not care for computer coders to develop the belief that they have their own symbol for microsecond which may be used at will, even in non-coding contexts.		   Every remaining unnoted occurrence of us for microsecond in the standard is referencing code rather than the term mu-s.  The editor will add "See Section 19.8 for a discssion of time scales."  as a forward reference to the description of mu-s in section 17.3.  He will also amend the note from Table 19-1 and add it to Table 17-10. Champions recommend