Re: [sv-ec] Re: [sv-bc] potential command line option

Randy Misustin wrote:

>But then again, my major concern isn't whether 
>the 2001 spec does or doesn't allow a config to appear in Verilog 
>source. My major concern is that the config keywords remain in the 
>keyword list for the upcoming 1364 specification. Whether the reason for 
>doing so is that configs are intended to be in Verilog source today, 
>whether it's to reserve that capability for the future, or whether its 
>for the frankly insightful reason you mentioned below (minus the 
>extended identifier silliness) isn't nearly as important to me (OK, I do 
>prefer the 1st but I'm pragmatic).

Let's consider the situation if configs were not allowed in Verilog
source, but the keywords were reserved.

Your implementation would have a non-standard extension that was
backward compatible with Verilog-2001 (i.e. configs in Verilog source).

Our implementation would have a non-standard extension that was
backward compatible with Verilog-2001 (i.e. greater backward
compatibility with Verilog-1995).

This might not look too bad from from both our points of view.
However, these two non-standard extensions would be mutually
incompatible.  Neither could be standardized without the other
extension becoming incompatible with the standard.

From the user point of view, this looks rather like the worst of
both worlds.  I would hope we could come to a better conclusion.


>Other messages in this thread have suggested that configs were, in fact, 
>intended to be part of Verilog source files. I guess you're arguing that 
>this was botched and, rather than fix it for the next version of the 
>spec, you'd like to drop it. Is this your position?

More or less.  We have more information about the seriousness of the
keyword conflict than they had originally.  The unintentional error in
the BNF may provide an opportunity to respond to that, because it means
that we don't clearly have a backward compatibility issue with the
previous standard.


Steven Sharp
sharp@cadence.com