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

Hi Tom,

the reason why disable may be desired is because it is asynchronous in
the case the reset/set is in the sensitivity list. This cannot be
achieved using the enable which is synchronous.

Regarding dual clock ff, it is not synthesizable as far as I know. I
think that for most cases the proposal will work. If the user does not
want to use this inference, the explicit disable iff can be specifiedd

Your last comment - yes, it is strange that the clock is last, but I did
not find it in the last p1364 draft document.

Regards,
ed 

> -----Original Message-----
> From: Thomas.Thatcher@Sun.COM [mailto:Thomas.Thatcher@Sun.COM] 
> Sent: Thursday, March 08, 2007 5:48 PM
> To: Eduard Cerny
> Cc: sv-ac@eda-stds.org
> Subject: Re: [sv-ac] Updated #1648: default disable
> 
> Hi Ed,
> 
> Inferrence of disable conditions may be more problematic than 
> I thought.
> 
> What about the following case?
> 
>     always @(posedge clk or negedge nrst or posedge set) begin
>         if (!nrst) begin
> 	    q <= 1'b0;
> 	end
> 	else begin
> 	    q <= d;
> 	    assert property (d == expected_d);
> 	end
>     end
> 
> This proposal says that the inferred disable will be !nrst || 
> set, which
> would be non-intuitive, according to the code.  The above 
> example might
> be a coding error, and the inferred disable might actually be correct.
> But a similar example could occur if a designer was trying to describe
> a dual-clocked register, and the inferred disable would be incorrect
> for that model.
> 
>     always @(posedge clk or posedge clk2 or negedge nrst) begin
> 	if (!nrst) begin
> 	    q <= 1'b0;
> 	end
> 	else begin
> 	    q <= d;
> 	    assert property (d == expected_d);
> 	end
>     end
> 
> (yes, this is a non-synthesizable model).
> 
> 
> Actually, it may not be necessary to infer a disabling 
> condition.  According
> to the language in secion 17.13.5, which comes immediately 
> before the place
> this proposal will be inserted, enabling conditions will be 
> inferred for
> verification statements placed in if .. else blocks.
> 
> What do others think?
> 
> 
> 
> One other interesting note:  I went to double check the multiple reset
> conditions by calling up the 1364.1-2002 standard (Verilog 
> RTL Synthesis).
> Here's what I read:  (Sec 5.2.2.1, p 9)
> 
>     The always statement shall be of the form:
> 
> 	always @ (posedge <condA> or negedge <condB> or negedge 
> <condC> or ...
> 		posedge <Clock>)
> 			^^^^^^^??????
> Isn't that backwards?  The clock event should be the first 
> event in the list.
> In fact all four examples on the next page have the clock as the first
> event in the list.
> 
> 
> Tom
> 
> 
> Eduard Cerny wrote On 03/08/07 08:59,:
> > Hi, I have uploaded a new version of the proposal for #1648. Also
> > attachd here.
> > Best regards,
> > ed
> > 
> 
> -- 
> ------------------
> Thomas J. Thatcher
> Sun Microsystems
> 408-616-5589
> ------------------
> 

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