Config Proposal for Draft 2 - GIFs for HTML include

From: Tom Fitzpatrick (tfitz@cadence.com)
Date: Fri Jan 29 1999 - 13:11:41 PST

Next message: Andrew T. Lynch: "Hierarchical Reference problems"
Previous message: Adam Krolnik: "BTF - B01 question"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Attachment Converted: "E:\INCOMING\draft2_gif.tar.gz"

---------------
Tom Fitzpatrick

Senior Technical Marketing Manager Cadence Design Systems, Inc.
Cycle Simulation Products 270 Billerica Rd.
Logic Design and Verification Business Unit Chelmsford, MA 01824
x6438 (978)446-6438From ???@??? Fri Jan 29 13:26:46 1999
Return-Path: <tfitz@cadence.com>
Received: from hub1.san-jose.webnexus.net (hub1-20.san-jose.webnexus.net [209.140.224.20])
        by gw.boyd.com (8.8.7/8.8.5) with ESMTP id NAA23847
        for <stefen@boyd.com>; Fri, 29 Jan 1999 13:22:12 -0800
Received: from mailgate.cadence.com (mailgate.Cadence.COM [158.140.2.1])
        by hub1.san-jose.webnexus.net (8.9.1a/8.8.5/WN-1.3) with ESMTP id NAA31024
        for <stefen@boyd.com>; Fri, 29 Jan 1999 13:08:57 -0800 (PST)
Received: (from smap@localhost) by mailgate.cadence.com (8.8.5/8.6.8) id NAA19447; Fri, 29 Jan 1999 13:07:41 -0800 (PST)
Received: from rowlf.Cadence.COM(158.140.104.39) by mailgate.cadence.com via smap (mjr-v1.2)
        id xma917644057.019429; Fri, 29 Jan 99 13:07:37 -0800
Received: (from tfitz@localhost)
        by rowlf.Cadence.COM (8.8.8/8.8.5) id QAA11958;
        Fri, 29 Jan 1999 16:07:33 -0500 (EST)
Date: Fri, 29 Jan 1999 16:07:33 -0500 (EST)
Message-Id: <199901292107.QAA11958@rowlf.Cadence.COM>
From: Thomas Fitzpatrick <tfitz@cadence.com>
To: stefen@boyd.com, cliffc@sunburst-design.com
Subject: Config Proposal for Draft 2 (HTML) - in progress
Status: RO
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML EXPERIMENTAL 970324//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="Adobe FrameMaker 5.5/HTML Export Filter">
<LINK REL="STYLESHEET" HREF="draft2.css">
<TITLE> Configuring the Contents of a Design</TITLE></HEAD>
<BODY BGCOLOR="#ffffff">
<DIV>
<H1 CLASS="Title">
<A NAME="pgfId=997482">
</A>
Configuring the Contents of a Design</H1>
<DIV>
<H2 CLASS="Heading1">
<A NAME="pgfId=1006051">
</A>
1. <A NAME="25206">
</A>
Introduction</H2>
<P CLASS="Body">
<A NAME="pgfId=1005996">
</A>
To facilitate both the sharing of Verilog designs between designers and/or design groups, and the repeatability of the exact contents of a given simulation (or other tool) session, we introduce the concept of configurations to the Verilog language. A configuration is simply an explicit set of rules to specify the exact source description to be used to represent each instance in a design. Example 1 shows a simple configuration problem. </P>
<PRE CLASS="Note"><A NAME="pgfId=1006004"> </A>
Example 1: </PRE>
<PRE CLASS="Note"><A NAME="pgfId=1006016"> </A>
file top.v file adder.v file adder.vg</PRE>
<PRE CLASS="Note"><A NAME="pgfId=1006005"> </A>
module top(); module adder(...); module adder(...);</PRE>
<PRE CLASS="Note"><A NAME="pgfId=1006006"> </A>
adder a1(...); // rtl adder description // gate-level adder description</PRE>
<PRE CLASS="Note"><A NAME="pgfId=1006007"> </A>
adder a2(...); ... ...</PRE>
<PRE CLASS="Note"><A NAME="pgfId=1006008"> </A>
endmodule endmodule endmodule</PRE>
<P CLASS="Body">
<A NAME="pgfId=1006009">
</A>
Suppose we wish to use the rtl adder description in adder.v for instance a1 in module top and the gate-level adder description in adder.vg for instance a2. In order to specify this particular set of instance bindings and to avoid having to change the source description to specify a new set, we introduce a new design element to Verilog: the configuration.</P>
<PRE CLASS="Note"><A NAME="pgfId=1006017"> </A>
config cfg1; // specify rtl adder for top.a1, gate-level adder for top.a2</PRE>
<PRE CLASS="Note"><A NAME="pgfId=1006018"> </A>
  design rtlLib.top;</PRE>
<PRE CLASS="Note"><A NAME="pgfId=1006022"> </A>
  default liblist rtlLib;</PRE>
<PRE CLASS="Note"><A NAME="pgfId=1006023"> </A>
  path top.a2 liblist gateLib;</PRE>
<PRE CLASS="Note"><A NAME="pgfId=1006024"> </A>
endconfig</PRE>
<P CLASS="BODY">
<A NAME="pgfId=1006025">
</A>
We will explain the elements of a config in the coming sections, but this simple example illustrates some important points about this new element. As evidenced by the config-endconfig syntax, the config is a design element, similar to a module, that exists in the Verilog namespace. The config contains a set of rules that are applied when searching for a source description to bind to a particular instance of the design.</P>
<P CLASS="BODY">
<A NAME="pgfId=1006026">
</A>
A Verilog design description starts with a top-level module (or modules), which is not instantiated elsewhere in the design. From this module's source description, the subinstances (or children) are found, and then the source descriptions for the module definitions of these subinstances must be located, and so on until every instance in the design is mapped to a source description. This mapping of an instances to a source descriptions is called "binding" an instance.</P>
<DIV>
<H3 CLASS="Heading2">
<A NAME="pgfId=1006613">
</A>
1.1 Library Notation</H3>
<P CLASS="BODY">
<A NAME="pgfId=1006031">
</A>
In order to map a Verilog instance to a source description, we introduce the concept of a library, which is simply a logical collection of design elements such as modules, macromodules, or primitives. We use the generic term cell to refer to these design elements. The cell name shall be the same as the name of the module/macromodule/udp/primitive/config being processed. In addition, since there may be multiple representations of a cell generated from a single source file (using macros, command-line arguments, etc.), or multiple versions of the same physical cell may exist in different source files (e.g. rtl and gate-level, etc.), the term view is used to refer to a particular version of the cell. We shall discuss views in more detail in <A HREF="draft2.html#17754" CLASS="XRef">
See Views.</A>
. To specify a particular view of a cell from a given library, we use the syntax shown here:</P>
<UL>
<P CLASS="Indented">
<A NAME="pgfId=1006032">
</A>
<library_name>.<cell_name>:<view_name></P>
</UL>
<P CLASS="BODY">
<A NAME="pgfId=1006033">
</A>
This notation gives us a symbolic method of referring to source descriptions, and we will go into greater detail in <A HREF="draft2.html#36460" CLASS="XRef">
See Specifying Libraries - The Library Map File.</A>
about the method of mapping source descriptions into libraries. </P>
<P CLASS="BODY">
<A NAME="pgfId=1007222">
</A>
For the purposes of this example, we shall simply state that the files top.v and adder.v, the rtl descriptions, have been mapped into the library rtlLib, and the file adder.vg, the gate-level description of the adder, has been mapped into the library gateLib. The default view has been used for all of these modules, so the viewname may be omitted from the configuration, as we have done.</P>
</DIV>
<DIV>
<H3 CLASS="Heading2">
<A NAME="pgfId=1006041">
</A>
1.2 Basic Configuration Elements</H3>
<P CLASS="BODY">
<A NAME="pgfId=1006618">
</A>
The design statement in example 1 specifies the top-level module in the design and what source description is to be used. In this example, the rtlLib.top notation indicates that the top-level module description shall be taken from rtlLib. Since top.v and adder.v were mapped to this library, the actual description for the module is known to come from top.v. </P>
<P CLASS="BODY">
<A NAME="pgfId=1006030">
</A>
The default statement coupled with the liblist clause specifies that, by default, all subinstances of top shall be taken from rtlLib, which means we shall use the descriptions in top.v and adder.v, which were mapped to this library. For a basic design, which may be completely rtl, this might be sufficient to specify completely the binding for the entire design. However, we wish to bind the top.a2 instance of adder to the gate-level description.</P>
<P CLASS="BODY">
<A NAME="pgfId=1006044">
</A>
The path statement specifies that, for the particular instance top.a2, the source description shall be taken from gateLib. Since adder.vg was mapped to gateLib, this statement dictates that the gate-level description in adder.vg be used for this instance.</P>
</DIV>
</DIV>
<DIV>
<H2 CLASS="Heading1">
<A NAME="pgfId=1006048">
</A>
2. Libraries</H2>
<P CLASS="Body">
<A NAME="pgfId=1006049">
</A>
As mentioned in the previous section, a library is a logical collection of cells that are mapped to particular source description files. The symbolic lib.cell:view notation supports the separate compilation of source files by providing a filesystem-independent name to refer to source descriptions when instances in a design are bound. It also allows multiple tools, which may have different invocation use-models, to share the same configuration.</P>
<DIV>
<H3 CLASS="Heading2">
<A NAME="pgfId=1006050">
</A>
2.1 <A NAME="36460">
</A>
Specifying Libraries - The Library Map File</H3>
<P CLASS="Body">
<A NAME="pgfId=1006068">
</A>
When parsing a source description file (or files), the parser must first read the library mapping information from a pre-defined file prior to reading any source files. The name of this file and the mechanism for reading it may be tool-specific. For the purposes of this discussion, we shall assume the existence of a file named lib.map in the current working directory, which is automatically read by the parser prior to parsing any source files specified on the command line. The syntax for declaring a library in the library map file is shown here:</P>
<UL>
<P CLASS="Indented">
<A NAME="pgfId=1006101">
</A>
library_declaration ::= <BR>
library <library_name> [<file_path_spec> [{,<file_path_spec>}]] [viewlist_spec];</P>
<P CLASS="Indented">
<A NAME="pgfId=1006102">
</A>
viewlist_spec ::= viewlist {<view_name>}</P>
<P CLASS="Indented">
<A NAME="pgfId=1006932">
</A>
file_path_spec ::= "file_path"</P>
<P CLASS="Indented">
<A NAME="pgfId=1006103">
</A>
NOTE: The file_path uses filesystem-specific notation to specify an absolute or relative path to a particular file or set of files. The following shortcuts/wildcards may be used:</P>
<P CLASS="Indented">
<A NAME="pgfId=1006106">
</A>
"?" - single character wildcard (matches any single character)</P>
<P CLASS="Indented">
<A NAME="pgfId=1006107">
</A>
"*" - multiple character wildcard (matches any number of characters in a directory/file name)</P>
<P CLASS="Indented">
<A NAME="pgfId=1006111">
</A>
"..." - hierarchical wildcard (matches any number of directories)</P>
<P CLASS="Indented">
<A NAME="pgfId=1006112">
</A>
".." - specifies the parent directory</P>
<P CLASS="Indented">
<A NAME="pgfId=1006113">
</A>
"." - specifies the current directory</P>
<P CLASS="Indented">
<A NAME="pgfId=1006150">
</A>
Paths that end in "/" shall include all files in the specified directory. Identical to "/*".</P>
</UL>
<P CLASS="Body">
<A NAME="pgfId=1006114">
</A>
If the file_path_spec is omitted from a library, then the specified library name shall be used as the default for all files that do not match any file_path_spec in another library definition. If more than one library definition is missing a file_path_spec, then the LAST library definition encountered in the lib.map file shall be used to define the default library name. By default, this default library shall be named "work."</P>
<P CLASS="BODY">
<A NAME="pgfId=1006130">
</A>
To perform the library mapping discussed in the example in Section 1, we would use the following library definitions in the lib.map file:</P>
<UL>
<P CLASS="Indented">
<A NAME="pgfId=1006131">
</A>
library rtlLib "./*.v"; // matches all files in the current directory with a ".v" suffix</P>
<P CLASS="Indented">
<A NAME="pgfId=1006132">
</A>
library gateLib "./*.vg"; // matches all files in the current directory with a ".vg" suffix</P>
</UL>
<DIV>
<H4 CLASS="Heading3">
<A NAME="pgfId=1006133">
</A>
<A NAME="41845">
</A>
File Path Resolution</H4>
<P CLASS="Body">
<A NAME="pgfId=1006134">
</A>
If a file name potentially matches multiple file path specifications, the path specifications shall be resolved in the following order:</P>
<OL>
<LI CLASS="Numbered1">
<A NAME="pgfId=1007061">
</A>
File path specifications that end with an explicit filename</LI>
<LI CLASS="Numbered">
<A NAME="pgfId=1007062">
</A>
File path specifications that end with a wildcarded filename</LI>
<LI CLASS="Numbered">
<A NAME="pgfId=1007063">
</A>
File path specifications that end with a directory</LI>
</OL>
<P CLASS="Body">
<A NAME="pgfId=1007059">
</A>
If a file name matches path specifications in multiple library definitions (after the above resolution rules have been applied), it shall be an error.</P>
<P CLASS="BODY">
<A NAME="pgfId=1006219">
</A>
Using these rules with the library definitions in the lib.map file, all source files encountered by the parser/compiler may be mapped to a unique library. Once the source descriptions have been mapped to libraries, the cells defined therein are available for binding.</P>
<UL>
<P CLASS="Indented">
<A NAME="pgfId=1006900">
</A>
Implementation Note: Tool implementers may find it convenient to provide a command-line argument to specify the library explicitly, which will override any library definitions in the lib.map file. If these libraries do not exist in the lib.map file, they may only be accessed via an explicit config. </P>
</UL>
</DIV>
</DIV>
<DIV>
<H3 CLASS="Heading2">
<A NAME="pgfId=1007110">
</A>
2.2 Using Multiple Library Mapping Files</H3>
<P CLASS="Body">
<A NAME="pgfId=1007111">
</A>
In addition to specifying library and view mapping information, a lib.map file may also include other lib.map files. The syntax of a lib.map file is limited to library and view specifications, include statements, and standard Verilog comment syntax.</P>
<UL>
<P CLASS="Indented">
<A NAME="pgfId=1007112">
</A>
include_statement ::= include <file_path_spec>;</P>
</UL>
<P CLASS="BODY">
<A NAME="pgfId=1007113">
</A>
If the file path specification describes a relative path, it shall be relative to the location of the file which contains the include statement.</P>
</DIV>
</DIV>
<DIV>
<H2 CLASS="Heading1">
<A NAME="pgfId=1006224">
</A>
3. <A NAME="17754">
</A>
Views</H2>
<P CLASS="Body">
<A NAME="pgfId=1006606">
</A>
As mentioned in Section 1, there are situations where it may be desirable to map multiple module definitions to the same cell in a given library. This may occur, for example, when you have both an rtl and a gate-level description of a module. These two different module descriptions represent simply different levels of abstraction being used to describe the same piece of a design at different points in the development process. Usually, these two different module descriptions will reside in separate source files, but since they represent the same design component, we may wish to map them to the same cell in a library. To differentiate between these two representations, we simply need to map them to different views of the same cell. Views may also be used to distinguish between different compilations of the same module definition in the same source file that may have been run using different macros, compiler directives and/or command-line arguments.</P>
<DIV>
<H3 CLASS="Heading2">
<A NAME="pgfId=1006666">
</A>
3.1 View Mapping in the Library Map File</H3>
<P CLASS="Body">
<A NAME="pgfId=1006665">
</A>
As with library mapping, view mapping is performed in the library map file. The basic syntax for view definitions is:</P>
<UL>
<P CLASS="Indented">
<A NAME="pgfId=1006667">
</A>
view_definition ::= view [<view_name> [{<file_clause>}[{<env_clause>}]]];</P>
<P CLASS="Indented">
<A NAME="pgfId=1006668">
</A>
file_clause::= file <file_path_spec> </P>
<P CLASS="Indented">
<A NAME="pgfId=1006770">
</A>
env_clause ::= <macro_clause><BR>
| <directive_clause><BR>
| <arg_clause></P>
<P CLASS="Indented">
<A NAME="pgfId=1006866">
</A>
macro_clause ::= macro <macro_name> [[!]=<value>]<BR>
| macro !<macro_name></P>
<P CLASS="Indented">
<A NAME="pgfId=1006871">
</A>
directive_clause ::= directive <directive_name> [[!]=<value>]</P>
<P CLASS="Indented">
<A NAME="pgfId=1006873">
</A>
arg_clause ::= arg <arg_name> [[!]= <value>]<BR>
| arg !<arg_name></P>
<P CLASS="Indented">
<A NAME="pgfId=1006842">
</A>
NOTE: The `!' before the macro_name in the macro clause and the arg_name in the arg clause indicates that the specified macro is undefined or the specified argument is not enabled.</P>
</UL>
<P CLASS="Body">
<A NAME="pgfId=1006773">
</A>
If the file_clause and env_clause are omitted from a view definition, then the specified view name shall be used as the default for all elements that do not match any other view definition. If multiple view definitions are specified without a file_clause or env_clause, then the LAST view definition encountered is used. By default, the default view name shall be based on the type of element being analyzed:</P>
<UL>
<P CLASS="Indented">
<A NAME="pgfId=1006793">
</A>
module/macromodule - default viewname "module"</P>
<P CLASS="Indented">
<A NAME="pgfId=1006794">
</A>
user-defined primitive - default viewname "udp"</P>
<P CLASS="Indented">
<A NAME="pgfId=1006795">
</A>
configuration - default viewname "config"</P>
</UL>
<P CLASS="BODY">
<A NAME="pgfId=1006675">
</A>
A view definition with no viewname implicitly sets the default viewname to the default values listed above.</P>
<P CLASS="BODY">
<A NAME="pgfId=1006808">
</A>
For view definitions that contain only file clauses, the precedence order is the same as for resolving library file path precedence (see <A HREF="draft2.html#41845" CLASS="XRef">
See File Path Resolution.</A>
). If a file path matches multiple view definitions, then the view definition(s) with an env_clause shall take precedence over any view definitions with only a file clause. View definitions which use the "arg" env_clause shall take precedence over those using only the "macro" and "directive" clauses.</P>
<P CLASS="BODY">
<A NAME="pgfId=1006846">
</A>
If a cell being analyzed resolves to match multiple view definitions, it shall be an error.</P>
<P CLASS="BODY">
<A NAME="pgfId=1006771">
</A>
Consider again the two adder descriptions from Example 1:</P>
<DIV>
<MAP NAME="draft2-1">
</MAP>
<IMG SRC="draft2-1.gif" USEMAP="#draft2-1">
</DIV>
<P CLASS="BODY">
<A NAME="pgfId=1006692">
</A>
These two module definitions actually represent the same adder, but at different levels of abstraction. Rather than mapping them to different libraries we could instead just map them to different views of the same cell using the lib.map entries shown here:</P>
<UL>
<P CLASS="Indented">
<A NAME="pgfId=1006695">
</A>
library adderLib "adder.*";</P>
<P CLASS="Indented">
<A NAME="pgfId=1006698">
</A>
view rtl file "*.v"; // module definitions in adder.v map to rtl view</P>
<P CLASS="Indented">
<A NAME="pgfId=1006699">
</A>
view gate file "*.vg"; // module definitions in adder.vg map to gate view</P>
</UL>
<P CLASS="BODY">
<A NAME="pgfId=1006700">
</A>
In this way, the rtl and gate-level descriptions now are considered different views of the same library cell: adderLib.adder:rtl and adderLib.adder:gate, respectively. This method of using views to distinguish between different representations of the same design component, instead of creating a new library for each abstraction, can greatly reduce the total number of libraries needed, and should simplify the process of managing configurations throughout the design process.</P>
<P CLASS="BODY">
<A NAME="pgfId=1006708">
</A>
In addition to distinguishing between different abstractions of a cell, views also provide the opportunity to analyze the same source description with different options and distinguish between them. Consider the following modifications to the adder files from Example 5:</P>
<DIV>
<MAP NAME="draft2-2">
</MAP>
<IMG SRC="draft2-2.gif" USEMAP="#draft2-2">
</DIV>
<P CLASS="BODY">
<A NAME="pgfId=1006732">
</A>
If we analyze the adder.v file with and without the MSG macro defined, the behavior of the rtl adder module will change slightly, displaying the "rtl" message, but the fundamental execution of the adder itself will not change. We need to be able to distinguish between these two behaviors, even though they came from the same source file. For this reason, the file specification alone is insufficient to manage the full mapping of views. We use the "macro" clause as shown in the "info" view definition in Example 7 (below) to distinguish.</P>
<P CLASS="BODY">
<A NAME="pgfId=1006806">
</A>
Consider the two gate-level adder descriptions from Example 6 in adder.vg and adder1.vg. The only difference between these two descriptions is the value of the `timescale compiler directive. To differentiate between the two, we use the "directive" clause as shown for the 1n10p and 1n1n view definitions in Example 7.</P>
<P CLASS="BODY">
<A NAME="pgfId=1006845">
</A>
Finally, the environment may be controlled by tool-specific command-line options. Suppose the tool supports a command-line option "+foo". If we wish to place all files analyzed with this option enabled into a view "foo", we use the view definition for view foo shown in Example 7.</P>
<P CLASS="BODY">
<A NAME="pgfId=1006807">
</A>
To distinguish between these different views, we could use the following view specifications:</P>
<UL>
<P CLASS="Indented">
<A NAME="pgfId=1006818">
</A>
Example 7:</P>
<P CLASS="Indented">
<A NAME="pgfId=1006743">
</A>
library adderLib "adder*.*";</P>
<P CLASS="Indented">
<A NAME="pgfId=1006744">
</A>
view rtl file "*.v"; // module definitions in adder.v map to rtl view</P>
<P CLASS="Indented">
<A NAME="pgfId=1006745">
</A>
view 1n1n file "*.vg" directive timescale = 1ns/1ns; // adder definitions in adder1.vg maps</P>
<P CLASS="Indented">
<A NAME="pgfId=1006831">
</A>
view 1n10p file "*.vg" directive timescale = 1ns/10ps; // adder in adder.vg</P>
<P CLASS="Indented">
<A NAME="pgfId=1006830">
</A>
view info file "*.*" macro MSG;</P>
<P CLASS="Indented">
<A NAME="pgfId=1006877">
</A>
view foo file "*.*" arg +foo;</P>
<P CLASS="Indented">
<A NAME="pgfId=1006832">
</A>
NOTE: Only cells which actually refer to a particular macro will satisfy a macro clause. If the adder.vg file is analyzed with the MSG macro defined, it will NOT match the info view definition.</P>
<P CLASS="Indented">
<A NAME="pgfId=1006878">
</A>
NOTE: Since the view definition for view foo contains an arg clause, it takes precedence over other view definitions. Analyzing the file adder.vg without the +foo option will map the adder module to view 1n10p, but when the +foo command-line argument is used, the view 1n10p definition is superceded by the view foo, even though the file paths both match.</P>
</UL>
<P CLASS="BODY">
<A NAME="pgfId=1006880">
</A>
Particularly when a view definition affects only a small number of cells, the view notation allows these cells to be managed more efficiently in a smaller number of libraries rather than creating a proliferation of libraries, each of which may only have a small number of cells in it. </P>
<P CLASS="BODY">
<A NAME="pgfId=1006879">
</A>
The user should think of a library as a collection of design elements, such as an "adder," that may be instantiated in a design. The view notation may be used to refer to specific implementations of the "adder," but all views are intended to represent the same design element.</P>
<UL>
<P CLASS="Indented">
<A NAME="pgfId=1006894">
</A>
Implementation Note: Tool implementers may find it convenient to provide a command-line argument to specify the view explicitly, which will override any view definitions in the lib.map file. If these views do not exist in the lib.map file, they may only be accessed via an explicit config. </P>
</UL>
</DIV>
</DIV>
<DIV>
<H2 CLASS="Heading1">
<A NAME="pgfId=1006055">
</A>
4. Configurations</H2>
<P CLASS="Body">
<A NAME="pgfId=1006931">
</A>
As mentioned in the introduction of this chapter, a configuration is simply a set of rules to apply when searching for library cells to which to bind instances. For a wide variety of design configuration scenarios, the syntax shown in <A HREF="draft2.html#13051" CLASS="XRef">
See Basic Configuration Syntax.</A>
will be sufficient. <A HREF="draft2.html#15842" CLASS="XRef">
See Advanced Configuration Syntax.</A>
includes some additional syntax that may be used in more complex scenarios, including use with non-simulation-specific tools.</P>
<DIV>
<H3 CLASS="Heading2">
<A NAME="pgfId=1007104">
</A>
4.1 <A NAME="13051">
</A>
Basic Configuration Syntax</H3>
<P CLASS="Body">
<A NAME="pgfId=1007163">
</A>
The basic configuration syntax is shown here:</P>
<UL>
<P CLASS="Indented">
<A NAME="pgfId=1007174">
</A>
config_declaration ::= config <config_identifier>;<BR>
                <design_statement><BR>
                {<config_rule_statement>}<BR>
        endconfig</P>
<P CLASS="Indented">
<A NAME="pgfId=1007194">
</A>
design_statement ::= design {[lib_name.]cell_name[:view_name]};</P>
<P CLASS="Indented">
<A NAME="pgfId=1007195">
</A>
config_rule_statement ::= <selection_clause> <expansion_clause>;</P>
<P CLASS="Indented">
<A NAME="pgfId=1007196">
</A>
selection_clause ::= <default_clause><BR>
| <lib_clause><BR>
| <path_clause></P>
<P CLASS="Indented">
<A NAME="pgfId=1007210">
</A>
expansion_clause ::= <liblist_clause><BR>
| <viewlist_clause><BR>
| <binding_clause></P>
</UL>
<DIV>
<H4 CLASS="Heading3">
<A NAME="pgfId=1007234">
</A>
Design Statement</H4>
<P CLASS="Body">
<A NAME="pgfId=1007235">
</A>
The design statement names the library, cell, and view of the top-level module in the design hierarchy configured by the config. There must be one and only one design statement. The design identified may not be in the same lib.cell:view as the configuration itself. It is possible, however, that the design identified will be a different view of the same library cell as the config.</P>
<P CLASS="Body">
<A NAME="pgfId=1007239">
</A>
The design statement must appear before any config rule statements in the config.</P>
</DIV>
</DIV>
<DIV>
<H3 CLASS="Heading2">
<A NAME="pgfId=1007105">
</A>
4.2 Selection Clauses</H3>
<DIV>
<H4 CLASS="Heading3">
<A NAME="pgfId=1007232">
</A>
The Default Clause</H4>
<P CLASS="Body">
<A NAME="pgfId=1007233">
</A>
The syntax for the default clause is </P>
<UL>
<P CLASS="Indented">
<A NAME="pgfId=1007203">
</A>
default_clause ::= default</P>
<P CLASS="Indented">
<A NAME="pgfId=1007204">
</A>
lib_clause ::= lib lib_name</P>
<P CLASS="Indented">
<A NAME="pgfId=1007205">
</A>
path_clause ::= path <inst_name></P>
</UL>
<P CLASS="Body">
<A NAME="pgfId=1007164">
</A>
</P>
</DIV>
</DIV>
<DIV>
<H3 CLASS="Heading2">
<A NAME="pgfId=1007165">
</A>
4.3 Expansion Clauses</H3>
<P CLASS="Body">
<A NAME="pgfId=1007231">
</A>
</P>
</DIV>
<DIV>
<H3 CLASS="Heading2">
<A NAME="pgfId=1007106">
</A>
4.4 Hierarchical Configurations</H3>
<P CLASS="Body">
<A NAME="pgfId=1007107">
</A>
</P>
</DIV>
<DIV>
<H3 CLASS="Heading2">
<A NAME="pgfId=1007108">
</A>
4.5 <A NAME="15842">
</A>
Advanced Configuration Syntax</H3>
<P CLASS="Body">
<A NAME="pgfId=1007109">
</A>
</P>
</DIV>
</DIV>
<DIV>
<H2 CLASS="Heading1">
<A NAME="pgfId=1006939">
</A>
5. Using the Library Mapping File to Control Library and View Searching</H2>
<P CLASS="Body">
<A NAME="pgfId=1006940">
</A>
In the absence of a configuration, it is possible to perform basic control of the library and view searching order when binding a design.</P>
<DIV>
<H3 CLASS="Heading2">
<A NAME="pgfId=1006945">
</A>
5.1 Using the lib.map File to Control Library Searching</H3>
<P CLASS="Body">
<A NAME="pgfId=1006946">
</A>
For simple designs, it is not necessary to create a config to control the binding. When searching for a library cell to bind to a particular instance, if no config is used, the libraries are searched in the order in which they appear in the lib.map file. </P>
<P CLASS="BODY">
<A NAME="pgfId=1006947">
</A>
Consider the following example</P>
<UL>
<P CLASS="Indented">
<A NAME="pgfId=1006969">
</A>
Example 4: </P>
</UL>
<DIV>
<MAP NAME="draft2-3">
</MAP>
<IMG SRC="draft2-3.gif" USEMAP="#draft2-3">
</DIV>
<P CLASS="Body">
<A NAME="pgfId=1007041">
</A>
Given the specified library definitions in the lib.map file, the instance binding shall be as follows:</P>
<TABLE BORDER="1">
<CAPTION>
<H6 CLASS="TableTitle">
<A NAME="pgfId=1006972">
</A>
Instance Binding</H6>
</CAPTION>
<TR>
<TH ROWSPAN="1" COLSPAN="1">
<P CLASS="CellHeading">
<A NAME="pgfId=1006982">
</A>
Instance Name</P>
</TH>
<TH ROWSPAN="1" COLSPAN="1">
<P CLASS="CellHeading">
<A NAME="pgfId=1006984">
</A>
Module Name</P>
</TH>
<TH ROWSPAN="1" COLSPAN="1">
<P CLASS="CellHeading">
<A NAME="pgfId=1006986">
</A>
File</P>
</TH>
<TH ROWSPAN="1" COLSPAN="1">
<P CLASS="CellHeading">
<A NAME="pgfId=1006988">
</A>
Binding</P>
</TH>
<TH ROWSPAN="1" COLSPAN="1">
<P CLASS="CellHeading">
<A NAME="pgfId=1006990">
</A>
Comment</P>
</TH>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="CellBody">
<A NAME="pgfId=1006992">
</A>
top</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="CellBody">
<A NAME="pgfId=1006994">
</A>
top</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="CellBody">
<A NAME="pgfId=1006996">
</A>
top.v</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="CellBody">
<A NAME="pgfId=1006998">
</A>
rtlLib.top</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="CellBody">
<A NAME="pgfId=1007000">
</A>
Cell only appears in rtlLib</P>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="CellBody">
<A NAME="pgfId=1007002">
</A>
top.a1</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="CellBody">
<A NAME="pgfId=1007004">
</A>
adder</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="CellBody">
<A NAME="pgfId=1007006">
</A>
adder.v</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="CellBody">
<A NAME="pgfId=1007008">
</A>
aLib.adder</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="CellBody">
<A NAME="pgfId=1007010">
</A>
Cell only appears in aLib</P>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="CellBody">
<A NAME="pgfId=1007012">
</A>
top.s2</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="CellBody">
<A NAME="pgfId=1007014">
</A>
subtr</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="CellBody">
<A NAME="pgfId=1007016">
</A>
subtr.v</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="CellBody">
<A NAME="pgfId=1007018">
</A>
sLib.subtr</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="CellBody">
<A NAME="pgfId=1007020">
</A>
Cell only appears in sLib</P>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="CellBody">
<A NAME="pgfId=1007022">
</A>
top.a1.f1</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="CellBody">
<A NAME="pgfId=1007024">
</A>
foo</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="CellBody">
<A NAME="pgfId=1007026">
</A>
top.v</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="CellBody">
<A NAME="pgfId=1007028">
</A>
rtlLib.foo</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="CellBody">
<A NAME="pgfId=1007030">
</A>
Searching starts with rtlLib, where the cell is found.</P>
</TD>
</TR>
<TR>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="CellBody">
<A NAME="pgfId=1007032">
</A>
top.s2.f2</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="CellBody">
<A NAME="pgfId=1007034">
</A>
foo</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="CellBody">
<A NAME="pgfId=1007036">
</A>
subtr.v</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="CellBody">
<A NAME="pgfId=1007038">
</A>
rtlLib.foo</P>
</TD>
<TD ROWSPAN="1" COLSPAN="1">
<P CLASS="CellBody">
<A NAME="pgfId=1007040">
</A>
Searching starts with rtlLib, where the cell is found.</P>
</TD>
</TR>
</TABLE>
<P CLASS="BODY">
<A NAME="pgfId=1007042">
</A>
Notice that both instances of foo, top.a1.f1 and top.s2.f2, get bound to rtlLib.foo, since rtlLib is always the first library searched.</P>
</DIV>
<DIV>
<H3 CLASS="Heading2">
<A NAME="pgfId=1007048">
</A>
5.2 Using the lib.map File to Control View Searching</H3>
<P CLASS="Body">
<A NAME="pgfId=1007049">
</A>
As with library searching, in the absence of a configuration, view searching is done according to the order of declaration in the library mapping file. For a cell being bound, the potential library is determined first (from the file name and the library definitions in lib.map) and then the views are searched in declaration order. If no view is found from the lib.map file, the default views shall be searched in the following order: config, module, udp.</P>
<P CLASS="Body">
<A NAME="pgfId=1007051">
</A>
If a cell being bound is located in a library that contains a viewlist clause in its definition, then the views shall be searched according to the order specified in the viewlist clause. If none of the views in the viewlist are found, then the next library shall be checked. When a library definition specifies a viewlist, then only the views in the viewlist shall be searched, regardless of other views which may exist.</P>
</DIV>
</DIV>
<DIV>
<H2 CLASS="Heading1">
<A NAME="pgfId=1006054">
</A>
6. Configuration Examples</H2>
<DIV>
<H3 CLASS="Heading2">
<A NAME="pgfId=1006047">
</A>
6.1 File Path Specification Examples</H3>
<UL>
<P CLASS="Indented">
<A NAME="pgfId=1007118">
</A>
Example: given the following set of files:</P>
<P CLASS="Indented">
<A NAME="pgfId=1007119">
</A>
        /proj/lib1/rtl/a.v</P>
<P CLASS="Indented">
<A NAME="pgfId=1007120">
</A>
/proj/lib2/gates/a.v </P>
<P CLASS="Indented">
<A NAME="pgfId=1007121">
</A>
                /proj/lib1/rtl/b.v</P>
<P CLASS="Indented">
<A NAME="pgfId=1007122">
</A>
        /proj/lib2/gates/b.v </P>
</UL>
<P CLASS="BODY">
<A NAME="pgfId=1007123">
</A>
The following absolute file_path_specs are resolved as shown: </P>
<UL>
<P CLASS="Indented">
<A NAME="pgfId=1007124">
</A>
"/proj/lib*/*/a.v" = /proj/lib1/rtl/a.v, /proj/lib2/gates/a.v </P>
<P CLASS="Indented">
<A NAME="pgfId=1007125">
</A>
".../a.v" = /proj/lib1/rtl/a.v, /proj/lib2/gates/a.v </P>
<P CLASS="Indented">
<A NAME="pgfId=1007126">
</A>
"/proj/.../b.v" = /proj/lib1/rtl/b.v, /proj/lib2/gates/b.v </P>
<P CLASS="Indented">
<A NAME="pgfId=1007127">
</A>
".../rtl/*.v" = /proj/lib1/rtl/a.v, /proj/lib1/rtl/b.v</P>
</UL>
<P CLASS="BODY">
<A NAME="pgfId=1007128">
</A>
>From the /proj/lib1 directory, the following relative file_path_specs are resolved as shown:</P>
<UL>
<P CLASS="Indented">
<A NAME="pgfId=1007129">
</A>
"../lib2/gates/*.v" = /proj/lib2/gates/a.v, /proj/lib2/gates/b.v</P>
<P CLASS="Indented">
<A NAME="pgfId=1007130">
</A>
"./rtl/?.v" = /proj/lib1/rtl/a.v, /proj/lib1/rtl/b.v</P>
<P CLASS="Indented">
<A NAME="pgfId=1007131">
</A>
"./rtl/" = /proj/lib1/rtl/a.v, /proj/lib1/rtl/b.v</P>
</UL>
</DIV>
<DIV>
<H3 CLASS="Heading2">
<A NAME="pgfId=1007116">
</A>
6.2 Resolving Multiple Path Specifications</H3>
<UL>
<P CLASS="Indented">
<A NAME="pgfId=1007147">
</A>
Example 3:</P>
<P CLASS="Indented">
<A NAME="pgfId=1007148">
</A>
library lib1 "/proj/lib1/foo*.v";</P>
<P CLASS="Indented">
<A NAME="pgfId=1007149">
</A>
library lib2 "/proj/lib1/foo.v";</P>
<P CLASS="Indented">
<A NAME="pgfId=1007150">
</A>
library lib3 "../lib1/";</P>
<P CLASS="Indented">
<A NAME="pgfId=1007151">
</A>
library lib4 "/proj/lib1/*ver.v";</P>
</UL>
<P CLASS="BODY">
<A NAME="pgfId=1007152">
</A>
When evaluated from the directory /proj/tb directory, the following source files shall map into the specified library:</P>
<UL>
<P CLASS="Indented">
<A NAME="pgfId=1007153">
</A>
../lib1/foobar.v - lib1 // potentially matches lib1 and lib3. Since lib1 includes a filename and lib3 only specifies a directory, lib1 takes precedence</P>
<P CLASS="Indented">
<A NAME="pgfId=1007154">
</A>
/proj/lib1/foo.v - lib2 // takes precedence over lib1 and lib3 path specifications</P>
<P CLASS="Indented">
<A NAME="pgfId=1007155">
</A>
/proj/lib1/bar.v - lib3</P>
<P CLASS="Indented">
<A NAME="pgfId=1007156">
</A>
/proj/lib1/barver.v - lib4 // takes precedence over lib3 path specification</P>
<P CLASS="Indented">
<A NAME="pgfId=1007157">
</A>
/proj/lib1/foover.v - ERROR // matches lib1 and lib4</P>
<P CLASS="Indented">
<A NAME="pgfId=1007158">
</A>
/test/tb/tb.v - work // does not match any library specifications.</P>
</UL>
<P CLASS="Body">
<A NAME="pgfId=1007145">
</A>
</P>
</DIV>
</DIV>
</DIV>
</BODY>
</HTML>

Next message: Andrew T. Lynch: "Hierarchical Reference problems"
Previous message: Adam Krolnik: "BTF - B01 question"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

This archive was generated by hypermail 2.1.4 : Mon Jul 08 2002 - 12:53:25 PDT and
sponsored by Boyd Technology, Inc.