Two netlist translation programs allow you to read netlists into the Xilinx software tools. EDIF2NGD allows you to read an EDIF 2 0 0 (Electronic Data Interchange Format) file. XNF2NGD allows you to read an XNF (Xilinx Netlist Format). In the “Design Entry Flow” figure, these programs are contained within the “Netlist Translation” block. The NGDBuild program automatically invokes these programs as needed to convert your EDIF or XNF file to the required format for the Xilinx software tools.
Following are descriptions of the EDIF2NGD, XNF2NGD, and NGDBuild programs.
EDIF2NGD converts an EDIF netlist to an NGO file. 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 logical components and hierarchy specified in the input design file.
If the input file is an EDIF file, the Netlist Launcher in NGDBuild will automatically invoke EDIF2NGD. (The variations of EDIF from Xilinx Alliance EDA partners are automatically recognized and processed by EDIF2NGD.) The program then converts the resulting NGO file into an NGD file which can be mapped. The resulting NCD file can then be placed and routed.
The Xilinx Development System toolset can understand EDIF files developed using components from Xilinx Unified Libraries or XSI (Xilinx Synopsys Interface) Libraries.
As input, EDIF2NGD uses the following files.
For details on EDIF2NGD, see the “NGDBuild” Chapter of the Development System Reference Guide.
XNF2NGD allows you to convert an XNF (Xilinx Netlist Format) file to an NGO file, which is a binary file containing a logical description of the design in terms of its original components and hierarchy. After you convert the XNF file to an NGO file, you run the NGDBuild program to create an NGD file. The NGD file expands the design to include a description reduced to Xilinx primitives.
XNF2NGD uses the following files as inputs.
If the input file is an XNF file, the Netlist Launcher in NGDBuild will automatically invoke XNF2NGD. XNF2NGD then converts the resulting NGO file into an NGD file. The NGD file can be mapped, and the resulting NCD file can be placed and routed.
XNF has been retained for upward compatibility from older netlist versions. The XNF format does not support architecture enhancements in devices beyond the XC4000E architecture.
For example, an XC4000E architecture can be migrated to a later architecture, such as the XC4000XL, using XNF as the input format.
However, the advanced architectural features of the XC4000XL device would not be available in the XNF format. Xilinx has migrated to the industry standard EDIF input format, which is supported for all architectures in the Alliance 1.5 software.
For more information on XNF2NGD, see the “NGDBuild” Chapter of the Development System Reference Guide.
The NGDBuild program supports multiple EDA vendor entry file types, along with various Xilinx device architectures. The “VHDL and Verilog Simulation Flow” figure shows a graphical representation of this process.
This program carries out three functions during the design implementation process. First, the Netlister Launcher calls netlist readers and creates a native netlist, using one of the supported input file types.
The Netlister Launcher, which is part of NGDBuild, determines whether a design object is up to date and creates a new version if it is not. It also determines which translator (XNF2NGD or EDIF2NGD) to invoke, depending on the format of the input file.
When a series of design objects is compiled into a design hierarchy, changes in the source netlists must be taken into account and out-of-date design objects must be rebuilt from these netlists.
For more information on the Netlister Launcher, see the Development System Reference Guide.
After the netlist is created, the design's elements are brought together into a single database so that subsequent operations, such as MAP and PAR, may be applied to the entire design at once.
The final function of NGDBuild consists of storing the design in an NGD (Native Generic Database) format, which consists of technology-independent primitives that are used to model all CPLDs and FPGAs. These primitives are similar to timing simulation primitives, called SIMPRIMS. The output NGD file also includes a logical description expressed in terms of the original netlist hierarchy. The NGD file can be mapped to the desired device family.
The types of input files supported by NGDBuild follow.
The netlist reader will read the constraints in the NCF file if the NCF file has the same name as the input netlist file.
The following figure represents the NGDBuild program flow.
Figure 2.2 NGDBuild |  |
The MAP program takes the NGD file and creates an NCD (Native Circuit Description) file. In the NCD format, the design is described physically in terms of the target device's resources.
PAR performs placement and routing on the NCD file, which is then fed into NGDAnno, the back-annotation program. NGDAnno produces an NGA file, which is a back-annotated NGD file.
The MAP and PAR program flows are discussed in the “Design Implementation” chapter.
