RE: [sv-bc] Errata in SV 3.1a LRM Section 18.4: inconsistent use of error and warning

I've been watching this thread build a mountain out of a molehill with some
amusement. I'm the one who raised the issue, so let me see if I can bring
the original errata back into perspective.

The errata was simply that the SV 3.1a LRM is not consistent about whether a
violation of the required checking for unique/priority is an ERROR or a
WARNING. Section 8.4 starts off calling the violations of the
unique/priority checks and an ERROR, and then changes to calling them a
WARNING. If it is an ERROR, then the LRM does not say if the tool should
simply print a message, or if it should abort (a fatal error).

I propose that all violation messages from unique/priority be a warning. I
have attached a file with a formal proposal on what to change in the LRM.
Since I am not the person assigned to this errata, I have not uploaded this
proposal to the data base.

Following is an explanation of why I feel that generating a warning is
appropriate:

The use of unique/priority decisions must be considered in the context of a
design, not as stand-alone constructs. The purpose of unique/priority
decisions is to allow a software tool to check that that designer's intent
is being met. In essence, the checks are (I'll use case statements to
illustrate, but the same applies to if...else...if decisions):

1) The value of the case expression always matches at least one case item
expression (both unique and priority).

2) The value of the case expression matches at most one case item expression
(unique)

For simulation, this can be a dynamic check that generates run-time warning
messages if the design's functionality does not match the stated intent.
That inherent dynamic checking of unique/priority is very important. To do
this dynamic checking in regular Verilog requires adding extra code to the
design logic. That's extra logic that the hardware itself typically does
not need--it was just to verify that the RTL model functions as expected.
To test that at least one branch of my decision is true is simple. All that
is needed is a default branch that only occurs if no other branch is taken.
Checking that at most only one branch is true is not so easy. They key
point to make here, is that I have never seen a real Verilog model treat
this extra checking in the RTL model as a fatal error that aborts
simulation. The checking will either generate an informative message, or
force logic X values into the simulation to show that there was an
unexpected condition (some engineers do both). Either way, it is a run-time
indication that the design is not functioning as was intended.

In other words, any user-specified checking that has been done with
traditional Verilog is an informational WARNING that an unexpected condition
occurred in the design.

For synthesis, any checking that decision statement is "unique" (i.e.:
mutually exclusive) will be static. A synthesis tool can statically detect
that not all possible case expression values have a matching case item, but
synthesis might not be able to statically determine if the unspecified
values will logically never occur. This means synthesis compilers might
generate a warning for a condition that never actually occurs in the design
(and then most probably add unneeded latches to the design logic).

If the unique/priority checks were treated as fatal errors, then it would
not be possible to synthesize the design, even though the logic actually
might actually function correctly. Therefore, synthesis really needs to
treat the checking of unique and priority to be an informational WARNING,
not an error. If the LRM says that a violation of unique/priority checking
is an ERROR, then it needs to explicitly say that is not a fatal error.

As an aside, synthesis compilers will likely assume that if unique or
priority was specified, then the engineer has already verified that the
design functions as intended. Synthesis will use unique/priority as a
guideline, and construct gate level logic accordingly. This assumption is
no different than what synthesis does with the full_case/parallel_case
pragmas and attributes. The problem with the pragmas and attributes, is
that simulation does not dynamically verify that my design intent matches
the pragmas or attributes. The burden is on the engineer to verify that the
RTL model actually functions the way the pragmas or attributes say that it
does.

In regards to the tangent that the discussion of this errata has taken on
unique case and possible glitches with state machine design, it is important
to keep the use of unique in context with the design, and not as a
stand-alone statement. RTL models of state machine encoding are typically
glitch free. All bits of a state vector change as a single event. The
run-time checking offered by unique/priority will not generate false
warnings in typical RTL models.

Gate level models are never glitch free. There is no state VECTOR, each bit
of what was a vector in RTL is a separate signal coming from different
gates. This is not a problem! That is of real hardware, and every hardware
design engineer knows that state transitions can have glitches during
transitions. There are design techniques all good state machine designers
know about if glitches between transitions are a concern. An engineer can
use Gray code, Johnson count or other techniques to ensure that only one bit
at a time changes between states. The reason Cliff, myself and others
designers on the original SV 3.0 committee were adamant that SV's enum
needed to be able to specify specific values for each named constant was so
that specific hardware design tricks such as this could be specified. The
original enum donation did not allow specifying values for the enum named
constants.

The point here is that at the RTL level, I need to know if my design logic
for a multiple branch decision can be treated as mutually exclusive
decisions. A simulation warning message from a unique/priority decision is
all that is needed for me to verify that functionality. This checking of
functionality is done at the RTL level, not the gate-level. I do not need
to worry about false warnings due to glitches at the gate-level. A unique
case statement is an RTL construct--it does not even exist at the gate
level, and therefore cannot generate false warnings due to glitches.
Glitches at the gate-level during state transitions are either ignored if
not critical to the design, or are handled in other ways if they are
critical. Glitches at the gate level are handled by having a
unique/priority checker in the hardware.

A proposal to make all unique/priority messages be warnings is attached.

Stu
~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland
stuart@sutherland-hdl.com
+1-503-692-0898
  

> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
> Behalf Of Shalom.Bresticker@freescale.com
> Sent: Wednesday, November 10, 2004 6:07 AM
> To: Brad Pierce
> Cc: sv-bc@eda.org
> Subject: Re: [sv-bc] Errata in SV 3.1a LRM Section 18.4:
> inconsistent use of error and warning
>
> Brad,
>
> This is not correct.
>
> In typical one-hot logic, we don't care if there is a small
> glitch when going from one value to another, since the output
> value is only sampled on the clock edge, and the glitch is so
> short that we don't care.
> But the glitch can indeed exist.
>
> If I write
>
> casez(a[1:0]) //synthesis parallel_case
> 2'b1?: out = b;
> 2'b?1: out = c;
> endcase
>
> I indeed tell the synthesizer to assume that the cases are
> mutually exclusive, but I don't assume that the 2'b11 cannot
> occur as a transient.
>
> Shalom
>
>
> On Tue, 9 Nov 2004, Brad Pierce wrote:
>
> > The user is asking for hardware that takes advantage of
> his/her assertion.
> > So 'unique' should be a promise that the implicit selector signals
> > will be one-hot by the end of each simulation time step.
>
> --
> Shalom Bresticker Shalom.Bresticker
> @freescale.com
> Design & Verification Methodology Tel:
> +972 9 9522268
> Freescale Semiconductor Israel, Ltd. Fax:
> +972 9 9522890
> POB 2208, Herzlia 46120, ISRAEL Cell:
> +972 50 5441478
>
> [ ]Freescale Internal Use Only [ ]Freescale Confidential
> Proprietary
>
>
>