RE: [sv-ac] rules for concurrent assertion clock in procedural code

yes, I agree that it can lead to errors. Putting concurrent assertions in
procedural code can be complex, not just because of inferred clocks. Don't
forget that because these are concurrent, they are not immediately evaluated
when reached in the code (16.15.6). I would not put as2 in the procedural
code. There are good reasons to put concurrent assertions in procedural
code, such as in for loops, but you need to be careful. I would avoid it
unless there is a good benefit and it is a simple procedural block.

Lisa



-----Original Message-----
From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
Behalf Of jonathan.bromley@doulos.com
Sent: Wednesday, July 01, 2009 2:06 PM
To: sv-ac@server.eda.org
Subject: RE: [sv-ac] rules for concurrent assertion clock in procedural code

> In the example being discussed:
> 
> default clocking dclk @(posedge clk);endclocking 
> always @(negedge clk) begin
>   as1: assert property (a ##1 a);
>   as2: assert property (@(posedge clk_s) clk && sig); 
> end 
> 
> the standard as currently written, says that no clock can be 
> inferred from the procedural block, so default clocking applies.  If
> this is not what the user wants, then they need to be explicit. 

I'm sorry, as a user I strongly disagree.  The subtlety of 
implied clocks is already a potential source of great 
confusion; this is only adding to it.  I suggest that any
typical user would regard the assertions as purely passive,
having no effect on the flow of execution of the always-
procedure, and therefore would expect as1 to be clocked 
by (negedge clk).  Having the clock lapse back to the
default clocking is a subtle error that might not surface
until far too late.  Excluding use within assertions
from the clock inference rules is easy and intuitive.

-- 
Jonathan Bromley



-- 
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.