ISSUE 350

Edit Proposal  Edit Class, Environment, or Release
Number 350
Category enhancement
Synopsis Proposal to deprecate configs in Verilog source files
State proposal
Class enhancement
Arrival-DateMay 19 2003
Originator sharp@cadence.com
Release 2001b
Environment
Description
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.

The main reason for proposing this is that configs use
a lot of reserved keywords that can create backward
compatibility problems for existing designs. A test on
a large set of real customer designs indicated that 15%
of them would not compile with these keywords reserved.
And before anyone suggests context-sensitive keywords
(blech!), the main offender was the keyword "config",
which marks the start of the context and therefore
can't be context-sensitive.

The idea of having configs in the source code presumably
came from VHDL. Most experienced Verilog people I have
consulted agree that Verilog source files should only
contain real Verilog source, and that configs should be
put in a side file. The existing standard already allows
for them to be put into the library map file, which fits
that description nicely.

Nor is putting configs in the Verilog source file the
most beneficial use model. If you want to change what are
effectively "link" options, you don't want to have to
change and recompile the source code each time. My
inquiries indicate that VHDL users most often supply
configs in separate files, usually generated by tools
and at most tweaked by hand. So this seems to be the
most natural way of using them anyway.

If we do deprecate this, it would be best to do it
soon and publicize it before it comes into wide use.
Fix
"Shalom voiced concern that approval of this proposal might change an affirmative vote to a negative.
Action Item: Steve Sharp to compose proposal to resolve ambiguity and disallow configs in Verilog source, and to propose (as an informative note) a command line option to specify the configuration file.
Proposal will also include two keyword lists: one for Verilog source and one for Library mapping files. This will be two subsections in Annex B.
Tom - ok to add into source files.
- tell vendor where config files reside if outside the design files.
Cliff - doesn't want to deal with incompatible switches from dif vendors
Stu - command line switches now part of p1800 text (see appendix g)
- have a note to specify a recommended option to specify config files.
Mark - need to ensure it doesn't conflict with existing vendor switches.
Stu: OK with separate file if there is a note with recommended command line option.
Cliff: -cfg might work"
Audit-Trail

From: Michael McNamara <mac@verisity.com>
To: sharp@cadence.com
Cc: etf-bugs@boyd.com
Subject: RE: enhancement/350: Proposal to deprecate configs in Verilog source files
Date: Tue, 20 May 2003 21:16:02 -0700

sharp@cadence.com writes:
> Precedence: bulk
>
>
> >Number: 350
> >Category: enhancement
> >Originator: sharp@cadence.com
> >Environment:
>
> >Description:
>
> 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.
>
> The main reason for proposing this is that configs use
> a lot of reserved keywords that can create backward
> compatibility problems for existing designs. A test on
> a large set of real customer designs indicated that 15%
> of them would not compile with these keywords reserved.
> And before anyone suggests context-sensitive keywords
> (blech!), the main offender was the keyword "config",
> which marks the start of the context and therefore
> can't be context-sensitive.
>
> The idea of having configs in the source code presumably
> came from VHDL. Most experienced Verilog people I have
> consulted agree that Verilog source files should only
> contain real Verilog source, and that configs should be
> put in a side file. The existing standard already allows
> for them to be put into the library map file, which fits
> that description nicely.
>
> Nor is putting configs in the Verilog source file the
> most beneficial use model. If you want to change what are
> effectively "link" options, you don't want to have to
> change and recompile the source code each time. My
> inquiries indicate that VHDL users most often supply
> configs in separate files, usually generated by tools
> and at most tweaked by hand. So this seems to be the
> most natural way of using them anyway.
>
> If we do deprecate this, it would be best to do it
> soon and publicize it before it comes into wide use.

As much as I an leary to deprecate things, Steve makes very good
points here, especially the practical necessity of separation of the
HDL code and what he calls 'link' information.

-mac


From: Shalom.Bresticker@motorola.com
To: sharp@cadence.com
Cc: etf-bugs@boyd.com
Subject: Re: enhancement/350: Proposal to deprecate configs in Verilog source
files
Date: Tue, 20 May 2003 19:37:48 +0300 (IDT)

> If we do deprecate this, it would be best to do it
> soon and publicize it before it comes into wide use.

Has any tool vendor actually implemented configurations yet?


From: Krishna Garlapati <krishna@synplicity.com>
To: sharp@cadence.com
Cc: etf-bugs@boyd.com
Subject: Re: enhancement/350: Proposal to deprecate configs in Verilog source
files
Date: Tue, 20 May 2003 09:58:22 -0700

This is a very neat idea. Seperating link info from source code
makes most practical sense.

- Krishna.

sharp@cadence.com wrote:

>Precedence: bulk
>
>
>
>
>>Number: 350
>>Category: enhancement
>>Originator: sharp@cadence.com
>>Environment:
>>
>>
>
>
>
>>Description:
>>
>>
>
>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.
>
>The main reason for proposing this is that configs use
>a lot of reserved keywords that can create backward
>compatibility problems for existing designs. A test on
>a large set of real customer designs indicated that 15%
>of them would not compile with these keywords reserved.
>And before anyone suggests context-sensitive keywords
>(blech!), the main offender was the keyword "config",
>which marks the start of the context and therefore
>can't be context-sensitive.
>
>The idea of having configs in the source code presumably
>came from VHDL. Most experienced Verilog people I have
>consulted agree that Verilog source files should only
>contain real Verilog source, and that configs should be
>put in a side file. The existing standard already allows
>for them to be put into the library map file, which fits
>that description nicely.
>
>Nor is putting configs in the Verilog source file the
>most beneficial use model. If you want to change what are
>effectively "link" options, you don't want to have to
>change and recompile the source code each time. My
>inquiries indicate that VHDL users most often supply
>configs in separate files, usually generated by tools
>and at most tweaked by hand. So this seems to be the
>most natural way of using them anyway.
>
>If we do deprecate this, it would be best to do it
>soon and publicize it before it comes into wide use.
>
>
>
>

--
- Krishna Garlapati, Synplicity Inc. (408)215-6152



From: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com, Shalom.Bresticker@motorola.com
Cc:
Subject: Re: enhancement/350: Proposal to deprecate configs in Verilog source files
Date: Tue, 20 May 2003 17:22:36 -0400 (EDT)

> Has any tool vendor actually implemented configurations yet?

I am not aware of any implementations, but that doesn't guarantee
anything. Cliff's DVCon paper shows none of the simulators he
tested supported configurations at that time.

The next major release of NC-Verilog will support configurations,
but only in the library mapping file, for the reasons given.

Steven Sharp
sharp@cadence.com

From: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com
Cc:
Subject: enhancement/350: BNF issues
Date: Thu, 6 May 2004 17:09:32 -0400 (EDT)

I was looking at the BNF to see what would need to be changed to restrict
configs to library mapping files. I discovered that the BNF already doesn't
seem to allow configs in Verilog source. And this single grammar seems to
be trying to define two different languages at the same time.

It is not clear in the BNF what the starting nonterminal for the language is.
Normally this would be the first nonterminal defined. In this case, that is
library_text. But if you follow that down, you find that it defines the
language of library mapping files. This is not Verilog. Library declarations
are not allowed in Verilog source, and you can't get to Verilog source
starting from library_text.

The starting nonterminal for Verilog appears to be source_text, which makes
sense and matches the BNF in the 1995 standard. This needs to be the first
nonterminal in the grammar, or the Annex needs to state that it is the
starting nonterminal for the Verilog language.

It looks to me like the simplest solution would be to state at the top of
the Annex that the Verilog language is derived from the starting nonterminal
source_text, and that library mapping file syntax is derived from the
starting nonterminal library_text.

Should I file this as a separate erratum, or fold it into the changes for
this enhancement request?

Note that if you follow the BNF, you can get to a config_declaration from
library_text, but you cannot get to it from source_text. So the BNF already
says that configs are not allowed in Verilog source, only in library mapping
files. No BNF changes are specifically required for this enhancement.

Steven Sharp
sharp@cadence.com

From: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com
Cc:
Subject: enhancement/350: PROPOSAL - Deprecate configs in Verilog source
Date: Tue, 11 May 2004 15:24:22 -0400 (EDT)

Proposal to allow configs only in the library mapping file. The changes for
this are not extensive, since there is no text that states that configs can
appear in Verilog source, and only a few sentences that imply it. The BNF
never actually allowed it.

I used <angle-brackets> to show keywords that should be bold.


In 13.1 REPLACE

As evidenced by the <config>-<endconfig> syntax, the config is a design
element, similar to a module, which exists in the Verilog namespace.
The config contains a set of rules which are applied when searching
for a source description to bind to a particular instance of the design.

WITH

A config definition shall be enclosed between the keywords <config>
and <endconfig>. The identifier following the keyword <config> shall
be the name of the config. The config is a design element containing
a set of rules which are applied when searching for a source description
to bind to a particular instance in the design.

A config shall not appear in a Verilog source description. It shall
appear only in a library mapping file (see 13.2.1).

Note - IEEE Std 1364-2001 did not state that configs could not appear
in Verilog source descriptions, implying that they could.


In 13.2.1 REPLACE

The syntax for declaring a library in the library map file is shown
in Syntax 13.2.

WITH

The syntax for declaring a library in the library map file is shown
in Syntax 13.2.

The library mapping file has a syntax which is distinct from the
syntax of Verilog source files. It uses some keywords which are not
considered keywords in Verilog HDL (<cell>, <config>, <design>,
<endconfig>, <include>, <instance>, <liblist>, <library>, <use>).
A library mapping file can still reference a cell name that matches a
library mapping file keyword by using an escaped identifier (see 2.7.1).


In 13.4.4 REPLACE

In the single-pass use-models, the config can be specified by including
its source description on the command line.

WITH

In the single-pass use-models, the config can be specified by including
it in the library mapping file.


In 13.4.4 REPLACE

In this strategy, the config itself shall also be precompiled.

WITH

In this strategy, a specified config can be obtained from the library
mapping file, or the tool can provide a mechanism for precompiling
configs into a library like other cells.


In Annex A, under "Formal syntax definition", REPLACE

The formal syntax of Verilog HDL is described using Backus-Naur Form (BNF).

WITH

The formal syntax of Verilog HDL is described using Backus-Naur Form (BNF).
The syntax of Verilog HDL is derived from the starting symbol source_text.
The syntax of a library mapping file is derived from the starting symbol
library_text.


In Annex B, under "List of keywords", REPLACE

An escaped identifier shall not be treated as a keyword.

WITH

An escaped identifier shall not be treated as a keyword.

These are the keywords for Verilog HDL:


From the keyword list, DELETE

<cell>, <config>, <design>, <endconfig>, <incdir>, <include>,
<instance>, <liblist>, <library>, <use>


After the keyword list, ADD

These are the keywords for a library mapping file:

<cell>, <config>, <default>, <design>, <endconfig>, <include>,
<instance>, <liblist>, <library>, <use>


Note that <default> appears in the library mapping file keywords, but
is not removed from the Verilog HDL keywords. It is a keyword in both.
The keyword <incdir> is removed from the Verilog HDL keywords, but is
not added to the library mapping file keywords. This is because the
syntax does not appear to require reserving <incdir> because it always
appears after a hyphen. However, it could still be added to the list
of library mapping file keywords if desired.



From: Shalom Bresticker <Shalom.Bresticker@freescale.com>
To: Steven Sharp <sharp@cadence.com>
Cc: btf-bugs@boyd.com
Subject: Re: enhancement/350: PROPOSAL - Deprecate configs in Verilog source
Date: Wed, 12 May 2004 13:00:26 +0300

> The keyword <incdir> is removed from the Verilog HDL keywords, but is
> not added to the library mapping file keywords. This is because the
> syntax does not appear to require reserving <incdir> because it always
> appears after a hyphen. However, it could still be added to the list
> of library mapping file keywords if desired.

This is related to the question of whether white space is allowed between
the hyphen and <incdir>. If not, what is the lexical token here?

Shalom


From: Steven Sharp <sharp@cadence.com>
To: sharp@cadence.com, Shalom.Bresticker@freescale.com
Cc: btf-bugs@boyd.com
Subject: Re: enhancement/350: PROPOSAL - Deprecate configs in Verilog source
Date: Wed, 12 May 2004 16:41:01 -0400 (EDT)

>> The keyword <incdir> is removed from the Verilog HDL keywords, but is
>> not added to the library mapping file keywords. This is because the
>> syntax does not appear to require reserving <incdir> because it always
>> appears after a hyphen. However, it could still be added to the list
>> of library mapping file keywords if desired.
>
>This is related to the question of whether white space is allowed between
>the hyphen and <incdir>. If not, what is the lexical token here?

Agreed. If no white space is allowed, then the token is <-incdir> and
<incdir> is not a reserved word. If white space is allowed, then the
tokens are the hyphen and <incdir>, which is presumably a reserved word.

I don't know where the hyphen syntax came from or why the hyphen is there
(and the LRM doesn't even say what -incdir means). The <library> syntax
looks like a command line in a script, while the config syntax looks more
Verilog-like.

If we assume that it is based on Unix command line syntax, then no white
space would be allowed after the hyphen. The BNF seems to imply that it
is all one token also.

Steven Sharp
sharp@cadence.com

From: "Jayaram Bhasker" <JBhasker@eSilicon.com>
To: "Shalom Bresticker" <Shalom.Bresticker@freescale.com>, <etf-bugs@boyd.com>
Cc:
Subject: RE: enhancement/350: PROPOSAL - Deprecate configs in Verilog source
Date: Wed, 12 May 2004 09:14:51 -0400

If configs are limited to occur in library map files, how would configs be referenced
within configs? Is the idea not to allow a config to reference other configs?

In the current config definition, a config can be in a file, the file is compiled
into a library and the library.config can be referenced in another config.

regards,
- bhasker


-----Original Message-----
From: Shalom Bresticker [mailto:Shalom.Bresticker@freescale.com]
Sent: Wednesday, May 12, 2004 5:50 AM
To: etf-bugs@boyd.com
Subject: Re: enhancement/350: PROPOSAL - Deprecate configs in Verilog
source


The following reply was made to PR enhancement/350; it has been noted by GNATS.

From: Shalom Bresticker <Shalom.Bresticker@freescale.com>
To: Steven Sharp <sharp@cadence.com>
Cc: btf-bugs@boyd.com
Subject: Re: enhancement/350: PROPOSAL - Deprecate configs in Verilog source
Date: Wed, 12 May 2004 13:00:26 +0300

> The keyword <incdir> is removed from the Verilog HDL keywords, but is
> not added to the library mapping file keywords. This is because the
> syntax does not appear to require reserving <incdir> because it always
> appears after a hyphen. However, it could still be added to the list
> of library mapping file keywords if desired.

This is related to the question of whether white space is allowed between
the hyphen and <incdir>. If not, what is the lexical token here?

Shalom

From: "Brophy, Dennis" <dennisb@model.com>
To: Jayaram Bhasker <JBhasker@esilicon.com>, etf-bugs@boyd.com
Cc:
Subject: RE: enhancement/350: PROPOSAL - Deprecate configs in Verilog sour
ce
Date: Thu, 13 May 2004 08:29:51 -0700

All,

I think it is a bad idea to regress behavior that is already supported in 2001. Configs should not be restricted to only appear in library map files since this restriction was not in place for the 2001 spec.

Users have come to use configs in other places other than library map files and I am hard pressed to see how we can now rationalize it out of being used in other places moving forward.

-Dennis

-----Original Message-----
From: owner-etf@boyd.com [mailto:owner-etf@boyd.com] On Behalf Of Jayaram Bhasker
Sent: Wednesday, May 12, 2004 3:50 PM
To: etf-bugs@boyd.com
Subject: RE: enhancement/350: PROPOSAL - Deprecate configs in Verilog source

The following reply was made to PR enhancement/350; it has been noted by GNATS.

From: "Jayaram Bhasker" <JBhasker@eSilicon.com>
To: "Shalom Bresticker" <Shalom.Bresticker@freescale.com>, <etf-bugs@boyd.com>
Cc:
Subject: RE: enhancement/350: PROPOSAL - Deprecate configs in Verilog source
Date: Wed, 12 May 2004 09:14:51 -0400

If configs are limited to occur in library map files, how would configs be referenced within configs? Is the idea not to allow a config to reference other configs?

In the current config definition, a config can be in a file, the file is compiled into a library and the library.config can be referenced in another config.

regards,
- bhasker


-----Original Message-----
From: Shalom Bresticker [mailto:Shalom.Bresticker@freescale.com]
Sent: Wednesday, May 12, 2004 5:50 AM
To: etf-bugs@boyd.com
Subject: Re: enhancement/350: PROPOSAL - Deprecate configs in Verilog source


The following reply was made to PR enhancement/350; it has been noted by GNATS.

From: Shalom Bresticker <Shalom.Bresticker@freescale.com>
To: Steven Sharp <sharp@cadence.com>
Cc: btf-bugs@boyd.com
Subject: Re: enhancement/350: PROPOSAL - Deprecate configs in Verilog source
Date: Wed, 12 May 2004 13:00:26 +0300

> The keyword <incdir> is removed from the Verilog HDL keywords, but is
> not added to the library mapping file keywords. This is because the
> syntax does not appear to require reserving <incdir> because it always
> appears after a hyphen. However, it could still be added to the list
> of library mapping file keywords if desired.

This is related to the question of whether white space is allowed between
the hyphen and <incdir>. If not, what is the lexical token here?

Shalom


From: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com, JBhasker@esilicon.com
Cc:
Subject: RE: enhancement/350: PROPOSAL - Deprecate configs in Verilog source
Date: Fri, 14 May 2004 17:32:16 -0400 (EDT)

Bhasker,

First, thanks for commenting on the details of the proposal. I want to
be sure that I'm not missing something.

> If configs are limited to occur in library map files, how would configs be
referenced
> within configs? Is the idea not to allow a config to reference other configs?

The proposal would still allow configs to reference other configs. I am
assuming that your issue is with the library portion of the config reference,
and how that would be specified for a config in a library map file.

Note that configs were allowed in library map files already, so this issue
was already present. Perhaps your assumption was that a config in the
library mapping file couldn't be referenced in another config. Maybe that
is even what was intended. The section isn't very clear.


> In the current config definition, a config can be in a file, the file is
compiled
> into a library and the library.config can be referenced in another config.

It was not clear to me whether this was possible in all use models (see 13.4)
or only with separate compilation. In 13.4.4, it says that "In the
single-pass use-models, the config can be specified by including its source
description file on the command line. In the case where the config includes
a design statement, then the specified cell shall be the top-level module..."

Note that this description seems to assume that there is only one config in
the source being compiled. That one config specifies the top-level cell. It
does not seem to allow for multiple configs, since it provides no rule for
determining which config's design rule to use for the top-level cell if there
are multiple configs. If this is the case, then a config cannot contain a
reference to another config in this use model.

There could be extended versions of this single-pass use model that allow
multiple configs, with one referencing others. There needs to be a rule for
determining which is the top-level config. Perhaps this could be an implicit
rule similar to the one for determining top-level modules. Or the tool could
allow the top-level cell to be specified explicitly on the command line.

This still leaves the issue of how to reference a config that is in the
library mapping file being read in this invocation, i.e. what is its library
name. That issue already existed for configs in the library mapping file.
It just becomes more important with this proposal. I don't know whether it
makes sense to apply the library mapping rules to the filename of the library
mapping file itself. If not, I would expect that since none of the mappings
were applied, the config would be considered to be in the default library,
which is named work.

Regardless, a config in a library mapping file could refer to another config
in the same library mapping file by leaving off the library identifier. By
section 13.3.1.1, "If the library identifier is omitted, then the library
which contains the config shall be used to search for the cell." Regardless
of what library the config is supposed to be in, the other config will be in
the same library, so this should work.

Now let me move on to the separate compilation use model, which is probably
the one you were really concerned with. Here my proposal was probably
unclear. In 13.4.4, the proposal says:

In this strategy, a specified config can be obtained from the library
mapping file, or the tool can provide a mechanism for precompiling
configs into a library like other cells.

My intent was to allow these tools to do what you described: compile the
configs into a library so the library.config can be referenced in another
config. The change is that the files containing these configs would not
be Verilog HDL source files, but separate files containing configs.

I think I created confusion by referring to these files as "library map
files". I meant input files that have the syntax of a library map file
instead of the syntax of Verilog HDL. As stated in 13.2.1, a tool shall
provide a mechanism to read in multiple library mapping files (which means
that the tool knows that these files contain library mapping syntax).
Unfortunately, the name implies that their main purpose is to provide the
library mappings for a particular invocation. But in a separate compilation
use model with a mechanism for precompiling configs, such a file might
contain only configs, which are being compiled into a library for later
reference, possibly in another config.

So a separate compilation use model could allow compilation of Verilog
HDL files into the libraries, and compilation of configs (in so-called
library mapping files) into the libraries. As stated in 13.2.1, there
would be some tool-specific mechanism for specifying library mapping
files, so the tool would know which it was compiling. However, 13.2.1
implies that reading the library mapping files is a kind of set-up step
to get library mappings before starting "real" compilation of Verilog HDL.
This obscures the possibility that compiling the configs from the library
mapping files into a library might be the primary purpose of this
invocation of the tool.

Does this make my intent clear? If so, does my intended meaning allow
the capability that you were asking about (assuming that a tool supports
this particular use model, which it was never required to do)?

Is there some particular way that this could be re-worded to make the
intent clearer?

Steven Sharp
sharp@cadence.com

From: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com, dennisb@model.com
Cc:
Subject: RE: enhancement/350: PROPOSAL - Deprecate configs in Verilog sour ce
Date: Fri, 14 May 2004 21:34:12 -0400 (EDT)

Dennis,

Your concern may be partly due to unclear wording in my proposal, which
may have made it seem more restrictive than I intended.

You wrote:

> Users have come to use configs in other places other than library map files
and I am hard pressed to see how we can now rationalize it out of being used in
other places moving forward.

As I pointed out in my response to Jayaram Bhasker's comments, any file
containing configs could be regarded as a library map file and fed into
a tool as such. As long as users have kept configs in separate files from
their Verilog source, they can provide them to the tools as library map
files instead of Verilog source files. My proposal explicitly allowed for
the possibility that tools could compile configs from these library map
files into libraries, just as they could have if they were allowed in
Verilog source files.

The only restriction that this imposes is that configs cannot be combined
with Verilog HDL source in the same file. My VHDL contacts tell me that
VHDL configs are almost invariably kept in separate files. There are
reasons why it is generally undesirable to keep them in the same files
as the HDL source.

I agree that it is a question of what will cause the least hardship for
users. I believe that configs are still implemented in very few tools at
this point. As a result, very few users are probably using them yet. If
they have used them the way VHDL users do, only a tiny fraction of those
would have combined them with Verilog source in the same file. This means
that the restrictions from this proposal would have minimal impact on users.

On the other hand, reserving the config keywords in Verilog source causes
15% of the customer designs in our customer test suite to fail to compile.
Assuming that this is representative of designs out there, there is a lot
of legacy code out there that would need to be modified or handled specially.

I believe that this proposal is in the best interests of Verilog users
overall. Now that I have clarified the amount of restriction that it
actually involves, perhaps you will agree. If you have contact with users
who would be negatively impacted by this change, please encourage them to
contact us and tell us about it.

Steven Sharp
sharp@cadence.com

From: "Brophy, Dennis" <dennisb@model.com>
To: Steven Sharp <sharp@cadence.com>, etf-bugs@boyd.com
Cc:
Subject: RE: enhancement/350: PROPOSAL - Deprecate configs in Verilog sour
ce
Date: Sun, 16 May 2004 22:10:51 -0700

Steven,

I don't agree.

I see no need to regress from the approved IEEE Std. 1364-2001 specification.

With all due respect, config is being supported and used in a manner which you wish to deprecate. I don't think this is wise. And pointing to the fact that you may not have an implementation of the same is no reason to support a change. It only shows your lack of interest in the standard or ability to support it.

Users have this option today, are using it and can create their own coding rules if they wish to enforce restricted use. There is no reason to restrict the combination of config in Verilog source files. This is permitted today. It is supported today. It is used today.

I think your motivation is clear. In these technical forums you have publicly stated your next product release has limitations that would render it to still not comply with the Verilog-2001 specification unless you can change the specification in Verilog-2005 per what is proposed. (See: http://www.boyd.com/1364_btf/report/full_pr/350.html)

I think I see your motivation and I don't think it has a place here.

-Dennis

-----Original Message-----
From: owner-etf@boyd.com [mailto:owner-etf@boyd.com] On Behalf Of Steven Sharp
Sent: Friday, May 14, 2004 6:20 PM
To: etf-bugs@boyd.com
Subject: RE: enhancement/350: PROPOSAL - Deprecate configs in Verilog sour ce

The following reply was made to PR enhancement/350; it has been noted by GNATS.

From: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com, dennisb@model.com
Cc:
Subject: RE: enhancement/350: PROPOSAL - Deprecate configs in Verilog sour ce
Date: Fri, 14 May 2004 21:34:12 -0400 (EDT)

Dennis,

Your concern may be partly due to unclear wording in my proposal, which may have made it seem more restrictive than I intended.

You wrote:

> Users have come to use configs in other places other than library map files and I am hard pressed to see how we can now rationalize it out of being used in other places moving forward.

As I pointed out in my response to Jayaram Bhasker's comments, any file containing configs could be regarded as a library map file and fed into a tool as such. As long as users have kept configs in separate files from their Verilog source, they can provide them to the tools as library map files instead of Verilog source files. My proposal explicitly allowed for the possibility that tools could compile configs from these library map files into libraries, just as they could have if they were allowed in Verilog source files.

The only restriction that this imposes is that configs cannot be combined with Verilog HDL source in the same file. My VHDL contacts tell me that VHDL configs are almost invariably kept in separate files. There are reasons why it is generally undesirable to keep them in the same files as the HDL source.

I agree that it is a question of what will cause the least hardship for users. I believe that configs are still implemented in very few tools at this point. As a result, very few users are probably using them yet. If they have used them the way VHDL users do, only a tiny fraction of those would have combined them with Verilog source in the same file. This means that the restrictions from this proposal would have minimal impact on users.

On the other hand, reserving the config keywords in Verilog source causes 15% of the customer designs in our customer test suite to fail to compile.
Assuming that this is representative of designs out there, there is a lot of legacy code out there that would need to be modified or handled specially.

I believe that this proposal is in the best interests of Verilog users overall. Now that I have clarified the amount of restriction that it actually involves, perhaps you will agree. If you have contact with users who would be negatively impacted by this change, please encourage them to contact us and tell us about it.

Steven Sharp
sharp@cadence.com


From: "Jayaram Bhasker" <JBhasker@eSilicon.com>
To: "Steven Sharp" <sharp@cadence.com>, <etf-bugs@boyd.com>
Cc:
Subject: RE: enhancement/350: PROPOSAL - Deprecate configs in Verilog source
Date: Mon, 17 May 2004 14:28:20 -0400

Steven:

Thanks for the clarification. And yes, you are right - i was objecting to the
fact that configs have to be declared in library map files.

To me, the intent of configs have been clear - allow indirect binding of instances
(similar to VHDL).
Also Sec 13.1 states "... a config is a design element, similar to a module, which
exists in the Verilog namespace . .". Even though, I agree that the BNF is not complete,
I believe the intention was to allow config declarations as part of the Verilog source.
So a file can contain many modules, and config declarations; all
of these design elements get compiled into a library (specified by the library map file
for that file) and user simulates the appropriate top, could be either a config or a
module. At least, this has been my interpretation of the LRM.

Deprecating a newly added "standard" feature is not a straightforward task. I suggest:

1. Retain the current functionality and fix bugs (and state limitations if any), and
2. Suggest modeling style to write each config in a separate file (as Verilog HDL source)
and state advantages.

regards,
- bhasker

eSilicon Corporation
1605 N. Cedar Crest Blvd, Ste 615, Allentown, PA 18104
e-mail: jbhasker@esilicon.com, phone: 610.439.6831, fax: 610.770.9634(fax)




-----Original Message-----
From: Steven Sharp [mailto:sharp@cadence.com]
Sent: Friday, May 14, 2004 5:32 PM
To: etf-bugs@boyd.com; Jayaram Bhasker
Subject: RE: enhancement/350: PROPOSAL - Deprecate configs in Verilog
source


Bhasker,

First, thanks for commenting on the details of the proposal. I want to
be sure that I'm not missing something.

> If configs are limited to occur in library map files, how would configs be
referenced
> within configs? Is the idea not to allow a config to reference other configs?

The proposal would still allow configs to reference other configs. I am
assuming that your issue is with the library portion of the config reference,
and how that would be specified for a config in a library map file.

Note that configs were allowed in library map files already, so this issue
was already present. Perhaps your assumption was that a config in the
library mapping file couldn't be referenced in another config. Maybe that
is even what was intended. The section isn't very clear.


> In the current config definition, a config can be in a file, the file is
compiled
> into a library and the library.config can be referenced in another config.

It was not clear to me whether this was possible in all use models (see 13.4)
or only with separate compilation. In 13.4.4, it says that "In the
single-pass use-models, the config can be specified by including its source
description file on the command line. In the case where the config includes
a design statement, then the specified cell shall be the top-level module..."

Note that this description seems to assume that there is only one config in
the source being compiled. That one config specifies the top-level cell. It
does not seem to allow for multiple configs, since it provides no rule for
determining which config's design rule to use for the top-level cell if there
are multiple configs. If this is the case, then a config cannot contain a
reference to another config in this use model.

There could be extended versions of this single-pass use model that allow
multiple configs, with one referencing others. There needs to be a rule for
determining which is the top-level config. Perhaps this could be an implicit
rule similar to the one for determining top-level modules. Or the tool could
allow the top-level cell to be specified explicitly on the command line.

This still leaves the issue of how to reference a config that is in the
library mapping file being read in this invocation, i.e. what is its library
name. That issue already existed for configs in the library mapping file.
It just becomes more important with this proposal. I don't know whether it
makes sense to apply the library mapping rules to the filename of the library
mapping file itself. If not, I would expect that since none of the mappings
were applied, the config would be considered to be in the default library,
which is named work.

Regardless, a config in a library mapping file could refer to another config
in the same library mapping file by leaving off the library identifier. By
section 13.3.1.1, "If the library identifier is omitted, then the library
which contains the config shall be used to search for the cell." Regardless
of what library the config is supposed to be in, the other config will be in
the same library, so this should work.

Now let me move on to the separate compilation use model, which is probably
the one you were really concerned with. Here my proposal was probably
unclear. In 13.4.4, the proposal says:

In this strategy, a specified config can be obtained from the library
mapping file, or the tool can provide a mechanism for precompiling
configs into a library like other cells.

My intent was to allow these tools to do what you described: compile the
configs into a library so the library.config can be referenced in another
config. The change is that the files containing these configs would not
be Verilog HDL source files, but separate files containing configs.

I think I created confusion by referring to these files as "library map
files". I meant input files that have the syntax of a library map file
instead of the syntax of Verilog HDL. As stated in 13.2.1, a tool shall
provide a mechanism to read in multiple library mapping files (which means
that the tool knows that these files contain library mapping syntax).
Unfortunately, the name implies that their main purpose is to provide the
library mappings for a particular invocation. But in a separate compilation
use model with a mechanism for precompiling configs, such a file might
contain only configs, which are being compiled into a library for later
reference, possibly in another config.

So a separate compilation use model could allow compilation of Verilog
HDL files into the libraries, and compilation of configs (in so-called
library mapping files) into the libraries. As stated in 13.2.1, there
would be some tool-specific mechanism for specifying library mapping
files, so the tool would know which it was compiling. However, 13.2.1
implies that reading the library mapping files is a kind of set-up step
to get library mappings before starting "real" compilation of Verilog HDL.
This obscures the possibility that compiling the configs from the library
mapping files into a library might be the primary purpose of this
invocation of the tool.

Does this make my intent clear? If so, does my intended meaning allow
the capability that you were asking about (assuming that a tool supports
this particular use model, which it was never required to do)?

Is there some particular way that this could be re-worded to make the
intent clearer?

Steven Sharp
sharp@cadence.com


From: Steven Sharp <sharp@cadence.com>
To: sharp@cadence.com, etf-bugs@boyd.com, JBhasker@eSilicon.com
Cc:
Subject: RE: enhancement/350: PROPOSAL - Deprecate configs in Verilog source
Date: Wed, 19 May 2004 21:40:33 -0400 (EDT)

Bhasker,

>Also Sec 13.1 states "... a config is a design element, similar to a module,
which
>exists in the Verilog namespace . .".

The second half of this statement is misleading or wrong, since 13.1.1 talks
about the case where a config has the same name as a module, which would not
be possible if they existed in the same namespace. That is why I removed
this statement in my proposal.

At any rate, satisfying this statement does not require that configs be in
the same files as modules. Modules from one kind of files (Verilog source)
and configs from another kind of file (library mapping files) can still be
compiled into the same design libraries. In fact, the current text already
requires compiling configs from the non-Verilog library mapping files.


> Even though, I agree that the BNF is not complete,
>I believe the intention was to allow config declarations as part of the Verilog
source.

I agree. An interpretation based solely on the LRM text might conclude
that they are not allowed already. However, I am not trying to make such
a legalistic argument. I believe that the intent was to allow them,
regardless of what the BNF says. I also believe that allowing them is a
bad idea.


>So a file can contain many modules, and config declarations; all
>of these design elements get compiled into a library (specified by the library
map file
>for that file) and user simulates the appropriate top, could be either a config
or a
>module. At least, this has been my interpretation of the LRM.

Aside from having modules and config declarations in the same file, this
proposal does not change any of that.


>Deprecating a newly added "standard" feature is not a straightforward task.

I would have thought that a newly added feature was the easiest kind to
deprecate. It may be more embarassing, but that isn't as important as
fixing problems.


> I suggest:
>
>1. Retain the current functionality and fix bugs (and state limitations if
any), and
>2. Suggest modeling style to write each config in a separate file (as Verilog
HDL source)
> and state advantages.

Suggested modeling styles don't solve the most serious problem. As long as
configs are allowed in Verilog source files, the config keywords have to be
reserved in Verilog HDL. That creates a serious backward compatibility
problem for legacy Verilog code. 15% of the customer designs in our suite
will not compile in Verilog-2001 if these particular keywords are reserved.
If that is typical of legacy Verilog code, I think the impact on the Verilog
user community is severe enough to justify making this change.

I have pointed out other issues with this modeling style mainly to show
that users wouldn't be losing much.

Steven Sharp
sharp@cadence.com

From: "Brad Pierce" <Brad.Pierce@synopsys.com>
To: <etf-bugs@boyd.com>
Cc:
Subject: Re: enhancement/350: Proposal to deprecate configs in Verilog source files
Date: Wed, 6 Apr 2005 14:38:42 -0700

Steven

You write --
>Verilog-2001 allows configs to appear in either Verilog
>source files, or the library map file.

The current BNF doesn't allow this.

-- Brad




From: Shalom.Bresticker@freescale.com
To: Brad Pierce <Brad.Pierce@synopsys.com>
Cc: etf-bugs@boyd.com
Subject: Re: enhancement/350: Proposal to deprecate configs in Verilog source
files
Date: Thu, 7 Apr 2005 05:52:12 +0300 (IDT)

The BNF may seem to not allow it,
but some users and vendors have interpreted the LRM to not forbid it,
and they have done it.

Even Steven wrote that he believes the original intention was to allow it.
(See May 19, 2004 mail (exactly one year after the original submission!))

Shalom


On Wed, 6 Apr 2005, Brad Pierce wrote:

> The following reply was made to PR enhancement/350; it has been noted by GNATS.
>
> From: "Brad Pierce" <Brad.Pierce@synopsys.com>
> To: <etf-bugs@boyd.com>
> Cc:
> Subject: Re: enhancement/350: Proposal to deprecate configs in Verilog source files
> Date: Wed, 6 Apr 2005 14:38:42 -0700
>
> Steven
>
> You write --
> >Verilog-2001 allows configs to appear in either Verilog
> >source files, or the library map file.
>
> The current BNF doesn't allow this.
>
> -- Brad
>
>
>
>
>

--
Shalom.Bresticker @freescale.com Tel: +972 9 9522268
Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478

[ ]Freescale Internal Use Only [ ]Freescale Confidential Proprietary


Fix replaced by Tom_Fitzpatrick@mentor.com on Mon Apr 11 14:18:21 2005
"Shalom voiced concern that approval of this proposal might change an affirmative vote to a negative.
Action Item: Steve Sharp to compose proposal to resolve ambiguity and disallow configs in Verilog source, and to propose (as an informative note) a command line option to specify the configuration file.
Proposal will also include two keyword lists: one for Verilog source and one for Library mapping files. This will be two subsections in Annex B.
Tom - ok to add into source files.
- tell vendor where config files reside if outside the design files.
Cliff - doesn't want to deal with incompatible switches from dif vendors
Stu - command line switches now part of p1800 text (see appendix g)
- have a note to specify a recommended option to specify config files.
Mark - need to ensure it doesn't conflict with existing vendor switches.
Stu: OK with separate file if there is a note with recommended command line option.
Cliff: -cfg might work"



Fix replaced by tom_fitzpatrick@mentor.com on Sun Apr 17 14:30:55 2005
"Shalom voiced concern that approval of this proposal might change an affirmative vote to a negative.
Action Item: Steve Sharp to compose proposal to resolve ambiguity and disallow configs in Verilog source, and to propose (as an informative note) a command line option to specify the configuration file.
Proposal will also include two keyword lists: one for Verilog source and one for Library mapping files. This will be two subsections in Annex B.
Tom - ok to add into source files.
- tell vendor where config files reside if outside the design files.
Cliff - doesn't want to deal with incompatible switches from dif vendors
Stu - command line switches now part of p1800 text (see appendix g)
- have a note to specify a recommended option to specify config files.
Mark - need to ensure it doesn't conflict with existing vendor switches.
Stu: OK with separate file if there is a note with recommended command line option.
Cliff: -cfg might work"


Unformatted



Hosted by Boyd Technology