libmap/config file interpretation/experience

From: Shalom.Bresticker@freescale.com
Date: Thu Apr 21 2005 - 12:17:48 PDT

  • Next message: Michael McNamara: "RE: [sv-ec] Re: [sv-bc] potential command line option"

    This seems to have bounced.

    Shalom

    -----Original Message-----
    Date: Thu, 21 Apr 2005 10:58:57 -0700
    From: Eric Olson <eolson@cisco.com>
    Subject: 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

    This archive was generated by hypermail 2.1.4 : Thu Apr 21 2005 - 11:54:35 PDT and
    sponsored by Boyd Technology, Inc.