|
|
|
This appendix describes the netlist reader programs, EDIF2NGD and XNF2NGD, and how these programs interact with NGDBuild. The appendix contains the following sections.
This program is compatible with the following families.
The EDIF2NGD program allows you to read an EDIF (Electronic Design Interchange Format) 2 0 0 file into the Xilinx Development System toolset. EDIF2NGD converts an industry-standard EDIF netlist to an NGO file - a Xilinx-specific format. The EDIF file includes the hierarchy of the input schematic. The output NGO file is a binary database describing the design in terms of the components and hierarchy specified in the input design file. The following figure shows the flow through EDIF2NGD.
Figure B.1 EDIF2NGD Design FlowThe NGO file can be converted to an NGD file using the NGDBuild program. The NGD file can be mapped into an NCD file, which can then be placed and routed.
The input file must be a Level 0 EDIF netlist, as defined in the EDIF 2 0 0 specification. The Xilinx Development System toolset can understand EDIF files developed using components from any of these libraries.
Note: Xilinx tools do not recognize Xilinx Unified Libraries components defined as macros; they only recognize the primitives from this library. The third-party EDIF writer must include definitions for all macros.
You can run EDIF2NGD in the following ways.
Note: When creating nets or symbols names, do not use reserved names. Reserved names are the names of symbols for primitives and macros in the Libraries Guide and net names GSR, RESET, GR, and PRELOAD. If you used these names, EDIF2NGD issues an error.
The following command reads your EDIF netlist and converts it to an NGO file.
edif2ngd [options] edif_file ngo_file
Options can be any number of the EDIF2NGD options listed in the “EDIF2NGD Options” section. They do not need to be listed in any particular order. Separate multiple options with spaces.
Edif_file is the EDIF 2 0 0 input file to be converted. The file must have an extension. If the file has an extension other than .edn, you must enter the extension as part of edif_file. If you enter a file name with no extension, EDIF2NGD looks for a file with an .edn extension and the name you specified.
Note: For EDIF2NGD to read a Mentor Graphics EDIF file, you must have installed the Mentor Graphics software component on your system. Similarly, to read a Cadence EDIF file, you must have installed the Cadence software component.
Ngo_file is the output file in NGO format. The output file name, its extension, and its location are determined in this way.
If the output file exists, it is overwritten with the new file.
This section describes the EDIF2NGD input and output files.
EDIF2NGD uses the following files as inputs.
The output of EDIF2NGD is an NGO file - a binary file containing a logical description of the design in terms of its original components and hierarchy.
This section describes the EDIF2NGD command options.
The -a option adds PAD properties to all top level port signals. This option is necessary if the EDIF2NGD input is an EDIF file in which PAD symbols were translated into ports. If you do not specify a -a option for one of these EDIF files, the absence of PAD instances in the EDIF file causes EDIF2NGD to read the design incorrectly. Subsequently, MAP interprets the logic as unused and removes it.
In all Mentor Graphics and Cadence EDIF files PAD symbols are translated into ports. For EDIF files from either of these vendors, the -a option is set automatically; you do not have to enter the -a option on the EDIF2NGD command line.
-f command_file
The -f option executes the command line arguments in the specified command_file. For more information on the -f option, see the “-f Option” section of the “Introduction” chapter.
-l libname
The -l option specifies a library to search when determining what library components were used to build the design. This information is necessary for NGDBuild, which must determine the source of the design's components before it can resolve the components to Xilinx primitives.
You may specify multiple -l options on the command line. Each must be preceded with -l; you cannot combine multiple libname specifiers after one -l. For example, -l xilinxun synopsys is not acceptable, while -l xilinxun -l synopsys is acceptable.
The allowable entries for libname are the following.
xilinxun (For Xilinx Unified library)
synopsys
Note: You do not have to enter xilinxun with a -l option. The Xilinx Development System tools automatically access these libraries. You do not have to enter synopsys with a -l option if the EDIF netlist contains an author construct with the string “Synopsys.” In this case, EDIF2NGD automatically detects that the design is from Synopsys.
-p part
The -p option specifies the part into which your design is implemented. The -p option can specify an architecture only, a complete part specification (device, package, and speed), or a partial specification (for example, device and package only).
The syntax for the -p option is described in the “Part Numbers in Commands” section of the “Introduction” chapter. Examples of part entries are XC3100A, XC4003E-PC84, and XC4028EX-HQ240-3.
If you do not specify a part when you run EDIF2NGD, you will have to specify one when you run NGDBuild.
You can also use the -p option to override a part name in the input EDIF netlist or a part name in an NCF file.
The -r option filters out all location properties (LOC=) from the design. This option can be used when you are migrating to a different device or architecture, because locations in one architecture do not match locations in another.
This program is compatible with the following families.
Note: XNF primitives are not defined for the Virtex architecture, and XNF files created for Virtex are rejected by XNF2NGD. However, if you have XNF netlists that were created for the XC3000, XC4000E, or XC5200 architectures, you can include these XNF netlists in a design that you target to a Virtex device.
XNF2NGD allows you to read a Version 6.1 XNF (Xilinx Netlist Format) file into the Xilinx Development System toolset. XNF2NGD converts an XNF file to an NGO file, which is a binary database describing the netlist in terms of Xilinx components. After you convert the XNF file to an NGO file, you run NGDBuild to create an NGD file, which expands the design to include a description reduced to Xilinx primitives. The following figure shows the flow through XNF2NGD.
Figure B.2 XNF2NGD Design FlowYou can run XNF2NGD in the following ways.
Note: When creating nets or symbols names, do not use reserved names. Reserved names are the names of symbols for primitives and macros in the Libraries Guide and net names GSR,RESET, GR, and PRELOAD. If you used these names, XNF2NGD issues an error.
The following command reads your XNF netlist and converts it to an NGO file.
xnf2ngd [options] xnf_file ngo_file
Options can be any number of the XNF2NGD options listed in the “XNF2NGD Options” section. They do not need to be listed in any particular order. Separate multiple options with spaces.
Xnf_file is the input file (in XNF format) to be converted. The file can have any extensions (for example, .xnf, .xtf, .xff, .xg, or .sxnf), as long as the file is in XNF format. If you enter a file name with no extension, XNF2NGD looks for a file with an .xnf extension and the name you specified.
Ngo_file is the output file in NGO format. The output file name, its extension, and its location are determined in this way.
If the output file already exists, it is overwritten with the new file.
This section describes the XNF2NGD input and output files.
XNF2NGD uses the following files as inputs.
The output of XNF2NGD is an NGO file - a binary file containing a logical description of the design in terms of its original components and hierarchy.
This section describes the XNF2NGD command options.
-f command_file
The -f option executes the command line arguments in the specified command_file. For more information on the -f option, see the “-f Option” section of the “Introduction” chapter.
-l libname
The -l option indicates the list of libraries to search when determining what library components were used to build the design. This information is necessary for NGDBuild, which must determine the source of the design's components before it can resolve the components to Xilinx primitives.
You can specify multiple -l options on the command line. Each must be preceded with -l; you cannot combine multiple libname specifiers after one -l. For example, -l xilinxun synopsys is not acceptable, while -l xilinxun -l synopsys is acceptable.
The allowable entries for libname are the following.
xilinxun (For Xilinx Unified library)
synopsys
XC3000
XC4000
XC9500
Note: You do not have to enter xilinxun with a -l option. The Xilinx Development System tools automatically access these libraries. In most cases, you do not have to enter XC3000 or XC4000 with a -l option. However, if your XNF file contains an input latch (INLAT) component and no part type is specified in the XNF file, the meaning of the INLAT component is ambiguous. In this case, XNF2NGD will stop with an error message. You must run XNF2NGD again using the -l option to define the INLAT component; -l XC3000 means the INLAT is transparent High and -l XC4000 means it is transparent Low.
-p part
The -p option specifies the part into which your design is implemented. The -p option can specify an architecture only, a complete part specification (device, package, and speed), or a partial specification (for example, device and package only).
The syntax for the -p option is described in the “Part Numbers in Commands” section of the “Introduction” chapter. Examples of part entries are XC3100A, XC4003E-PC84, and XC4028EX-HQ240-3.
If you do not specify a part when you run XNF2NGD, you will have to specify one when you run NGDBuild.
You may also use the -p option to override a part name in the input XNF netlist or a part name in an NCF file.
The -r option filters out all location properties (LOC=) from the design. This can be used when you are migrating to a different device or architecture, because locations in one architecture do not match locations in another.
The -u option specifies that the input XNF file is the top-level design netlist. When XNF2NGD translates netlists at lower hierarchical levels, XNF2NGD adds to the lower-level NGO file information that is unnecessary in the top-level NGO file. The -u option prevents this information from being added to the top-level NGO file.
This program is compatible with the following families.
NGDBuild performs all the steps necessary to read a netlist file in XNF or EDIF format and create an NGD file describing the logical design. The NGD file resulting from an NGDBuild run contains both a logical description of the design reduced to NGD primitives and a description in terms of the original hierarchy expressed in the input netlist. The output NGD file can be mapped to the desired device family.
NGDBuild performs the following steps to convert a netlist to an NGD file. This flow is shown in the following figure.
Figure B.3 NGDBuild and the Netlist ReadersWhen NGDBuild reads the source netlist, it detects any files or parts of the design that have changed since the last run of NGDBuild. It updates files as follows.
Note: If the NGO for an netlist file is up to date, NGDBuild looks for an NCF file with the same base name as the netlist in the netlist directory and compares the timestamp of the NCF file against that of the NGO file. If the NCF file is newer, XNF2NGD or EDIF2NGD is run again. However, if an NCF file existed on a previous run of NGDBuild and the NCF file was deleted, NGDBuild will not detect that XNF2NGD or EDIF2NGD must be run again. In this case, you must use the -nt on option to force a rebuild.
Syntax, files, and options for the NGDBuild command are described in the “NGDBuild” chapter.
When NGDBuild encounters an instance of one netlist within another netlist, it requires that each pin specified on the upper-level instance match to a pin (or port) on the lower-level netlist. Two pins must have exactly the same name in order to be matched. This requirement applies to all FPGAs and CPLDs supported for NGDBuild.
If the interface between the two netlists uses bused pins, these pins are expanded into scalar pins before any pin matching occurs. For example, the pin A[7:0] might be expanded into 8 pins namedA[7] through A[0]. If both netlists use the same nomenclature (that is, the same index delimiter characters) when expanding the bused pin, the scalar pin names will match exactly. However, if the two netlists were created by different vendors and different delimiters are used, the resulting scalar pin names do not match exactly.
In cases where the scalar pin names do not match exactly, NGDBuild analyzes the pin names in both netlists and attempts to identify names that resulted from the expansion of bused pins. When it identifies a bus-expanded pin name, it tries several other bus-naming conventions to find a match in the other netlist so it can merge the two netlists. For example, if it finds a pin named A(3) in one netlist, it looks for pins named A(3), A[3], A<3> or A3 in the other netlist.
Following are the bus naming conventions understood by NGDBuild.
| Naming Convention | Example |
|---|---|
| busname(index) | DI(3) |
| busname<index> | DI<3> |
| busname[index] | DI[3] |
| busnameindex | DI3 |
If your third-party netlist writer allows you to specify the bus-naming convention, use one of the conventions shown in the preceding table to avoid “pin mismatch” errors during NGDBuild. If your third-party EDIF writer preserves bus pins using the EDIF “array” construct, the bus pins will be expanded by EDIF2NGD using parentheses, which is one of the supported naming conventions.
Note: NGDBuild support for bused pins is limited to this understanding of different naming conventions. It is not able to merge together two netlists if a bused pin has different indices between the two files. For example, it cannot match A[7:0] in one netlist to A[15:8] in another.
In the Xilinx UnifiedPro library for Virtex, some of the pins on the block RAM primitives are bused. If your third-party netlist writer uses one of the bus naming conventions listed in the preceding table or uses the EDIF array construct, these primitives are recognized properly by NGDBuild. The use of any other naming convention may result in an “unexpanded block” error during NGDBuild.
The Netlister Launcher, which is part of NGDBuild, performs any netlist translations necessary to execute the NGDBuild command.
When NGDBuild is invoked, the Netlister launcher goes through the following steps.
Note: The timestamp check can be overridden by options on the NGDBuild command line. The -nt on option updates all existing NGO files, regardless of their timestamps. The -nt off option does not update any existing NGO files, regardless of their timestamps.
The behavior of the Netlister Launcher is determined by rules defined in the system rules file and the user rule file. These rules determine the following.
The system rules file contains the default rules supplied with the Xilinx Development System software. The user rules file can add to or override the system rules.
The following sections describe the user rules file and the system rules.
The user rules file can add to or override the rules in the system rules file. You can specify the location of the user rules file with the -ur option to the NGDBuild command line.
User rules are treated as described below.
Each rule in the user rules file has the following format.
RuleName = <rulename1>;
<key1> = <value1>;
<key2> = <value2>;
.
.
.
<keyn> = <valuen>;
The following is a description of the keys allowed and the values expected.
Note: All of the values mentioned in the following paragraphs are described in the “Value Types in Key Statements” section.
The value types used in the preceding key statements are the following.
The system rules are shown following. The system rules file is not an ASCII file, but for the purpose of describing the rules, the rules are described using the same syntax as in the user rules file. This syntax is described in the “User Rules File” section.
Note: If a rule attribute is not specified, it is assumed to have the value NONE.
#####################################################
# xnf2ngd rules
#####################################################
RuleName = XNF_RULE;
NetlistFile = .xnf;
TargetExtension = .ngo;
Netlister = xnf2ngd;
NetlisterTopOptions = "[-p $PART] -u [$IGNORE_LOCS] {-l $LIBRARIES} $INFILE $OUTFILE";
NetlisterOptions = "[-p $PART] [$IGNORE_LOCS] {-l $LIBRARIES} $INFILE $OUTFILE";
NetlisterDirectory = NONE;
NetlisterSuccessStatus = 0;
RuleName = XTF_RULE;
NetlistFile = .xtf;
TargetExtension = .ngo;
Netlister = xnf2ngd;
NetlisterTopOptions = "[-p $PART] -u [$IGNORE_LOCS] {-l $LIBRARIES} $INFILE $OUTFILE";
NetlisterOptions = "[-p $PART] [$IGNORE_LOCS] {-l $LIBRARIES} $INFILE $OUTFILE";
NetlisterDirectory = NONE;
NetlisterSuccessStatus = 0;
RuleName = XFF_RULE;
NetlistFile = .xff;
TargetExtension = .ngo;
Netlister = xnf2ngd;
NetlisterTopOptions = "[-p $PART] -u [$IGNORE_LOCS] {-l $LIBRARIES} $INFILE $OUTFILE";
NetlisterOptions = "[-p $PART] [$IGNORE_LOCS] {-l $LIBRARIES} $INFILE $OUTFILE";
NetlisterDirectory = NONE;
NetlisterSuccessStatus = 0;
RuleName = XG_RULE;
NetlistFile = .xg;
TargetExtension = .ngo;
Netlister = xnf2ngd;
NetlisterTopOptions = "[-p $PART] -u [$IGNORE_LOCS] {-l $LIBRARIES} $INFILE $OUTFILE";
NetlisterOptions = "[-p $PART] [$IGNORE_LOCS] {-l $LIBRARIES} $INFILE $OUTFILE";
NetlisterDirectory = NONE;
NetlisterSuccessStatus = 0;
RuleName = SYN_XNF_RULE;
NetlistFile = .sxnf;
TargetExtension = .ngo;
Netlister = xnf2ngd;
NetlisterTopOptions = "[-p $PART] -u [$IGNORE_LOCS] -l synopsys {-l $LIBRARIES} $INFILE $OUTFILE";
NetlisterOptions = "[-p $PART] [$IGNORE_LOCS] -l synopsys {-l $LIBRARIES} $INFILE $OUTFILE";
NetlisterDirectory = NONE;
NetlisterSuccessStatus = 0;
#####################################################
# edif2ngd rules
#####################################################
RuleName = EDN_RULE;
NetlistFile = .edn;
TargetExtension = .ngo;
Netlister = edif2ngd;
NetlisterTopOptions = "[$IGNORE_LOCS] [$ADD_PADS] {-l $LIBRARIES} $INFILE $OUTFILE";
NetlisterOptions = "-noa [$IGNORE_LOCS] {-l $LIBRARIES} $INFILE $OUTFILE";
NetlisterDirectory = NONE;
NetlisterSuccessStatus = 0;
RuleName = EDF_RULE;
NetlistFile = .edf;
TargetExtension = .ngo;
Netlister = edif2ngd;
NetlisterTopOptions = "[$IGNORE_LOCS] [$ADD_PADS] {-l $LIBRARIES} $INFILE $OUTFILE";
NetlisterOptions = "-noa [$IGNORE_LOCS] {-l $LIBRARIES} $INFILE $OUTFILE";
NetlisterDirectory = NONE;
NetlisterSuccessStatus = 0;
RuleName = EDIF_RULE;
NetlistFile = .edif;
TargetExtension = .ngo;
Netlister = edif2ngd;
NetlisterTopOptions = "[$IGNORE_LOCS] [$ADD_PADS] {-l $LIBRARIES} $INFILE $OUTFILE";
NetlisterOptions = "-noa [$IGNORE_LOCS] {-l $LIBRARIES} $INFILE $OUTFILE";
NetlisterDirectory = NONE;
NetlisterSuccessStatus = 0;
RuleName = SYN_EDIF_RULE;
NetlistFile = .sedif;
TargetExtension = .ngo;
Netlister = edif2ngd;
NetlisterTopOptions = NONE;
NetlisterOptions = "-l synopsys [$IGNORE_LOCS] {-l $LIBRARIES} $INFILE $OUTFILE";
NetlisterDirectory = NONE;
NetlisterSuccessStatus = 0;
#####################################################
# other rules
#####################################################
RuleName = PLD_RULE;
NetlistFile = .pld;
TargetExtension = .xnf;
Netlister = readpld;
NetlisterTopOptions = "-f $INFILE -t -ox $OUTFILE";
NetlisterOptions = "-f $INFILE -ox $OUTFILE";
NetlisterDirectory = NONE;
NetlisterSuccessStatus = 0;
The following sections provide examples of system and user rules. The first example explains one of the system rules presented in the preceding “System Rules File” section. This example is the basis for understanding the ensuing user rules examples.
As shown in the “System Rules File” section, the XNF_RULE system rule is defined as follows.
RuleName = XNF_RULE;
NetlistFile = .xnf;
TargetExtension = .ngo;
Netlister = xnf2ngd;
NetlisterTopOptions = "[-p $PART] -u [$IGNORE_LOCS] {-l $LIBRARIES} $INFILE $OUTFILE";
NetlisterOptions = "[-p $PART] [$IGNORE_LOCS] {-l $LIBRARIES} $INFILE $OUTFILE";
NetlisterDirectory = NONE;
NetlisterSuccessStatus = 0;
The XNF_RULE instructs the Netlister Launcher to use XNF2NGD to translate an XNF file to an NGO file. If the top-level netlist is being translated, the options defined in NetlisterTopOptions are used; if a lower-level netlist is being processed, the options defined by NetlisterOptions are used. The -u option is used on the top-level netlist, but not on lower-level netlists. Because NetlisterDirectory is NONE, the Netlister Launcher runs XNF2NGD in the current working directory (the one from which NGDBuild was launched). The launcher expects XNF2NGD to issue a return code of 0 if it was successful; any other value is interpreted as failure.
// URF Example 2
RuleName = OTHER_RULE; // end-of-line comments are also allowed
NetlistFile = .oth;
TargetExtension = .xnf;
Netlister = other2xnf;
NetlisterOptions = "$INFILE $OUTFILE";
NetlisterSuccessStatus = 1;
The user rule OTHER_RULE defines a completely new translation, from a hypothetical OTH file to an XNF file. To do this translation, the other2xnf program is used. The options defined by NetlisterOptions are used for translating all OTH files, regardless of whether they are top-level or lower-level netlists (because no explicit NetlisterTopOptions is given). The launcher expects other2xnf to issue a return code of 1 if it was successful; any other value be interpreted as failure.
After the Netlister Launcher has used OTHER_RULE to run other2xnf and create an XNF file, it uses the XNF_RULE system rule (shown in the preceding section) to translate the XNF file to an NGO file.
// URF Example 3
RuleName = XNF_LIB_RULE;
NetlistFile = .xnf;
TargetExtension = .ngo;
NetlisterOptions = "-l xilinxun $INFILE $OUTFILE";
Because both the NetlistFile and TargetExtension of this user rule match those of the system rule XNF_RULE (shown in the “Example 1: XNF_RULE System Rule” section), the XNF_LIB_RULE overrides the XNF_RULE system rule. Any settings that are not defined by the XNF_LIB_RULE are inherited from XNF_RULE. So XNF_LIB_RULE uses the same netlister (XNF2NGD), the same top-level options, the same directory, and expects the same success status as XNF_RULE. However, when translating lower-level netlists, the options used are only “-l xilinxun $INFILE $OUTFILE.” (There is no reason to use “-l xilinxun” on XNF2NGD; this is for illustrative purposes only.)
// URF Example 4
RuleName = STATE_XNF_RULE;
NetlistFile = state.xnf;
TargetExtension = .ngo;
Netlister = state2ngd;
Although the NetlistFile is a complete file name, this user rule also matches the system rule XNF_RULE (shown in the “Example 1: XNF_RULE System Rule” section), because the extensions of NetlistFile and TargetExtension match. When the Netlister Launcher tries to make a file called state.ngo, it uses this rule instead of the system rule XNF_RULE (assuming that state.xnf exists). As with the previous example, the unspecified settings are inherited from the matching system rule. The only change is that the fictitious program state2ngd is used in place of XNF2NGD.
Note that if XNF_LIB_RULE (from the example in the “Example 3: User Rule” section) and this rule were both in the user rules file, STATE_XNF_RULE includes the modifications made by XNF_LIB_RULE. So a lower-level state.xnf is translated by running state2ngd with the “-l xilinxun” option.
Following are some notes about file names and notations in NGDBuild.