>This proposal seems very weird and unnatural. You are allowed to change the signed attribute between the two declarations (because 1364 clearly says you can), but nothing else? That make no sense. The signed property is part of the data type. So what you are saying is the you can change some parts of the data type and not others. I would love to get rid of the weird signedness thing. However, it would not be backward compatible with 1364, so I assumed that would be rejected. I could try to restrict this weirdness to the case where the data type is specified with just a range and optional signedness, if people would prefer that. The wording would be more complex, and probably raise even more complaints about clarity. >The P1800-2005 LRM was very vague about this. At this point a very restrictive interpretation, like is proposed here, will almost certainly cause backwards incompatibility problems for vendors. This means that vendors will probably never implement this or will implement it inconsistently. I don't have a problem with this. We have inconsistency now. I see two reasonable ways to go from here. One is to get very restrictive, and only allow the cases where we are sure that all implementations get the same result. That would be the case where the data types are the same, because how could an implementation not treat that as the resulting data type? Vendors may not be consistent in their implementation of this, but they would only be inconsistent for code that was technically illegal and should be fixed. The other way is to try to get very flexible and allow anything that any implementation is likely to allow. Also make it simple so that it is easy for any implementation to be relaxed to allow it. The best candidate I see for this is Brad's suggestion that the declaration on the port be ignored if there is a variable/net declaration. Do you have a better proposal? Saying nothing certainly won't help future consistency. Steven Sharp sharp@cadence.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Apr 29 17:45:56 2009
This archive was generated by hypermail 2.1.8 : Wed Apr 29 2009 - 17:47:04 PDT