Stu,
I wonder if this is an issue to be resolved during the merge into a
single specification for 1364/1800? I read the inclusion/exclusion of
keywords to address a first order effect and not some more difficult
semantic definitions that could be in conflict with each other.
As an example, in the case of "generate," if I specify Verilog-2001 do
I get that specification of generate? It was acknowledged that there
might have been some errors in the -2001 specification for generate, but
they were first addressed in a -2005 draft, not as an errata for -2001.
Forward progress on this, and many other issues, has left older
specifications and definitions behind. I think this is something the
working groups wanted and intended. My concern here is this is a plan
to keep in place for perpetuity semantic definitions that we have
otherwise elected to change.
There is a great benefit to mixing the use of different versions of
Verilog for the user. I have also heard some discussion on this issue
that some wanted it to be at the binary level as well - that is - the
user does not want to have to recompile code. As has been noted, the
market is responding to user needs in this area presently, with
limitations that the market is willing to accept.
-Dennis
-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Stuart Sutherland
Sent: Monday, November 29, 2004 6:06 PM
To: sv-bc@eda.org
Subject: [sv-bc] Proposal for compatibility problems with mixed
Verilog/SystemVerilog code
All,
I have attached a complete proposal for the P1800 standard to fix a
serious compatibility problem between the 1364 and 1800 standards. This
compatibility is particularly a problem when mixing models from both
standards, such as when a SystemVerilog module instantiates an IP model
written in Verilog, or when a SystemVerilog netlist uses a Verilog
standard cell library. At issue is the large number of keywords that
SystemVerilog adds to Verilog. Many of these new reserved words were
commonly used as net or variable identifiers in existing Verilog code
(e.g.: as bit, byte and logic). Currently, software implementations
must invent proprietary ways for a tool to read source code as either
Verilog code or SystemVerilog code.
Each tool I have used has invented different methods to handle the
keyword differences in the two languages. Some tools do not handle
mixing Verilog and SystemVerilog models at all. Keyword compatibility
creates portability problems between software tools, and inhibits the
adoption of SystemVerilog.
The attached proposal provides a pair of compiler directives that make
it simple to mix Verilog models and SystemVerilog models. By making
these directives part of the SystemVerilog standard, user's can rely on
a portable mechanism for using new SystemVerilog models together with
their existing Verilog models.
I would like to bring the attached proposal up for a vote in Tuesday's
SV-BC meeting. Can someone please add this to the list of errata in the
SV data base?
Stu
P.S. This compatibility problem was originally opened in the 1364 ETF
data base, as item 287.
~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland
stuart@sutherland-hdl.com
+1-503-692-0898
Received on Tue Nov 30 15:37:30 2004
This archive was generated by hypermail 2.1.8 : Tue Nov 30 2004 - 15:37:41 PST