Re: [sv-bc] Proposal for compatibility problems with mixed Verilog/SystemVerilog code

Stu,

Thanks for the clarification.

-Dennis

--
Dennis Brophy                                Email: dennisb@model.com
Director of Strategic Business Development   Phone: +1 503-685-0893
Mentor Graphics Corporation                    Fax: +1 503-685-0923
8005 Boeckman Rd, Bldg E-4                  Mobile: +1 503-706-8987
Wilsonville, OR 97070-7777                Home Fax: +1 503-579-2664
-----Original Message-----
From: Stuart Sutherland <stuart@sutherland-hdl.com>
To: Brophy, Dennis <dennisb@model.com>; sv-bc@eda.org <sv-bc@eda.org>
Sent: Tue Nov 30 16:13:32 2004
Subject: RE: [sv-bc] Proposal for compatibility problems with mixed
Verilog/SystemVerilog code
Dennis,
The proposal I made is strictly for allowing reserved keywords that are
unique in later versions of the standard(s) to be used as legal
identifiers
in older models.  The reserved keyword differences is where I have, and
I
feel many Verilog users will, run into problems with mixing old Verilog
models with new SystemVerilog models.
You raised the specter of semantic compatibility.  The proposal I made
specifically states that the `keywords directive does not affect the
language semantics, language tokens or other differences in various
versions
of the standards.  I agree that there may be times that a user, or an
EDA
vendor, may wish to have a product use the semantic rules, event
scheduling,
or some other behavior that were defined in an older version of the
Verilog
standard.  To define this type of backward compatibility as part of the
standard, however, would be very complex, if even possible.  I think
that
level of version compatibility is best left to the software tools.  I
also
think that there will be very few users that see a need for semantic
compatibility with older standards.
Another reason for limiting the proposal to just keyword compatibility
is
that, in my experience, adding new operators and new language constructs
the
standard do not cause a compatibility problem when mixing older models
with
newer models.  These types of changes are opening the lid of the box
wider.
They are not adding restrictions to the language that did not exist
before.
Older code will not contain the new language features, including, for
example, using "interface" as a modeling block.  Thus, older code can be
parsed and compiled with tools that support the new features, without a
compatibility problem.
Reserving new keywords is a different situation than most other new
language
features.  Adding new reserved words is making the language more
restrictive
than before.  Older models that did not have those restrictions will
very
likely have problems compiling with more restrictive rules.  The intent
of
the `keywords directive is to give users a means to tell the compiler to
relax the restriction on reserved words for selected portions of the
source
code.  The nature of compiler directives in Verilog does put some burden
on
the user to correctly turn the directives on and off, but it also gives
the
user needed control over compiler.
Just my thoughts...
Stu
~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland
stuart@sutherland-hdl.com
+1-503-692-0898
  
> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On 
> Behalf Of Brophy, Dennis
> Sent: Tuesday, November 30, 2004 3:37 PM
> To: stuart@sutherland-hdl.com; sv-bc@eda.org
> Subject: RE: [sv-bc] Proposal for compatibility problems with 
> mixed Verilog/SystemVerilog code
> 
> 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
>  
> 
> 
>