Re: errata/237: A.7.5.3: scalar_timing_check_expressions has redundancies

From: Shalom.Bresticker@freescale.com
Date: Fri Jun 25 2004 - 06:00:00 PDT

  • Next message: Brophy, Dennis: "RE: enhancement/287: `compatibility - backward compatibilitycompi lerdirectives"

    The following reply was made to PR errata/237; it has been noted by GNATS.

    From: Shalom.Bresticker@freescale.com
    To: etf-bugs@boyd.com
    Cc:
    Subject: Re: errata/237: A.7.5.3: scalar_timing_check_expressions has
     redundancies
    Date: Fri, 25 Jun 2004 15:55:14 +0300 (IDT)

     I have a little work regarding issue 237, to investigate what is the
     existing behavior in current simulators in a variety of simulations.
     
     I looked at 3 simulators. Of course, there are others, and there may be
     additional behaviors or combinations of behaviors different from these
     three. My hope was to get an idea more or less on what there seems to be
     agreement and what not.
     
     There seems to be less agreement today than we thought. Behavior seems to
     be consistent across all the tools I looked at only in the basic cases.
     
     I looked mostly at simple expressions for the enabling conditions.
     I did not extend the investigation (yet) to much more complex cases.
     
     The following table shows the results.
     
     The left-hand column ("Condition") of each row shows the syntactic
     form of the condition, where c is the signal (scalar wire) being tested.
     
     The following columns in each row show what happened for each value of c,
     where - means that a timing violation was not reported, and y means that
     a violation was reported.
     
     Each cell of the table contains 3 characters, such as yy-,
     which indicate the results for simulators 1, 2, and 3, respectively.
     
     Note that simulator1 does not claim to support 1364-2001.
     
     Shalom
     
     
     Condition Value of c
                   0 1 x z undriven
     =============================================
     c --- yyy --- yy- ---
     ~c yyy --- --- yy- ---
     
     c == 1'b0 yyy --- yyy yyy yyy
     c == 1'b1 --- yyy yyy yyy yyy
     
     c != 1'b0 --- yyy yyy yyy yyy
     c != 1'b1 yyy --- yyy yyy yyy
     
     c === 1'b0 yyy --- --- yy- -y-
     c === 1'b1 --- yyy --- yy- -y-
     
     c !== 1'b0 --- yyy --y yyy -yy
     c !== 1'b1 yyy --- --y yyy -yy
     
     ---------------------------------------
     
     c == 1'bz --y yyy yyy yyy yyy
     c != 1'bz yyy --y yyy yyy yyy
     c === 1'bz --- yy- --- yyy -yy
     c !== 1'bz yyy --y --y yy- -y-
     
     c == 1'bx *-y *-y *yy *yy *y-
     c != 1'bx *yy *yy *yy *yy *y-
     c === 1'bx *-- *-- *yy *y- *y-
     c !== 1'bx *yy *yy *-- *yy *y-
     
     * = gave compilation error in sim1
     y = gives timing check violation
     - = no timing check violation
     
     Terminology (reminder):
     "Deterministic": c, ~c, ===, !==
     "Non-Deterministic": ==, !=
     
     (The terminology should probably be changed.)
     
     
     1. For the standard cases, where the condition is c, ~c, or
     "c op const", and "op" is ==, !=, ===, or !==, and
     "const" is 0 or 1, and the value of c is 0 or 1, all the
     simulators agree, as expected.
     
     
     2. However, there is already a disagreement where the value of c is x.
     Here they all agree that c and ~c do not enable the timing check.
     And for the == and != operators, the check is enabled.
     And for the === operator, the check is enabled.
     However, for !==, Sim3 enables the check whereas Sim1 and Sim2 disable it.
     This appears to be a difference in interpretation of the standard.
     A strict reading of the LRM would support the interpretation of Sim1 and Sim2,
     although the behavior of Sim3 seems more logical.
     But we already have the discrepancy where 'c' behaves differently than 'c == 1'.
     
     
     3. What happens if c is z?
     The LRM does not mention this case.
     For these comparisons, Sim3 treats c=x and c=z and c=undriven exactly alike
     (though Sim3 does distinguish between them in other cases not discussed yet.)
     For Sim1, if c is z, then the check is always enabled,
     no matter what the form of the condition.
     Same for Sim2.
     Sim3, as mentioned above, treats c=z like c=x.
     Sim3 differs from Sim1 and 2 in the following cases: c, ~c, c===1'b0, c===1'b1.
     
     4. For c = undriven: (I did not write this description yet, but you can
     see the results in the table)
     
     5. Sim1 and Sim3 treat c always the same as c===1'b1 and ~c as c===1'b0.
     As previously noted, in normal Verilog, c is the same as c==1'b1, not c===1'b1.
     
     
     6. Two other cases not discussed by the LRM and in fact not allowed by the
     current BNF are comparison of c to the value x or z.
     However, all the simulators allow you to write the comparison to z operation.
     Sim2 and Sim3 also allow the comparison to x, but Sim1 gives you a fatal error.
     
     
     7: Condition "!c" instead of "~c":
     Sim1 and Sim2 do not allow it.
     Sim3 allows it and reacts like "~c".
     
     
     8: Parentheses around entire condition do not change anything.
     However, when I put separate pairs of parentheses around the LHS and the RHS,
     as in (cond) == (1'b0), then sim1 and sim3 accepted it and nothing changed,
     but sim2 did not accept it.
     
     
     9: I tried a condition (1'b1 ? cond : 1'b0). Sim1 and Sim2 did not accept it.
     Sim3 treated it exactly the same as 'cond'.
     
     --
     Shalom Bresticker Shalom.Bresticker @freescale.com
     Design & Reuse 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
     

    This archive was generated by hypermail 2.1.4 : Fri Jun 25 2004 - 06:00:12 PDT and
    sponsored by Boyd Technology, Inc.