RE: [sv-ec] Fwd: Cliff's Votes - E-mail Vote (part 2) Closes 12am PST May 2 2007

Jonathan,

We already have sampled value functions that are persistent until the
end of the time slot. We just need to define them for use when the
signal it the sampling clock itself. That's not hard to do. $rose(clk)
would be true when clk is 0 in the preponed region and goes to 1 any
time in the current time slot. 

Dave


> -----Original Message-----
> From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org]
On
> Behalf Of Jonathan Bromley
> Sent: Friday, May 04, 2007 2:37 PM
> To: Clifford E. Cummings; sv-ec@server.eda-stds.org
> Subject: RE: [sv-ec] Fwd: Cliff's Votes - E-mail Vote (part 2) Closes
12am
> PST May 2 2007
> 
> As the instigator of 1715 I'm *extremely* confused by this....
> 
> > always_ff @(posedge clk or rst_n or set_n)
> >   if (!rst_n) q <= '0;
> >   else if (!set_n) q <= '1;
> >   else if (clk.triggered) q <= d;
> 
> 1715 attempted to propose that, since a clocking block's name
> can be used much as an event in an @event_name timing control,
> then the implied event associated with a clocking block's name
> should have all the same attributes as any other event; in
> particular, that it should be possible to use its name also
> in a wait() timing control.  I also very much wanted to be
> able to assign the clocking block's name to an event handle.
> None of these concerns makes a lot of sense in synthesis.
> 
> Even if we could detect the .triggered attribute of a
> (posedge some_clock) event, it would be a fatally flawed
> way to mimic the rising_edge() functionality of VHDL.
> VHDL's rising_edge() is defined (in paraphrase) as
> 
>   clock'event and clock = '1' and clock'last_value = '0'
> 
> The key issue is that clock'event lasts only for one
> delta cycle.  There is no exact equivalent of a delta
> cycle in Verilog, but one complete loop around the
> active region-set is a fairly close approximation (it
> is one complete round of scheduling zero-delay NBAs
> and then allowing them to update, which is about as
> close as you'll get to a VHDL delta).  clock'event most
> definitely does NOT persist until the end of the timeslot,
> whereas .triggered does.  Consider the behaviour of the
> proposed FF model in the following situation:
> 
> initial begin
>   clock = 0; // clock quiet
>   #1
>   set_n = 1; rst_n = 0; // reset, no set
>   #1
>   rst_n = 1;  // come out of reset, q==0 for sure
>   #1          // recovery time to avoid any ambiguity
> 
>   // FF is now cleanly reset and all its inputs are quiet
> 
>   d = 1;
>   #1 clock = 1; // clean posedge on clock
>   wait (q === 1'b1);  // wait for FF to respond, later in timeslot
>   rst_n = 0;  // assert reset in same timeslot
>   wait (q === 1'b0); // wait for reset to take effect in zero time
>   rst_n = 1;  // release reset, retriggers clocked code in FF model
!!!
> 
> The release of reset, late in the t=1 timeslot,
> has the effect of executing your FF model's
> "clocked" logic, because (posedge clock).triggered is
> still active.  In VHDL this would not be possible because the
> various signal updates have consumed more than one delta,
> so clock'event would be false by that time.
> 
> Getting the set/reset FF model to work is easy, but requires
> a leap of imagination for synthesis (forgive the active high
> resets, but they make the logic easier to follow):
> 
> always_ff @(posedge clock or posedge rst or posedge (set & !rst))
>   if (rst)
>     q <= 0;
>   else if (set)
>     q <= 1;
>   else
>     q <= d;
> 
> Simulates OK, expresses intent OK, clarifies priority of set/reset.
> No fooling around with event.triggered, which makes little sense
> for synthesis.  Only the "posedge (set & !rst)" is vexatious.
> --
> 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.