RE: [sv-bc] ansi interface port declarations

Makes sense, except that for variable ports, the [=constant_expression] is only for output ports, or at least so I have thought.

Note that this initializer for variable ports is a constant_expression, whereas a regular variable initializer can be a regular expression.

Shalom

From: Greg Jaxon [mailto:Greg.Jaxon@synopsys.com]
Sent: Wednesday, August 24, 2011 12:24 AM
To: Bresticker, Shalom
Cc: Greg Jaxon; SV-BC
Subject: Re: [sv-bc] ansi interface port declarations

Point well-taken.
So I would add a footnote as follows:
ansi_port_declaration ::=
  [ net_port_header ] port_identifier { unpacked_dimension } [ = constant_expression ]2
| [ variable_port_header ] port_identifier { variable_dimension } [ = constant_expression ]2
| [ interface_port_header ] port_identifier { unpacked_dimension }
| [ port_direction ] .port_identifier ( [ expression ] )
2Constant expressions specifying a default value for omitted port connections may only appear
on ansi_port_declarations whose port_direction is implicitly or explicitly "input".

On 8/23/2011 1:38 PM, Bresticker, Shalom wrote:
23.2.2.4 is explicit that defaults are allowed only on input ports.

Shalom

From: Greg Jaxon [mailto:Greg.Jaxon@synopsys.com]
Sent: Tuesday, August 23, 2011 8:53 PM
To: Bresticker, Shalom
Cc: Greg Jaxon; SV-BC
Subject: Re: [sv-bc] ansi interface port declarations

Can a nested module take an interface-type port?
If so, couldn't it be declared with some default value taken from the interface instances of the containing module?

On 8/23/2011 1:41 AM, Bresticker, Shalom wrote:
Yes, but I was thinking more along the lines that module interface ports cannot have default values.

Shalom

From: Greg Jaxon [mailto:Greg.Jaxon@synopsys.com]
Sent: Monday, August 22, 2011 11:38 PM
To: Bresticker, Shalom
Cc: SV-BC
Subject: Re: [sv-bc] ansi interface port declarations

That helps dispel the idea that there is some constant_expression of interface_type.
However, the list_of_port_connections syntax still calls all connections "expression"s.

Greg

On 8/21/2011 9:24 AM, Bresticker, Shalom wrote:
Hi,

I have returned to working on port declarations, particularly on integrating interface port declarations (i.e., port that is an interface, not a port of an interface), hoping we can approve something before the October 1 deadline, though I am in doubt whether I will be able to attend the September 12 meeting.

Anyway, Mantis 1619, which added default values to input net ports in ANSI style declarations changed the BNF from

ansi_port_declaration ::= [ net_port_header | interface_port_header ] port_identifier { unpacked_dimension } | ...

to

ansi_port_declaration ::= [ net_port_header | interface_port_header ] port_identifier { unpacked_dimension } [ = constant_expression ] | ...

The addition of the [= constant_expression] is appropriate for net_port_header, but does not seem so for interface_port_header. I think we should split them into two, like this:

ansi_port_declaration ::= [ net_port_header ] port_identifier { unpacked_dimension } [ = constant_expression ]
                                      | [ interface_port_header ] port_identifier { unpacked_dimension }
                                       | ...

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