Cliff wrote: >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. That is not the backward compatibility issue that I was describing. We do indeed have a backward compatibility issue in our implementation. This was caused by an attempt to avoid the backward compatibility issue between Verilog-2001 and Verilog-1995, which is what I was referring to. >Any time we add a keyword to the language, we potentially break backward >compatibility with a previously declared identifier of the same name. And we accept this because we expect that (say) 99.9% of existing designs won't have this problem. 99.9% backward compatible is close enough that we can consider it backward compatible. On the other hand, I don't consider 85% backward compatible to be close enough, and I think many people would agree with me. >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. Such things are clumsy at best. They are only adequate for situations that come up very rarely. The command line options don't work well if you are trying to combine a mixture of legacy code and new code on the same command line. They also require keeping track of which files need which options, separate from the files themselves. The embedded directives may require modifying a lot of source files. Also, a source file containing a directive to indicate that it is Verilog-1995 code won't compile in an actual old Verilog-1995 tool, because that tool won't understand the directive. That might be resolved by using a `ifdef around the directive and defining or not defining a macro on the command line, depending on the tool being used, but that makes it clumsier. If users have to deal with these problems only occasionally, then these are not too bad of a workaround. They are a lot better than nothing. If users have to deal with it often, then these are not a good solution. Steven Sharp sharp@cadence.comReceived on Wed Apr 27 15:28:25 2005
This archive was generated by hypermail 2.1.8 : Wed Apr 27 2005 - 15:30:09 PDT