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.Received on Mon Apr 26 19:05:50 2010
This archive was generated by hypermail 2.1.8 : Mon Apr 26 2010 - 19:08:15 PDT