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

These are interesting questions; I'm adding the sv-ac to this discussion
too.

Steven-- The way I was thinking about it, a 'process' begins at the
start of an always_comb block or similar construct, and ends when that
block is exited.  Any form of suspension, forking, or delay would leave
it as the same process; reaching the end of the defining block is the
way to end the process, at least for the purpose of the glitch-free
assertions we're defining.   

But I don't have a deep knowledge of process evaluation/execution.  Is
there a fundamental hole in this definition?  Can we state it more
formally in a way that would alleviate your concern?
 

-----Original Message-----
From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On
Behalf Of Steven Sharp
Sent: Thursday, October 11, 2007 10:38 AM
To: sv-bc@server.eda-stds.org; gordonv@model.com
Subject: Re: [sv-bc] Suppression of unique/priority glitches


>The basic idea is that as a *process* executes, any unique/priority 
>failure is determined but NOT reported.  The deferred report is 
>associated with the *process* and is reported in the observed region.
>If the process re-evaluates prior to the observed region, all pending 
>unique/priority failures are discarded.

This concept of the process "evaluating" seems to assume that all
processes behave like continuous assignments: waking up, evaluating, and
suspending to wake up in the same place and execute the same code next
time.  But in fact, processes are not constrained to behave that way.
They can suspend and wake up in a different place each time and execute
completely different code each time.  How do you define "evaluating" for
the arbitrary case?

>This cleanly handles all scenarios including function and task enables,

>internal delays, etc.  It seems to be pretty easy to reason about and 
>completely covers the truly problematic cases that have been raised.

As with fork..join_none in functions, there are problems because
functions can be called from constructs that may require subprocesses to
implement, but which are not formally recognized as processes by the
LRM.  That leaves their behavior ill-defined under your process-based
proposal.  The issue was avoided with fork..join_none by making it an
error to execute the fork..join_none from any of these constructs.
Would you propose the same restriction for unique/priority?  Note that
trying to define what a process is for these situations may get into
contentious issues based on how different tools have implemented them.

Internal delays would seem to get into the same issue raised above with
the definition of "evaluating".  If a process waits for an internal #0
delay and then continues executing, is this a new "evaluation"?


Steven Sharp
sharp@cadence.com


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