| Number | 157
|
| Category | errata
|
| Synopsis | 12.3.1, A.1.4, port -- port_expression optional?
|
| State | closed
|
| Class | mistaken
|
| Arrival-Date | Oct 10 2002
|
| Originator | "Brad Pierce" <Brad.Pierce@synopsys.com>
|
| Release | 2001b
|
| Environment |
|
| Description |
This is a multi-part message in MIME format. ------=_NextPart_000_003A_01C27047.54D1A6D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit The definition of port in 12.3.1/A.1.4 says -- port ::= [ port_expression ] | . port_identifier ( [ port_expression ] ) How could the port_expression be optional? That would mean, for example, that ( , , , , , ) is a possible list_of_ports. Should the definition be -- port ::= port_expression | . port_identifier ( port_expression ) ? -- Brad ------=_NextPart_000_003A_01C27047.54D1A6D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 5.50.4807.2300" name=3DGENERATOR> <FONT face=3DArial size=3D2><SPAN class=3D813211517-10102002>The =
definition of=20 port in 12.3.1/A.1.4 says -- <FONT face=3DArial size=3D2><SPAN=20
class=3D813211517-10102002> <FONT face=3DArial size=3D2><SPAN class=3D813211517-10102002> =
port ::=3D [=20 port_expression ] <FONT face=3DArial size=3D2><SPAN=20
class=3D813211517-10102002> &nbs= p; =20 | . port_identifier ( [ port_expression ] = ) <FONT face=3DArial size=3D2><SPAN=20
class=3D813211517-10102002> <FONT face=3DArial size=3D2><SPAN class=3D813211517-10102002>How =
could the=20 port_expression be optional? <FONT face=3DArial size=3D2><SPAN class=3D813211517-10102002>That =
would mean, for=20 example, that ( , , , , , ) <FONT face=3DArial size=3D2><SPAN class=3D813211517-10102002>is a =
possible=20 list_of_ports. <FONT face=3DArial size=3D2><SPAN=20
class=3D813211517-10102002> <FONT face=3DArial size=3D2><SPAN class=3D813211517-10102002>Should =
the=20 definition be -- <FONT face=3DArial size=3D2><SPAN=20
class=3D813211517-10102002> <FONT face=3DArial size=3D2><SPAN class=3D813211517-10102002> =
port ::=3D=20 port_expression <FONT face=3DArial size=3D2><SPAN=20
class=3D813211517-10102002> &nbs= p; =20 | . port_identifier ( port_expression ) <FONT face=3DArial size=3D2><SPAN=20
class=3D813211517-10102002> <FONT face=3DArial size=3D2><SPAN=20
class=3D813211517-10102002>? <FONT face=3DArial size=3D2><SPAN=20
class=3D813211517-10102002> <FONT face=3DArial size=3D2><SPAN class=3D813211517-10102002>--=20
Brad <FONT face=3DArial size=3D2><SPAN=20
class=3D813211517-10102002> <FONT face=3DArial size=3D2><SPAN=20
class=3D813211517-10102002> ------=_NextPart_000_003A_01C27047.54D1A6D0-- |
| Fix |
|
| Audit-Trail |
From: Steven Sharp <sharp@cadence.com> To: etf-bugs@boyd.com, Brad.Pierce@synopsys.com Cc: Subject: Re: errata/157: 12.3.1, A.1.4, port -- port_expression optional? Date: Thu, 10 Oct 2002 13:44:08 -0400 (EDT) >Category: errata >Confidential: no >Originator: Steven Sharp <sharp@cadence.com> >Release: 2001b >Class: TBD >Description: >The definition of port in 12.3.1/A.1.4 says -- > > port ::= [ port_expression ] > | . port_identifier ( [ port_expression ] ) > >How could the port_expression be optional? It means the port is explicitly unconnected. For connecting by position, it is the only way to skip past an unconnected port to connect to the next. I have also seen it done with named port connections, presumably to make clear that the port was deliberately unconnected (or perhaps the output of a tool that generates named port connections for all ports, including the unconnected ones). >That would mean, for example, that ( , , , , , ) >is a possible list_of_ports. Yes, it is perfectly legal. > >Should the definition be -- > > port ::= port_expression > | . port_identifier ( port_expression ) > >? Nope. Steven Sharp sharp@cadence.com From: "Brad Pierce" <Brad.Pierce@synopsys.com> To: <etf-bugs@boyd.com> Cc: Subject: Re: errata/157: 12.3.1, A.1.4, port -- port_expression optional? Date: Thu, 10 Oct 2002 11:16:14 -0700 >Category: errata >Confidential: no >Originator: "Brad Pierce" <Brad.Pierce@synopsys.com> >Release: 2001b >Class: TBD >Description: Sorry about my noise. As Steven points out, according to 12.3.2 -- "The port expression is optional because ports can be defined that do not connect to anything internal to the module." Thanks for the help, -- Brad From: Shalom.Bresticker@motorola.com To: stefen@boyd.com Cc: etf-bugs@boyd.com Subject: Re: errata/157: 12.3.1, A.1.4, port -- port_expression optional? Date: Thu, 10 Oct 2002 22:26:09 +0200 (IST) >Category: errata >Confidential: no >Originator: Shalom.Bresticker@motorola.com >Release: 2001b >Class: TBD >Description: Stefen, Please classify this item appropriately - close it or delete it or something. Thanks, Shalom From: Shalom.Bresticker@motorola.com To: Steven Sharp <sharp@cadence.com> Cc: etf-bugs@boyd.com Subject: Re: errata/157: 12.3.1, A.1.4, port -- port_expression optional? Date: Thu, 10 Oct 2002 22:44:08 +0200 (IST) >Category: errata >Confidential: no >Originator: Shalom.Bresticker@motorola.com >Release: 2001b >Class: TBD >Description: Steven, Although the issue has already been resolved, it seems to me that you were talking about module instantiations, whereas this section talks about module definitions. Shalom On Thu, 10 Oct 2002, Steven Sharp wrote: > >The definition of port in 12.3.1/A.1.4 says -- > > > > port ::= [ port_expression ] > > | . port_identifier ( [ port_expression ] ) > > > >How could the port_expression be optional? > > It means the port is explicitly unconnected. For connecting by position, > it is the only way to skip past an unconnected port to connect to the next. > I have also seen it done with named port connections, presumably to make > clear that the port was deliberately unconnected (or perhaps the output of > a tool that generates named port connections for all ports, including the > unconnected ones). > > >That would mean, for example, that ( , , , , , ) > >is a possible list_of_ports. > > Yes, it is perfectly legal. > > > > >Should the definition be -- > > > > port ::= port_expression > > | . port_identifier ( port_expression ) > > > >? > > Nope. > > Steven Sharp > sharp@cadence.com > > From: Steven Sharp <sharp@cadence.com> To: Shalom.Bresticker@motorola.com Cc: etf-bugs@boyd.com Subject: Re: errata/157: 12.3.1, A.1.4, port -- port_expression optional? Date: Thu, 10 Oct 2002 17:00:06 -0400 (EDT) >Category: errata >Confidential: no >Originator: Steven Sharp <sharp@cadence.com> >Release: 2001b >Class: TBD >Description: >Steven, > >Although the issue has already been resolved, >it seems to me that you were talking about module instantiations, >whereas this section talks about module definitions. Yes, I wasn't paying close attention. However, the inside port connections inside a module definition are pretty much symmetrical with the outside port connections on a module instantiation, so I wasn't wrong :-). Steven Sharp sharp@cadence.com From: "Brad Pierce" <Brad.Pierce@synopsys.com> To: <etf-bugs@boyd.com> Cc: Subject: Re: errata/157: 12.3.1, A.1.4, port -- port_expression optional? Date: Wed, 4 Dec 2002 19:17:58 -0800 Is there any use for a module definition to be able to declare unconnectable ports? Wouldn't it be an error to instantiate module m1(); endmodule with anything other than m1 inst(); or to instantiate module m2(,); endmodule with anything other than m2 inst(,) ? I don't see this restriction in the standard though. But assuming there is such a restriction, what's the use of such ports? Does anybody have an example where empty port declarations are useful? -- Brad From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: Brad Pierce <Brad.Pierce@synopsys.com> Cc: etf-bugs@boyd.com Subject: Re: errata/157: 12.3.1, A.1.4, port -- port_expression optional? Date: Thu, 05 Dec 2002 10:32:56 +0200 I think there are at least two cases here. One issue is about a port declaration defined as [ port_expression ] . One use of that is of course to allow the "empty port list," i.e., a module which has no ports. Yes, I know the PLI may see it as one anonymous port, but from the user's point of view, there are no ports. Another case is the syntax, ". port_identifier ( [ port_expression ] )", where port_expression is null. This is a better question. If you try this to connect this in Verilog-XL, you will get an error message that you are trying to connect to a null port. Shalom Brad Pierce wrote: > Is there any use for a module definition to be able to > declare unconnectable ports? > > Wouldn't it be an error to instantiate > > module m1(); > endmodule > > with anything other than > > m1 inst(); > > or to instantiate > > module m2(,); > endmodule > > with anything other than > > m2 inst(,) > > ? I don't see this restriction in the standard though. But assuming > there is such a restriction, what's the use of such ports? > > Does anybody have an example where empty port declarations are > useful? -- Shalom Bresticker Shalom.Bresticker@motorola.com Design & Reuse Methodology Tel: +972 9 9522268 Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478 "The devil is in the details." From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: etf-bugs@boyd.com Cc: Subject: Re: errata/157: 12.3.1, A.1.4, port -- port_expression optional? Date: Thu, 05 Dec 2002 11:09:01 +0200 > Another case is the syntax, ". port_identifier ( [ port_expression ] )", > where port_expression is null. > > This is a better question. > If you try this to connect this in Verilog-XL, you will get an error message > that you are trying to connect to a null port. A few reasons why you might want to do this: 1. To document signals which should be there, but you don't need them in your model, and you don't want to clutter your connections with them. An example might be power supply signals, especially if you have multiple supplies, e.g, multiple voltages, noisy and quiet. Or pure analog signals. 2. Signals you plan to add in the future. Currently they are place-holders. 3. Template reuse. Let different modules have same port list, even though not all in use. All of these are a little weak. Maybe no one would have complained if the possibility had never been there. But after all these years, I would be very reluctant to break backward compatibility unless there is a strong benefit from it. Shalom |
| Unformatted |
|
Hosted by Boyd Technology