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

From: Gordon Vreugdenhil <gordonv@model.com>
Date: Wed Oct 20 2010 - 07:43:19 PDT

  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 (
> *in**put *.P1(r[3:0]),
> *output *.P2(r[7:4]), // r used partly as input and partly as output
> *input** *.Y(x),
> *out**put *.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
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Wed Oct 20 07:43:43 2010

This archive was generated by hypermail 2.1.8 : Wed Oct 20 2010 - 07:46:37 PDT