config-endconfig in NC-Verilog

[Paul Uiterlinden]

I'm trying to use a configuration (config endconfig construct)
with NC-Verilog. The goal is to have multiple configurations
available in one library. Each configuration would bind a different
implementation to the DUT (RTL, post-synthesis netlist, post place
and route netlist).

In order to test the principle, I created a small example with a
top module instantiating a leaf module. This leaf module is bound
to a module from different libraries. So I have two configurations:

File top_cfg1.v:
config top_cfg1;
design work.top;
default liblist work;
cell leaf use lib1.leaf;
endconfig

File top_cfg2.v:
config top_cfg2;
design work.top;
default liblist work;
cell leaf use lib2.leaf;
endconfig

In ModelSim, this works like a charm.

In NC-Verilog, trying to compile a configuration gives:

$ ncvlog verilog/top_cfg1.v
ncvlog: 05.10-p004: (c) Copyright 1995-2003 Cadence Design Systems, Inc.
config top_cfg1;
|
ncvlog: *E,EXPMPA (verilog/top_cfg1.v,1|5): expecting the keyword
'module', 'macromodule' or 'primitive'[A.1].

It would seem that the new Verilog-2001 keywords are turned off with the
-v1995 switch, but that is not the case.

Does this version of ncvlog lack support of configurations? What is the
latest version of NCSIM anyway? (I cannot find that on the Cadence WEB
site)

Thanks.
Paul.

 

[Paul Uiterlinden]

sharp@cadence.com wrote:

Does this version of ncvlog lack support of configurations?

NC-Verilog version 5.1 supports configurations. However,
it only allows them in a library mapping file. It does
not allow them in Verilog source files. This should be
covered in the documentation.

I read that, and I already started to suspect what you say above.

I do not want a library mapping file, which, if I understand
correctly, says what files should be compiled into which libraries.
This is already taken care of by the compilation scripts (which
already exist, and are global for the project).

The Verilog-2001 LRM is actually unclear about whether
configs are allowed in Verilog source files. The text
implies that they are, but the language grammar or BNF
does not allow it. It only allows them in library
mapping files.

The original intent was actually to allow them in the
source files. However, we believe that this was a
bad idea. We have gotten considerable support for this
view in the committees, but there has been reluctance
to actually remove it. The committee consensus process
makes that difficult.

Coming back on ncvlog, is there a solution to my problem? What I want
is:

1) Different top level configurations stored in one libray
2) Have elaboration snapshots of these configurations in that library
3) Don't mess with different cds.lib files

All I really want is the same behavior of a VHDL configuration, but
then in Verilog. With ModelSim this seems possible, now don't tell me
it is not possible with ncvlog...

Paul.

 

[Pooja Maheswari]

Hi Paul,

You can define both library mappings (what files to compile in which dir)
and configs in
same file say "lib.map". And you can have top leavel config name as "cfg1"

Then use following command
"ncverilog +nclibmap+lib.map +work+{$work_dir} +nctop+cfg1 -c ${files}"

Here $files is list of all "*.v" files.

Hope this solve your problem.

Regards,
Pooja

Paul Uiterlinden wrote:

mpub@sohu.com wrote:
Why not use VHDL directly?

There's nothing that I'd rather do than doing just that, but it simply
is not an option. The complete design and testbench is in Verilog.

Not try to mix two language together. I think you can find another
method to solve you problem if you do not think it in VHDL but
implement it in VERILOG.

Hey, I did not start it, it's Verilog that started this!

I mean: VHDL constructs like generates and configurations have been
brought into the language. Now that I try to use one of them, it appears
it is not usable (at least not the implementation in NCSIM).

Paul.

 

Paul Uiterlinden wrote:

I do not want a library mapping file, which, if I understand
correctly, says what files should be compiled into which libraries.
This is already taken care of by the compilation scripts (which
already exist, and are global for the project).

Despite the name, library mapping files are not just for
mapping files into libraries. A file containing just a
config is a legal library mapping file. It is not clear
whether it is a legal Verilog source file. A library
mapping file (with or without any actual library mapping
information) is the one way that the standard definitely
allows providing a config to a tool. You can call it a
configuration file, if you like that name better.

Coming back on ncvlog, is there a solution to my problem? What I want
is:

1) Different top level configurations stored in one libray

I don't believe that NC-Verilog stores pre-compiled
configurations in a library. I believe that it reads
the configurations from your library mapping file at
the time when you elaborate. You can keep multiple
library mapping files (or configuration files) around,
and use the appropriate one for a particular elaboration.
You may find it strange that NC-Verilog pre-compiles
modules and not configs, but it is a valid use-model.

2) Have elaboration snapshots of these configurations in that library

You can certainly have elaboration snapshots produced
by different configs in the library. If you have used
different names for your different configs, I assume
that those will be used as the default snapshot names
when you elaborate them.

3) Don't mess with different cds.lib files

The cds.lib file is not a Verilog-2001 library mapping
file. It is a Cadence thing that was defined before
Verilog-2001, though the standardized library mapping
file was presumably based on it. Cadence also provided
configuration capabilities with something called 5.X
configurations, before configurations were standardized
in Verilog-2001.

At any rate, feeding in different library mapping files
should not require having different cds.lib files. It
does require having different library mapping files.
But even with pre-compiled configs, you have to have
multiple different files with different configs in
them. It is just a question of whether you have to
pre-compile them, or can just provide them during
elaboration.

All I really want is the same behavior of a VHDL configuration, but
then in Verilog.

I suppose that it depends on whether you insist that
pre-compiling configurations into persistent libraries
is an essential part of that behavior. You may be used
to that behavior, and therefore regard it as "right".
There may be minor advantages and disadvantages to
having configs be pre-compiled versus read at elaboration
time. But the basic capabilities are the same.

If you believe that being able to pre-compile configs
into a persistent library is an important capability,
you can request that as an enhancement. There is no
inherent reason that this couldn't be done in NC-Verilog.