Subject: Re: [sv-bc] SV-BC59 -- Proposal -- Inconsistency in priority/unique
From: Adam Krolnik (krolnik@lsil.com)
Date: Tue Mar 04 2003 - 07:46:58 PST
Hi Brad;
Thanks for proposing wording to address this problem.
Unfortunately, I did not see the potential problem for false errors (or warnings) to
occur due to signal values changing multiple times in a timestep or between clock
edges of a synchronous design.
As we have seen in SV-AC, producing an error on an unclocked procedural statement may
cause a false error. E.g. for code in a combinatorial (not clocked) block
always @(*)
unique if (a | b) c = 2;
else if (a) c = 1;
If 'a' transitions before b this code can cause an error that will not be real (due to
a subsequent change that will bring the correct, stable, value.)
Thus, we can't produce errors based on the dynamic information contained in signals.
For the case statement, one can produce an error for overlapping conditions as this
is a static determination.
One could argue that a warning statement on this dynamic information is also
undesirable. (You could be receiving warning messages that would get ignored in almost
all cases, and remove all usefulness of the message.)
Summary: rewrite errors as warnings.
Consider the usefulness of such a warning. [Clocked] assertions are the more correct
form to check the dynamic behavior of variables.
Thanks Brad.
Adam Krolnik
Verification Mgr.
LSI Logic Corp.
Plano TX. 75074
This archive was generated by hypermail 2b28 : Tue Mar 04 2003 - 07:47:46 PST