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.