Steve, Karen, Randy and the rest of the BTF - I am FEDEXing my ballot in today with the errata proposals (comments) shown below. I agree with Mac that the example sent out by Randy Misustin should be deterministic and I hope Randy will agree. If this piece is too controversial (if it appears that we are doing more than an errata change on this issue), I would be willing to pull the last note of the proposals to confine all changes to pure errata updates. We would leave this issue unresolved (and undefined) until the next IEEE Verilog revision. The example that Randy gave is in my opinion rarely used and therefore could be omitted from the spec. I hope that Randy and ModelTech would agree that the events would be scheduled as shown in the example, but I can live with continued ambiguity on this example. I also believe I am in agreement with Stu on additional errata updates to section 5 regarding scheduling of PLI commands, but I will leave the proposal for this to Stu (not my area of expertise). Regards - Cliff Clifford E. Cummings Record # 44606 *1364r/D5 REV* 1364/D5 Revision -- Standard For Verilog Hardware Description Language Voted: Affirmative - Approve as an IEEE Standard with comments Comments below: ========= Errata - pg. 366, first paragraph, insert a space between "time" and "specified": WAS: ... within the unit of timespecified here ... PROPOSED: ... within the unit of time specified here ... ========= Errata - pg. 68, section 5.3, paragraph (1), current wording seems to contradict other wording in section 5. Re-word to clarify: WAS: 5.3 (1) Events that occur at the current simulation time and can be processed in any order. These are the active events. PROPOSED: 5.3 (1) Events that occur at the current simulation time are the active events. Events are placed onto the event queues in an arbitrary order if the events are in separates procedural blocks, but events within the same procedural block are placed onto the event queue in code-order. The events are then removed from the event queues in the same order in which they were placed on the queue. ========= Errata - pg. 68, section 5.3, paragraph (5), current wording seems to contradict other wording in sections 5 and . Re-word to clarify: WAS: 5.3 (5) Events that occur at some future simulation time. These are the future events. Future events are divided into future inactive events, and future nonblocking assignment update events. PROPOSED: TBD QUESTION: future nonblocking assignment update events I understand how these can be scheduled. Example: a <<= #5 b; b is sampled and evaluated immediately and scheduled as a future nonblocking assignment update event. QUESTION: future inactive events ??? I do not understand how these can be scheduled. Example?: a = #5 b; b is sampled and evaluated immediately and scheduled as a future ??**active events** queued event ?? ========= Errata - pg. 69, section 5.4.2, 1st paragraph, current wording seems to contradict other wording in section 5. Re-word to clarify: WAS: One source of nondeterminism is the fact that active events can be taken off the queue and processed in any order. ... PROPOSED: One source of nondeterminism is the fact that events can be placed onto the active events queue in an arbitrary order if the events are in separates procedural blocks and then taken off the active events queue and processed in the same order in which they were placed on the queue. ... ========= Errata - pg. 128, section 9.2.2, 1st paragraph on page 128 (middle of the page), current wording contradicts section 5.4.1 and is wrong. Re-word to correct as follows: Also remove the extraneous out variable from example 4. WAS: When multiple nonblocking assignments are scheduled to occur in the same variable in a particular time slot, the order in which the assignments are evaluated is not guaranteed -- the final value of the variable is indeterminate. As shown in the following example, the value of reg a is not known until the end of time step 4. < < < PROPOSED: When multiple nonblocking assignments are scheduled to occur to the same variable in a particular time slot from different procedural blocks, the order in which the assignments are evaluated might not be guaranteed -- the final value of the variable might be indeterminate. When multiple nonblocking assignments are scheduled to occur to the same variable in a particular time slot from the same procedural block, the order in which the assignments shall be performed is the order the statements were executed and the final value of the variable shall be the last value scheduled, as previously described in section 5.4.1. As shown in the following example, the value of reg a at the end of time step 4 is 1. Example 4: module multiple2; reg a; initial a = 1; // The assigned value of reg a is determinate initial begin a <<= #4 0; // schedules a = 0 at time 4 a <<= #4 1; // schedules a = 1 at time 4 end // At time 4, a = 1 endmodule If the simulator executes two procedural blocks concurrently, and if these procedural blocks contain nonblocking assignment operators to the same variable, the final value of that variable is indeterminate. For example, the value of reg a is indeterminate in the following example. Example 5: module multiple3 ; reg a; initial a = 1; initial a <<= #4 0; // schedules 0 at time 4 initial a <<= #4 1; // schedules 1 at time 4 // At time 4, a = ?? // The assigned value of the reg is indeterminate endmodule Note: the fact that two nonblocking assignments targeting the same variable are in different blocks is not by itself sufficient to make the order of assignments to a variable indeterminate. For example, the value of reg a at the end of time cycle 16 is determinate in the following example. module multiple2a ; reg a; initial #8 a <<= #8 1; // executed at time 8; schedules // an update of 1 at time 16 initial #12 a <<= #4 0; // executed at time 12; schedules // an update of 0 at time 16 // Because it is determinate that the update of a to // the value 1 is scheduled before the update of a to // the value 0, then it is determinate that a will have the // value 0 at the end of time slot 16. endmodule END OF PROPOSAL //*****************************************************************// // Cliff Cummings Phone: 503-579-6362 // // Sunburst Design, Inc. FAX: 503-579-7631 // // 15870 SW Breccia Drive E-mail: cliffc@sunburst-design.com // // Beaverton, OR 97007 Web: www.sunburst-design.com // // // // Expert Verilog, Synthesis and Verification Training // //*****************************************************************//