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

Adam,

 

I've finished a proposal based on Erik's that answers your questions
about event expression.

It's undergoing internal review, and I expect to post later today.

 

BTW, my intention in proposing event expression is not what Erik
understood

and wrote in his version of the proposal.  My bad, due to not enough
detail

in my original exposition of the concept.

 

Deferred assertions are always associated with their calling process's

deferred assertion report queue.  It doesn't matter what function or

block of code they live in.

 

Concurrent assertions and deferred assertions are very different beasts

in their semantics and implementation.  Be careful about drawing too

many parallels.  Concurrent assertions require an almost synthesis-like

inferencing of context and surrounding logic.  Deferred assertions are

simpler to implement, given that they fit into the natural sequence of

procedural execution in a simulator (including knowledge of parent

process).

 

Regards,

Doug

 

 

From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
Behalf Of Adam Krolnik
Sent: Monday, October 29, 2007 11:22 AM
To: Seligman, Erik
Cc: sv-ac@server.eda.org; sv-bc@server.eda-stds.org
Subject: 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 <http://www.mailscanner.info/> , and is

believed to be clean. 


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