>I would like to withdraw this proposal entirely, and see if we can't >put together something that would do a better job of avoiding mismatches. I hope I didn't discourage you with my comments. This is just a bigger thing to specify than it might appear at first glance. However, it sounds like you are concerned that it may not do the job it is intended to do. >The inside operator doesn't seem to be the right one for the job. There is an elegance to using something based on inside, since it implies both the asymmetric compare and the ranges. On the other hand, we may want to extend the other kinds of cases to allow ranges too. At that point, this won't seem as elegant. The thing that will distinguish this kind of case will just be the asymmetric wildcarding. >I need to think it through more, but perhaps an asymetric case-wildcard >as proposed earlier (with no ranges) except that > > 1) The case items must be literals This might be overly restrictive. Admittedly, non-constant case items are less important once you have made the case asymmetric. For synthesis you would presumably require the case item expressions to be constants (not literals), but simulation doesn't require it. We can optimize a lot better with constants, but already have to handle non-constants for case, casex and casez, so this isn't any worse. > 2) An x or z in a case item would match only a 0 or 1 in the > case expression. > >That is, a don't-care in the case item would mean I don't care if the >case expression has a 0 or 1 in that bit, but it must be an actual bit, >not an x or z. I remember seeing a request for this kind of overly pessimistic wild-card treatment in an enhancement request. It doesn't make sense to me. It is not consistent with the meaning of 4-state logic. The intent does not seem to be matching the actual behavior of logic. It seems to be "I don't want X's, or don't understand them, so make sure my simulation doesn't work even if the real logic would." This does not match the usual design philosophy for 4-state logic in Verilog. An X means a value is either 0 or 1, but we cannot deduce which one it is under these circumstances. If a case item has a don't- care for a bit where the case expression has an X, it should match. If the X were 0 it would match, and if the X were 1 it would match. Since it will match regardless of whether the X is 0 or 1, we should treat it as matching. Verilog generally tries to model this accurately, unless it is too expensive to do so (as with arithmetic operations). In this case, it is the same cost to do it accurately as to do it pessimistically. To put it another way, if there is a don't-care on a bit in a case item expression, it means that the bit is not an input to the decode logic that selects that case item. Its value has no effect on the result of that decode. Why would it matter if the bit is X or Z? Not letting a don't-care match an X will *cause* mismatches between pre/post-synthesis simulation, not avoid them. [Somebody might suggest unusual situations where an X or Z would not be treated consistently as a 0 or 1 by the logic, but if that were a concern we need to redesign the rest of the Verilog 4-state logic operations too.] Steven Sharp sharp@cadence.comReceived on Tue Apr 5 18:40:33 2005
This archive was generated by hypermail 2.1.8 : Tue Apr 05 2005 - 18:40:37 PDT