ISSUE 237

Add Proposal  Add Analysis  Edit Class, Environment, or Release
Number 237
Category errata
Synopsis 15.1, 15.6, A.7.5.3: scalar_timing_check_expressions has redundancies
State open
Class errata-discuss
Arrival-DateDec 29 2002
Originator Dan.Jacobi@intel.com
Release 2001b: 15.1, 15.6, A.7.5.3
Environment
See SV-BC19-41,42
Description
This is from Dan Jacobi.

scalar_timing_check_condition ::=
expression
| ~ expression
| expression == scalar_constant
| expression === scalar_constant
| expression != scalar_constant
| expression !== scalar_constant

The last 5 rules are redundant due to the fact that they all
can be parsed by parsing the expression token.
The main intention might have been to use the syntactic
category 'primary' instead of 'expression' in all the
above rules.
In this case we wouldn't need to strike out the specified
rules.

This issue is labeled as SV-BC-19-42.
This issue is related to the IEEE-1364 standard.

timing_check_condition ::=
scalar_timing_check_condition
| ( scalar_timing_check_condition )

Assuming the previous fix is correct,
then the brackets can be added when parsing the token
'expression', therefore the removed rule is redundant.

This issue is labeled as SV-BC-19-41.
This issue is related to the IEEE-1364 standard.

Fix
1. In Syntaxes 15-2 and 15-16 and in A.7.5.3:

REPLACE:
timing_check_condition ::=
scalar_timing_check_condition
| ( scalar_timing_check_condition )
WITH:
timing_check_condition ::=
expression

AND
REMOVE:
the definitions of scalar_constant and
scalar_timing_check_condition

2. In addition, in 15.6, REPLACE paragraphs 2,3,4:

"The comparisons used in the condition can be deterministic, as in ===, !==, ~, or no operation, or nondeterministic,
as in == or !=. 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.

The conditioning signal shall be a scalar net; if a vector net or an expression resulting in a multi-bit value is
used, then the least significant bit of the vector net or the expression value is used.

If more than one conditioning signal is required for conditioning timing checks, appropriate logic shall be
combined in a separate signal outside the specify block, which can be used as the conditioning signal."

WITH:

"The condition may be a single-bit or multi-bit signal or
expression. The timing check is enabled if the condition is
different from zero. The timing check is disabled if the
condition is zero. If it is ambiguous whether the value of
the condition is zero or not, then the timing check is
enabled."


3. Also in 15.6, REMOVE Examples 2 and 3.
Audit-Trail
From: "Brad Pierce" <Brad.Pierce@synopsys.com>
To: <etf-bugs@boyd.com>
Cc:
Subject: Re: errata/237: A.7.5.3: scalar_timing_check_expressions has redundancies
Date: Wed, 15 Jan 2003 11:06:45 -0800

Before proceeding further with this issue, I think we need to resolve
the following question --

Can timing checks (15.6) really use arbitrary expressions as
the BNF suggests, or was the intent to limit them to using
primaries (or constant_primaries or ...) ?

-- Brad

From: Shalom.Bresticker@motorola.com
To: Brad Pierce <Brad.Pierce@synopsys.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/237: A.7.5.3: scalar_timing_check_expressions has
redundancies
Date: Thu, 16 Jan 2003 11:58:54 +0200 (IST)

> Before proceeding further with this issue, I think we need to resolve
> the following question --
>
> Can timing checks (15.6) really use arbitrary expressions as
> the BNF suggests, or was the intent to limit them to using
> primaries (or constant_primaries or ...) ?

I found an old mail from Ted Elkind from 1997-07-31 which may shed some light on
this. The excerpt starts in the middle of a reply to a previous mail:

start excerpt:
> timing_check_condition ::=
> scalar_expression
>
>This supports the apparent intent of the actual syntax, and it
>allows all the examples given in section 14.5.11.
>
>(Note: Perhaps the syntax given in 14.5.11 is intended more as a
>suggested usage pattern than as a linguistic definition.)

I have an older version of the Verilog-XL reference manual that
explicitly defines scalar_expression. Here's the whole definition
from Appendix A of the March 1991 version 1.6 manual:

<timing_check_condition>
::= <SCALAR_EXPRESSION>
||= ~<SCALAR_EXPRESSION>
||= <SCALAR_EXPRESSION> == <scalar_constant>
||= <SCALAR_EXPRESSION> === <scalar_constant>
||= <SCALAR_EXPRESSION> != <scalar_constant>
||= <SCALAR_EXPRESSION> !== <scalar_constant>

<SCALAR_EXPRESSION> is a one bit net or a bit select of an
expanded vector net.

This means that section 14.5.11 incompletely captured what was in the
Verilof-XL manual, and that the syntax in Annex A incorrectly
captured what was in section 14.5.11.

It has been a very common Verilog-XL enhancement request to allow
generalized expressions in timing check conditions. We may want to do
this for the 1364 standard, but by conscious decision rather than by
accident.

end excerpt:

Shalom


From: Shalom.Bresticker@motorola.com
To: etf-bugs@boyd.com
Cc:
Subject: Re: errata/237: PROPOSAL - A.7.5.3: scalar_timing_check_expressions
has redundancies
Date: Tue, 4 Mar 2003 12:04:03 +0200 (IST)

If this is still in the investigation phase,
then I think it is premature to already move the issue to the PROPOSAL state.

Furthermore, it seems to me that a change in the BNF requires substantial
changes to the text as well.

Shalom


On Mon, 3 Mar 2003, Karen Pieper wrote:

> I did. I checked with the VCS team and it matches their behavior. Charles
> is still checking on Cadences.


From: Shalom Bresticker <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_expressionshas
redundancies]
Date: Wed, 20 Aug 2003 08:14:37 +0300

I resend this to etf-bugs to get it into the database, Shalom.

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

--David Roberts

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


From: David Roberts <roberts@cadence.com>
To: Shalom.Bresticker@motorola.com
Cc: etf-bugs@boyd.com, David Roberts <roberts@cadence.com>
Subject: Re: errata/237: PROPOSAL - A.7.5.3: scalar_timing_check_expressions
has redundancies
Date: Thu, 4 Sep 2003 09:17:26 -0400

Shalom.Bresticker@motorola.com writes:
> OK, I believe I finally understand what is going on here.
>
snip-snip-snip
>
> 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.

The use of "==" or "===" or ... results are scalar values. I will look
into updating NCV's behavior to properly do a full vector comparison
which generates a scalar TRUE/FALSE result.

There should be no contention on this part of the LRM.


--David Roberts
Cadence Design Systems, Inc.


From: Shalom.Bresticker@motorola.com
To: David Roberts <roberts@cadence.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/237: PROPOSAL - A.7.5.3: scalar_timing_check_expressions
has redundancies
Date: Thu, 4 Sep 2003 16:29:16 +0300 (IDT)

Thanks.

That still leaves the issue of whether the timing check should be
enabled or not when the condition is X or Z.

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


From: David Roberts <roberts@cadence.com>
To: Shalom.Bresticker@motorola.com
Cc: David Roberts <roberts@cadence.com>, etf-bugs@boyd.com
Subject: Re: errata/237: PROPOSAL - A.7.5.3: scalar_timing_check_expressions
has redundancies
Date: Thu, 4 Sep 2003 09:53:11 -0400

Shalom.Bresticker@motorola.com writes:
> Thanks.
>
> 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.


--David Roberts
Cadence Design Systems, Inc.

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

From: Shalom.Bresticker@motorola.com
To: David Roberts <roberts@cadence.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/237: PROPOSAL - A.7.5.3: scalar_timing_check_expressions
has redundancies
Date: Thu, 4 Sep 2003 17:34:51 +0300 (IDT)

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.

I agree that what is in 1364-2001 documents the behavior of Verilog-XL and
NCV.

The VCS User Guide states:

"VCS, like Verilog-XL, supports timing check conditioners as in the
following example where the setup check on data every positive edge of clk
is conditioned by the signal rst:

$setup(data, posedge clk &&& rst, 1.0);

However, VCS enables the timing check only when rst is 1.
Alternatively if the condition is ~rst, then the timing check is enabled
only when rst is 0.
Verilog-XL also enables the timing check if the conditioner is value z
(undriven). In both Verilog-XL and VCS, if the conditioner is an
unconnected port, the timing check is disabled."

I confess that I do not understand this completely.

The Verilog-XL Manual does not actually mention the case where the
condition is Z. It does say that X enables the timing check, but it does
not mention Z. I assumed the treatment of Z is identical to X, as is
usual.
The NCV manual mentions both X and Z.

I don't understand what the VCS manual says, that if the conditioner is
unconnected, then the timing check is disabled, even in VXL. If it is
unconnected, then its value is X or Z, no? So why is the check disabled?

Be that as it may, the behavior that x/z usually act like 0 in Verilog,
not 1. This place is an exception. So there is reason to reconsider it.

Although in general 1364 tries to remain back-compatible with itself and
with Verilog-XL, there have been exceptions.

I will revise the proposal to take into account the recent comments.

The decision of the committee on how to relate to x/z will simply affect
whether we use the word "enable" or "disable". The rest of the proposal
need not change.

Shalom

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


From: Shalom.Bresticker@motorola.com
To: etf-bugs@boyd.com
Cc:
Subject: Re: errata/237: PROPOSAL - A.7.5.3: scalar_timing_check_expressions
has redundancies
Date: Fri, 5 Sep 2003 11:45:56 +0300 (IDT)

Please note that the proposal allows a complex expression to appear without
parentheses. I do not think that is a problem, since the expression is
preceded by &&& and followed by a comma.

> REPLACE:
> timing_check_condition ::=
> scalar_timing_check_condition
> | ( scalar_timing_check_condition )
> WITH:
> timing_check_condition ::=
> expression

Shalom

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

From: Shalom Bresticker <Shalom.Bresticker@freescale.com>
To: etf-bugs@boyd.com
Cc:
Subject: errata/237: timing check conditions
Date: Sun, 02 May 2004 17:02:19 +0300

This is a multi-part message in MIME format.
--------------E5DD19436531D689AAE55A67
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

This is some additional information.
--------------E5DD19436531D689AAE55A67
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Message-ID: <md5:7AB70244E9B2CAE6101D6A012B38CBB8>
Received: from il06exr02.mot.com ([129.188.137.132]) by zil05exm01.sps.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.2)
id CXT6M5BA; Wed, 4 Feb 2004 16:45:00 +0200
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100])
by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id i14Ehb4m002330
for <Shalom.Bresticker@motorola.com>; Wed, 4 Feb 2004 08:43:38 -0600
Received: from mailgate.Cadence.COM (mailgate.Cadence.COM [158.140.2.1])
by motgate.mot.com (Motorola/Motgate) with ESMTP id i14Eis46003186
for <Shalom.Bresticker@motorola.com>; Wed, 4 Feb 2004 07:44:54 -0700 (MST)
Received: from mailhub.Cadence.COM (mailhub.Cadence.COM [158.140.128.33])
by mailgate.Cadence.COM (8.9.3/8.9.3) with ESMTP id GAA09300;
Wed, 4 Feb 2004 06:40:38 -0800 (PST)
Received: from tweety.Cadence.COM (tweety [158.140.104.136])
by mailhub.Cadence.COM (8.12.8/8.8.5) with ESMTP id i14EecL8001235;
Wed, 4 Feb 2004 06:40:38 -0800 (PST)
Received: (from roberts@localhost)
by tweety.Cadence.COM (8.11.6+Sun/8.11.6) id i14Eebm03225;
Wed, 4 Feb 2004 09:40:37 -0500 (EST)
From: David Roberts<roberts@cadence.com>
Content-Type: text/plain; charset=us-ascii
Date: Wed, 4 Feb 2004 09:40:37 -0500
To: David Roberts<roberts@tweety.cadence.com>
Cc: "Shalom Bresticker"<Shalom.Bresticker@motorola.com>,
<karen.pieper@synopsys.com>
Subject: Re: 1364 ETF issue errata/237 take 2
X-Mozilla-Status2: 00000000
X-Status:
X-Keywords:
X-UID: 79290

Some information to the semantics of conditions.

For the simple or what was called "deterministic" conditions the
initial state of the condition is concidered FALSE. There has to
be some transition to make the condition turn TRUE.

Normally all wire start out as X at pre time 0. There is the
exception that an undriven wire has an initial value of Z. Because
the undriven wire has an initial value of Z it does not transition on
time 0 and does not enable the condition. I would call this a bug but
I have replicated this basic Verilog-XL behavior in NC-SIM.

There is a caveat, if you force this undriven net to a 1 then release
it the conditon will now be concidered TRUE. This is the case with
both Verilog-XL and NC-Sim. The one difference is that NC-SIM will
treat the floating "1'bZ' net condition as TRUE starting at time 0.
Because there is a force on the net the net will have an X->Z
transition at time 0. I had refused to match this behavior way back
when and was never dinged on it.

My bad for not catching this funky behavior earlier. It's been a
while since I had to play with this corner case behavior. A testcase
is contained below.



--David



module top;

reg a, b, c;
wire w;

foo u1 (a, b, c, out);
foo u2 (a, b, , out2);
foo u2a(a, b, w, out2a);
foo2 u3 (a, b, d, out3);
foo2 u4 (a, b, d, out4);

initial
begin
$monitor($time,,a,b, out);
a = 0;
b = 0;
c = 1'bz;

#100 a = ~a;
#5 b = ~b;

#95 force u4.m = 1'b1;
#100 a = ~a;
#5 b = ~b;

// #95 force u4.m = 1'bz;
#95 release u4.m;
#100 a = ~a;
#5 b = ~b;
end
endmodule

module foo(a, b, c, o);
input a, b, c;
output o;

always @(c) $display($time, " %m c= ", c);
and (o, a, b);

specify
$setup(a, b &&& c, 10);
endspecify
endmodule

module foo2(a, b, c, o);
input a, b, c;
output o;
wire m;

and (o, a, b);

specify
$setup(a, b &&& m, 10);
endspecify
endmodule


--------------E5DD19436531D689AAE55A67--

From: Shalom Bresticker <Shalom.Bresticker@freescale.com>
To: etf-bugs@boyd.com
Cc:
Subject: re: errata/237
Date: Mon, 10 May 2004 18:03:10 +0300

>Category: errata
>Confidential: no
>Originator: Shalom Bresticker <Shalom.Bresticker@freescale.com>
>Release: 2001b
>Submitter-Id: etf
>Class: TBD
>Description:
Just wanted to let people know that I am actually making progress on this,
depending on your definition of progress.

I have been recording what existing tools actually do in these cases.
My results show that the actual behavior is sometimes different than what we
thought or were told.

In some cases, behavior seems to differ from the LRM,
in others, it seems to differ from what is described in the tool documentation,
and in others, it seems even to differ from what the tool developers think!

Don't whether whether that's good or bad.

It does seem to leave us more flexibility.

Shalom

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

Unformatted

Hosted by Boyd Technology