Re: [sv-ac] Re: [sv-bc] 2005: Deferred assertions (new proposal at http://www.verilog.org/mantis/view.php?id=2005)

Hello all;

Can the discussion about using an event expression be expanded ? Does it 
really mean that when a deferred
assertion is executed delayed from a clocked event, its checking is 
suppressed ? This would seem to give a false
sense of security if logic is used a different clock domain. [ False 
security since the user sees an assertion in there but
it does nothing because the wrong clock is being used.]  On the other 
side, concurrent assertions would be
evaluating assertions in the wrong clock domain and report (most likely) 
a failure.

What happens to the delayed assertion, inside a function, if called from 
multiple processes ? Does it evaluate
and report failures correctly for each process ?  It would seem that 
maybe concurrent assertions should be
supported in functions if one is going to support deferred assertions in 
functions.

These 2 forms are the ones that users may confuse.

assert @(posedge clk) (expr)                               - deferred   
(sequential scope and module level scope)
assert property @(posedge clk) (property_expr) - concurrent  (sequential 
scope and module level scope)

More cases and or additional examples would help clarify the operation 
of deferred assertions.

     Thanks.



Seligman, Erik wrote:
> Hmmm... Someone else made a similar point in private email.
>  
> But isn't this already a problem in current SVA?  For example, the 
> following two are both legal in some contexts:
>     assert (foo);
>     assert property (foo);
>  
> I'm not sure I see how (#0 | event expr) vs. 'defer' makes a major 
> difference in this confusion-- the root cause is the similarity 
> between immediate & concurrent asserts in the language. 
>  
> Are other people concerned about this?  Are there suggestions for 
> providing this functionality but making it less confusing?
>  
>
> ------------------------------------------------------------------------
> *From:* owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] 
> *On Behalf Of *Adam Krolnik
> *Sent:* Monday, October 29, 2007 8:56 AM
> *To:* Seligman, Erik
> *Cc:* sv-ac@server.eda.org; sv-bc@server.eda-stds.org
> *Subject:* [sv-ac] Re: [sv-bc] 2005: Deferred assertions (new proposal 
> at http://www.verilog.org/mantis/view.php?id=2005)
>
>
> Hello all;
>
> My concern with this new syntax is that you are now very close to 
> concurrent assertions.
>
> Deferred:
> assert  (#0 | event_expr) ...
>
> Concurrent
> assert property ...
>
> If you keep the ability for an event expression, then you have two 
> seemingly same syntax constructions.
> This may cause confusion to users.
>
> SV-AC what do you think about this confusion between deferred and 
> concurrent forms ?
>
> -- 
>     Soli Deo Gloria
>     Adam Krolnik
>     Director of Design Verification
>     VeriSilicon Inc.
>     Plano TX. 75074
>     Co-author "Assertion-Based Design", "Creating Assertion-Based IP"
>
>
>   
>
> -- 
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean. 

-- 
    Soli Deo Gloria
    Adam Krolnik
    Director of Design Verification
    VeriSilicon Inc.
    Plano TX. 75074
    Co-author "Assertion-Based Design", "Creating Assertion-Based IP"


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