>From: "Bresticker, Shalom" <shalom.bresticker@intel.com> >I think the proposed wording, >"Aside from the signed attribute mentioned below, the data type between the two declarations of a port shall be identical." >is more ambiguous than the current wording because it is not clear what is meant by "data type" here. >That is a term used ambiguously throughout the LRM. >That is why in 23.2.2.3, I had to specify what is meant by "data type" there: >"Within this subclause, the term data type means both explicit and implicit data type declarations and does not include unpacked dimensions." I suppose you could say that the current wording is less ambiguous for the one case it addresses. But since it leaves all cases other than a single range unspecified, the current wording is far more ambiguous overall. I could try adding text about "explicit or implicit", but I am not sure that it will make it easier to understand. And in this case, unpacked dimensions are included, so it is indeed the full data type of the object. In the subclause you mentioned, you were talking about the syntax, where the part of the type to the left of the identifier can be used to declare multiple identifiers, while any unpacked dimensions after each identifier cannot. If you want to quibble about wording, I would have to consider the text you quote from 23.2.2.3 incorrect, since that "data type" could include unpacked dimensions if they were part of a named type, such as a typedef name. In my proposal, I am using "data type" in its usual meaning, so I don't think I need to provide a special definition. >Also, the reason that 1111 never passed was to allow "input in1" to be followed by "wire [5:0] in1" for back-compatibility. >The proposed wording might disallow that. As I said for 1111, I think the current wording disallows that. This is just a case where the "de facto" standard is to ignore the standard and allow what Verilog-XL did. I would also be OK with changing the LRM to allow this officially. 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 Tue Apr 28 18:23:49 2009
This archive was generated by hypermail 2.1.8 : Tue Apr 28 2009 - 18:24:36 PDT