| Add Proposal | Add Analysis | Edit Class, Environment, or Release |
| Number | 48
|
| Category | errata
|
| Synopsis | 6.1.3: wire delays and continuous assigns
|
| State | open
|
| Class | errata-discuss
|
| Arrival-Date | Oct 14 2001
|
| Originator |
|
| Release | 2001b: 6.1.3
|
| Environment |
http://www.boydtechinc.com/btf/archive/btf_2001/1587.html |
| Description |
Subject: Section 6.1.3 Delays (in continuous assign) Date: Wed, 13 Dec 2000 14:47:43 +0000 From: Daryl Stewart <Daryl.Stewart@cl.cam.ac.uk> To: btf@boyd.com Hi all, I know this is very late in the day but I've noticed that no change has been made to section 6.1.3 in the recently sent "1364.A.pdf" and I believe the description does not make clear the behaviour caused by the combination of a net delay and a driver delay. The closest it comes is "When there is a continuous assignment in the declaration, the delay is part of the continuous assignment and is not a net delay. Thus it is not added to the delay of other drivers". Which seems to imply that "When there is no continuous assignment in the declaration, the delay is a net delay. Thus it is added to the delay of other drivers". Which is not true. In particular, step b) is confusing since it refers to "the value currently scheduled to propagate to the left-hand side". Consider: module foo(); reg r1, r2; wire #10 wireA; // specifies a net delay of 10 for wireA wire wireB; // specifies a net delay of 0 for wireB wire #5 wireC = r1; // specifies no net delay for wireC // and a driver delay of 5 for this assign assign #10 wireA = r1; // specifies a driver delay of 10 for this assign assign wireA = r2; // specifies no driver delay assign #5 wireB = r1; // specifies a driver delay of 5 for this assign initial r1 = 0; initial r2 = 0; initial begin #5 $display("%b %b %b %b %b",r1, r2, wireA, wireB, wireC, $time); #0 $display("%b %b %b %b %b",r1, r2, wireA, wireB, wireC, $time,"+#0"); #95 r1 = 1; #5 r1 = 0; #95 r1 = 1; #15 r1 = 0; end // initial begin initial begin $display("r1 r2 A B C"); $monitor("%b %b %b %b %b",r1, r2, wireA, wireB, wireC, $time); end // initial begin endmodule // foo /* verilog foo.cv VERILOG-XL 2.5 Dec 13, 2000 14:22:03 Highest level modules: foo r1 r2 A B C 0 0 x x x 0 0 0 x x 0 5 0 0 x 0 0 5+#0 0 0 x 0 0 5 0 0 0 0 0 20 1 0 0 0 0 100 0 0 0 1 1 105 0 0 0 0 0 110 1 0 0 0 0 200 1 0 0 1 1 205 0 0 0 1 1 215 0 0 x 0 0 220 0 0 0 0 0 235 0 simulation events (use +profile or +listcounts option to count) + 3 accelerated events CPU time: 0.4 secs to compile + 0.2 secs to link + 0.1 secs in simulation End of VERILOG-XL 2.5 Dec 13, 2000 14:22:09 */ Notice that a) wireC changes one #0 before wireB, since it has no net delay section. b) the assignment of 1 to r1 at time 200 makes it through the driver delay of #10 associated with "assign #10 wireA = r1" and although r1 changes to 0 before the 1 reaches wireA it is not descheduled as one might surmise from the present description. c) when the 1 from r1 at time 200 completes its driver delay section it is combined with the 0 from "assign wireA = r2" to schedule a value of x at time 220. I have attached a new description which I think is suitable for 6.1.3., based on the observed behaviour of Verilog-XL 2.5. I mentioned this once before but got no response. Could someone let me know if this is just plain irrelevant... ;) cheers Daryl Proposed.6.1.3.txt Name: Proposed.6.1.3.txt Type: Plain Text (text/plain) Description: Proposed.6.1.3.txt ubject: Section 6.1.3 Delays (in continuous assign) Date: Wed, 13 Dec 2000 14:47:43 +0000 From: Daryl Stewart <Daryl.Stewart@cl.cam.ac.uk> To: btf@boyd.com Hi all, I know this is very late in the day but I've noticed that no change has been made to section 6.1.3 in the recently sent "1364.A.pdf" and I believe the description does not make clear the behaviour caused by the combination of a net delay and a driver delay. The closest it comes is "When there is a continuous assignment in the declaration, the delay is part of the continuous assignment and is not a net delay. Thus it is not added to the delay of other drivers". Which seems to imply that "When there is no continuous assignment in the declaration, the delay is a net delay. Thus it is added to the delay of other drivers". Which is not true. In particular, step b) is confusing since it refers to "the value currently scheduled to propagate to the left-hand side". Consider: module foo(); reg r1, r2; wire #10 wireA; // specifies a net delay of 10 for wireA wire wireB; // specifies a net delay of 0 for wireB wire #5 wireC = r1; // specifies no net delay for wireC // and a driver delay of 5 for this assign assign #10 wireA = r1; // specifies a driver delay of 10 for this assign assign wireA = r2; // specifies no driver delay assign #5 wireB = r1; // specifies a driver delay of 5 for this assign initial r1 = 0; initial r2 = 0; initial begin #5 $display("%b %b %b %b %b",r1, r2, wireA, wireB, wireC, $time); #0 $display("%b %b %b %b %b",r1, r2, wireA, wireB, wireC, $time,"+#0"); #95 r1 = 1; #5 r1 = 0; #95 r1 = 1; #15 r1 = 0; end // initial begin initial begin $display("r1 r2 A B C"); $monitor("%b %b %b %b %b",r1, r2, wireA, wireB, wireC, $time); end // initial begin endmodule // foo /* verilog foo.cv VERILOG-XL 2.5 Dec 13, 2000 14:22:03 Highest level modules: foo r1 r2 A B C 0 0 x x x 0 0 0 x x 0 5 0 0 x 0 0 5+#0 0 0 x 0 0 5 0 0 0 0 0 20 1 0 0 0 0 100 0 0 0 1 1 105 0 0 0 0 0 110 1 0 0 0 0 200 1 0 0 1 1 205 0 0 0 1 1 215 0 0 x 0 0 220 0 0 0 0 0 235 0 simulation events (use +profile or +listcounts option to count) + 3 accelerated events CPU time: 0.4 secs to compile + 0.2 secs to link + 0.1 secs in simulation End of VERILOG-XL 2.5 Dec 13, 2000 14:22:09 */ Notice that a) wireC changes one #0 before wireB, since it has no net delay section. b) the assignment of 1 to r1 at time 200 makes it through the driver delay of #10 associated with "assign #10 wireA = r1" and although r1 changes to 0 before the 1 reaches wireA it is not descheduled as one might surmise from the present description. c) when the 1 from r1 at time 200 completes its driver delay section it is combined with the 0 from "assign wireA = r2" to schedule a value of x at time 220. I have attached a new description which I think is suitable for 6.1.3., based on the observed behaviour of Verilog-XL 2.5. I mentioned this once before but got no response. Could someone let me know if this is just plain irrelevant... ;) cheers Daryl Proposed.6.1.3.txt Name: Proposed.6.1.3.txt Type: Plain Text (text/plain) Description: Proposed.6.1.3.txt 6.1.3 Delays Values propagate through two inertial delays on their way from the right-hand side of a continuous assignment to the left-hand side. A delay given to a wire declaration shall specify the wire's net delay. If no delay is given, a net delay of #0 is used. When there is a continuous assignment in a declaration, the delay is a driver delay for the right-hand side specified, and no net delay is specified for the wire. A delay given to a continuous assignment shall specify the driver delay for the right-hand side specified. For example: wire #10 wireA; // specifies a net delay of 10 for wireA wire wireB; // specifies a net delay of 0 for wireB wire #5 wireC = r1; // specifies no net delay for wireC // and a driver delay of 5 for this assign assign #10 wireA = r1; // specifies a driver delay of 10 for this assign assign wireA = r2; // specifies no driver delay assign #5 wireB = r1; // specifies a driver delay of 5 for this assign If the left-hand side references a scalar net, then the delay shall be treated in the same way as for gate delays - that is, different delays can be given for the output rising, falling, and changing to high impedance (see Section 7). If the left-hand side references a vector net, then up to three delays can be applied. The following rules determine which delay controls the assignment: If the right-hand side makes a transition from nonzero to zero, then the falling delay shall be used. If the right-hand side makes a transition to z, then the turn-off delay shall be used. For all other cases, the rising delay shall be used. When a right-hand side operand of an assign changes: a) The value of the right-hand side expression is evaluated. b) If this right-hand side value differs from the value (if any) currently propagating through the driver delay section for that particular assign then the value currently propagating through the driver delay section is descheduled. c) If the new right-hand side value equals the value (if any) currently propagating through the driver delay section for that particular assign then no event is scheduled otherwise the new value is scheduled to complete the driver delay section according to the driver delay. Whenever a value completes propagation through the driver delay section of any assign: a) A new value is calculated for the wire using the new value and the last values to propagate through all assigns to the wire, according the strength resolution rules. b) If this value differs from the value (if any) currently propagating through the net delay section for that particular wire then the value currently propagating through the net delay section is descheduled. c) If the new right-hand side value equals the value (if any) currently propagating through the driver delay section for that particular assign then no event is scheduled otherwise the new value is scheduled to complete the driver delay section according to the driver delay. For example in the presence of the declarations above the code: initial r1 = 0; initial r2 = 0; initial begin #100 r1 = 1; #5 r1 = 0; #95 r1 = 1; #15 r1 = 0; end // initial begin produces the results: r1 r2 A B C Time ---------------------------------- 0 0 x x x 0 0 0 x x 0 5 0 0 x 0 0 5+#0 0 0 0 0 0 20 1 0 0 0 0 100 0 0 0 1 1 105 0 0 0 0 0 110 1 0 0 0 0 200 1 0 0 1 1 205 0 0 0 1 1 215 0 0 x 0 0 220 0 0 0 0 0 235 Notice that a) wireC changes one #0 before wireB, since it has no net delay section. b) the assignment of 1 to r1 at time 200 makes it through the driver delay of #10 associated with "assign #10 wireA = r1" and although r1 changes to 0 before the 1 reaches wireA it is not descheduled. c) when the 1 from r1 at time 200 completes its driver delay section it is combined with the 0 from "assign wireA = r2" to schedule a value of x at time 220. ====================ubject: Re: Section 6.1.3 Delays (in continuous assign) Date: Tue, 19 Dec 2000 20:47:14 -0500 (EST) From: Steven Sharp <sharp@cadence.com> To: btf@boyd.com, Daryl.Stewart@cl.cam.ac.uk I have no objection to the clarification that continuous assignment delays and net delays are separate delays that deschedule separately. However, the references to wireC changing one #0 before wireB cannot be included in the description. There is no guarantee of this, and in fact the standard states that such things are not guaranteed. As further illustration, if XL is run with the +turbo+3 optimization switch, wireB and wireC will change at the same time. Steven Sharp sharp@cadence.com |
| Fix |
This needs some work on wording. |
| Audit-Trail |
From: Daryl Stewart <Daryl.Stewart@cl.cam.ac.uk> To: Shalom.Bresticker@motorola.com Cc: btf-bugs@boyd.com, Daryl.Stewart@cl.cam.ac.uk Subject: Re: errata/48: Section 6.1.3 Delays (in continuous assign) Date: Mon, 15 Oct 2001 12:10:44 +0100 Hi Shalom, thanks for digging that one out! I recently had time to follow up on Steven's comment about #0 delays. I'm not sure I'm happy about allowing simulation to decide which side of a #0 an update occurs, but if this erratum is going to be considered this late then the following is pretty non-committal about #0 schedules and doesn't contradict the golden XL model. (it says "#0 may be used" instead of "#0 is used" and explicitly declares #0 net delay for wireB in the example) Please consider this version in preference to the one posted in December 2000. cheers Daryl ------------- 6.1.3 Delays Values propagate through two inertial delays on their way from the right-hand side of a continuous assignment to the left-hand side. A delay given to a wire declaration shall specify the wire's net delay. If no delay is given, a net delay of #0 may be used. When there is a continuous assignment in a declaration, the delay is a driver delay for the right-hand side specified, and no net delay is specified for the wire. A delay given to a continuous assignment shall specify the driver delay for the right-hand side specified. For example: wire #10 wireA; // specifies a net delay of 10 for wireA wire #0 wireB; // specifies a net delay of 0 for wireB wire #5 wireC = r1; // specifies no net delay for wireC // and a driver delay of 5 for this assign assign #10 wireA = r1; // specifies a driver delay of 10 for this assign assign wireA = r2; // specifies no driver delay for this assign assign #5 wireB = r1; // specifies a driver delay of 5 for this assign If the left-hand side references a scalar net, then the delay shall be treated in the same way as for gate delays - that is, different delays can be given for the output rising, falling, and changing to high impedance (see Section 7). If the left-hand side references a vector net, then up to three delays can be applied. The following rules determine which delay controls the assignment: If the right-hand side makes a transition from nonzero to zero, then the falling delay shall be used. If the right-hand side makes a transition to z, then the turn-off delay shall be used. For all other cases, the rising delay shall be used. When a right-hand side operand of an assign changes: a) The value of the right-hand side expression is evaluated. b) If this right-hand side value differs from the value (if any) currently propagating through the driver delay section for that particular assign then the value currently propagating through the driver delay section is descheduled. c) If the new right-hand side value equals the value (if any) currently propagating through the driver delay section for that particular assign then no event is scheduled otherwise the new value is scheduled to complete the driver delay section according to the driver delay. Whenever a value completes propagation through the driver delay section of any assign: a) A new value is calculated for the wire using the new value and the last values to propagate through all other assigns to the wire, according the strength resolution rules. b) If this value differs from the value (if any) currently propagating through the net delay section for that particular wire then the value currently propagating through the net delay section is descheduled. c) If the new right-hand side value equals the value (if any) currently propagating through the driver delay section for that particular assign then no event is scheduled otherwise the new value is scheduled to complete the driver delay section according to the driver delay. For example in the presence of the declarations above the code: initial r1 = 0; initial r2 = 0; initial begin #100 r1 = 1; #5 r1 = 0; #95 r1 = 1; #15 r1 = 0; end // initial begin produces the results: r1 r2 A B C Time ---------------------------------- 0 0 x x x 0 0 0 x x 0 5 0 0 x 0 0 5+#0 0 0 0 0 0 20 1 0 0 0 0 100 0 0 0 1 1 105 0 0 0 0 0 110 1 0 0 0 0 200 1 0 0 1 1 205 0 0 0 1 1 215 0 0 x 0 0 220 0 0 0 0 0 235 Notice that a) wireC changes one #0 before wireB, since it has no net delay section. b) the assignment of 1 to r1 at time 200 makes it through the driver delay of #10 associated with "assign #10 wireA = r1" and although r1 changes to 0 before the 1 reaches wireA it is not descheduled. c) when the 1 from r1 at time 200 completes its driver delay section it is combined with the 0 from "assign wireA = r2" to schedule a value of x at time 220. From: "liu" <liu7312@sina.com> To: <btf-bugs@boyd.com> Cc: Subject: Re: errata/48: Section 6.1.3 Delays (in continuous assign) Date: Thu, 20 Feb 2003 18:25:16 +0800 Hi sir, I am Mike Liu from PeiKing University. I need the IEEE1364-1995 or IEEE1364-2001 document. Could you help me? Thanks and Best Regards, Mike |
| Unformatted |
Daryl Stewart <Daryl.Stewart@cl.cam.ac.uk> |
Hosted by Boyd Technology