RE: [sv-ec] When do clocking output skew 0 values show up on a var output?

Jonathan, Gordon, SV-EC,

I have added text to SV-890-8-part1.pdf that attempts to capture
your conclusions here.  I liked Jonathan's final analysis.  I agree
with Gordon that the system can glitch clocking output signals in
edge cases only.  I provided text and an example in 15.14.2.

SV-890-8-part1 also includes some wording cleanups proposed by
Arturo. These have no semantic impact on the proposal. 

Finally, Dmitry's suggestions 1 and 2 were incorporated.
See the attachments in
   http://eda.org/svdb/bug_view_page.php?bug_id=0000890.

Thanks and Regards,
Doug

> -----Original Message-----
> From: owner-sv-ec@server.eda.org 
> [mailto:owner-sv-ec@server.eda.org] On Behalf Of Jonathan Bromley
> Sent: Tuesday, March 13, 2007 7:44 AM
> To: Vreugdenhil, Gordon; SV_EC List
> Subject: RE: [sv-ec] When do clocking output skew 0 values 
> show up on a var output?
> 
> Gord,
> 
> Ouch.
> 
> > For the "normal" cases of having drives appear before the clocking
> > event, this is fine.
> 
> I don't think that *is* the "normal" case.  Recall that we 
> should not attempt to read input clockvars until after @cb,
> because otherwise we may have a read/update race.  But I
> probably want to *use* the input clockvar values in 
> constructing my output stimulus.  So the typical flow
> of execution of a reactive testbench (reactive in the sense 
> that it reacts to the DUT's behaviour) - for example, one
> doing handshaking on a DUT output - would be...
> 
>   @cb;
>   local_variable = cb.invar;
>   cb.outvar <= some_function(local_variable);
> 
> Using this idiom, I get testbench-controlled feedback from 
> DUT outputs back to DUT inputs corresponding to a logic 
> path with a register in it.  (Note, in passing, that I 
> can't directly use a clocking block to mimic combinational 
> feedback from DUT output to DUT input, unless I use 
> the dreaded input #0.)
> 
> 
> >     initial begin
> >       ## 1;
> >       cb.a <= 0;
> >       @(x);
> >       cb.a <= 1;
> >     end
> > 
> > Assume that the above is all active region set code but that
> > "x" is an event that happens as a result of re-active
> > stimulus in the same time step.
> 
> I agree with your analysis, but I think there's a way out.  
> As you say, this is a *very* forced example.  The key point, 
> though, is that we're making two separate passes through 
> Re-NBA.  The guarantee of last-write-wins can only reasonably
> be enforced for a single pass through Re-NBA.  For 
> non-pathological code, this (I think) is OK.  So all we need
> to do is to find a form of words that expresses this....
> 
> I think your last paragraph is close.  Maybe we could just
> avoid making any explicit claims about last-write-wins, and
> simply say that a clocking drive schedules an assignment to
> its target clocking signal in the Re-NBA region of the 
> appropriate timeslot, and that assignment shall supersede 
> any other pending assignment to the same variable in 
> that Re-NBA region?
> 
> It just emphasises once again that the only really hygienic
> usage of clocking blocks is to have their clock event happen
> in the active region set, and all manipulation of their 
> clockvars happen in the reactive region set.
> -- 
> 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
> 
> The contents of this message may contain personal views which 
> are not the views of Doulos Ltd., unless specifically stated.
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 
> 
> 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.