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