Jonathan, I reviewed your example and found it to be a solid piece of code useful to illustrate the different sampling behavior made available by clocking blocks. By solid, I mean that your example does not hit on any of the corner cases or LRM ambiguities that Mantis item 890 attempts to clarify. Specifically, your example does not: 1) drive values at times in between clock edges (all drives are synchronous with the rising edge of the clock) 2) trigger the clocking event from within the program block 3) attempt to drive a value from the program without a clocking block Thus, your example is well formulated and should behave in a predictable manner. I do not know which vendors or products are represented by the two columns in your message, but I can definitely tell you that the results of "Vendor B" are conceptually correct. I applied two basic tests to help determine that the "Vendor A" column has some egregious mistakes: a) In your example, there is no activity between the preponed region corresponding to a clock edge and the time tick preceding the clock edge. That is, there is no activity at all between time 4 and the preponded region of time 5, and similarly for times 14 and 15, and so on ... Therefore, the sampled value of signal Q of the clocking block using #1 input sampling (cb) and the clocking block using #1step sampling (in_s) must be identical: For all cycles: cb.Q == in_s.Q You'll note that this condition is not true in cycles 3 and 6 of column "Vendor A" b) In your example, signal D is always driven (via cb.D) 7 ticks away from the clock edge. Since value changes of signal D are never coincident with the clock edge, the sampled values of signal D of the clocking blocks using #0 and #1step sampling must be the same: For all cycles: in_s.D == in_z.D - This property is satisfied by both vendors A and B. c) In your example, the latch (test5b_dut) updates the value of signal Q on the same edge as the clocking block sampling. Therefore, Q is the one signal susceptible to value differences when sampled using #0 and #1step sampling; this means that the sampled values of signal Q of the clocking blocks using #0 sampling must be "one cycle ahead" of the values of the clocking block using #1step sampling: For all cycles: in_s.Q == $past( in_z.Q ) // using assertion syntax You'll note that this condition is not true in cycles 3 and 6 of column "Vendor A" I hope this clarifies things, and trust that I'm not about to receive a bug report :-) Arturo -----Original Message----- From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Rich, Dave Sent: Tuesday, February 07, 2006 7:51 AM To: Jonathan Bromley Cc: sv-ec@eda.org; sv-bc@eda.org Subject: [sv-ec] RE: [sv-bc] Clocking blocks - discrepancies hard to resolve Jonathon, Check out mantis 890 and see if the proposal clarifies things. The gist of this is that using program blocks do not eliminate all races, and the LRM is not correct about when synchronous drives should be applied. (Correct in terms of what the intent was and what the LRM actually says). http://www.eda.org/svdb/bug_view_page.php?bug_id=0000890 Clocking blocks are the responsibility of the sv-ec (Not that you're supposed to know this). Anybody replying to this email please remove the copy to the sv-bc. Dave > -----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.Received on Fri Feb 10 16:36:50 2006
This archive was generated by hypermail 2.1.8 : Fri Feb 10 2006 - 16:37:31 PST