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

But I may interface my clean, timing-free RTL model with another model which is
gate-level, or RTL with timing, or behavioral with timing (e.g., memory), or
even I may deliberately drive my inputs to the block with slight timing
jitter (I have done so and advocate it).

Shalom

On Wed, 10 Nov 2004, Stuart Sutherland wrote:

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

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