RE: [sv-ec] Re: [sv-bc] potential command line option

From: Mark Hartoog <Mark.Hartoog_at_.....>
Date: Wed Apr 20 2005 - 14:10:05 PDT
You say that you were expecting the config and verilog syntax
to be separate, but were you expecting configurations to be
allowed only in library mapping files?

If you were expecting them only in library mapping files, how 
do you get a config into a logical library. As I describe in 
more detail in the attached email, the LRM says/implies:

1) configs only appear in library mapping files.
2) configs can be cells in logical libraries.
3) the library map file is NOT a source file
4) the library mapping in a libmap file applies to 
source files only.

This leaves no mechanism for specifying how a configuration
gets into a logical library.

It is clear to me that configs are part of the design, and therefore
should be in a "source file". The libmap file does not really look 
like a source file to me. It looks more like a tool/library setup file. 
I think it is a bad idea to mix tool setup information with design 
information in the same file.

Many people interested in using configs in Verilog are coming from a vhdl
background, where configs are part of the language and could appear in 
the same file as other vhdl. They may find it strange that Verilog has
a separate configuration language that is only allowed in separate files,
and I am sure they will find it strange if it is only allowed in libmap files.

I believe the current proposal creates a separate class of source files
for configurations, as well as allowing them in libmap files, and then 
recommends some command line options to specify to tools that the next 
file is a config source file rather than a verilog source file. Having 
to specify that extra option all the time looks inconvient to me. It means
I cannot do something like 

<tool-name> *.v <other_options>

You cannot even do 

<tool-name> *.v *.cfg <other_options> 

because you would need a command line option in front of every config file.

I don't really like that.


> Behalf Of Adam Krolnik
> Hi Randy;
> 
> A little history about configurations.
> 
> The BTF originally did not combine the configuration file 
> syntax with the verilog file syntax. That was done during 
> editing of the final specification. We were expecting that 
> the configuration file syntax and keywords was separate from 
> the verilog language syntax and keyword set.
> 
>    Thanks.
> 
> -- 
>      Adam Krolnik
>      ZSP Verification Mgr.
>      LSI Logic Corp.
>      Plano TX. 75074
>      Co-author "Assertion-Based Design"
> 

attached mail follows:


In the section on Hierarchical configurations the 1364-2001/1364-2005
LRMs say you can specify the following mapping:

instance top.a1.foo use lib1.foo:config;
// bind to the config foo in library lib1

This clearly implies that a config can be an "cell" in a library.

The BNF only allows configs in library mapping files. How would
you get the configs into a libraries? Would you name the library mapping
file in the wild card patterns so that its contents would be mapped 
into the library also? 

In the section on libraries (13.2.1 in 1364-2001) it says "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." This implies that library mapping files are NOT
source files.

In the section on "Mapping source files to libraries" (13.2.3 in 
1364-2001) it says "For each cell definition encountered during 
parsing/compiling, the name of the source file being parsed is
compared to the file path specifications of the library declarations 
in all of the library map files being used. The cell is mapped into 
the library whose file path specification matches the source file name."

This implies that library mapping only applies to source files, and
library map files are NOT source files. I don't see any way to get
a configuration into a library if configurations are not allowed 
in some kind of source file. 

I think the 1364-2001 LRM is inconsistent about where configuration may
appear. Either it was an error in the BNF that configurations can not 
appear in source files, or it was an error that configurations can be
cells that are in libraries.

I think we should allow configurations in libraries, so I think we should
say it was an error in the BNF. I don't like the idea of creating two 
classes of source files, normal verilog and config, but I suppose I can
live with that, if we have too.

> -----Original Message-----
> From: owner-btf@boyd.com [mailto:owner-btf@boyd.com] On 
> Behalf Of Shalom.Bresticker@freescale.com
> Sent: Tuesday, April 19, 2005 8:18 PM
> To: Steven Sharp
> Cc: btf@boyd.com; etf@boyd.com
> Subject: Re: [sv-bc] potential command line option
> 
> Just to be fair, I should point out that IEEE rules state 
> that where the standard is ambiguous, an interpretation needs 
> to allow the most liberal interpretation. This is because the 
> content of a standard is determined by what is written there, 
> not by what was intended to be written there, and here there 
> was not even an intent at that time.
> 
> Shalom
> 
> 
> > It is not clear that this would be a change to what is specified in 
> > 1364-2001.  The text doesn't state where configs can 
> appear, and the 
> > syntax boxes and BNF clearly specify that they cannot appear in 
> > Verilog source files.  This proposal could be viewed as an official 
> > interpretation with a corresponding clarification in the 
> LRM.  There 
> > has been no prior request for interpretation that would 
> conflict with 
> > this.  Supporting both 1364-2001 and 1364-2005 would not 
> require different behavior.
> 
> -- 
> 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
> 
Received on Wed Apr 20 14:10:23 2005

This archive was generated by hypermail 2.1.8 : Wed Apr 20 2005 - 14:10:45 PDT