| Add Proposal | Add Analysis | Edit Class, Environment, or Release |
| Number | 198
|
| Category | errata
|
| Synopsis | 12.3.9.2: sinks should allow only constant part-selects
|
| State | open
|
| Class | errata-discuss
|
| Arrival-Date | Nov 19 2002
|
| Originator | Shalom.Bresticker@motorola.com
|
| Release | 2001b: 12.3.9.2
|
| Environment |
#54 #75 |
| Description |
12.3.9.2 defines "structural net expressions" which may be the sinks in a port connection. Among other things, it lists: - A constant bit-select of a vector net - A part-select of a vector set The latter should be "A constant part-select or constant indexed part-select of a vector net", as in Table 30 in Clause 6. Originally, part-selects were always constants so there was no need to say so. That changed in 1364-2001. The list appears a second time a few lines down in this same section, and should be corrected there too. Actually, I see no reason why these two paragraphs with identical lists which say almost the same thing can not be combined together into one. Even better would be to say that the legal expressions are the same which can appear on the lhs of a continuous assignment, and then reference Table 30. It is bad practice to write the same thing several times. Then when you change or correct one, you forget to change the others. That is exactly what happened here. I also have a problem with the terminology of source and sink, which are not appropriate for inout ports. Also see issue #54. Shalom |
| Fix |
|
| Audit-Trail |
From: Shalom.Bresticker@motorola.com To: etf-bugs@boyd.com Cc: Subject: Re: errata/198: 12.3.9.2: sinks should allow only constant part-selects Date: Sun, 9 Nov 2003 11:16:40 +0200 (IST) Regarding sinks in port connections, > 12.3.9.2 defines "structural net expressions" which may be the sinks in a port > connection. > Even better would be to say that the legal expressions are the same which can > appear on the lhs of a continuous assignment, and then reference Table 30. In the last ETF call, we decided that both continuous assignment LHS's and port connection sinks should have the same possibilities, and in particular, both should allow constant element-selects of arrays and constant bit-/part-selects of constant element-selects of arrays. Basically, any net_lvalue (see A.8.5). In looking at this, I found the following problem with respect to ports: With respect to the list_of_ports in the module header, this change means basically changing (see Syntax 12-5) port_reference from "port_identifier [ [ constant_range_expression ] ]" to "net_lvalue", and that seems natural. However, it also seems to require extending input_declaration from the form input [ range ] port_identifier to input [ range ] port_identifier { [ dimension ] } That is, to declare arrays as well, even though the array_identifier cannot appear in a simple port list as just a port_identifier, since arrays cannot currently be passed as ports. And that is because the port_identifiers in the port_references have to appear in port declarations as well. Your thoughts, please. Thanks, Shalom -- 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 From: Steven Sharp <sharp@cadence.com> To: etf-bugs@boyd.com, Shalom.Bresticker@motorola.com Cc: Subject: Re: errata/198: Re: errata/198: 12.3.9.2: sinks should allow only constant part-selects Date: Thu, 13 Nov 2003 17:09:13 -0500 (EST) Shalom, If I understand you correctly, you are talking about the syntax where the user declares module foo (.bar(fubar[0])); input fubar; // or is that input fubar[0]; Except that here, you want to connect the port that is bar externally to one element of fubar internally, and there is no way to declare one element of an array as a port. The basic flaw was introduced way back when it was decided that the internal name would be declared as the port, instead of the external name. If it had been defined so that you declared the port direction for bar, this wouldn't be an issue. You could connect any port expression you wanted on the inside, just like on the outside. There also wouldn't be mixed-direction ports. It is possible that there was a good reason for making it the way it is, but I haven't thought about it much. At any rate, you are right and there is no good way to declare this. On the other hand, this style of port declaration is very rare. Most users don't even know that it exists. It isn't possible with ANSI-C style port declarations. That implies an acceptance that it won't necessarily be supported for new extensions. Arrays of nets are a new extension. It also doesn't appear to be essential functionality. Connecting an element of an array to a port of an instance is important, since instantiation can be done with a generate-for, and there needs to be an algorithmic way of connecting each one up. But there is no algorithmic way to specify a module port list with some kind of loop. Each port must be explicitly listed. So there is minimal value to being able to connect the ports to array elements. As a result, I would suggest not trying to extend module declarations to handle this. Steven Sharp sharp@cadence.com From: Shalom.Bresticker@motorola.com To: Steven Sharp <sharp@cadence.com> Cc: etf-bugs@boyd.com Subject: Re: errata/198: 12.3.9.2: sinks should allow only constant part-selects Date: Fri, 14 Nov 2003 12:33:51 +0200 (IST) > If I understand you correctly, you are talking about the syntax where the > user declares > > module foo (.bar(fubar[0])); > input fubar; // or is that input fubar[0]; Yes, that's what I meant. More specifically, let's assume that fubar is a vector. Then we can write module foo (.bar(fubar[0])); input [3:0] fubar ; or module foo (fubar[0]); input [3:0] fubar ; That is, in the port_declaration (input, output, or inout), you declare the net or variable completely with its entire range if it is a vector. Remember that you cannot write a port and net declarations with different ranges, like input [3:0] fubar ; wire [7:0] fubar ; Even though you declare the entire net in the port declaration, it may be that only part of it is connected externally. This also means you cannot declare part of a net vector with one direction and another part with a different port direction. Extending that idea, if fubar were a net array, and I wanted to declare it as a port, I would have to write it as input [3:0] fubar [7:0] [7:0] ; but that is not legal today. Today fubar can only be a scalar or a vector, not an array. Remember that I cannot today pass an array as a single port, like module foo (fubar); input [3:0] fubar [7:0] [7:0] ; In principle, there is no obstacle though to writing something like module foo (foobar[0][0]) ; input [3:0] fubar [7:0] [7:0] ; such that the port is still only a single vector or scalar. However, as I said, I would still not be able to write module foo (fubar); That is, until we decide to allow arrays as ports and define how to do it. > Except that here, you want to connect the port that is bar externally to > one element of fubar internally, and there is no way to declare one element > of an array as a port. > > The basic flaw was introduced way back when it was decided that the internal > name would be declared as the port, instead of the external name. If it had > been defined so that you declared the port direction for bar, this wouldn't > be an issue. You could connect any port expression you wanted on the inside, > just like on the outside. There also wouldn't be mixed-direction ports. It > is possible that there was a good reason for making it the way it is, but > I haven't thought about it much. One possible reason for doing it that way is that it prevents duplicate and contradictory declarations. > At any rate, you are right and there is no good way to declare this. On > the other hand, this style of port declaration is very rare. Most users > don't even know that it exists. I remember how surprised I was to learn about it. And not all tools support it either. > It isn't possible with ANSI-C style port declarations. That implies an > acceptance that it won't necessarily be supported for new extensions. > Arrays of nets are a new extension. > > It also doesn't appear to be essential functionality. Connecting an element > of an array to a port of an instance is important, since instantiation can > be done with a generate-for, and there needs to be an algorithmic way of > connecting each one up. But there is no algorithmic way to specify a module > port list with some kind of loop. Each port must be explicitly listed. So > there is minimal value to being able to connect the ports to array elements. I don't agree, but I won't argue about it now. > As a result, I would suggest not trying to extend module declarations to > handle this. Unfortunately, this breaks the symmetry between external and internal port sinks, and being internal port sinks and continuous assignments. It means that internal port sinks (port_references) will be more restricted than net_lvalues. And that is how I got into this issue. If that is the sense of the ETF, then I will continue in that direction. -- 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 From: Steven Sharp <sharp@cadence.com> To: sharp@cadence.com, Shalom.Bresticker@motorola.com Cc: etf-bugs@boyd.com Subject: Re: errata/198: 12.3.9.2: sinks should allow only constant part-selects Date: Mon, 17 Nov 2003 15:02:28 -0500 (EST) >Unfortunately, this breaks the symmetry between external and internal port >sinks, and being internal port sinks and continuous assignments. It means >that internal port sinks (port_references) will be more restricted than >net_lvalues. And that is how I got into this issue. I agree that it is unfortunate, but this asymmetry already existed. You can attach arbitrary expressions as sources on the outside, but are quite restricted on any attachment on the inside, whether source or sink. Steven Sharp sharp@cadence.com From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: Steven Sharp <sharp@cadence.com> Cc: etf-bugs@boyd.com Subject: Re: errata/198: 12.3.9.2: sinks should allow only constant part-selects Date: Tue, 18 Nov 2003 10:28:03 +0200 I was referring to sinks. 12.3.8 and 12.3.9.2 say, I think, that port sinks are structural port expressions, and the same restrictions exist whether the sink is on the inside or the outside. And that is true according to the definition of structural port expression given there. And the same restrictions exist on the LHS of a continuous assignment as defined in Table 30 (beginning of Clause 6). Now we have decided that the LHS of a continuous assignment can be anything the BNF of net_lvalue allows. We also decided that that is true of a port sink on the external side (of an output or inout port). The trouble comes with extending that to a port sink on the internal side (of an input or inout port). Shalom Steven Sharp wrote: > >Unfortunately, this breaks the symmetry between external and internal port > >sinks, and being internal port sinks and continuous assignments. It means > >that internal port sinks (port_references) will be more restricted than > >net_lvalues. And that is how I got into this issue. > > I agree that it is unfortunate, but this asymmetry already existed. You > can attach arbitrary expressions as sources on the outside, but are quite > restricted on any attachment on the inside, whether source or sink. -- 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 |
| Unformatted |
|
Hosted by Boyd Technology