RE: [sv-ac] Updated #1648: default disable

Do we then agree that inference should be done from always_ff only and
then follow the rules as Jonathan stated below? For backward
comapatibility should we limit inference from always blocks to what it
is in the LRM now. 

What do you say?

ed


> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On 
> Behalf Of Jonathan Bromley
> Sent: Sunday, March 11, 2007 8:17 AM
> To: sv-ac@eda-stds.org
> Subject: RE: [sv-ac] Updated #1648: default disable
> 
> [Thomas Thatcher]
> 
> > Wow!  So that means that the following always block could be 
> > "synthesizable",
> > (at least according to a broad interpretation of Std 
> > 1364.1-2002), 
> 
> And common-sense, and all realistic tools.  The inference
> of clock and reset in such a block is straightforward:
> 
> * pos[neg]edge delay control on a signal that does not
>   otherwise appear in the logic: it's a clock
>   (and, presumably, there should be only one such);
> * pos[neg]edge delay control on a signal that's used
>   to conditionally enable some assignments to outputs:
>   it's an asynchronous reset (or preload, if tools 
>   and target technology support it).
> 
> > but the
> > current proposal would infer the wrong disable!
> > 
> >     always @(negedge nrst or posedge clk) begin
> > 	if (!nrst) begin
> > 	    q <= 1'b0;
> > 	else begin
> > 	    q <= d;
> > 	    assert property (d == exp_data);
> > 	end
> >     end
> 
> And in 1800-2005 it would fail to infer a clock! In fact 
> I encountered exactly this issue during a class
> last week.  The existing 1800-2005 clock inference rule that 
> appeals to the *ordering* of the event control is absurd.
> 
> I have also previously urged that such inferences should
> be restricted to always_ff blocks, which have the desirable
> characteristics that 
> (a) they are specifically intended for the description of 
>     clocked next-state logic, matching the requirements of
>     assertions;
> (b) they already apply useful restrictions (for example,
>     outlawing any other delay controls within the code)
>     and already license tools to perform synthesisability
>     checks.
> 
> -- 
> 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.