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

I look at what the 1364 LRM say differently. 1364 only allowed default unsigned type variable or net types in port declarations. What 1364 is saying is you can override default type in the port declaration, but not things that are explicitly specified.

If you say:

input [7:0] in;

You haven't explicitly specified if it is a net/var, [logic, bit, reg] or signed/unsigned, so you can specify a non-default value for those in a net or var declaration. If you specify part of it, then the subsequent declaration cannot contradict the first.

input signed [7:0] in;
var logic unsigned [7:0] in; // Illegal

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Steven Sharp
Sent: Tuesday, April 28, 2009 6:28 PM
To: sv-bc@eda.org; Brad.Pierce@synopsys.COM
Subject: RE: Mantis 2593 about non-ANSI port declarations (Was: [sv-bc] Mantis 1111, omitting range on port declaration)


>Another option would be to say that if there is both a port declaration and a
net/variable declaration for the same name, then all type/kind information in
the port declaration shall be ignored.


That seems pretty close to what Verilog-XL is doing, and I assume lots of
other tools do something like this to be compatible.  I could go along with
this also.

This still leaves the oddity in the LRM text that says you pay attention to
the signed attribute (sic) if it is on the port declaration, even if it is
missing from the net/variable declaration.  Do we need to maintain backward
compatibility with this?

I don't know where this weird signedness rule came from.  It didn't come
from the original implementation in Verilog-XL.  XL actually errors if the
signedness doesn't match, even though it allows range mismatches.


Steven Sharp
sharp@cadence.com


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