RE: Mantis 2593 about non-ANSI port declarations (Was: [sv-bc] Mantis 1111, omitting range on port declaration)

> I prefer not to allow this explicitly. I think it is bad practice.

Why is it bad practice to eliminate redundancy and have a single declaration for the type and kind of the data object?

> I prefer to try to word the LRM in such a way as to allow it implicitly, between the lines.

I don't know how to write an implicit compiler that reads between the lines.

-- Brad

________________________________________
From: owner-sv-bc@eda.org [owner-sv-bc@eda.org] On Behalf Of Bresticker, Shalom [shalom.bresticker@intel.com]
Sent: Wednesday, April 29, 2009 8:21 AM
To: Steven Sharp
Cc: sv-bc@eda.org
Subject: RE: Mantis 2593 about non-ANSI port declarations (Was: [sv-bc] Mantis 1111, omitting range on port declaration)

Hi,

> >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.

The current text has limited applicability. It only attempts to say something about range specifications. It does not attempt to discuss other cases. The proposed text attempts to be much wider in its applicability, but the wording is less clear. We have already seen that people disagree on what it means. I am not against the intent, with certain reservations, but it means to be worded more clearly.


> 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.

That is your intent, but it would not be clear to readers.


> 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.

True. Another point for the next PAR. I am the first to admit that that subclause is still not perfect, but it is much better than the previous version.


> In my proposal, I am using "data type" in its usual meaning,
> so I don't
> think I need to provide a special definition.

The problem is that "data type" does not have a "usual" rigorous meaning.
This is one place where the precise meaning is critical.


> >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.

So you claim and I agree. However, other people have claimed that the current wording allows it by the word "if", saying that it says nothing about the "else" case.


> I would also be OK with changing the LRM to allow this officially.

I prefer not to allow this explicitly. I think it is bad practice. I prefer to try to word the LRM in such a way as to allow it implicitly, between the lines.

Shalom
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.