[sv-bc] Re: Config-keyword work-around - was: potential command line option

Hi, Steve -

I better understand your dilemma as described below. More comments below.

At 03:53 PM 4/25/2005, you wrote:

> >There is a reasonable workaround for the config keyword issue. Users can do
> >the following [workaround using `begin_keywords "1364-2001" omitted]
>
>There is a problem with this proposed solution.
>
>The only keywords in 1364-2001 that have caused problems in customer
>designs are certain ones in configs.  Those keywords don't really need
>to be reserved in Verilog source if configs are not allowed in Verilog
>source (which they technically are not).

The "technically are not" is opinion.
1364-2001 - Does not define any command line switches (we thought about it 
and rejected it)

Annex A (normative) - technically they are not (this was my mistake - we 
don't force tools to implement mistakes)

Annex B (normative) - technically config and the others are reserved words.

Section 13 (normative) - does not prohibit configs from being in the same 
file or read in the same input stream.

Section 13.1 (normative) -
As evidenced by the config-endconfig syntax, the config is a design 
element, similar to a module, which exists in the Verilog namespace.

Section 13.2.1 (normative) -
"When parsing a source description file (or files), the parser shall first 
read the library mapping information from a pre-defined file prior to 
reading any source files. The name of this file and the mechanism for 
reading it shall be tool-specific, but all compliant tools shall provide a 
mechanism to specify one or more library mapping files to be used for a 
particular invocation of the tool.  ...  For the purposes of this 
discussion, assume the existence of a file named lib.map in the current 
working directory, which is automatically read by the parser prior to 
parsing any source files specified on the command line."
This is the only reference to a possible separate library file related to 
configurations in Section 13.

Section 13.4.1 (normative) Title: 13.4.1 Precompiling in a single-pass 
use-model
The single-pass use-model is the traditional use-model with which most 
users are familiar. In this use-model, all of the source description files 
shall be provided to the simulator via the command line, and only these 
source descriptions can be used to bind cell instances in the current design.
(NOTE: Section 13.4.4 tells us the legal way to bind the cells - no mention 
of required command line switches in 13.4.1)

Section 13.4.2 (normative) Title: 13.4.2 Elaboration-time compiling in a 
single-pass use-model
... Once the top-level module(s) has been found, then it can be compiled 
into the library, and the tool can proceed down the hierarchy, only 
compiling the source descriptions necessary to bind the design successfully.
(NOTE: Section 13.4.4 tells us the legal way to bind the cells - no mention 
of required command line switches in 13.4.2)

Section 13.4.4 (normative) - In each of the three preceding strategies, the 
binding rules can either be specified via a config, or the default rules 
(from the library map file) can be used.
(This section tells us binding happens from EITHER configs or libraries, so 
the configs were listed in the same input stream when compiled)

Section 13.7.1 (informative note at the end of the section)
NOTE It is recommended all compliant tools use "-L <library_name>" to 
specify this search order.
(No -config switch recommended because none was needed to implement configs 
- you are now proposing a config  switch of some variety, which is a 
reasonable proposal but one that I would prefer to omit)

Non-normative 1364-2001 Draft 4 - config, endconfig and library were part 
of the Verilog keywords but the other config and library keywords were in 
separate keyword lists.

There is ample evidence to show that we intended configs to be part of the 
Verilog input stream. Based on this information, to argue that configs 
could not be in the same file or read in the same input stream is a real 
stretch.

>As a result, NC-Verilog (and
>possibly other tools) support a dialect of 1364-2001 that does not
>reserve those keywords.  This dialect is very useful, since it can
>compile legacy Verilog-1995 without significant keyword issues, and can
>also compile legal Verilog-2001 designs.
>
>This means that there may be a significant amount of Verilog code by now
>that uses the config keywords as identifiers, but also uses Verilog-2001
>features.  The workaround you have suggested won't work for such code.

We are four years into the 1364-2001 Standard. Another implementation has 
agreed with my interpretation for the past two years. The fact that 
NC-Verilog has already implemented most of Verilog-2001 but is just now 
completing configs has caused the above predicament. It is regrettable but 
it was a business decision on the part of Cadence.

Like I said in a previous email, I believe it is a dangerous precedent to 
invalidate a legal interpretation of the standard and any working 
implementations of that interpretation to make it easier for another vendor 
to put a different implementation into place.

As a standards group, we CAN make this change. I do not believe it is wise 
to make this change. Do you want 75% of the balloting entities to vote to 
remove or change the SystemVerilog data types and kinds four years from 
now? Backward compatibility has generally been considered to be almost sacred.

>As I mentioned in an earlier email, a compromise might be possible that
>takes advantage of `begin_keywords.  However, that compromise needs to
>take into account that in practice, those keywords didn't really need
>to be reserved until configs were allowed in Verilog source files.  So
>it needs to support the intermediate dialect that doesn't reserve them.

This again is a side-effect of having implemented most of the Verilog-2001 
standard and saving configs for last. I sympathize for the NC-Verilog 
predicament.

>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