[sv-bc] Re: Config facts & Dangerous Precedent - was: potential command line option

At 04:57 PM 4/26/2005, Steven Sharp wrote:
>Cliff wrote:
>
> >·       I guess the follow-on question is, do we really want to set a
> >precedent that might allow a vendor to implement a SystemVerilog feature
> >and then have other companies come back a few years later and request a
> >significant change to the feature to make it easier to implement on another
> >tool?
>
>I would say that it depends a lot on whether the LRM was ambiguous about
>the feature in question (and whether the first vendor made any attempt
>to get that ambiguity clarified before implementing).

Now we have to determine what constitutes a valid "attempt to get the 
ambiguity clarified before implementing."

It is true that Cadence did file issue 350 on May 19th, 2003 (I had not 
noticed the filed issue because I was swamped with SV 3.1 work at that time 
and we followed immediately with SV 3.1a work). Although a good first step, 
IMO filing an issue does not constitute a sufficient attempt to resolve an 
ambiguity. IMO driving an issue to resolution would constitute a sufficient 
attempt.

http://www.boydtechinc.com/btf/report/full_pr/350.html

Also, my reading of issue 350 does not show as much ambiguity as has been 
claimed.

Issue Title: Proposal to deprecate configs in Verilog source files (note: 
"in Verilog source files")

1st paragraph:
Verilog-2001 allows configs to appear in either Verilog
source files, or the library map file. I am proposing
that they not be allowed in Verilog source files, only
in the library map file.
(note: "Verilog-2001 allows configs to appear in either Verilog source files")

All the email suggesting that there was ambiguity regarding whether config 
files could be read in the Verilog source code does not match up to the 
issue-350 description.

A quick scan of issue 350 also does not seem to indicate any BNF problems 
(although I acknowledge that the BNF does have mistakes, which I made and 
for which I intend to propose corrections).

>Also, the issue in this case is not easier implementation on another tool.
>The main issue is one of backward compatibility, which is primarily of
>concern to users.

Despite all other perceived ambiguities, the Verilog-2001 Annex B clearly 
reserved the keywords in question.

Any time we add a keyword to the language, we potentially break backward 
compatibility with a previously declared identifier of the same name. 
Implementations have traditionally implemented non-standard command-line 
switches to help their customers identify that certain files should follow 
the syntax and reserved words of an earlier implementation. Verilog-2005 
has passed a `begin_compatibility proposal to provide a standard method to 
address this problem.

The backward compatibility issue described is the result of an 
implementation that partially implemented Verilog-2001 functionality while 
still allowing users to declare identifiers from a partial list of the 
normative, Annex-B Verilog-2001 reserved keywords. IMO this is a clear 
mistake and in violation of the Verilog-2001 standard. The vendor filed 
issue 350 and then chose to allow the illegal identifiers to be used in 
"Verilog-2001" code in anticipation that those identifiers would be legal 
when the issue was resolved. To date, this has not happened and this has 
now been labeled a backward compatibility issue, which IMO it is not.

>Steven Sharp
>sharp@cadence.com

Regards - Cliff

----------------------------------------------------
Cliff Cummings - Sunburst Design, Inc.
14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
Phone: 503-641-8446 / FAX: 503-641-8486
cliffc@sunburst-design.com / www.sunburst-design.com
Expert Verilog, SystemVerilog, Synthesis and Verification Training