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<mailto: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, and is
believed to be clean.