Doug's proposal is attached. ________________________________ From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Warmke, Doug Sent: Thursday, February 23, 2006 9:06 PM To: Jonathan Bromley; sv-ec@eda.org Subject: RE: [sv-ec] RE: [sv-bc] Clocking blocks - discrepancies hard to resolve SV-EC, Both Jonathan and Cliff have expressed concerns about divergent implementations of clocking blocks. I would like SV-EC to consider Mantis item #890 with a bit more urgency than has been demonstrated so far. The proposal has been newly updated, see SV-890-1.htm attached to http://www.eda.org/svdb/bug_view_page.php?bug_id=0000890 The proposal's goal is to eliminate all ambiguities in the LRM such that users can rely on consistent behavior across all SV implementations. Since the proposal is large, I would think some email discussion on the reflector would be in order. Please fire away. For convenience, here is the original description of the problems we see in P1800-2005: The current LRM sections on program and clocking blocks have a few ambiguities that should be addressed to ensure consistent behavior across implementations. The first set of ambiguities is concerned with the timing of when program code samples and drives clocking block outputs back into the design. The upshot is that *any* assignment made to a clocking block output or inout in a time unit at which a clock edge appears shall be propagated into the design in the NBA region, after all active and reactive processing is finished. It doesn't matter if the assignment to the clocking block output was made before or after the clocking event has occured, as long as it is in the same time unit as the clocking event. The next set of ambiguities is related to what the behavior of a program and clocking block should be in case assignments are made to clocking block outputs at time units inbetween clock edges. Currently the LRM is silent on this topic, and the behavior of such code must be defined. Lastly, there are ambiguities present when there is no clocking block present in a program block, and direct assignments or drives are made to program ports from program code. Clarifications are introduced to help specify what the behavior of such constructs should be. Thanks and Regards, Doug > -----Original Message----- > From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of > Jonathan Bromley > Sent: Tuesday, February 07, 2006 2:24 AM > To: sv-bc@eda.org > Subject: [sv-bc] Clocking blocks - discrepancies hard to resolve > > hi, > > I've already made myself a nuisance about clocking > blocks, and I'm going to do it again. Sorry. > > I attach an example of clocking blocks and programs that > I believe is sound, but behaves spectacularly differently > in the two simulators to which I have access. Worse still, > it is beyond my comprehension skills to infer from the > LRM text which if either of them is correct. > > The attached rather simple code example attempts to > follow the spirit of the use of clocking and program. > The program uses ##1 cycle delays throughout; it > accesses the design through a clocking block with > non-zero skews; the design is zero-delay RTL. > > If I am abusing the constructs in some way in this > example, I would be pleased to know - but I put it > to you that if so, I'm probably not the only user > who will make such errors. If, as I believe, the > example is sound, could someone kindly show me how > to infer its correct behaviour from the LRM so that > I can decide which vendor(s) should receive a bug > report? > > Here are the discrepant results: > > Vendor A Vendor B > ~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~ > ... ... > (clock cycle 2) (clock cycle 2) > cb.Q = x cb.Q = x > in_s.D,Q = x,x in_s.D,Q = 0,x > in_z.D,Q = x,x in_z.D,Q = 0,0 > (clock cycle 3) (clock cycle 3) > cb.Q = x cb.Q = 0 > in_s.D,Q = 0,0 in_s.D,Q = 0,0 > in_z.D,Q = 0,0 in_z.D,Q = 0,0 > (clock cycle 4) (clock cycle 4) > cb.Q = 0 cb.Q = 0 > in_s.D,Q = 0,0 in_s.D,Q = 0,0 > in_z.D,Q = 0,0 in_z.D,Q = 0,0 > (clock cycle 5) (clock cycle 5) > cb.Q = 0 cb.Q = 0 > in_s.D,Q = 0,0 in_s.D,Q = 1,0 > in_z.D,Q = 0,0 in_z.D,Q = 1,1 > (clock cycle 6) (clock cycle 6) > cb.Q = 0 cb.Q = 1 > in_s.D,Q = 1,1 in_s.D,Q = 1,1 > in_z.D,Q = 1,1 in_z.D,Q = 1,1 > (clock cycle 7) (clock cycle 7) > cb.Q = 1 cb.Q = 1 > in_s.D,Q = 1,1 in_s.D,Q = 1,1 > in_z.D,Q = 1,1 in_z.D,Q = 1,1 > ... ... > > And here's the source code: > > // test5b Jonathan Bromley, 7 Feb 2006 > // > // simple example of clocking block that *should* be race-free, > // but gives different behaviour in two different simulators > > // __________________________________________________ DUT ___ > // > module test5b_dut(input bit clk, input logic D, output logic Q); > always @(posedge clk) Q <= D; > endmodule > > // ____________________________________________ TESTBENCH ___ > // > program p5b (output logic D, input logic Q, input bit clk); > > // Three clocking blocks: the first is testbench drive and > // receive, the way I would like to do it; the others are > // there to illustrate some monitoring behaviour > // > default clocking cb @(posedge clk); > output #7 D; input #1 Q; > endclocking > > clocking in_s @(posedge clk); > input #1step D; input #1step Q; > endclocking > > clocking in_z @(posedge clk); > input #0 D; input #0 Q; > endclocking > > // Cycle-based procedural testbench code. Note that > // the test activity is entirely controlled by ##1 > // delays, equivalent to @cb. > // > initial begin : TestMyFF > for (int i=0; i<10; i=i+1) ##1 begin > cb.D <= (i>2? 1: 0); > $display("(clock cycle %0d)", ($time+5)/10); > $display(" cb.Q = %b", cb.Q ); > $display(" in_s.D,Q = %b,%b", in_s.D, in_s.Q); > $display(" in_z.D,Q = %b,%b", in_z.D, in_z.Q); > end > $stop; > end > > endprogram > > // _______________________________ TOP LEVEL AND CLOCK GENERATOR ___ > // > module test5b; > logic D, Q; > bit clk; > test5b_dut DUT(.*); > p5b tester(.*); > always #5 clk = ~clk; > endmodule > -- > Jonathan Bromley, Consultant > > DOULOS - Developing Design Know-how > VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services > > Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, > UK > Tel: +44 (0)1425 471223 Email: > jonathan.bromley@doulos.com > Fax: +44 (0)1425 471573 Web: > http://www.doulos.com > > This e-mail and any attachments are confidential and Doulos Ltd. > reserves > all rights of privilege in respect thereof. It is intended for the use of > the addressee only. If you are not the intended recipient please delete it > from your system, any use, disclosure, or copying of this document is > unauthorised. The contents of this message may contain personal views > which > are not the views of Doulos Ltd., unless specifically stated.
This archive was generated by hypermail 2.1.8 : Thu Feb 23 2006 - 22:07:44 PST