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

From: Shalom.Bresticker@motorola.com
Date: Thu Feb 05 2004 - 07:40:00 PST

  • Next message: sharp@cadence.com: "errata/535: errors in $width, 15.3.4 and 15.5"

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

    From: Shalom.Bresticker@motorola.com
    To: etf-bugs@boyd.com
    Cc: David Roberts <roberts@cadence.com>
    Subject: Re: errata/237: PROPOSAL - A.7.5.3: scalar_timing_check_expressions
     has redundancies
    Date: Thu, 5 Feb 2004 17:41:56 +0200 (IST)

     I have corresponded recently with David Roberts about this issue,
     and we had a long phone conversation about it the other day.
     
     I would like to discuss this issue at Monday's ETF phone call.
     
     As I see it, there are several inconsistencies in the existing
     behavior, and we have to decide what to do about them, and only then
     can we generalize it.
     
     David, please check that I am describing things correctly.
     
     Specifically, let's first take only the limited cases which are
     supported by Verilog-XL. XL's behavior in these cases is duplicated by
     VCS and NC-Verilog.
     
     XL supports only the cases where the timing check condition is of the
     form:
     
     signal (1-bit net or bit-select)
     !signal
     signal == scalar_constant (1-bit constant)
     signal != scalar_constant
     signal === scalar_constant
     signal !== scalar_constant
     
     1. The first inconsistency is the behavior if the signal value is 1'bx.
     If your condition is "signal === 1'b1", then the result is of course
     False, and the condition is disabled. However, if the condition is
     "signal == 1'b1", which in normal Verilog results in 1'bx, then the
     condition is ENABLED. The inconsistency is that if the condition is
     simply "signal", which in normal Verilog is also 1'bx, then the
     condition is DISABLED, as though you had written "signal === 1'b1".
     So there is an inconsistency between the behavior of two expressions
     which both result in 1'bx.
     
     The problem is that this behavior is well-established, documented,
     duplicated by VCS and NCV, and used by users.
     
     
     2. The second inconsistency is between X and Z. Pretty much everywhere
     in Verilog, where X/Z are treated as True or False, they are treated
     the same way, either both as True or both as False. The obvious
     exception is casez, but there the difference is explicit in the name,
     and besides the usual 'case' does not distinguish between them.
     
     Here in the timing check, if your timing condition is simply "signal",
     and it is 1'bx, then the condition is DISABLED, as above. However, if
     it is 1'bz, then it is ENABLED.
     
     And again, this behavior is well-established,
     duplicated by VCS and NCV, and used by users.
     
     However, it is NOT documented in the Verilog-XL Manual, but it IS
     documented in the VCS and NCV documented.
     
     
     3. Even worse, there is an inconsistency between Z and Z.
     That is, what I wrote above, that Z is considered True, that is if
     "signal" is connected to a driver which is 3-stated, driving 1'bz.
     However, if "signal" is simply unconnected, which is also a 1'bz,
     then the condition is considered False, and the timing check is
     DISABLED.
     
     And again, this behavior is well-established, duplicated by VCS and
     NCV, and used by users
     
     However, it is documented only by VCS, and not at all in the
     Cadence documentation.
     
     But as I wrote, the NCV code was written deliberately to duplicate
     the VXL behavior on this.
     
     
     So, before generalizing the behavior to vector conditions and
     more general expressions, we need to decide what to do with these
     cases, whether to standardize this behavior or not.
     
     Another option, for example, might be, to standardize a "saner"
     behavior (David Robert's word), and let the tool vendors add a
     switch to let the users choose whether the prefer the sane or the
     insane behavior.
     
     Another option might be to standardize this behavior, explicitly
     saying that it is only due to well-established existing behavior,
     but that anything beyond the limited cases accepted by Verilog-XL,
     e.g., vectors or expressions, go by saner behavior.
     
     Anyway, we need the ETF to recommend a direction. This is not
     something I can decide on by myself.
     
     Thanks,
     Shalom
     
     
     On Thu, 4 Sep 2003, David Roberts wrote:
     
    > > That still leaves the issue of whether the timing check should be
    > > enabled or not when the condition is X or Z.
    >
    > The only comment I can make is that, what is presently in the IEEE
    > 1364-2001 standard ignoring the confusing gobbledygook wording.
    >
    > "When comparisons are deterministic, an X value on the conditioning
    > signal shall not enable the timing check. For nondeterministic
    > comparisons, an X on the conditioning signal shall enable the
    > timing check."
    >
    > This was the origional documented to behavior of Verilog-XL. It
    > is the way Verilog-XL presently behaves. NCV has also implimented
    > the same behavior. Changing this behavior would have a nasty impact
    > on users.
    >
    > Changing the behavior would make the behavior of simulators supporting
    > the different version of the IEEE-1364 incompatible. I do not see
    > this part of the issue as an errata.
     
     --
     Shalom Bresticker Shalom.Bresticker@motorola.com
     Design, Verification & Reuse Methodology Tel: +972 9 9522268
     Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890
     POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478
     

    This archive was generated by hypermail 2.1.4 : Thu Feb 05 2004 - 07:40:03 PST and
    sponsored by Boyd Technology, Inc.