Don,
I claim that your example is an argument to NOT allow semi-colon
delimited lists. This how we got to the problem of mixed ANSI/non-ANSI
style port lists. People took the following code
module A(p1,p2);
input p1;
output p2;
reg p2;
...
endmodule
and converted it to
module A(
input p1,
output p2
);
reg p2;
...
endmodule
This should have never been allowed, but was so common that at least one
vendor started supporting it. Trying to explain this in the LRM is going
to be painful and confusing to the user.
Allowing semi-colons as delimiters will just reinforce this bad coding
style.
Dave
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Don
Mills
Sent: Monday, April 26, 2010 3:04 PM
To: Gates, David
Cc: 'sv-bc@eda.org'
Subject: Re: [sv-bc] Top-25 proposed enhancement: Allow trailing commas
in ANSI port / named connection lists
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. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Apr 26 16:57:16 2010
This archive was generated by hypermail 2.1.8 : Mon Apr 26 2010 - 16:59:35 PDT