| Add Proposal | Add Analysis | Edit Class, Environment, or Release |
| Number | 404
|
| Category | enhancement
|
| Synopsis | add wildcards for equality operators
|
| State | open
|
| Class | enhancement
|
| Arrival-Date | Jul 27 2003
|
| Originator | Shalom.Bresticker@motorola.com
|
| Release | 2001b
|
| Environment |
|
| Description |
It is common to have to write something like, " if ((a==3'b001) | (a==3'b101)) ". It would be extremely convenient to be able to write " if ( (a==3'b@01) ) ", where "@" represents some symbol which is a wildcard operator. "?" would be ideal, but today it represents the "z" high-impedance value. |
| Fix |
|
| Audit-Trail |
From: Steven Sharp <sharp@cadence.com> To: etf-bugs@boyd.com, Shalom.Bresticker@motorola.com Cc: Subject: Re: enhancement/404: add wildcards for equality operators Date: Mon, 4 Aug 2003 20:50:08 -0400 (EDT) I believe that the proper way to add this functionality would be to add a new pair of equality operators that do "don't cares" like the existing casex or casez statements. In other words, just as there are case equality and case inequality operators that do comparisons like the procedural case statement, add casez equality and casez inequality operators that do comparisons like the procedural casez statement. If we assume a syntax of ==? and !=? for the operators, the syntax for your example would be "if (a ==? 3'b?01)". There would be several questions about the desired functionality that would need to be answered: 1. Is it necessary to have both casex and casez equality operators? I have never seen much use for casex, since casez is better. There also isn't an obvious syntax for casex comparable to ==? for casez. Is there some obscure use for casex that would make such an operator desirable in addition to one for casez? Is it important to have an equality operator corresponding to each of the case statement flavors? 2. After eliminating the "don't care" bits, should the remaining bits use the case equality comparison, or the logical equality comparison? The casez comparison does a case equality comparison, while the example appeared to assume a logical equality comparison. Which is really needed? If both are really needed, both could be provided (e.g. ==? and !=? versus ===? and !==?). 3. The casez statement treats ?/z as a don't care value in both the case expression and the case items. This allows putting the don't care condition in the case expression with variables in the case items, instead of vice versa, but this isn't done much in practice. And it is very unlikely that anyone would want don't cares in both positions. This possibility is more likely to be a problem than a benefit (especially with casex, where a variable or net might be x unexpectedly; casez is safer for this reason). A casez equality operator could be defined to only treat ?/z as a don't care in the right-hand operand. Unlike casez, if you wanted the other operand to have the don't cares, you could simply swap them. As noted, it is probably undesirable for both sides to have don't cares. If only one side has ?/z treated as don't cares, it would presumably be the right-hand side. As in the example, usually people put the value being compared to on the right-hand side. The question mark in the ==? syntax that I suggested is on the right-hand side, which would act as a reminder of which side can have don't cares. Steven Sharp sharp@cadence.com From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: Steven Sharp <sharp@cadence.com> Cc: etf-bugs@boyd.com Subject: Re: enhancement/404: add wildcards for equality operators Date: Wed, 06 Aug 2003 12:59:57 +0300 Hi, Steven. As usual, you have good comments and questions. See inside. Steven Sharp wrote: > I believe that the proper way to add this functionality would be to add > a new pair of equality operators that do "don't cares" like the existing > casex or casez statements. Worth considering. On further thought, I tend to agree that a new operator is best. > In other words, just as there are case > equality and case inequality operators that do comparisons like the > procedural case statement, add casez equality and casez inequality > operators that do comparisons like the procedural casez statement. > > If we assume a syntax of ==? and !=? for the operators, the syntax for > your example would be "if (a ==? 3'b?01)". > > There would be several questions about the desired functionality that > would need to be answered: > > 1. Is it necessary to have both casex and casez equality operators? I > have never seen much use for casex, since casez is better. There > also isn't an obvious syntax for casex comparable to ==? for casez. > Is there some obscure use for casex that would make such an operator > desirable in addition to one for casez? Is it important to have an > equality operator corresponding to each of the case statement flavors? The "conventional wisdom" says that casez is better. The arguments I have seen have not convinced me. And not everyone agrees. Foster and Bening in "Principles of Verifiable RTL Design" chose casex over casez (1st ed, 7.4.1.3, pp. 176-177). The argument that x classically represents both 0 and 1 simultaneously, and that therefore a don't-cared x bit is considered a match, seems to me to be natural, just as "a ? b : c", if a is x, and both b and c are 1, still returns 1, because whether the x is considered 1 or 0, it does not matter. If it were like a casez equality, that would also not allow it to act like a mask like you wanted to suggest could be used sometimes instead of the part-select list of bits, because then x in one of the masked bits would cause the comparison to fail. If we were to agree on a casex-like equality, then I would say that a casez-like operation would not be important. Actually, I don't know why both casex and casez exist. It is one of the few places where z and x are treated differently (except for obvious differences caused by their electrical characteristics). > 2. After eliminating the "don't care" bits, should the remaining bits use > the case equality comparison, or the logical equality comparison? The > casez comparison does a case equality comparison, while the example > appeared to assume a logical equality comparison. Which is really > needed? If both are really needed, both could be provided > (e.g. ==? and !=? versus ===? and !==?). You are correct that I was thinking about a regular logical equality, == being more common than ===. == is also the synthesizable version. Generally, I would prefer that an x on a cared bit give me an x result. > 3. The casez statement treats ?/z as a don't care value in both the case > expression and the case items. This allows putting the don't care > condition in the case expression with variables in the case items, > instead of vice versa, but this isn't done much in practice. And it > is very unlikely that anyone would want don't cares in both positions. > This possibility is more likely to be a problem than a benefit > (especially with casex, where a variable or net might be x unexpectedly; > casez is safer for this reason). 9.5.1 gives an example of x in both the case expression and the case items, but it seems a poor example in that it could have been done with x's only in the case items. In fact, the code would have been cleaner that way. > A casez equality operator could be defined to only treat ?/z as a don't > care in the right-hand operand. Unlike casez, if you wanted the other > operand to have the don't cares, you could simply swap them. As noted, > it is probably undesirable for both sides to have don't cares. If only > one side has ?/z treated as don't cares, it would presumably be the > right-hand side. As in the example, usually people put the value being > compared to on the right-hand side. The question mark in the ==? syntax > that I suggested is on the right-hand side, which would act as a reminder > of which side can have don't cares. This is directly related to # 2, isn't it? So, I think, for the same reasons as I wrote above, I would prefer the don't care action only on the RHS, as you suggest. As I said, your questions are very good ones. Shalom -- Shalom Bresticker Shalom.Bresticker@motorola.com Design & Reuse Methodology Tel: +972 9 9522268 Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478 From: Steven Sharp <sharp@cadence.com> To: sharp@cadence.com, Shalom.Bresticker@motorola.com Cc: etf-bugs@boyd.com Subject: Re: enhancement/404: add wildcards for equality operators Date: Mon, 29 Sep 2003 15:09:46 -0400 (EDT) Apparently SystemVerilog 3.1 added wildcard equality and inequality operators, in section 7.5. The syntax is very similar to my suggestion: =?= and !?=, instead of ==? and !=?. That is probably the syntax I would have suggested for a symmetric compare, but my syntax is more natural for an asymmetric compare (wildcards only in the right operand). It is not clear whether all of the choices I mentioned were fully considered in deciding on the SV functionality. I doubt that they thought of making it asymmetric. Most of the choices can be argued either way, depending on the intended use. Making it asymmetric is the one choice that seems clearly better in all real situations. Steven Sharp sharp@cadence.com From: Shalom.Bresticker@motorola.com To: Steven Sharp <sharp@cadence.com> Cc: etf-bugs@boyd.com Subject: Re: enhancement/404: add wildcards for equality operators Date: Tue, 30 Sep 2003 05:43:06 +0300 (IDT) When I made my proposal, I was not aware of the SystemVerilog construct. I think the Jeda donation also includes a similar construct. > Apparently SystemVerilog 3.1 added wildcard equality and inequality operators, > in section 7.5. The syntax is very similar to my suggestion: =?= and !?=, > instead of ==? and !=?. That is probably the syntax I would have suggested > for a symmetric compare, but my syntax is more natural for an asymmetric > compare (wildcards only in the right operand). Shalom -- Shalom Bresticker Shalom.Bresticker@motorola.com Design & Reuse Methodology Tel: +972 9 9522268 Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478 |
| Unformatted |
|
Hosted by Boyd Technology