ISSUE 203

Add Proposal  Add Analysis  Edit Class, Environment, or Release
Number 203
Category errata
Synopsis A.1.4: list_of_port_declarations BNF rule
State open
Class errata-discuss
Arrival-DateNov 19 2002
Originator Dennis Marsa <drm@xilinx.com>
Release 2001b: A.1.4
Environment
Description
The following BNF rule from section A.1.4 describes the syntax
for new-style port lists:

list_of_port_declarations ::=
"(" port_declaration { "," port_declaration } ")"
| "(" ")"

This rule should be modified to remove the second alternative,
leaving just:

list_of_port_declarations ::=
"(" port_declaration { "," port_declaration } ")"

A port list of the form "(" ")" should be treated as
an old-style port list, whose syntax is already defined
by the BNF rule "list_of_ports".

See the thread beginning with:

http://boydtechinc.com/etf/archive/etf_2002/0543.html

for additional information.
Fix
Audit-Trail

From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: etf-bugs@boyd.com
Cc:
Subject: Re: errata/203: A.1.4: list_of_port_declarations BNF rule
Date: Sun, 24 Nov 2002 14:39:46 +0200

What does this do to the decision on #155,
to delete the [] around list_of_ports, but leave them on
list_of_port_declarations ?

That decision caused a module declaration with no port list
(i.e., no parentheses) to be parsed "as though" it were a new-style port
list.

The reasoning was that it syntactically restricted the following
statements
to non_port_module_item instead of just module_item.

But what logic is there to treat the "no port list" and "empty port
list" cases differently?

In the empty port list case, you also may not have port declarations
within the module!

Maybe it is better to make them consistent with each other?

A third possiblity would be to break out the "no port list" case
explicitly to a separate production,
and remove the brackets around both list_of_ports and
list_of_port_declarations.

Shalom


> The following BNF rule from section A.1.4 describes the syntax
> for new-style port lists:
>
> list_of_port_declarations ::=
> "(" port_declaration { "," port_declaration } ")"
> | "(" ")"
>
> This rule should be modified to remove the second alternative,
> leaving just:
>
> list_of_port_declarations ::=
> "(" port_declaration { "," port_declaration } ")"
>
> A port list of the form "(" ")" should be treated as
> an old-style port list, whose syntax is already defined
> by the BNF rule "list_of_ports".


From: Dennis Marsa <drm@xilinx.com>
To: Shalom Bresticker <Shalom.Bresticker@motorola.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/203: A.1.4: list_of_port_declarations BNF rule
Date: Mon, 25 Nov 2002 09:08:28 -0700

Shalom Bresticker wrote:
>
> What does this do to the decision on #155,
> to delete the [] around list_of_ports, but leave them on
> list_of_port_declarations ?
>
> That decision caused a module declaration with no port list
> (i.e., no parentheses) to be parsed "as though" it were a new-style port
> list.
>
> The reasoning was that it syntactically restricted the following
> statements
> to non_port_module_item instead of just module_item.
>
> But what logic is there to treat the "no port list" and "empty port
> list" cases differently?
>
> In the empty port list case, you also may not have port declarations
> within the module!

Let's be careful describing "()" as the "empty port list". It is not
empty. It has one anonymous, internally unconnected port. I don't know
if there is a good term to accurately describe "()".

You're right that a module with a () port list cannot contain port
declarations, but its not the only possible old-style port list with
that restriction: Consider:

module (,); // 2 anonymous ports
module (,,); // 3 anonymous ports
module (,,,); // 4 anonymous ports etc.
...

Dennis

From: Shalom.Bresticker@motorola.com
To: Dennis Marsa <drm@xilinx.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/203: A.1.4: list_of_port_declarations BNF rule
Date: Mon, 25 Nov 2002 22:02:16 +0200 (IST)

> You're right that a module with a () port list cannot contain port
> declarations, but its not the only possible old-style port list with
> that restriction: Consider:
>
> module (,); // 2 anonymous ports
> module (,,); // 3 anonymous ports
> module (,,,); // 4 anonymous ports etc.
> ...

All true, but

1. That does not change my point.
2. In contrast to (), I have never seen (,) and I believe I never will.
I do not consider that an interesting case.

Unformatted


Hosted by Boyd Technology