Trying to direct this thread back to the original proposal.
My goal was to describe the issue and possible solution well enough for people to vote on its importance and to decide whether this should be combined with another issue during voting. My guess is that it will be addressed anyway when discussing Mantis 210 (which is sitting at #12 on the weighted list), but I wanted to raise it now before the list of topics was closed. I don't know that it's necessary to decide the issue now, or even if that's appropriate.
Since this is definitely an enhancement request that is independent of the other requests, and not a clarification that would fall under 3056, maybe a separate Mantis entry is needed and we should vote separately. Unfortunately I can't create Mantis entries myself. For now, I added Item n/a 39 to the Google spreadsheet to capture this.
However, to clarify the relationships of this proposal with Mantis 210 and n/a 10, Mantis 210 proposes making something like this legal:
module foo #(parameter flag=0)
( generate
if (flag ==1)
input x;
endgenerate
);
...
endmodule
This is an instance-specific, parameterized version of a globally configurable port list using `ifdef:
module foo
(
`ifdef FOO_FLAG
input x;
`endif
);
...
endmodule
In my view, it would be odd to allow the former (with semicolon terminator) and not the latter, which is why this is related to n/a 10. As a user, I don't want to have to remember to use a different port declaration syntax depending on whether I'm using `ifdef or generate to configure the list.
If you disallow use of semicolon, then perhaps Mantis 210 should look like this, with a comma:
module foo #(parameter flag=0)
( generate
if (flag ==1)
input x,
endgenerate
);
...
endmodule
But under the current syntax, the `ifdef version with a trailing comma is illegal, which is once again odd. So maybe you don't want trailing commas in port generate statements:
module foo #(parameter flag=0)
( generate
if (flag ==1)
input x
endgenerate
);
...
endmodule
I think this is actually a workable solution, but of course, this still has the problem that comma-separated lists of ports are harder to maintain and generate than comma-or-semicolon-terminated lists.
~ Dave
-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of John Michael Williams
Sent: Monday, April 26, 2010 7:16 PM
Cc: 'sv-bc@eda.org'
Subject: Re: [sv-bc] Top-25 proposed enhancement: Allow trailing commas in ANSI port / named connection lists
Hi.
I don't understand this problem: It seems to me that a simple
solution would be to enclose the legacy code in an ANSI-header
wrapper module, and map the new `included parameter values
by name to an unmodified, old-style module (instance). This way,
only the wrapper would see `includes (in ANSI style), and the wrapper
header could be modified independently of the legacy module.
In general, one should avoid designing with `includes,
wherever possible . . ..
On 04/26/2010 03:04 PM, Don Mills wrote:
> this makes since to add to the comma/semicolon n/a 10 proposal. Both
> trailing or leading commas could cause a problem in this example.
>
> The comma/semicolon issue is nothing but painful where I work at now.
> They have legacy old school `include list of parameters files that are
> semicolon delimited as was required with old code. As they migrate
> forward, they want to use the new ansii style port netlists, but they
> can't 'include the parameter file into the proper area because of the
> comma/semicolon issue. If they change the file, then their legacy code
> fails. They could manage two files, but that is always problematic.
>
>
> Gates, David wrote:
>>
>> Hi,
>>
>> I'd like to add a proposal that is somewhat related to Item n/a 10:
>>
>> (10) ANSI style ports and parameters - allow either comma or semicolon
>> separators (slide 36)
>>
>> It can either be a separate item to vote on, or combined with n/a 10.
>>
>> When generating or transforming Verilog code, it is common to iterate
>> over a list of items such as port declarations or connections.
>> Currently in such cases, the generation code must take into account
>> whether an item is the first or last when deciding whether to insert a
>> comma between items. This is annoying all on its own, but is
>> especially problematic when generating code that may be conditionally
>> parsed:
>>
>> module foo (
>>
>> `ifdef NEED_PORT_A
>>
>> input a,
>>
>> `endif
>>
>> `ifdef NEED_PORT_B
>>
>> input b
>>
>> `endif
>>
>> );
>>
>> endmodule
>>
>> module bar();
>>
>> foo foo (
>>
>> `ifdef NEED_PORT_A
>>
>> .a(a),
>>
>> `endif
>>
>> `ifdef NEED_PORT_B
>>
>> .b(b)
>>
>> `endif
>>
>> );
>>
>> endmodule
>>
>> If NEED_PORT_A is defined but NEED_PORT_B isn't, then you get syntax
>> errors. You can try to use leading commas instead:
>>
>> module foo (
>>
>> `ifdef NEED_PORT_A
>>
>> input a
>>
>> `endif
>>
>> `ifdef NEED_PORT_B
>>
>> , input b
>>
>> `endif
>>
>> );
>>
>> endmodule
>>
>> module bar();
>>
>> foo foo (
>>
>> `ifdef NEED_PORT_A
>>
>> .a(a)
>>
>> `endif
>>
>> `ifdef NEED_PORT_B
>>
>> , .b(b)
>>
>> `endif
>>
>> );
>>
>> endmodule
>>
>> But now if NEED_PORT_A is undefined and NEED_PORT_B is defined, you
>> get different syntax errors. It's actually quite difficult to write
>> legal code for all 4 cases (especially given the absence of a `if or
>> `ifeq in the preprocessor.) Add more ports and things get
>> exponentially worse.
>>
>> However, if you allow trailing commas, then it's possibly to generate
>> "safe" code in all cases, and also it's no longer necessary to detect
>> the first or last item as a special case.
>>
>> So the proposal is to allow trailing commas at the end of named
>> connection lists and ANSI-Style port declaration lists:
>>
>> list_of_port_connections ::=
>>
>> ordered_port_connection { *, *ordered_port_connection }
>>
>> | named_port_connection { *, *named_port_connection } { *, *}
>>
>> list_of_port_declarations ::=//
>>
>> *( *[ { attribute_instance} ansi_port_declaration { *, *{
>> attribute_instance} ansi_port_declaration } { *, **}* ] *)*
>>
>> This becomes somewhat more important if you also consider Mantis 210,
>> that would extend generate functionality to these same lists. In that
>> case, you have to decide what form of separator / terminator is needed
>> for the generated ports / connections.
>>
>> An alternative to the proposed enhancement would continue to restrict
>> use of comma as a port / connection item _/separator/_ and add the
>> option of using semicolon as a port / connection item _/terminator/_.
>>
>> ~ Dave
>>
>> // David A. Gates, Ph.D. 408.749.4497
>>
>> // Director, RTL Center of Expertise
>>
>> // Fellow, Design Automation
>>
>> // Advanced Micro Devices www.amd.com <http://www.amd.com/>
>>
>> // Less talk, more action.
>>
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
>> believed to be clean.
>
> --
> ==========================================================
> Don Mills
> mills@lcdm-eng.com
> www.lcdm-eng.com
> ==========================================================
>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
--
John Michael Williams
jwill@BasicISP.net
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Tue Apr 27 10:28:29 2010
This archive was generated by hypermail 2.1.8 : Tue Apr 27 2010 - 10:31:10 PDT