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

See my comment, below...

Stu
~~~~~~~~~~~~~~
Stuart Sutherland
stuart@sutherland-hdl.com
(503) 692-0898


> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
> Bresticker, Shalom
> Sent: Thursday, April 30, 2009 4:29 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)
> 
> You're mostly correct. I misremembered. I went back and checked and found
> that the actual misinterpretation, far more far-fetched in my opinion
also,
> was thus:
> 
> "If the net or variable is declared as a vector, the range specification
> between the two declarations of a port shall be identical."
> 
> This specifies that the two range specifications shall be identical, but
that
> applies only if there are two range specifications. If the port
declaration
> does not contain a range specification, then there is no requirement.
> 

[SS] I seem to recall discussion long, long ago (perhaps on the 1364 PLI
committee) that if the port did not have a range specification, and the
internal net/variable did, then the port had an inferred [0:0] range which
was matched against the internal net/variable declaration, which will likely
not be identical and result in an error.

> Yes, I lift an eyebrow at that interpretation also...
> 
> Shalom
> 
> > -----Original Message-----
> > From: Steven Sharp [mailto:sharp@cadence.com]
> > Sent: Thursday, April 30, 2009 4:21 AM
> > To: sharp@cadence.com; Bresticker, Shalom
> > Cc: sv-bc@eda.org
> > Subject: RE: Mantis 2593 about non-ANSI port declarations
> > (Was: [sv-bc] Mantis 1111, omitting range on port declaration)
> >
> >
> > >From: "Bresticker, Shalom" <shalom.bresticker@intel.com>
> >
> > >> >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.
> >
> >
> > This situation doesn't fall into the "else" case.  The LRM says
> >
> > "If the net or variable is declared as a vector, the range
> > specification
> > between the two declarations of a port shall be identical."
> >
> > In this situation, the net is declared as a vector.  It falls
> > into the "if"
> > case, not the "else" case.  The only argument that can be
> > made about it
> > is to claim that a given range specification is identical to a missing
> > range specification.  Since that is not what "identical"
> > means, such an
> > argument would be wrong.
> >
> > The "else" case would be the case where the net or variable is not
> > declared as a vector.  In that case I will acknowledge that the LRM
> > does not actually say that the ranges must be identical.  So
> > that would
> > allow
> >
> >   input [5:0] in1;
> >   wire in1;
> >
> > I don't think anybody is really arguing in favor of allowing this.
> > If you wanted to allow it for backward compatibility in legacy code,
> > you would have to treat it as a scalar, because Verilog-XL did.
> >
> > So if you want to allow "input in1; wire [5:0] in1;" we will need to
> > change the LRM.  The current LRM clearly does not allow it.
> >
> > Steven Sharp
> > sharp@cadence.com
> >
> >
> ---------------------------------------------------------------------
> 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.