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