ISSUE 401

Add Proposal  Add Analysis  Edit Class, Environment, or Release
Number 401
Category enhancement
Synopsis reduce relational operators x-pessimism
State open
Class enhancement
Arrival-DateJul 25 2003
Originator Shalom.Bresticker@motorola.com
Release 2001b: 4.1.7
Environment
Description
Today, 4.1.7 says,
"If either operand of a relational operator contains an unknown (x)
or high impedance (z) value, then the result value shall be a 1-bit unknown
value (x)."

There are cases where it is clearly possible to be less conservative.
For example, for 4'b1000 > 4'b000x, then clearly the result could be 1'b1
instead of 1'bx.

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

Fix
Audit-Trail

From: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com, Shalom.Bresticker@motorola.com
Cc:
Subject: Re: enhancement/401: reduce relational operators x-pessimism
Date: Mon, 28 Jul 2003 20:05:49 -0400 (EDT)

Getting an exact answer for relational operators is not as expensive as
for the arithmetic operators, but is still more expensive than with
the current pessimistic definition.

Many of the other comments that I made about the arithmetic operators
in enhancement/400 still apply here.

Steven Sharp
sharp@cadence.com

From: Shalom.Bresticker@freescale.com
To: btf-bugs@boyd.com
Cc:
Subject: enhancement/401: Reduce relational operators x-pessimism
Date: Sun, 23 May 2004 09:57:55 +0300 (IDT)

---------- Forwarded message ----------
Date: Sun, 23 May 2004 09:51:24 +0300 (IDT)
From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: jon.beecroft@quadrics.com
Cc: btf@boyd.com
Subject: RE: my enhancement request priorities

Thanks for your interesting comments.

I am forwarding them to the entire list because I think they will interest
others as well.

I see what you are saying, but there is of course another side to it as well.

I might want to be able to control the operator behavior on a file by file
basis, maybe with a compiler directive, or even have some way of indicating
an individual operator.

It reminds me that when signed arithmetic was being discussed, there was a
discussion as to whether the signedness should be an attribute of operands
or of operators. There was a proposal to designate a signed arithmetic operation
by adding a ` to the operator, such as `+ for signed addition. Of course,
in the end the signed operand approach was taken.

I would like to suggest you look at the correspondence on issue 404 as well.

With respect to the specific issues you raise, see below.


On Fri, 21 May 2004 jon.beecroft@quadrics.com wrote:

> Shalom,
>
> I am a busy designer who has an interest in simulation with a view to correct, first time, design. I was put on the btd@boyd.com list a few years ago after helping co-design with superlog. For the most part I am very happy to let you, very competent people, steadily improve the verilog language.
>
> I would like to briefly discuss the following point.
>
> > 400 Reduce arithmetic operators x-pessimism
> > 401 Reduce relational operators x-pessimism
> >
> > These two proprosals come from the fact that arithmetic
> > and relational
> > operations in Verilog are "unreasonably" pessimistic.
> > Basically, an X/Z anywhere
> > in any of the operations causes the entire result to be
> > X, even if the result or
> > part of it can actually be shown to be deterministic.
> > Too much X propagation
> > often fouls up simulations and causes many troubles for
> > users. Objections to
> > changing are: it is more expensive in simulation time
> > to be more realistic, some
> > people might prefer the pessimistic evaluation, it is
> > not clear that it is
> > correct to simply treat each X as 0 or 1 and combine
> > the results, and it is not
> > back-compatible.
> > The case for improving the relational operators is
> > stronger. MEDIUM-LOW priority
> > due to the compatibility problem.
>
> I am a huge believer in X! It is a very powerful construct that has on many occasions saved our company. Yes it can be irritating, especially in the early stages of a design, but it is also a life saver as it finds bugs that would never be found, in the lifetime of a project, through normal simulation. It is truly brilliant on the end of very fat decode as it is never possible to put a design into all the possible states.
>
> Far from reducing pessimism I would like certain operations to propagate X more eagerly. In particular the following:
>
> 1. == e.g. (variable == constant) Here the result should be X if any bit of variable is X or Z.
> I have been hurt by this one and as a result, in places where I feel I might be vulnerable, I now use the very ugly &(variable ~^ constant) that at least always returns the correct answer and is totally safe.

I believe this would come up only where the operands are definitely not equal?
If there is any x or z, then they are not equal even in today's verilog
( x == x gives a result of x), and if the equality is ambiguous (e.g, 0 == x),
then even today the result is x. So it would change only in a case like
00 = 1x, which would today give 0 and you would want x.


> 2. if (expression) If expression returns X then I believe that everything assigned in both the if and else part should be put to X. Again I have been nearly bitten by this one on more than one occasion.

A problem here is that the if and else clauses can contain aribitrary
behavioral code, such as system and user task calls. What do you do with
these?


> If these two changes were put into the verilog and the regression tests were rerun on a number of designs I bet new and real bugs would be discovered.

I do agree with you at least about #2.


> The whole point of verilog is to shake out all the problems in a design. In my opinion it is far more important to have a "correct" design than to have a "simulate to the end without going X" design. As a design philosophy I also reset the minimum amount of state. In this way I get the maximum benefit from X where a signal has not had enough decode applied to correctly implement the required function.
>
> I guess you would suffer from the legacy problem if you were to include my suggestions but I currently have to use +v2k with vcs so another flag would be a price I would pay for readable and correct verilog.
>
> I am Head of ASIC design for Quadrics Ltd. We design supercomputers. Last year 6 of the top ten machines used our technology. We have just finished the installation of Thunder at Lawrence Livermore Labs. This uses A rev silicon for both my switch component and my network interface chip.
>
> Best Regards
>
> Jon Beecroft

Thanks,
Shalom

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

From: Michael McNamara <mac@verisity.com>
To: Shalom.Bresticker@freescale.com
Cc: etf-bugs@boyd.com
Subject: RE: enhancement/401: Reduce relational operators x-pessimism
Date: Sun, 23 May 2004 08:03:54 -0700

I have to agree with Jon - pessimism is warrented when the cost of
optimisim is a $500,000 mask re-tool.

I am intrigued with the notion of:

if (a ) begin
b = c;
end
else begin
d = e;
end

setting b & d to x if a is ambiguous.

I never liked the fact that if a was ambiguous, the else block would
be executed; and hence always (tried to) code these as:

if (a ) begin
b = c;
end
else if (!a) begin
d = e;
end




-- On May 22 2004 at 23:40, Shalom.Bresticker@freescale.com sent a message:
> To: etf-bugs@boyd.com
> Subject: "enhancement/401: Reduce relational operators x-pessimism"
> The following reply was made to PR enhancement/401; it has been noted by GNATS.
>
> From: Shalom.Bresticker@freescale.com
> To: btf-bugs@boyd.com
> Cc:
> Subject: enhancement/401: Reduce relational operators x-pessimism
> Date: Sun, 23 May 2004 09:57:55 +0300 (IDT)
>
> ---------- Forwarded message ----------
> Date: Sun, 23 May 2004 09:51:24 +0300 (IDT)
> From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
> To: jon.beecroft@quadrics.com
> Cc: btf@boyd.com
> Subject: RE: my enhancement request priorities
>
> Thanks for your interesting comments.
>
> I am forwarding them to the entire list because I think they will interest
> others as well.
>
> I see what you are saying, but there is of course another side to it as well.
>
> I might want to be able to control the operator behavior on a file by file
> basis, maybe with a compiler directive, or even have some way of indicating
> an individual operator.
>
> It reminds me that when signed arithmetic was being discussed, there was a
> discussion as to whether the signedness should be an attribute of operands
> or of operators. There was a proposal to designate a signed arithmetic operation
> by adding a ` to the operator, such as `+ for signed addition. Of course,
> in the end the signed operand approach was taken.
>
> I would like to suggest you look at the correspondence on issue 404 as well.
>
> With respect to the specific issues you raise, see below.
>
>
> On Fri, 21 May 2004 jon.beecroft@quadrics.com wrote:
>
> > Shalom,
> >
> > I am a busy designer who has an interest in simulation with a view to correct, first time, design. I was put on the btd@boyd.com list a few years ago after helping co-design with superlog. For the most part I am very happy to let you, very competent people, steadily improve the verilog language.
> >
> > I would like to briefly discuss the following point.
> >
> > > 400 Reduce arithmetic operators x-pessimism
> > > 401 Reduce relational operators x-pessimism
> > >
> > > These two proprosals come from the fact that arithmetic
> > > and relational
> > > operations in Verilog are "unreasonably" pessimistic.
> > > Basically, an X/Z anywhere
> > > in any of the operations causes the entire result to be
> > > X, even if the result or
> > > part of it can actually be shown to be deterministic.
> > > Too much X propagation
> > > often fouls up simulations and causes many troubles for
> > > users. Objections to
> > > changing are: it is more expensive in simulation time
> > > to be more realistic, some
> > > people might prefer the pessimistic evaluation, it is
> > > not clear that it is
> > > correct to simply treat each X as 0 or 1 and combine
> > > the results, and it is not
> > > back-compatible.
> > > The case for improving the relational operators is
> > > stronger. MEDIUM-LOW priority
> > > due to the compatibility problem.
> >
> > I am a huge believer in X! It is a very powerful construct that has on many occasions saved our company. Yes it can be irritating, especially in the early stages of a design, but it is also a life saver as it finds bugs that would never be found, in the lifetime of a project, through normal simulation. It is truly brilliant on the end of very fat decode as it is never possible to put a design into all the possible states.
> >
> > Far from reducing pessimism I would like certain operations to propagate X more eagerly. In particular the following:
> >
> > 1. == e.g. (variable == constant) Here the result should be X if any bit of variable is X or Z.
> > I have been hurt by this one and as a result, in places where I feel I might be vulnerable, I now use the very ugly &(variable ~^ constant) that at least always returns the correct answer and is totally safe.
>
> I believe this would come up only where the operands are definitely not equal?
> If there is any x or z, then they are not equal even in today's verilog
> ( x == x gives a result of x), and if the equality is ambiguous (e.g, 0 == x),
> then even today the result is x. So it would change only in a case like
> 00 = 1x, which would today give 0 and you would want x.
>
>
> > 2. if (expression) If expression returns X then I believe that everything assigned in both the if and else part should be put to X. Again I have been nearly bitten by this one on more than one occasion.
>
> A problem here is that the if and else clauses can contain aribitrary
> behavioral code, such as system and user task calls. What do you do with
> these?
>
>
> > If these two changes were put into the verilog and the regression tests were rerun on a number of designs I bet new and real bugs would be discovered.
>
> I do agree with you at least about #2.
>
>
> > The whole point of verilog is to shake out all the problems in a design. In my opinion it is far more important to have a "correct" design than to have a "simulate to the end without going X" design. As a design philosophy I also reset the minimum amount of state. In this way I get the maximum benefit from X where a signal has not had enough decode applied to correctly implement the required function.
> >
> > I guess you would suffer from the legacy problem if you were to include my suggestions but I currently have to use +v2k with vcs so another flag would be a price I would pay for readable and correct verilog.
> >
> > I am Head of ASIC design for Quadrics Ltd. We design supercomputers. Last year 6 of the top ten machines used our technology. We have just finished the installation of Thunder at Lawrence Livermore Labs. This uses A rev silicon for both my switch component and my network interface chip.
> >
> > Best Regards
> >
> > Jon Beecroft
>
> Thanks,
> Shalom
>
> --
> 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
>

From: Shalom.Bresticker@freescale.com
To: Michael McNamara <mac@verisity.com>
Cc: etf-bugs@boyd.com
Subject: RE: enhancement/401: Reduce relational operators x-pessimism
Date: Sun, 23 May 2004 22:37:58 +0300 (IDT)

> if (a ) begin
> b = c;
> end
> else if (!a) begin
> d = e;
> end

Of course, that would give you yet a third behavior if a were equal to x:
b and d would retain their old values whereas in a true gate-level
implementation, they would get a cross between old values and new values.

From: Michael McNamara <mac@verisity.com>
To: Shalom.Bresticker@freescale.com
Cc: Michael McNamara <mac@verisity.com>, etf-bugs@boyd.com
Subject: RE: enhancement/401: Reduce relational operators x-pessimism
Date: Sun, 23 May 2004 14:38:42 -0700

-- On May 23 2004 at 22:37, Shalom.Bresticker@freescale.com sent a message:
> To: mac@verisity.com, etf-bugs@boyd.com
> Subject: "RE: enhancement/401: Reduce relational operators x-pessimism"
> > if (a ) begin
> > b = c;
> > end
> > else if (!a) begin
> > d = e;
> > end
>
> Of course, that would give you yet a third behavior if a were equal to x:
> b and d would retain their old values whereas in a true gate-level
> implementation, they would get a cross between old values and new values.

Indeed. I believe what Jon is looking for is to get:

if (a )
b = c;
else if (!a)
d = e;
else begin
b = 'x;
d = 'x;
end

automagically.


From: "Stuart Sutherland" <stuart@sutherland-hdl.com>
To: <etf-bugs@boyd.com>
Cc:
Subject: RE: enhancement/401: Reduce relational operators x-pessimism
Date: Mon, 24 May 2004 00:06:46 -0700

I also like pessimism, but don't thing changing the 20-year behavior
if...else is warranted. The pessimism can be attained using the ?:
conditional operator if it is important to the user. Looking forward, this
is an ideal place to use a very simple SystemVerilog immediate assertion.
The pessimistic checking for X can quickly be turned on or off, as desired.

Stu

~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland
stuart@sutherland-hdl.com
503-692-0898

> -----Original Message-----
> From: owner-etf@boyd.com [mailto:owner-etf@boyd.com] On
> Behalf Of Michael McNamara
> Sent: Sunday, May 23, 2004 7:50 AM
> To: etf-bugs@boyd.com
> Subject: RE: enhancement/401: Reduce relational operators x-pessimism
>
> The following reply was made to PR enhancement/401; it has
> been noted by GNATS.
>
> From: Michael McNamara <mac@verisity.com>
> To: Shalom.Bresticker@freescale.com
> Cc: etf-bugs@boyd.com
> Subject: RE: enhancement/401: Reduce relational operators x-pessimism
> Date: Sun, 23 May 2004 08:03:54 -0700
>
> I have to agree with Jon - pessimism is warrented when the cost of
> optimisim is a $500,000 mask re-tool.
>
> I am intrigued with the notion of:
>
> if (a ) begin
> b = c;
> end
> else begin
> d = e;
> end
>
> setting b & d to x if a is ambiguous.
>
> I never liked the fact that if a was ambiguous, the else block would
> be executed; and hence always (tried to) code these as:
>
> if (a ) begin
> b = c;
> end
> else if (!a) begin
> d = e;
> end
>
>
>
>
> -- On May 22 2004 at 23:40, Shalom.Bresticker@freescale.com
> sent a message:
> > To: etf-bugs@boyd.com
> > Subject: "enhancement/401: Reduce relational operators
> x-pessimism"
> > The following reply was made to PR enhancement/401; it
> has been noted by GNATS.
> >
> > From: Shalom.Bresticker@freescale.com
> > To: btf-bugs@boyd.com
> > Cc:
> > Subject: enhancement/401: Reduce relational operators x-pessimism
> > Date: Sun, 23 May 2004 09:57:55 +0300 (IDT)
> >
> > ---------- Forwarded message ----------
> > Date: Sun, 23 May 2004 09:51:24 +0300 (IDT)
> > From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
> > To: jon.beecroft@quadrics.com
> > Cc: btf@boyd.com
> > Subject: RE: my enhancement request priorities
> >
> > Thanks for your interesting comments.
> >
> > I am forwarding them to the entire list because I think
> they will interest
> > others as well.
> >
> > I see what you are saying, but there is of course
> another side to it as well.
> >
> > I might want to be able to control the operator behavior
> on a file by file
> > basis, maybe with a compiler directive, or even have
> some way of indicating
> > an individual operator.
> >
> > It reminds me that when signed arithmetic was being
> discussed, there was a
> > discussion as to whether the signedness should be an
> attribute of operands
> > or of operators. There was a proposal to designate a
> signed arithmetic operation
> > by adding a ` to the operator, such as `+ for signed
> addition. Of course,
> > in the end the signed operand approach was taken.
> >
> > I would like to suggest you look at the correspondence
> on issue 404 as well.
> >
> > With respect to the specific issues you raise, see below.
> >
> >
> > On Fri, 21 May 2004 jon.beecroft@quadrics.com wrote:
> >
> > > Shalom,
> > >
> > > I am a busy designer who has an interest in simulation
> with a view to correct, first time, design. I was put on the
> btd@boyd.com list a few years ago after helping co-design
> with superlog. For the most part I am very happy to let you,
> very competent people, steadily improve the verilog language.
> > >
> > > I would like to briefly discuss the following point.
> > >
> > > > 400 Reduce arithmetic operators x-pessimism
> > > > 401 Reduce relational operators x-pessimism
> > > >
> > > > These two proprosals come from the fact that arithmetic
> > > > and relational
> > > > operations in Verilog are "unreasonably" pessimistic.
> > > > Basically, an X/Z anywhere
> > > > in any of the operations causes the entire result to be
> > > > X, even if the result or
> > > > part of it can actually be shown to be deterministic.
> > > > Too much X propagation
> > > > often fouls up simulations and causes many troubles for
> > > > users. Objections to
> > > > changing are: it is more expensive in simulation time
> > > > to be more realistic, some
> > > > people might prefer the pessimistic evaluation, it is
> > > > not clear that it is
> > > > correct to simply treat each X as 0 or 1 and combine
> > > > the results, and it is not
> > > > back-compatible.
> > > > The case for improving the relational operators is
> > > > stronger. MEDIUM-LOW priority
> > > > due to the compatibility problem.
> > >
> > > I am a huge believer in X! It is a very powerful
> construct that has on many occasions saved our company. Yes
> it can be irritating, especially in the early stages of a
> design, but it is also a life saver as it finds bugs that
> would never be found, in the lifetime of a project, through
> normal simulation. It is truly brilliant on the end of very
> fat decode as it is never possible to put a design into all
> the possible states.
> > >
> > > Far from reducing pessimism I would like certain
> operations to propagate X more eagerly. In particular the following:
> > >
> > > 1. == e.g. (variable == constant) Here the result
> should be X if any bit of variable is X or Z.
> > > I have been hurt by this one and as a result, in
> places where I feel I might be vulnerable, I now use the very
> ugly &(variable ~^ constant) that at least always returns the
> correct answer and is totally safe.
> >
> > I believe this would come up only where the operands are
> definitely not equal?
> > If there is any x or z, then they are not equal even in
> today's verilog
> > ( x == x gives a result of x), and if the equality is
> ambiguous (e.g, 0 == x),
> > then even today the result is x. So it would change only
> in a case like
> > 00 = 1x, which would today give 0 and you would want x.
> >
> >
> > > 2. if (expression) If expression returns X then I
> believe that everything assigned in both the if and else part
> should be put to X. Again I have been nearly bitten by this
> one on more than one occasion.
> >
> > A problem here is that the if and else clauses can
> contain aribitrary
> > behavioral code, such as system and user task calls.
> What do you do with
> > these?
> >
> >
> > > If these two changes were put into the verilog and the
> regression tests were rerun on a number of designs I bet new
> and real bugs would be discovered.
> >
> > I do agree with you at least about #2.
> >
> >
> > > The whole point of verilog is to shake out all the
> problems in a design. In my opinion it is far more important
> to have a "correct" design than to have a "simulate to the
> end without going X" design. As a design philosophy I also
> reset the minimum amount of state. In this way I get the
> maximum benefit from X where a signal has not had enough
> decode applied to correctly implement the required function.
> > >
> > > I guess you would suffer from the legacy problem if
> you were to include my suggestions but I currently have to
> use +v2k with vcs so another flag would be a price I would
> pay for readable and correct verilog.
> > >
> > > I am Head of ASIC design for Quadrics Ltd. We design
> supercomputers. Last year 6 of the top ten machines used our
> technology. We have just finished the installation of Thunder
> at Lawrence Livermore Labs. This uses A rev silicon for both
> my switch component and my network interface chip.
> > >
> > > Best Regards
> > >
> > > Jon Beecroft
> >
> > Thanks,
> > Shalom
> >
> > --
> > 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