| Add Proposal | Add Analysis | Edit Class, Environment, or Release |
| Number | 400
|
| Category | enhancement
|
| Synopsis | reduce arithmetic operators x-pessimism
|
| State | open
|
| Class | enhancement
|
| Arrival-Date | Jul 25 2003
|
| Originator | Shalom.Bresticker@motorola.com
|
| Release | 2001b: 4.1.5
|
| Environment |
|
| Description |
Today, 4.1.5 says, "For the arithmetic operators, if any operand bit value is the unknown value x or the high-impedance value z, then the entire result value shall be x." There are cases where it is clearly possible to be less conservative. For example, if I add 5'b0000x + 5'b00000, then clearly the high-order bits have a definite value (0 in this case). -- 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/400: reduce arithmetic operators x-pessimism Date: Mon, 28 Jul 2003 19:56:04 -0400 (EDT) Yes, it is clearly possible to be less pessimistic with the arithmetic operators. The question is whether the cost of reducing pessimism is justified by the gains in simulation accuracy. For the logical operators, the extra cost of getting "exact" results is negligible. And there are many circuits that cannot be initialized properly if the logical operators are too pessimistic. For example, a flip-flop with clock enable implemented with a mux cannot ever be loaded if the feedback of the initial X state causes an X at the output of the mux. For the arithmetic operators, the cost of getting "exact" results is high. The obvious approach requires trying all possible combinations of 0 and 1 for each X bit, which has a cost that is exponential in the number of X bits. There are other algorithms that are less expensive, but are more pessimistic. They are still significantly more expensive than the current algorithm. It is not clear how much it is worth to reduce the pessimism in a given way. It is not clear that there is any significant worth to reducing the pessimism at all. I am not aware of any common design elements that cannot be initialized properly with the existing pessimism. Have any designers out there really run into a problem, or is this just a desire to tinker with something that isn't really broken because the results can obviously be "improved"? Some designers might prefer to know about an X value getting into their arithmetic units by having it propagated pessimistically, instead of getting "lucky" enough that their particular test vectors didn't propagate it to anything visible. They might not agree that this is an improvement, even if it didn't slow down their simulations. Also, a definition of "exact" that assumes that an X is a definite 0 or 1 might be too optimistic. There are situations that could behave worse. For example, an X resulting from a missed setup/hold time could occasionally be an actual metastable state, settling at a late enough time to result in treatment as a 0 by part of the logic computing the arithmetic result, but as a 1 by the rest. Without knowing the underlying logic implementation, it would be hard to determine an "exact" result. How pessimistic do you have to be to be sure of covering any real situation? And finally, this would create a backward compatibility issue. Even if the results are "new and improved", they don't match the results that have been gotten in the past. Re-goldenizing existing regression tests can be painful. Steven Sharp sharp@cadence.com From: Shalom.Bresticker@freescale.com To: btf-bugs@boyd.com Cc: Subject: enhancement/400: Reduce arithmetic operators x-pessimism Date: Sun, 23 May 2004 09:57:12 +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: Steven Sharp <sharp@cadence.com> To: etf-bugs@boyd.com, Shalom.Bresticker@freescale.com Cc: Subject: Re: enhancement/400: Reduce arithmetic operators x-pessimism Date: Tue, 25 May 2004 21:17:36 -0400 (EDT) Some responses to Jon Beecroft's comments: > > 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. Jon, you appear to be saying that you use &(variable ~^ constant) instead of (variable == constant) because you believe that the first form gives you a more pessimistic result. In fact, these two expressions give you the exact same result in all cases. Your uglier form gives you no benefit. Shalom suggests that your issue is where some non-X bits do not match, which gives you a 0 result with ==. In your alternate form, the bitwise ~^ will give you a 0 in the bit positions that do not match. Then the reduction-AND operation will produce a 0 if any of the input bits are 0, regardless of whether there are any X bits. Therefore your alternate form will also produce a 0, not X, if there are any bits that are clearly unequal. If you have been relying on this alternate form to give you more pessimism, then it has been false security. If you have not had any problems when using your alternate form, then == would have worked fine for you also. This may not affect your opinion of how == should work, but I thought I should point it out. At least you can avoid using the uglier form, since it is not doing you any good. Or perhaps you can come up with another variation that does what you want. I believe (variable - constant == 0) would work, but a synthesis tool might actually create a subtracter instead of the simpler comparator. Perhaps the uglier (variable + 0 == constant) would be optimized better. > > 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. This one is certainly a more severe problem, as Verilog is actually optimistic in this case. It is one of only two situations I am aware of where Verilog handles X too optimistically. I think this one has bitten a lot of users. > 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? As Shalom points out, if and else clauses can contain lots of things other than assignments. I don't see a way to pessimistically maybe-execute arbitrary behavioral code. Setting everything assigned in the code could be far too pessimistic. There could be a nested if with an unambiguous condition that would guarantee that something didn't get assigned. Setting that to X could prevent the design from initializing. What about an assignment to a bit-select? Does the entire object have to be set to X, even if only one bit could have been assigned? If not, the code has to be executed to determine which bit might have been assigned. But both the if and else might need to be executed speculatively, which creates a whole new set of problems. And even if you are willing to be overly pessimistic about assignments, how do you pessimistically execute a delay or event control or a disable statement? > > 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 think you are right about the second of these. Unfortunately, I think that with your suggested solution, the pessimism would be so excessive that you would run into far more spurious failures. You might be willing to write your code so that this doesn't happen, but there is a lot of legacy code out there. This would be a serious backward compatibility issue. Note that there is a way of conditionally assigning different values in Verilog using the ?: operator instead of if-then-else. This doesn't have the problem of having to select between executing arbitrary statements, and does not produce optimistic results (aside from the unusual situation of executing a function call that has side effects). One possible alternative to attempting to do pessimistic execution of if-then-else is to have a run-time warning produced any time an if-condition comes out X. This would notify the user directly that there was a potential problem, rather than trying to figure out an appropriate pessimistic result that might propagate somewhere they might notice. For backward compatibility with legacy code, it might be desirable to use a special syntax where this was desired (such as the SystemVerilog "priority if" syntax, which produces run-time warnings, but not in this situation). Steven Sharp sharp@cadence.com From: Shalom Bresticker <Shalom.Bresticker@freescale.com> To: Steven Sharp <sharp@cadence.com> Cc: etf-bugs@boyd.com Subject: Re: enhancement/400: Reduce arithmetic operators x-pessimism Date: Thu, 27 May 2004 16:36:13 +0300 Steven, Please remind us what the other situation is. Thanks, Shalom > > > 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. > > This one is certainly a more severe problem, as Verilog is actually > optimistic in this case. It is one of only two situations I am aware of > where Verilog handles X too optimistically. I think this one has bitten > a lot of users. -- 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: Steven Sharp <sharp@cadence.com> To: sharp@cadence.com, Shalom.Bresticker@freescale.com Cc: etf-bugs@boyd.com Subject: Re: enhancement/400: Reduce arithmetic operators x-pessimism Date: Thu, 27 May 2004 14:28:08 -0400 (EDT) >Please remind us what the other situation is. If you assign a value to a bit-select or array select where the index contains an X, it has no effect in Verilog. This is overly optimistic behavior. Steven Sharp sharp@cadence.com |
| Unformatted |
|
Hosted by Boyd Technology