libmap/config file interpretation/experience

I wanted to share some experience and my interpretation of the verilog 
2001/2005 Chapter 13 standards. We have been using libmap files and 
config blocks for the past 3-4 years for various in-house tools that 
parse the design tree. (single pass only) The tools and design 
environment have been through several generations to meet the needs of 
the designers. We tried our best to conform to the standard and be 
productive, but some thing are a little fuzzy.

Libmap files:
All Libmap files must be read at the beginning of a tool invocation. (or

else bindings may become incorrect) They may contain config blocks that 
belong to the default library. [in practice, config blocks in a libmap 
file are discouraged] We use a full verilog preprocessor (so -define 
statements from the command line can be used) [useful for very global 
defines, like ifdefs based on library versions]

If the library file_path_spec is:
filename: the file may need to get parsed to determine bindings
*.ext: matching files may need to be parsed to determine bindings if the

module name matches the wildcard.
Directory or other wildcard: matching files may need to be parsed if the

module name matches the base name and the extension matches the verilog 
LIBEXT
After several generations of asic design environments containing large 
amounts of reusable IP, teams tended to converge on having a shared 
common libmap file that included other libmap files (e.g. 
vendorX.libmap, blockA.libmap, etc)

Config files:
A config file is a file with libmap syntax, but contains only config 
blocks (no library statements) A config file can be read at any time and

a config block uses the same binding rules as normal verilog. Config 
blocks are in the same namespace and libraries as modules (except the 
module name is suffixed with ":config") [as per Syntax 13.1]

In practice, we used a config file LIBEXT (as well as a verilog LIBEXT) 
to help bind config/verilog to different files. [standard is unclear 
about this]

Like lib.map files, a full verilog preprocessor is used (same macro 
space as the verilog parser). This is very useful! Users treated config 
files as a set of properties that configured the design. Conceptually 
like preserving a group of command like arguments (e.g. top level 
modules, library search paths, verilog defines, etc)

Future idea: add attributes to config blocks so other configuration 
information can be included in a standard manner.

FYI - Internal extension to the standard: we allow wildcards in the 
liblist names, so unknown library names can be matched in the order they

are declared in the lib.map. (so changes to a Libmap don't require 
changes in the configurations)

I'm a little worried that removing the semi-colons in the libmap syntax 
may cause parser problems. Especially since the file_path_spec does not 
require double/single quotes. It is not clear if a directory named 
"library" could be allowed unless quotes are required. Speaking of 
quotes, there is also the troublesome:
library foo path/* not_comment_path/*/*.v ;

One more question:
The liblist behavior when there is no config block (or no ancestor is a 
config block) is to search the libraries in the order they are declared 
in the libmap file. [13.5.1] How do you force that behavior within a 
config block? (important when using config blocks to capture the 
configuration of a reusable IP block & combining simulations)

default liblist ; // ?

Dr. Eric Olson, internal cad @ Cisco Systems