RE: [sv-bc] ANSI vs. non-ANSI explicitly named ports

Trying to keep ANSI and non-ANSI styles consistant may not always be
pratical, and I do not want to invest anymore time in the non-ANSI
styles mand hopefully depricate them.

From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Bresticker, Shalom
Sent: Wednesday, October 20, 2010 7:59 AM
To: Vreugdenhil, Gordon
Cc: sv-bc
Subject: RE: [sv-bc] ANSI vs. non-ANSI explicitly named ports

I can agree with your interpretation, but the declaration style still
seems to me to be inconsistent between the ANSI and non-ANSI forms.

Shalom

From: Gordon Vreugdenhil [mailto:gordonv@model.com]
Sent: Wednesday, October 20, 2010 4:43 PM
To: Bresticker, Shalom
Cc: sv-bc
Subject: Re: [sv-bc] ANSI vs. non-ANSI explicitly named ports

Shalom,

I don't think there is really a clear answer on this.

My interpretation would likely be based on thinking about the port and
the underlying declared object separately. So in the case of a net, it
really doesn't matter what the mode in the port says due to the impact
of net collapsing. So I don't think there is any issue there.

For a var, I think that I would consider the port/var relationship as
essentially an implied continuous assign in the direction indicated.
This ends up working out rather well since it would allow "slicing' of a
var in input/output directions, but would not generally allow an overlap
of modes due to the existence of the continuous drive -- so any portion
being continuously driven would still have to have a single drive or
else there would be a conflict.

I don't think there is any definitive text that I could point to in the
LRM, but I think my interpretation is consistent with various other
rules and other forms of expressing the implied behavior.

Gord.

On 10/19/2010 2:39 AM, Bresticker, Shalom wrote:

Hi,

Both ANSI and non-ANSI port declaration styles allow explicitly named
ports, but they seem inconsistent to me.

The explicitly named port declaration has the form

.port_identifier ([port_expression])

For the non-ANSI style, we have the statement in 23.2.2.1,

"Each port_identifier in a port_expression in the list of ports for the
module declaration shall also be declared in the body of the module as
one of the following port declarations: input, output, inout
(bidirectional), ref, or as an interface port (see Clause 25)."

We have examples like

Example 7-Explicitly named port with mix of input and output directions
(non-ANSI style module header)

module mixed_direction (.p({a, e}));

input a; // p contains both input and output directions.

output e;

On the other hand, for ANSI style, we have in 23.2.2.2,

module mymod (

output .P1(r[3:0]),

output .P2(r[7:4]),

ref .Y(x),

input R );

logic [7:0] r;

int x;

...

endmodule

Here it looks like the direction is attached to the port names (P1, P2,
Y) and not to the signal names visible inside the module (r,x).

There does not seem to be anything preventing me from writing, for
example,

module mymod (

input .P1(r[3:0]),

output .P2(r[7:4]), // r used partly as input and partly as output

input .Y(x),

output .Z(x) ); // x used both as input and as output

logic [7:0] r;

int x;

In the non-ANSI style, however, the port direction is declared on the
internal signal name and not on the external name.

Comments?

Thanks,

Shalom

Shalom Bresticker

Intel LAD DA, Jerusalem, Israel

+972 2 589 6582 (office)

+972 54 721 1033 (cell)

http://www.linkedin.com/in/shalombresticker

---------------------------------------------------------------------
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 <http://www.mailscanner.info/> , and is
believed to be clean. 
 
-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.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 <http://www.mailscanner.info/> , and is
believed to be clean. 
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.