ISSUE 566

Add Proposal  Add Analysis  Edit Class, Environment, or Release
Number 566
Category errata
Synopsis 9.5: case item expression ambiguity
State open
Class errata-discuss
Arrival-DateMar 19 2004
Originator "Brad Pierce" <Brad.Pierce@synopsys.com>
Release 2001c: 9.5
Description
Subclause 9.5 may not be not clear enough about what
a 'case item expression' is. Apparently, the case item
expression can include several expressions, and, if any of
them match, then the case item expression matches. "The case
item expressions shall be evaluated and compared in the exact
order in which they are given. During the linear search,
if one of the case item expressions matches the case expression
given in parentheses, then the statement associated with that
case item shall be executed and the linear search shall terminate."
If the comma separated list were composed of individual case item
expressions, then the above would mean that the following *must*
display 1 and could not legally display 2.

module m ( o1, o2 ) ;
output [1:0] o1, o2 ;
reg [1:0] o1, o2 ;

function f ;
input i ;
begin
o1 = o1 + 1 ;
f = i ;
end
endfunction

always begin
o1 = 0 ;
o2 = 0 ;
case ( 1'b1 )
f(1'b1) , f(1'b0) : o2 = o2 + 1 ;
default ;
endcase
$display("couldn't this be 2? -- is %d", o1 );
end

endmodule



Fix

Unknown
Audit-Trail
From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: etf-bugs@boyd.com
Cc:
Subject: Re: errata/566: 9.5: case item expression ambiguity
Date: Sun, 21 Mar 2004 16:33:47 +0200

In the implementations I checked, some returned 1 and some returned 2.

But I still don't see any ambiguity in the term "case item expression".

(By the way, you have an infinite loop there.)

Shalom

> Subclause 9.5 may not be not clear enough about what
> a 'case item expression' is. Apparently, the case item
> expression can include several expressions, and, if any of
> them match, then the case item expression matches. "The case
> item expressions shall be evaluated and compared in the exact
> order in which they are given. During the linear search,
> if one of the case item expressions matches the case expression
> given in parentheses, then the statement associated with that
> case item shall be executed and the linear search shall terminate."
> If the comma separated list were composed of individual case item
> expressions, then the above would mean that the following *must*
> display 1 and could not legally display 2.
>
> module m ( o1, o2 ) ;
> output [1:0] o1, o2 ;
> reg [1:0] o1, o2 ;
>
> function f ;
> input i ;
> begin
> o1 = o1 + 1 ;
> f = i ;
> end
> endfunction
>
> always begin
> o1 = 0 ;
> o2 = 0 ;
> case ( 1'b1 )
> f(1'b1) , f(1'b0) : o2 = o2 + 1 ;
> default ;
> endcase
> $display("couldn't this be 2? -- is %d", o1 );
> end
>
> endmodule

From: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com, Brad.Pierce@synopsys.com
Cc:
Subject: Re: errata/566: 9.5: case item expression ambiguity
Date: Mon, 22 Mar 2004 18:46:56 -0500 (EST)

Anything can always be made clearer, but this seems clear enough to me.
A "case item expression" is one of those expressions attached to a case item.
There may be a list of multiple expressions attached to a single case item,
in which case each expression is still a separate case item expression.

The phrase is clearly talking about an expression. A comma-separated list
of expressions is not an expression, and therefore not a case item expression.
I don't see how that could be considered a valid interpretation.

If this is really not clear, we could change the BNF for case_item to

case_item ::=
case_item_expression {, case_item_expression } : statement_or_null
| default [: ] statement_or_null

case_item_expression ::= expression

And I agree with Brad, that this means that his example code must display
1 and could not legally display 2. The description says that the case
item expressions shall be evaluated and compared in order and that the
linear search shall terminate when one matches. That does not allow
evaluating any later case item expressions, including ones attached to
the same case item.

Mind you, this is a pretty obscure thing, and is not likely to come up
in the real world.

Steven Sharp
sharp@cadence.com

From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: etf-bugs@boyd.com
Cc:
Subject: Re: errata/566: 9.5: case item expression ambiguity
Date: Tue, 23 Mar 2004 11:25:39 +0200

Although I basically agree with Steven, including about the obscurity
(I might call it pathology), conceivably someone could interpret the
phrase "shall be evaluated and compared in the exact order in which they are
given"
as meaning "shall be evaluated in order" and
"shall be compared in order", but allowing all the expressions to be first
evaluated before beginning the comparisons.
Especially since it also says above,
"The case expression and the case item expression can be computed at runtime".
This implies that the expressions can be evaluated earlier also.

Still I agree that that is a "dachuk" (difficult, weak, far-fetched)
interpretation.

But that entire phrase about evaluation and comparison in order was added by us
in issue 402 and is not part of 2001c.

Shalom


Steven Sharp wrote:

> And I agree with Brad, that this means that his example code must display
> 1 and could not legally display 2. The description says that the case
> item expressions shall be evaluated and compared in order and that the
> linear search shall terminate when one matches. That does not allow
> evaluating any later case item expressions, including ones attached to
> the same case item.
>
> Mind you, this is a pretty obscure thing, and is not likely to come up
> in the real world.

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

[x]Motorola General Business Information
[ ]Motorola Internal Use Only
[ ]Motorola Confidential Proprietary



From: "Brad Pierce" <Brad.Pierce@synopsys.com>
To: <etf-bugs@boyd.com>
Cc:
Subject: Re: errata/566: 9.5: case item expression ambiguity
Date: Tue, 23 Mar 2004 15:18:19 -0800

Even if, as an interpretation of the current text, those semantics
were dachuk, they nevertheless make good sense.

The text could specify that, just as with the case expression
in parentheses, all the case item expressions shall be evaluated
exactly once, in order, and before any comparisons. The only time
one would notice the difference would be in the presence of side-effects.

-- Brad



-----Original Message-----
From: owner-etf@boyd.com [mailto:owner-etf@boyd.com]On Behalf Of Shalom
Bresticker
Sent: Tuesday, March 23, 2004 1:20 AM
To: etf-bugs@boyd.com
Subject: errata/566: Re: errata/566: 9.5: case item expression ambiguity


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

From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: etf-bugs@boyd.com
Cc:
Subject: Re: errata/566: 9.5: case item expression ambiguity
Date: Tue, 23 Mar 2004 11:25:39 +0200

Although I basically agree with Steven, including about the obscurity
(I might call it pathology), conceivably someone could interpret the
phrase "shall be evaluated and compared in the exact order in which they
are
given"
as meaning "shall be evaluated in order" and
"shall be compared in order", but allowing all the expressions to be first
evaluated before beginning the comparisons.
Especially since it also says above,
"The case expression and the case item expression can be computed at
runtime".
This implies that the expressions can be evaluated earlier also.

Still I agree that that is a "dachuk" (difficult, weak, far-fetched)
interpretation.

But that entire phrase about evaluation and comparison in order was added
by us
in issue 402 and is not part of 2001c.

Shalom


Steven Sharp wrote:

> And I agree with Brad, that this means that his example code must
display
> 1 and could not legally display 2. The description says that the case
> item expressions shall be evaluated and compared in order and that the
> linear search shall terminate when one matches. That does not allow
> evaluating any later case item expressions, including ones attached to
> the same case item.
>
> Mind you, this is a pretty obscure thing, and is not likely to come up
> in the real world.

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

[x]Motorola General Business Information
[ ]Motorola Internal Use Only
[ ]Motorola Confidential Proprietary




From: Shalom.Bresticker@motorola.com
To: Brad Pierce <Brad.Pierce@synopsys.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/566: 9.5: case item expression ambiguity
Date: Wed, 24 Mar 2004 05:49:51 +0200 (IST)

Why do you want them to be evaluated before the comparisons?

> The text could specify that, just as with the case expression
> in parentheses, all the case item expressions shall be evaluated
> exactly once, in order, and before any comparisons. The only time
> one would notice the difference would be in the presence of side-effects.

From: "Brad Pierce" <Brad.Pierce@synopsys.com>
To: <etf-bugs@boyd.com>
Cc:
Subject: Re: errata/566: 9.5: case item expression ambiguity
Date: Wed, 24 Mar 2004 09:08:10 -0800

First, if this would effect the simulation efficiency
of even those case statements without side-effecting
case item expressions, then I wouldn't want it. I
assumed that static analysis could determine which
case statements are afflicted with this rather rare
style, and treat only those case statements in the
new way. If not, then never mind.

Having said that, the reason I was attracted to your
interpretation is that it seemed to fit better with
the handling of full_case parallel_case pragmas, which,
unlike side-effecting case item expressions, are very
common. It seemed natural to pull out all the side-effects,
do them in sequence, and only then do the case. (But
maybe it's just me, because full_case parallel_case
itself seems more natural to me than priority style.)

-- Brad

-----Original Message-----
From: owner-etf@boyd.com [mailto:owner-etf@boyd.com]On Behalf Of
Shalom.Bresticker@motorola.com
Sent: Tuesday, March 23, 2004 7:40 PM
To: etf-bugs@boyd.com
Subject: errata/566: Re: errata/566: 9.5: case item expression ambiguity


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

From: Shalom.Bresticker@motorola.com
To: Brad Pierce <Brad.Pierce@synopsys.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/566: 9.5: case item expression ambiguity
Date: Wed, 24 Mar 2004 05:49:51 +0200 (IST)

Why do you want them to be evaluated before the comparisons?

> The text could specify that, just as with the case expression
> in parentheses, all the case item expressions shall be evaluated
> exactly once, in order, and before any comparisons. The only time
> one would notice the difference would be in the presence of
side-effects.


From: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com, Brad.Pierce@synopsys.com
Cc:
Subject: Re: errata/566: Re: errata/566: 9.5: case item expression ambiguity
Date: Wed, 24 Mar 2004 19:51:18 -0500 (EST)

> First, if this would effect the simulation efficiency
> of even those case statements without side-effecting
> case item expressions, then I wouldn't want it. I
> assumed that static analysis could determine which
> case statements are afflicted with this rather rare
> style, and treat only those case statements in the
> new way. If not, then never mind.

You are correct. Such an analysis is possible, and not
particularly difficult. Case item expressions with function
calls would be very rare, so they would have minimal effect
on overall performance.

However, that still leaves subtler costs. Having to implement
and maintain multiple approaches has a cost. There are more
likely to be bugs in the resulting more complex implementations.
These costs are harder to measure, but would end up getting
passed on to the user in one way or another.

I also have a philosophical objection to defining the semantics
by specifying an inefficient algorithm, and excusing it because
there is an undocumented optimization that makes it more efficient.
In this particular situation, the optimization is pretty obvious.
In others, it might not be obvious. This could result in a language
that can only be implemented efficiently by the people privy to the
undocumented information. I don't think we want to start going down
that path.

> Having said that, the reason I was attracted to your
> interpretation is that it seemed to fit better with
> the handling of full_case parallel_case pragmas, which,
> unlike side-effecting case item expressions, are very
> common. It seemed natural to pull out all the side-effects,
> do them in sequence, and only then do the case. (But
> maybe it's just me, because full_case parallel_case
> itself seems more natural to me than priority style.)

The reason why full_case parallel_case pragmas exist is that the
definition of Verilog case is not parallel. It is defined as
sequential operations, like an if-then-else-if. Even if you
specified that all of the side effects should be done on each
execution, they would still be done in a particular sequence,
so they would still not be parallel. And if there are multiple
potential matches, only the first will be taken, which is not
parallel. Since cases are defined sequentially, taking this one
piece and trying to make it more parallel just makes it inconsistent
with the rest.

If a case qualifies for full_case parallel_case, then I assume it
can't have any case item expresion side effects anyway. So in the
situation where it seems natural to you to evaluate all the case item
expressions before the compares, it doesn't really matter whether you
do or not. You are free to regard it that way if you like (in a sort
of reversal of your argument above about optimizing simulation). And
in the situations where it would matter, you can't treat it as a
full_case parallel_case anyway. So where is the advantage?

So even if the cost of this were almost zero, you haven't described
any clear benefit that would offset it.

More importantly, Verilog cases currently evaluate and then compare
each case item expression before moving on to evaluate the next. If
this were changed, it could create backward compatibility issues. Why
would we want to change it?

Steven Sharp
sharp@cadence.com

From: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com, Shalom.Bresticker@motorola.com
Cc:
Subject: Re: errata/566: Re: errata/566: 9.5: case item expression ambiguity
Date: Wed, 24 Mar 2004 20:25:31 -0500 (EST)

> conceivably someone could interpret the
> phrase "shall be evaluated and compared in the exact order in which they are
> given"
> as meaning "shall be evaluated in order" and
> "shall be compared in order", but allowing all the expressions to be first
> evaluated before beginning the comparisons.

Would it help to change the wording to "shall be evaluated and then compared,
in the exact order in which they are given" (i.e. adding the word "then",
to show an explicit sequence, and a comma to keep the evaluate and compare
grouped together before talking about the sequence of multiple expressions)?

I'm sorry, I just think that this is the way one describes doing both before
doing the next expression. If you wanted to express the opposite, you would
say something like "shall be evaluated in the exact order in which they are
given, and then compared in that order". It is easy to show that the two
are separate by separating them in the sentence, but there are limits to
how close you can put them together in the sentence.

> Especially since it also says above,
> "The case expression and the case item expression can be computed at runtime".
> This implies that the expressions can be evaluated earlier also.

True, though only in cases where it wouldn't matter.

I don't think this sentence is really there to describe a contrast between
different situations in Verilog anyway. It is there to describe a contrast
with other languages the reader may know, which require their case items to
be compile-time constants. A better wording for this sentence would replace
"can be computed at runtime" with "are not required to be constants".

Steven Sharp
sharp@cadence.com

From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: etf-bugs@boyd.com
Cc:
Subject: Re: errata/566: 9.5: case item expression ambiguity
Date: Sun, 28 Mar 2004 16:45:52 +0200

> More importantly, Verilog cases currently evaluate and then compare
> each case item expression before moving on to evaluate the next. If
> this were changed, it could create backward compatibility issues. Why
> would we want to change it?

Actually, one of the implementations I tested did give 2 in Brad's case.

Shalom

From: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com, Shalom.Bresticker@motorola.com
Cc:
Subject: Re: errata/566: Re: errata/566: 9.5: case item expression ambiguity
Date: Tue, 30 Mar 2004 17:36:12 -0500 (EST)

> > More importantly, Verilog cases currently evaluate and then compare
> > each case item expression before moving on to evaluate the next. If
> > this were changed, it could create backward compatibility issues. Why
> > would we want to change it?
>
> Actually, one of the implementations I tested did give 2 in Brad's case.

The existence of a noncompliant simulator does not affect what the Verilog
language does.

The current LRM text says, reasonably clearly, that the evaluation and
comparison are done for each item before moving on to the next, and that
when a match is found, the associated statement is executed. Changing it
to say that evaluation should be done for all items before any comparisons
would not be backward-compatible with this. The two behaviors would be
different, and therefore incompatible.

This would be a backward compatibility issue within the standard itself,
independent of tools. Backward compatibility of legacy Verilog code with
existing tools is closely related, to the extent that existing tools are
compliant with the standard.

Steven Sharp
sharp@cadence.com

From: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com, Shalom.Bresticker@motorola.com
Cc:
Subject: Re: errata/566: Re: errata/566: 9.5: case item expression ambiguity
Date: Tue, 30 Mar 2004 17:44:34 -0500 (EST)

Shalom wrote:

> But that entire phrase about evaluation and comparison in order was added by
us
> in issue 402 and is not part of 2001c.


This is incorrect. The phrase about evaluation and comparison in order was
even in the 1995 standard (and the OVI standard before that).


Steven Sharp
sharp@cadence.com

From: Michael McNamara <mac@verisity.com>
To: Steven Sharp <sharp@cadence.com>
Cc: etf-bugs@boyd.com
Subject: RE: errata/566: Re: errata/566: Re: errata/566: 9.5: case item expression ambiguity
Date: Tue, 30 Mar 2004 17:26:52 -0800

I agree 100% with Steve.

There is a valid technical basis to what the standard says, I.E., that
case items are executed sequentially.


I believe there is no ambiguity as to what happens if a user codes:

module williams;
reg [31:0] a = 1;
reg [31:0] b,c;
case(1'b1) {
a == f(b) : $display ("Vietnam");
a == f(c) : $display ("Vietname");
endcase

function [31:0] f;
input [31:0] in;
begin
$write("Goodmorning ");
f = 1;
end
endmodule
The minor ambiguity is considering what happens if a user codes a case
versus:

case(1'b1) {
a == f(b), a==f(c) : $display ("Vietname");
endcase

Should we see "Good morning Vietnam" or "Good morning Good morning Vietnam" ??

My read of the standard is that one should see "Good morning Vietnam"

-mac

-- On Mar 30 2004 at 14:20, Steven Sharp sent a message:
> To: etf-bugs@boyd.com
> Subject: "errata/566: Re: errata/566: Re: errata/566: 9.5: case item expression ambiguity"
> The following reply was made to PR errata/566; it has been noted by GNATS.
>
> From: Steven Sharp <sharp@cadence.com>
> To: etf-bugs@boyd.com, Shalom.Bresticker@motorola.com
> Cc:
> Subject: Re: errata/566: Re: errata/566: 9.5: case item expression ambiguity
> Date: Tue, 30 Mar 2004 17:36:12 -0500 (EST)
>
> > > More importantly, Verilog cases currently evaluate and then compare
> > > each case item expression before moving on to evaluate the next. If
> > > this were changed, it could create backward compatibility issues. Why
> > > would we want to change it?
> >
> > Actually, one of the implementations I tested did give 2 in Brad's case.
>
> The existence of a noncompliant simulator does not affect what the Verilog
> language does.
>
> The current LRM text says, reasonably clearly, that the evaluation and
> comparison are done for each item before moving on to the next, and that
> when a match is found, the associated statement is executed. Changing it
> to say that evaluation should be done for all items before any comparisons
> would not be backward-compatible with this. The two behaviors would be
> different, and therefore incompatible.
>
> This would be a backward compatibility issue within the standard itself,
> independent of tools. Backward compatibility of legacy Verilog code with
> existing tools is closely related, to the extent that existing tools are
> compliant with the standard.
>
> Steven Sharp
> sharp@cadence.com
>
From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: etf-bugs@boyd.com
Cc:
Subject: Re: errata/566: 9.5: case item expression ambiguity
Date: Wed, 31 Mar 2004 10:15:19 +0200

My last comments on this for now:

> > Actually, one of the implementations I tested did give 2 in Brad's case.
>
> The existence of a noncompliant simulator does not affect what the Verilog
> language does.

That's assuming it is noncompliant, which is the exact question before us.

I don't think the statement in the LRM was necessarily intended to require
that evaluation immediately precede comparison. As we have seen, the only
cases where it seems to matter are pathological corner cases.

I think the LRM wording intended to say that the case items are compared in
order.
And then the LRM almost parenthetically adds that, "Of course, before comparing
it, you have to evaluate it first." Evaluation is mentioned because it is a
necessary
part of the process. But the emphasis is on the order of comparison and not on
the order of evaluation.

For simulation optimization, you would naturally want to perform only those
evaluations
you need to, so you would generally wait to see the result of the previous
comparison
before the next evaluation.


> The current LRM text says, reasonably clearly, that the evaluation and
> comparison are done for each item before moving on to the next, and that
> when a match is found, the associated statement is executed. Changing it
> to say that evaluation should be done for all items before any comparisons
> would not be backward-compatible with this. The two behaviors would be
> different, and therefore incompatible.

I don't think anyone suggested to say that evaluation SHOULD be done for all
items
before any comparisons, only to allow it as permitted.

Shalom

From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: etf-bugs@boyd.com
Cc:
Subject: Re: errata/566: 9.5: case item expression ambiguity
Date: Wed, 31 Mar 2004 10:16:19 +0200

You are correct. I misread 402.

Thanks,
Shalom

From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: etf-bugs@boyd.com
Cc:
Subject: Re: errata/566: 9.5: case item expression ambiguity
Date: Wed, 31 Mar 2004 10:25:55 +0200

Mac,

Besides the minor point that your example does not compile,
I note that the latest version of a certain Verilog simulator that you helped author produces
in your ambiguous case:

Goodmorning Goodmorning Vietname

Shalom


> The minor ambiguity is considering what happens if a user codes a case
> versus:
>
> case(1'b1) {
> a == f(b), a==f(c) : $display ("Vietname");
> endcase
>
> Should we see "Good morning Vietnam" or "Good morning Good morning Vietnam" ??
>
> My read of the standard is that one should see "Good morning Vietnam"

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

[x]Motorola General Business Information
[ ]Motorola Internal Use Only
[ ]Motorola Confidential Proprietary



From: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com, Shalom.Bresticker@motorola.com
Cc:
Subject: Re: errata/566: Re: errata/566: 9.5: case item expression ambiguity
Date: Wed, 31 Mar 2004 20:42:30 -0500 (EST)

> I think the LRM wording intended to say that the case items are compared in
> order.
> And then the LRM almost parenthetically adds that, "Of course, before
comparing
> it, you have to evaluate it first." Evaluation is mentioned because it is a
> necessary
> part of the process. But the emphasis is on the order of comparison and not on
> the order of evaluation.

If the wording were just intended to say that the first matching item is
selected, it could have said that. And I don't see anything parenthetical
about the reference to evaluation.

What I see is a step-by-step description of the operations that should be
followed in evaluating a case statement (with the first and last step left
as implied, unfortunately). Only an implementation that gets the same result
as that sequence of operations matches the standard.

You are describing the most important property of that sequence of operations
and claiming that one property was the sole intent of the description. Then
you are suggesting that any sequence of operations that satisfies that one
property is acceptable, even if it doesn't match the specified description
in other ways. I don't agree that this is a valid way to interpret the LRM.


> I don't think anyone suggested to say that evaluation SHOULD be done for all
> items
> before any comparisons, only to allow it as permitted.

Actually, I think Brad was sort of suggesting that.

And I don't see any reason to permit it. I think that the standard is
clear enough that it is not permitted, and has been that way since the
start. Allowing it just adds a situation where the behavior is not
standardized, and is therefore not portable. It is an obscure situation,
but I don't see how allowing the alternative behavior offers any advantage
to offset the disadvantage.

Steven Sharp
sharp@cadence.com

From: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com, Shalom.Bresticker@motorola.com
Cc:
Subject: Re: errata/566: Re: errata/566: 9.5: case item expression ambiguity
Date: Thu, 1 Apr 2004 14:14:59 -0500 (EST)

> Mac,
>
> I note that the latest version of a certain Verilog simulator that you helped
author produces
> in your ambiguous case:
>
> Goodmorning Goodmorning Vietname


I'm not sure why Mac's involvement in that implementation is relevant to
his statements. Are you suggesting that the behavior of that simulator
is due to Mac himself having previously decided that the LRM should be
interpreted that way? (As opposed to another engineer doing so, or
failing to read and apply the LRM, or a simple software bug.)

Or do you think that Mac would change his interpretation of the LRM
rather than acknowledge that a product he was involved in might contain
an error (horrors!). I hope that everyone involved in this work has
enough integrity that face-saving is not the basis for technical judgements.

Or perhaps this was just a cryptic way of indicating what simulator you
were talking about, without the mentioning of product names that everyone
has gotten so skittish about lately.

Steven Sharp
sharp@cadence.com

From: Shalom.Bresticker@motorola.com
To: Steven Sharp <sharp@cadence.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/566: 9.5: case item expression ambiguity
Date: Fri, 2 Apr 2004 05:37:16 +0200 (IST)

I just think it's ironic.

I hope everyone knows I greatly respect Mac.
Certainly his achievements and contributions over the years are far greater
than mine.

Shalom


On Thu, 1 Apr 2004, Steven Sharp wrote:

>
> > Mac,
> >
> > I note that the latest version of a certain Verilog simulator that you helped
> author produces
> > in your ambiguous case:
> >
> > Goodmorning Goodmorning Vietname
>
>
> I'm not sure why Mac's involvement in that implementation is relevant to
> his statements. Are you suggesting that the behavior of that simulator
> is due to Mac himself having previously decided that the LRM should be
> interpreted that way? (As opposed to another engineer doing so, or
> failing to read and apply the LRM, or a simple software bug.)
>
> Or do you think that Mac would change his interpretation of the LRM
> rather than acknowledge that a product he was involved in might contain
> an error (horrors!). I hope that everyone involved in this work has
> enough integrity that face-saving is not the basis for technical judgements.
>
> Or perhaps this was just a cryptic way of indicating what simulator you
> were talking about, without the mentioning of product names that everyone
> has gotten so skittish about lately.

From: Michael McNamara <mac@verisity.com>
To: Steven Sharp <sharp@cadence.com>
Cc: etf-bugs@boyd.com
Subject: RE: errata/566: Re: errata/566: Re: errata/566: 9.5: case item expression ambiguity
Date: Thu, 1 Apr 2004 21:35:05 -0800

Thanks Steve.

Again, the principle of least suprize says to me that

case (a)
b:
c,d:
e:
enddcase

should (in this case) be evaluated in alphabetical order, with the
first match short circuiting evaluation and preventing evaluation of
any subsequent comparisons, and their side effects.

-mac

-- On Apr 1 2004 at 11:00, Steven Sharp sent a message:
> To: etf-bugs@boyd.com
> Subject: "errata/566: Re: errata/566: Re: errata/566: 9.5: case item expression ambiguity"
> The following reply was made to PR errata/566; it has been noted by GNATS.
>
> From: Steven Sharp <sharp@cadence.com>
> To: etf-bugs@boyd.com, Shalom.Bresticker@motorola.com
> Cc:
> Subject: Re: errata/566: Re: errata/566: 9.5: case item expression ambiguity
> Date: Thu, 1 Apr 2004 14:14:59 -0500 (EST)
>
> > Mac,
> >
> > I note that the latest version of a certain Verilog simulator that you helped
> author produces
> > in your ambiguous case:
> >
> > Goodmorning Goodmorning Vietname
>
>
> I'm not sure why Mac's involvement in that implementation is relevant to
> his statements. Are you suggesting that the behavior of that simulator
> is due to Mac himself having previously decided that the LRM should be
> interpreted that way? (As opposed to another engineer doing so, or
> failing to read and apply the LRM, or a simple software bug.)
>
> Or do you think that Mac would change his interpretation of the LRM
> rather than acknowledge that a product he was involved in might contain
> an error (horrors!). I hope that everyone involved in this work has
> enough integrity that face-saving is not the basis for technical judgements.
>
> Or perhaps this was just a cryptic way of indicating what simulator you
> were talking about, without the mentioning of product names that everyone
> has gotten so skittish about lately.
>
> Steven Sharp
> sharp@cadence.com
>
From: Michael McNamara <mac@verisity.com>
To: Shalom.Bresticker@motorola.com
Cc: etf-bugs@boyd.com
Subject: RE: errata/566: Re: errata/566: 9.5: case item expression ambiguity
Date: Thu, 1 Apr 2004 22:08:37 -0800

-- On Apr 1 2004 at 19:20, Shalom.Bresticker@motorola.com sent a message:
> To: etf-bugs@boyd.com
> Subject: "errata/566: Re: errata/566: 9.5: case item expression ambiguity"
> The following reply was made to PR errata/566; it has been noted by GNATS.
>
> From: Shalom.Bresticker@motorola.com
> To: Steven Sharp <sharp@cadence.com>
> Cc: etf-bugs@boyd.com
> Subject: Re: errata/566: 9.5: case item expression ambiguity
> Date: Fri, 2 Apr 2004 05:37:16 +0200 (IST)
>
> I just think it's ironic.
>
> I hope everyone knows I greatly respect Mac. Certainly his
> achievements and contributions over the years are far greater than
> mine.

The final tally has yet to be calculated... (and this is a good thing)

Live long and prosper!

>
> Shalom
>
>
> On Thu, 1 Apr 2004, Steven Sharp wrote:
>
> >
> > > Mac,
> > >
> > > I note that the latest version of a certain Verilog simulator that you helped
> > author produces
> > > in your ambiguous case:
> > >
> > > Goodmorning Goodmorning Vietname
> >
> >
> > I'm not sure why Mac's involvement in that implementation is relevant to
> > his statements. Are you suggesting that the behavior of that simulator
> > is due to Mac himself having previously decided that the LRM should be
> > interpreted that way? (As opposed to another engineer doing so, or
> > failing to read and apply the LRM, or a simple software bug.)
> >
> > Or do you think that Mac would change his interpretation of the LRM
> > rather than acknowledge that a product he was involved in might contain
> > an error (horrors!). I hope that everyone involved in this work has
> > enough integrity that face-saving is not the basis for technical judgements.
> >
> > Or perhaps this was just a cryptic way of indicating what simulator you
> > were talking about, without the mentioning of product names that everyone
> > has gotten so skittish about lately.
>
Unformatted



Hosted by Boyd Technology