RE: [sv-ac] RE: [sv-bc] Suppression of unique/priority glitches

Hello all;


I would expect that 'expert' users would choose concurrent assertions instead of immediate.
There is enough need to focus on creating the assertion that having to focus on how the code
is written 'now' and also figure out all the special places for flushes. This coupled with
possibly having to change the flushes as the code changes - no functional change, just
futzing to making it work - makes the solution less robust.


    Adam Krolnik
    Director of Design Verification
    VeriSilicon, Inc.
    Plano TX. 75074
    Co-author "Assertion-Based Design"

 

-----Original Message-----
From: owner-sv-bc@server.eda.org on behalf of Seligman, Erik
Sent: Thu 10/18/2007 9:12 AM
To: Warmke, Doug; Steven Sharp; Vreugdenhil, Gordon
Cc: Thomas.Thatcher@sun.com; sv-ac@server.eda.org; sv-bc@server.eda-stds.org
Subject: RE: [sv-ac] RE: [sv-bc] Suppression of unique/priority glitches
 
 
> I'll try to write up our understanding of the state of this issue
sometime in the next day.  Including "finite time pulse reject".

Thanks, that will be useful.

I've been thinking some more about these explicit flushes, and I do like
the idea of providing some controllability for advanced users.  As we
saw in the discussion, various pathological cases can get unintuitive
results with the flush-on-* rules.  

What do you guys think of the idea I mentioned in passing, that we might
make automatic flushing the default, but provide an explicit flush
function that also disables future auto-flushing in the process?  

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