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

From: Shalom.Bresticker@motorola.com
Date: Mon Sep 01 2003 - 06:40:01 PDT

  • Next message: Shalom Bresticker: "errata/460: 9.6, 9.7.7: neg/x/z repeat count"

    Precedence: bulk

    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: Mon, 1 Sep 2003 16:27:11 +0300 (IDT)

     OK, I believe I finally understand what is going on here.
     
     In Verilog-XL, the "expression" in "scalar_timing_check_condition"
     is a SCALAR expression, and not even a general scalar expression,
     but just a scalar net or a net bit-select.
     
     So the form of scalar_timing_check_condition in Verilog-XL is very
     limited. That is the source of the sentence that "The conditioning
     signal shall be a scalar net".
     
     That is also the source of the statement that if you want to use
     more than one conditioning signal, you must combine them outside
     the timing check, because the timing check condition may contain
     only a scalar net name, possibly compared to a scalar constant,
     but not a general expression. In Verilog-XL.
     
     NC-Verilog somewhat generalizes it.
     
     In NCV, you can use a vector as well as a scalar, or even a general
     expression. So the paragraph which says that if you want to use
     more than one conditioning signal, you must combine them outside
     the timing check, is actually not accurate. And indeed the language
     in the NCV manual is more relaxed on that point.
     
     The sticky point in my mind is the following:
     
     NCV and 1364-2001 say that if the expression is multi-bit, then only
     the LSB is used. First, this is actually different than every other
     place in the LRM. (The case of @(posedge ...) is not relevant here.)
     In every other place, a vector is considered true if it is
     different from zero, and false if it is zero.
     
     NCV allows the "scalar_constant" to be a vector also, but again
     says that only the LSB will be used.
     
     I see a problem because the NCV manual gives the following example:
     
     "&&&(A == 4'b1010)
     In this case, the least significant bit of A and 4'b1010 are
     considered with the non-deterministic == operator."
     
     The problem is that NCV recognizes the condition of being of the form
     "expression == constant". Then it says, I will look only at the LSB
     of A and the LSB of 4'b1010. So it actually evaluates "(A[0] == 1'b0)".
     
     This is different from evaluating "(A == 4'b1010)" and then looking
     at the LSB of the result. (Actually, the "==" operation always results
     in a 1-bit result.)
     
     So there actually is a real difference between the form of "expression"
     and "expression == constant". That is, there is today in NCV.
     
     I don't know about VCS. The documentation does not say.
     
     That means that the proposed change changes the behavior from how
     it works today. I think the proposal is much cleaner than the current
     behavior, but there is a compatibility question here.
     But not with Verilog-XL, because it does not allow these cases anyway.
     
     Final issue: The second paragraph of 15.6 discusses deterministic and
     non-deterministic comparisons, and x value on the conditioning signal.
     All that suddenly becomes much clearer when you realize that that
     paragraph comes from Verilog-XL with its very limited syntax.
     (I.e., the expression can only be a scalar net). Also, the Verilog-XL
     LRM contains an additional clause which further clarifies the
     intentionL it says that the deterministic comparison to an X value on
     the conditioning signal shall not enable the timing check EXCEPT FOR
     THE FORM "signal === 1'bx"
     
     Basically, what this paragraph is trying to say that the == and ===
     operators act like usual, where the result of the == may be X, and
     the result of === is always an absolute True of False. The important
     point here is that if the timing_check_condition evaluates to Z or X,
     then the timing check is ENABLED.
     
     And that is what that paragraph should say instead of the current
     confusing gobbledygook.
     
     However, the VCS documentation seems to imply that if the condition
     is X or Z, then the timing check is DISABLED.
     
     So we have to decide on that too.
     
     And NOW that we understand what is going on, we can decide what we
     want to do.
     
     Shalom
     
     
    > Date: Wed, 20 Aug 2003 08:14:37 +0300
    > From: David Roberts <roberts@cadence.com>
    > Subject: Re: errata/237: PROPOSAL - A.7.5.3: scalar_timing_check_expressions has redundancies
    >
    > > In A.7.5.3:
    > >
    > > REPLACE:
    > > scalar_timing_check_condition ::=
    > > expression
    > > | ~ expression
    > > | expression == scalar_constant
    > > | expression === scalar_constant
    > > | expression != scalar_constant
    > > | expression !== scalar_constant
    > >
    > > WITH:
    > > scalar_timing_check_condition ::=
    > > expression
    > >
    > > REPLACE:
    > > timing_check_condition ::=
    > > scalar_timing_check_condition
    > > | ( scalar_timing_check_condition )
    > > WITH:
    > > timing_check_condition ::=
    > > scalar_timing_check_condition
    >
    > As far as the present set of proposed changes to the BNF they look OK.
    > All they are doing is removing what appears to be redundant syntax.
    > These changes can be supported in NC-Verilog.
    >
    > There is still work that needs to be done with the proposal. First
    > the BNF definition of "scalar_constant" will no longer be needed in
    > "Syntax 15-16" and section A.7.5.3. Next, is the intent of the edits
    > to clean up the present documented BNF or to allow timing checks to
    > work with complex expressions.
    >
    > If the intent is to allow complex expressions then the use of "scalar"
    > should be removed from the tcheck BNF. Using it, implies that there
    > is still some set of restrictions on what the express can be. Next
    > the text in section 15.6 is still restrictive on what a condition can
    > be. The third paragraph has gone part of the way by saying that the
    > signal and the resulting expression can be a vector. On the other
    > hand paragraph four states that only one signal can be used in a
    > condition.
     
     --
     Shalom Bresticker Shalom.Bresticker@motorola.com
     Design & 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 : Mon Sep 01 2003 - 06:42:08 PDT and
    sponsored by Boyd Technology, Inc.