Previous

Appendix B

EDIF2NGD, XNF2NGD, and NGDBuild

This appendix describes the netlist reader programs, EDIF2NGD and XNF2NGD, and how these programs interact with NGDBuild. The appendix contains the following sections.

EDIF2NGD

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 Flow

The 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.

You can run EDIF2NGD in the following ways.

EDIF2NGD Syntax

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.

EDIF2NGD Files

This section describes the EDIF2NGD input and output files.

Input Files

EDIF2NGD uses the following files as inputs.

Output Files

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.

EDIF2NGD Options

This section describes the EDIF2NGD command options.

-a (Add PADs to Top-Level Port Signals)

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 (Execute Commands File)

-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 (Libraries to Search)

-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 Name)

-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.

-r (Ignore LOC Properties)

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.

XNF2NGD

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 will 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 Flow

You 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 netnames GSR,RESET, GR, and PRELOAD. If you used these names, XNF2NGD issues an error.


XNF2NGD Syntax

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.

XNF2NGD Files

This section describes the XNF2NGD input and output files.

Input Files

XNF2NGD uses the following files as inputs.

Output Files

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.

XNF2NGD Options

This section describes the XNF2NGD command options.

-f (Execute Commands File)

-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 (Libraries to Search)

-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 Name)

-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.

-r (Ignore LOC Properties)

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.

-u (Top-Level XNF Netlist)

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.

NGDBuild

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.

Converting a Netlist to an NGD File

NGDBuild performs the following steps to convert a netlist to an NGD file. This flow is shown in the “NGDBuild and the Netlist Readers” figure.

  1. Reads the source netlist.

    To perform this step, NGDBuild invokes the Netlister Launcher, a part of the NGDBuild software which determines the type of the input netlist and starts the appropriate netlist reader program. If the input netlist is in EDIF or XNF format, the Netlister Launcher invokes EDIF2NGD or XNF2NGD. If the input netlist is in another format that the Netlister Launcher recognizes, the Netlister Launcher invokes the program necessary to convert the netlist to EDIF or XNF format, then invokes EDIF2NGD or XNF2NGD. The netlist reader produces an NGO file for the top-level netlist file.

    If any subfiles are referenced in the top-level netlist (for example, a PAL description file, or another schematic file), the Netlister Launcher invokes the appropriate netlist reader for each of these files to convert each referenced file to an NGO file.

    The Netlister Launcher is described in the “Netlister Launcher” section. The netlist reader programs are described in the “EDIF2NGD” section and the “XNF2NGD” section.

  2. Reduces all components in the design to NGD primitives.

    To perform this step, NGDBuild merges components that reference other files by finding the referenced NGO files. NGDBuild also finds the appropriate system library components, physical macros (NMC files) and behavioral models.

  3. Checks the design by running a Logical DRC (Design Rule Check) on the converted design.

    The Logical DRC is a series of tests on the logical design. It is described in “The Logical Design Rule Check” chapter.

  4. Writes an NGD file as output.

Figure B.3 NGDBuild and the Netlist Readers

When 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.

Bus Matching in Virtex

In the Xilinx UnifiedPro library for Virtex, some of the pins on the block RAM primitives are bused. If your synthesis or schematic vendor writes out EDIF netlists in which bused pins are left intact (in what are known as “array constructs”), EDIF2NGD expands the bused pins correctly for NGDBuild.

However, many synthesis and schematic vendors expand these bused pins into scalar pins when writing an EDIF or XNF netlist. If your synthesis or schematic vendor expands bused pins, the naming convention for the resulting scalar pins must be one of those recognized by NGDBuild, or the block RAM instance will be reported as “unexpanded.”

NGDBuild supports the conventions shown in the following table.

Naming Convention
Example
busname(index)
DI(3)
busname<index>
DI<3>
busname[index]
DI[3]
busnameindex
DI3

If your synthesis or schematic allows you to configure the naming convention it uses when expanding bused pins, adhere to one of these conventions to avoid “unexpanded” instances.

Netlister Launcher

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.

  1. The Netlister Launcher initializes itself with a set of rules for determining what netlist reader is to be used with each type of netlist, and the options with which each reader is invoked.

    The rules are contained in the system rules file (described in the “System Rules File” section) and in the user rules file (described in the “User Rules File” section).

  2. NGDBuild makes the directory of the top-level netlist the first entry in the Netlister Launcher's list of search paths.

  3. For the top-level design and for each file referenced in the top-level design, NGDBuild queries the Netlist Launcher for the presence of the corresponding NGO file.

  4. For each NGO file requested, the Netlister Launcher performs these actions.

  5. The Netlister launcher indicates to NGDBuild that the requested NGO files have been found, and NGDBuild can process all of these NGO files.

Netlister Launcher Rules Files

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.

User Rules File

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 and System Rules

User rules are treated as described below.

User Rules Format

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 options in the NetlisterTopOptions line must be enclosed in quotation marks.

Value Types in Key Statements

The value types used in the preceding key statements are the following.

System Rules File

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 here 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;

Rules File Examples

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.

XNF_RULE System Rule

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.

User Rule Example 1

// URF Example 1
  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 above) to translate the XNF file to an NGO file.

User Rule Example 2

// URF Example 2
  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 “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.)

User Rule Example 3

// URF Example 3
  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 “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 here is that the fictitious program state2ngd is used in place of XNF2NGD.


Note that if XNF_LIB_RULE (from the example in the “User Rule Example 2” section) and this rule were both in the user rules file, STATE_XNF_RULE would also include the modifications made by XNF_LIB_RULE. So a lower-level state.xnf would be translated by running state2ngd with the “-l xilinxun” option.

File Names and Locations

Following are some notes about file names and notations in NGDBuild.