Previous

NGDBuild Options

This section describes NGDBuild command line options.

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

If the top-level input netlist is in EDIF format, the -a option causes NGDBuild to add a PAD symbol to every signal that is connected to a port on the root-level cell. This option has no effect on lower-level netlists or on a top-level XNF netlist.

Whether you need to use -a depends on the behavior of your third-party EDIF writer. If your EDIF writer treats pads as instances (like other library components), you should not use -a. But if your EDIF writer treats pads as hierarchical ports, you should use -a to infer actual pad symbols. If you do not use -a where necessary, logic may be improperly removed during mapping.

For EDIF files produced by Mentor Graphics and Cadence, the -a option is set automatically; you do not have to enter -a explicitly for these vendors.


NOTE

The NGDBuild -a option corresponds to the EDIF2NGD -a option. If you run EDIF2NGD on the top-level EDIF netlist separately, rather than allowing NGDBuild to run EDIF2NGD, you should use the two -a options consistently.


-dd (Destination Directory)

-dd ngo_directory

The -dd option specifies the directory for intermediate files (design NGO files and netlist files). If the -dd option is not specified, files are placed in the current directory.

-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 option is passed to the appropriate netlist reader. The information allows NGDBuild to determine the source of the design's components so it can resolve the components to NGD primitives.

You can specify multiple libraries by entering multiple -l libname entries on the NGDBuild command line.

The allowable entries for libname are the following.

xilinxun (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. In cases where NGDBuild automatically detects Synopsys designs (for example, the netlist extension is .sxnf or .sedif), you do not have to enter synopsys with a -l option.


-nt (Netlist Translation Type)

-nt {timestamp | on | off}

The -nt option determines how timestamps are treated by the Netlister Launcher when it is invoked by NGDBuild. A timestamp is information in a file that indicates the date and time the file was created. The timestamp option (which is the default if no -nt option is specified) has the Netlister Launcher perform the normal timestamp check and update NGO files according to their timestamps. The on option translates netlists regardless of timestamps (rebuilding all NGO files), and the off option does not rebuild an existing NGO file, regardless of its timestamp.

-p (Target Architecture)

-p part

The -p option specifies the part into which the 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 XC4000L, XC4003E-PC84, and XC4028EX-HQ240-3.

When you specify the part, the NGD file produced by NGDBuild is optimized for mapping into that architecture.

You do not have to specify a -p option if your NGO file already contains information about the desired vendor and family (for example, if you placed a PART property in a schematic or a CONFIG PART statement in a UCF file). However, you can override the information in the NGO file with the -p option when you run NGDBuild.

-r (Ignore LOC Constraints)

The -r option eliminates all location constraints (LOC=) found in the input netlist or UCF file. Use this option when you migrate to a different device or architecture, because locations in one architecture may not match locations in another.


NOTE

If you have run NGDBuild previously on your design and NGO files are present, you must use the -nt on option the first time you use -r. This forces a rebuild of the NGO files, allowing NGDBuild to run EDIF2NGD or XNF2NGD to remove location constraints.


-sd (Search Specified Directory)

-sd search_path

The -sd option adds the specified search_path to the list of directories to search when resolving file references (that is, files specified in the schematic with a FILE=filename property) and when searching for netlist, NGO, NGC, NMC, and MEM files. You do not have to specify a search path for the top-level design netlist directory, because it is automatically searched by NGDBuild.

The search_path must be separated from the -sd by spaces or tabs (for example, -sd designs is correct, -sddesigns is not).

You can specify multiple -sd options on the command line. Each must be preceded with -sd; you cannot combine multiple search_path specifiers after one -sd. For example, the following syntax is not acceptable.

-sd /home/macros/counter /home/designs/pal2

The following syntax is acceptable.

-sd /home/macros/counter -sd /home/designs/pal2

-u (Allow Unexpanded Blocks)

In the default behavior of NGDBuild (without -u option), NGDBuild generates an error if a block in the design cannot be expanded to NGD primitives. If this error occurs, an NGD file is not written.

If you enter the -u option, NGDBuild generates a warning instead of an error if a block cannot be expanded, and writes an NGD file containing the unexpanded block.

You may want to run NGDBuild with the -u option to perform preliminary mapping, placement and routing, timing analysis, or simulation on the design even though the design is not complete. To ensure the unexpanded blocks remains in the design when it is mapped, run the MAP program with the -u (Do Not Remove Unused Logic) option.

-uc (User Constraints File)

-uc ucf_file[.ucf]

The -uc option specifies a UCF (User Constraints File) for the Netlister Launcher to read. The UCF file contains timing and layout constraints that affect how the logical design is implemented in the target device.

The user constraints file must have a .ucf extension. If you specify a user constraints file without an extension, NGDBuild appends the .ucf extension to the file name. If you specify a file name with an extension other than .ucf, you get an error message and NGDBuild does not run.

If you do not enter a -uc option and a UCF file exists with the same base name as the input design file and a .ucf extension, NGDBuild automatically reads the constraints in this UCF file.

The User Constraints File is described in “The User Constraints (UCF) File” chapter.

-ur (Read User Rules File)

-ur rules_file[.urf]

The -ur option specifies a user rules file for the Netlister Launcher to access. This file determines the acceptable netlist input files, the netlist readers that read these files, and the default netlist reader options.

The user rules file must have a .urf extension. If you specify a user rules file with no extension, NGDBuild appends the .urf extension to the file name. If you specify a file name with an extension other than .urf, you get an error message and NGDBuild does not run.

The user rules file is described in the “User Rules File” section of the “EDIF2NGD, XNF2NGD, and NGDBuild” appendix.

Next