Development System Reference Guide 8.
R Xilinx is disclosing this Document and Intellectual Property (hereinafter “the Design”) to you for use in the development of designs to operate on, or interface with Xilinx FPGAs. Except as stated herein, none of the Design may be copied, reproduced, distributed, republished, downloaded, displayed, posted, or transmitted in any form or by any means including, but not limited to, electronic, mechanical, photocopying, recording, or otherwise, without the prior written consent of Xilinx.
R Preface About This Guide The Development System Reference Guide contains information about the command line software programs in the Xilinx Development System.
R Preface: About This Guide 4 • Chapter 7, “MAP”—MAP packs the logic defined by an NGD file into FPGA elements such as CLBs, IOBs, and TBUFs. • Chapter 8, “Physical Design Rule Check”—The physical Design Rule Check (DRC) comprises a series of tests run to discover physical errors in your design. • Chapter 9, “PAR”—PAR places and routes FPGA designs.
R Additional Resources Additional Resources To find additional documentation, see the Xilinx website at: http://www.xilinx.com/literature. To search the Answer Database of silicon, software, and IP questions and answers, or to create a technical support WebCase, see the Xilinx website at: http://www.xilinx.com/support. Conventions This document uses the following conventions. An example illustrates each convention.
R Preface: About This Guide Convention Meaning or Use Example Vertical ellipsis . . . Repetitive material that has been omitted IOB #1: Name = QOUT’ IOB #2: Name = CLKIN’ . . . Horizontal ellipsis . . . Repetitive material that has been omitted allow block block_name loc1 loc2 ...
Table of Contents Preface: About This Guide Guide Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Typographical . . . . . . . . . . . . . . . . .
R Xilinx Design Download Cables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Probe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 ChipScope ILA and ChipScope PRO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 FPGA Design Tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
R set (set analysis properties) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . set_constraint (set constraint for custom analysis) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . set_endpoints (set source and destination endpoints) . . . . . . . . . . . . . . . . . . . . . . . . . . set_filter (set filter for analysis) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . set_query (set up net or timegroup report) .
R Chapter 5: Logical Design Rule Check Logical DRC Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Logical DRC Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Block Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Net Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
R –equivalent_register_removal (Remove Redundant Registers) . . . . . . . . . . . . . . . . . –f (Execute Commands File) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . –gf (Guide NCD File) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . –global_opt (Global Optimization) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . –gm (Guide Mode) . . . . . . . . . . . . . . . . . .
R Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Timing-driven PAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Command Line Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 Guided PAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
R Turns Engine (PAR Multi-Tasking Option) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Turns Engine Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Turns Engine Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Turns Engine Input Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
R Chapter 12: TRACE TRACE Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 TRACE Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 TRACE Input Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212 Input files to TRACE: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
R OFFSET OUT Detail Path Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246 PERIOD Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 PERIOD Constraints Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PERIOD Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PERIOD Path . . . .
R Gclkdel0, Gclkdel1, Gclkdel2, Gclkdel3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GSR_cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GWE_cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GTS_cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HswapenPin . . .
R USE Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scan Port Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TAP Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Boundary Register Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
R Chapter 18: CPLDfit CPLDfit Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CPLDfit Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CPLDfit Input Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CPLDfit Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
R TAEngine Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 –detail (Detail Report) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 –iopath (Trace Paths) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 –l (Specify Output Filename) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
R –tp (Bring Out Global 3-State Net as Port) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326 –w (Overwrite Existing Files) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326 Verilog-Specific Options for Functional and Timing Simulation . . . . . . . . . . . . . . . . –insert_glbl (Insert glbl.v Module) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . –ism (Include SimPrim Modules in Verilog File) . . . . . . .
R Preserving and Writing Hierarchy Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 Testbench File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 Hierarchy Information File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 Dedicated Global Signals in Back-Annotation Simulation . . . . . . . . . . . . . . . . . .
R Chapter 24: Data2MEM Data2MEM Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367 Data2MEM Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368 Data2MEM Input and Output Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368 Block RAM Memory Map (.bmm) files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
R Chapter 1 Introduction This chapter describes the command line programs for the Xilinx development system. The chapter contains the following sections: • “Command Line Program Overview” • “Command Line Syntax” • “Command Line Options” • “Invoking Command Line Programs” Command Line Program Overview Xilinx command line programs allow you to implement and verify your design. The following table lists the programs you can use for each step in the design flow.
R Chapter 1: Introduction Command Line Syntax Command line syntax always begins with the command line program name. The program name is followed by any options and then file names. Use the following rules when specifying command line options: • Enter options in any order. • Precede options with a hyphen (-) and separate them with spaces. • Be consistent with upper case and lower case. • When an option requires a parameter, separate the parameter from the option by spaces or tabs.
R Command Line Options • To insert certain command options and file names within the command line, as in the following example: par -f placeoptions -s 4 -f routeoptions design_i.ncd design_o.ncd placeoptions is the name of a file containing placement command parameters. routeoptions is the name of a file containing routing command parameters. You create the command file in ASCII format. Use the following rules when creating the command file: • Separate program options and file names with spaces.
R Chapter 1: Introduction Symbol Description | Logical OR to show a choice of one out of many items. The OR operator may only separate logical groups or literal keywords. () Encloses a logical grouping for a choice between subformats. Following are examples of syntax used for file names: • shows that typing the .ncd extension is optional but that the extension must be .ncd. • > shows that the .
R Command Line Options –p (Part Number) You can use the –p option with the EDIF2NGD, NGDBuild, MAP, and XFLOW programs to specify the part into which your design will be implemented.
R Chapter 1: Introduction Table 1-2: Part Number Examples Specification DevicePackage Examples xc4fx12sf363 xc3s100evq100 Device–Package xc4vfx12-sf363 xc3s100e-vq100 DeviceSpeed–Package xc4vfx1210-sf363 xc3s100e4-vq100 DevicePackage–Speed xc4fx12sf363-10 xc3s100evq100-4 Device–Speed–Package xc4vfx12-10-sf363 xc3s100e-4-vq100 Device–SpeedPackage xc4vfx12-10sf363 xc3s100e-4vq100 Invoking Command Line Programs You start Xilinx Development System command line programs by entering a command at t
R Chapter 2 Design Flow This chapter describes the process for creating, implementing, verifying, and downloading designs for FPGA and CPLD devices. For a complete description of FPGAs and CPLDs, refer to the Xilinx Data Sheets at http://www.xilinx.com/xlnx/xweb/xil_publications_index.
R Chapter 2: Design Flow The following figure shows the standard Xilinx design flow. Design Verification Design Entry Functional Simulation Design Synthesis Design Implementation Static Timing Analysis Optimization FPGAs Mapping Placement Routing Back Annotation CPLDs Fitting Timing Simulation Bitstream Generation Download to a Xilinx Device In-Circuit Verification X9537 Figure 2-1: 30 www.xilinx.
R Design Flow Overview The following figure shows the Xilinx software flow chart for FPGA designs. Schematic Libraries CORE Generator Synthesis Libraries HDL Simulation Libraries Testbench Stimulus Symbol Schematic Capture NGC Synthesis NGC (XST Netlist) EDIF 2 0 0 & Constraints/NCF UCF NGDBuild NGDBuild NGDBuild Simulation V& SDF 2.1 VHD & SDF 2.
R Chapter 2: Design Flow The following figure shows the Xilinx software flow chart for CPLD designs. CORE Generator Schematic Libraries Synthesis Libraries HDL Simulation Libraries Testbench Stimulus Symbol Schematic Capture NGC Synthesis NGC (XST Netlist) EDIF 2 0 0 & Constraints/NCF NGDBuild NGDBuild Simulation V& SDF 2.1 VHD & SDF 2.1 EDIF 200 NetGen NGDBuild NGD GYD CPLD Fitter JED VM6 iMPACT Timing Analyzer X10294 Figure 2-3: 32 Xilinx Software Design Flow (CPLDs) www.
R Design Entry and Synthesis Design Entry and Synthesis You can enter a design with a schematic editor or a text-based tool. Design entry begins with a design concept, expressed as a drawing or functional description. From the original design, a netlist is created, then synthesized and translated into a native generic object (NGO) file. This file is fed into the Xilinx software program called NGDBuild, which produces a logical native generic database (NGD) file.
R Chapter 2: Design Flow In hierarchical designing, a specific hierarchical name identifies each library element, unique block, and instance you create. The following example shows a hierarchical name with a 2-input OR gate in the first instance of a multiplexer in a 4-bit counter: /Acc/alu_1/mult_4/8count_3/4bit_0/mux_1/or2 Xilinx strongly recommends that you name the components and nets in your design. These names are preserved and used by the FPGA Editor tool.
R Design Entry and Synthesis HDL Entry and Synthesis A typical Hardware Description Language (HDL) supports a mixed-level description in which gate and netlist constructs are used with functional descriptions. This mixed-level capability enables you to describe system architectures at a high level of abstraction, then incrementally refine the detailed gate-level implementation of a design. HDL descriptions offer the following advantages: • You can verify design functionality early in the design process.
R Chapter 2: Design Flow Block Placement Block placement can be constrained to a specific location, to one of multiple locations, or to a location range. Locations can be specified in the schematic, with synthesis tools, or in the User Constraints File (UCF). Poor block placement can adversely affect both the placement and the routing of a design. Only I/O blocks require placement to meet external pin requirements. Timing Specifications You can specify timing requirements for paths in your design.
R Design Implementation The following figure shows the design implementation process for FPGA designs: NGDBuild UCF NGD Constraints Editor Floorplanner MAP NCD & PCF FPGA Editor TRACE & Timing Analyzer PAR NCD BitGen BIT PROMGen iMPACT X10296 Figure 2-5: Development System Reference Guide Design Implementation Flow (FPGAs) www.xilinx.
R Chapter 2: Design Flow The following figure shows the design implementation process for CPLD designs: NGDBuild Implementation Options NGD CPLD Fitter Design Loader Auto Device/Speed Selector Logic Synthesis Technology Mapping Global Net Optimization Partitioning Logic Optimization Export Level Generator Exporting Assignments PTerm Mapping Pin Feedback Generation Post-Mapping Enhancements Power/Slew Optimization Routing RPT Fitter Report (Text) GYD VM6 HPLUSAS6 VM6 HPREP6 JED iMPACT
R Design Implementation Mapping (FPGAs Only) For FPGAs, the MAP command line program maps a logical design to a Xilinx FPGA. The input to MAP is an NGD file, which contains a logical description of the design in terms of both the hierarchical components used to develop the design and the lower-level Xilinx primitives, and any number of NMC (hard placed-and-routed macro) files, each of which contains the definition of a physical macro.
R Chapter 2: Design Flow Design Verification Design verification is testing the functionality and performance of your design. You can verify Xilinx designs in the following ways: • Simulation (functional and timing) • Static timing analysis • In-circuit verification The following table lists the different design tools used for each verification type.
R Design Verification Design verification procedures should occur throughout your design process, as shown in the following figures.
R Chapter 2: Design Flow The following figure shows the verification methods of the design flow for CPLDs.
R Design Verification The following figures show the back-annotation flows: NGD Logical Design MAP PCF Simulation Netlist NCD Physical Design (Mapped) NCD Equivalence Checking Netlist NetGen PAR Static Timing Analysis Netlist NCD Physical Design (Placed and Routed) X10298 Figure 2-9: Back-Annotation Flow for FPGAs EDIF V NetGen SDF VHD SDF NGD Logical Design Command line only Optimization and Fitting NGA VM6 Physical Design TSIM Timing Simulator X10297 Figure 2-10: Development System
R Chapter 2: Design Flow NetGen NetGen is a command line program that distributes information about delays, setup and hold times, clock to out, and pulse widths found in the physical NCD design file back to the logical NGD file and generates a Verilog or VHDL netlist for use with supported timing simulation, equivalence checking, and static timing analysis tools. NetGen reads an NCD as input. The NCD file can be a mapped-only design, or a partially or fully placed and routed design.
R Design Verification Timing Simulation Timing simulation verifies that your design runs at the desired speed for your device under worst-case conditions. This process is performed after your design is mapped, placed, and routed for FPGAs or fitted for CPLDs. At this time, all design delays are known. Timing simulation is valuable because it can verify timing relationships and determine the critical paths for the design under worst-case conditions.
R Chapter 2: Design Flow The following figure shows when you can perform functional and timing simulation: HDL Design UniSim Library Testbench Stimulus HDL RTL Simulation Synthesis LogiBLOX Modules Post-Synthesis Gate-Level Functional Simulation CORE Generator Modules Xilinx Implementation HDL Timing Simulation SimPrim Library X9243 Figure 2-11: Simulation Points for HDL Designs The three primary simulation points can be expanded to allow for two post-synthesis simulations.
R Design Verification The libraries required to support the simulation flows are described in detail in the “VHDL/Verilog Libraries and Models” section of the Synthesis and Simulation Design Guide. The flows and libraries support close functional equivalence of initialization behavior between functional and timing simulations. This is due to the addition of new methodologies and library cells to simulate Global Set/Reset (GSR) and Global 3-State (GTS) behavior.
R Chapter 2: Design Flow In-Circuit Verification As a final test, you can verify how your design performs in the target application. In-circuit verification tests the circuit under typical operating conditions. Because you can program your Xilinx devices repeatedly, you can easily load different iterations of your design into your device and test it in-circuit. To verify your design in-circuit, download your design bitstream into a device with the Parallel Cable IV or MultiPRO cable.
R FPGA Design Tips FPGA Design Tips The Xilinx FPGA architecture is best suited for synchronous design. Strict synchronous design ensures that all registers are driven from the same time base with no clock skew. This section describes several tips for producing high-performance synchronous designs. Design Size and Performance Information about design size and performance can help you to optimize your design.
R Chapter 2: Design Flow Data Feedback and Clock Enable The following figure shows a gated clock. The gated clock’s corresponding timing diagram shows that this implementation can lead to clock glitches, which can cause the flip-flop to clock at the wrong time. a) Gated Clock D Q Enable Clock Clock Enable b) Corresponding Timing Diagram Clock Enable Clock Enable Output X9201 Figure 2-12: Gated Clock The following figure shows a synchronous alternative to the gated clock using a data path.
R FPGA Design Tips This circuit guarantees a minimum clock pulse width and it does not add skew to the clock. The Spartan-II, and Virtex families’ flip-flops have a built-in clock-enable (CE). a) Using a Feedback Path D Enable D Q Clock b) Corresponding Timing Diagram Clock Enable Output X9202 Figure 2-13: Synchronous Design Using Data Feedback Counters Cascading several small counters to create a larger counter is similar to a gated clock.
R Chapter 2: Design Flow The following figure shows how you can create a synchronous design using the CE input. In this case, the TC of the first stage is connected directly to the CE of the second stage. a) 16-bit counter with TC connected to the clock. Q 8. . . .Q 15 H O D Q 0. . . .Q 7 CE TC IM PR O PE R M ET TC b) 16-bit counter with TC connected to the clock-enable. Q 0. . . .Q 7 TC Q 8. . . .
R Chapter 3 Tcl Xilinx Tcl commands are compatible with the following device families: • Virtex™, Virtex™-E • Virtex™-II • Virtex™-II Pro, Virtex™-II Pro X • Virtex™-4 • Virtex ™-5 LX • Spartan™-II, Spartan™-IIE • Spartan™-3, Spartan™-3E, Spartan™-3L This chapter describes the Xilinx Tcl Shell (xtclsh) and the Xilinx Tcl commands.
R Chapter 3: Tcl The Xilinx Tcl command language also supports more advanced scripting techniques. Xilinx Tcl commands provide support for collections and objects that allow advanced users to write scripts that query the design and implementation, and then to take appropriate actions based on the results. “Tcl Commands for Advanced Scripting” are described in more detail later in the this chapter.
R Tcl Fundamentals Tcl Fundamentals This section provides some very basic information about the syntactic style of Xilinx Tcl commands. For more information about Tcl in general, please refer to Tcl documentation easily available on the internet, for example: http://www.tck.tk/doc , which is the website for the Tcl Developer Xchange. In general, Tcl commands are procedural. Each Tcl command is a series of words, with the first word being the command name.
R Chapter 3: Tcl Xilinx Namespace All Xilinx Tcl commands are part of the Tcl namespace ::xilinx::. If another Tcl package uses a command name that conflicts with a Xilinx-specific Tcl command name, the Xilinx namespace must be used to access the command. For example, type the following to create a new project using Xilinx-specific Tcl commands: % xilinx::project new It is only necessary to specify the Xilinx namespace when you have more than one namespace installed.
R Xilinx Tcl Commands Table 3-1: Xilinx Tcl Commands for General Usage Commands project (create and manage projects) Subcommands clean close delete get get_processes new open properties set timing_analysis (generate timing analysis reports) delete disable_constraints disable_cpt enable_constraints enable_cpt get new reset run saveas set set_constraint set_endpoints set_filter set_query show_settings xfile (manage project files) add get remove Development System Reference Guide www.xilinx.
R Chapter 3: Tcl Table 3-2: Xilinx Tcl Commands for Advanced Scripting Commands collection (create and manage a collection) Subcommands append_to copy equal foreach get index properties remove_from set sizeof object (get object information) get name properties type search (search and return matching objects) Tcl Commands for General Usage This section describes the Xilinx Tcl commands for general usage.
R Tcl Commands for General Usage delete (delete a partition) The partition delete command deletes the specified partition from the current ISE project. This command also deletes any properties on the partition; however, timing and other logic constraints on the instance are preserved. Note: A Partition name may not be unique to the project. In this case, the full hierarchical name of the partition should be specified for the partition you wish to delete.
R Chapter 3: Tcl Table 3-3: Partition Property Names and Tcl Returns Partition Property Name Tcl Return up_to_date_synthesis True or false, based on the status of the synthesis results. up_to_date_implementation True or false, based on the status of the implementation results. Example: % partition get /stopwatch/Inst_dcm1 preserve Description: In this example, the partition get command is used to obtain the current value of the preserve property.
R Tcl Commands for General Usage properties (list available partition properties) The partition properties command displays a list of the supported properties for all partitions. You can set the value of any property with the partition set command. % partition properties partition is the name of the Xilinx Tcl command. properties is the name of the partition subcommand.
R Chapter 3: Tcl set (set partition preserve property) The partition set command assigns the partition preserve property and value for the specified partition. % partition set preserve partition is the name of the Xilinx Tcl command. set is the name of the partition subcommand. partition specifies the full hierarchical name of the partition or the collection you wish to set the property for.
R Tcl Commands for General Usage process (run and manage project processes) The process command runs and manages all processes within the current ISE project. run (run process task) The process run command runs the synthesis and implementation tools based on the specified process task. Process tasks are entered on the command line as strings distinguished by double quotes (“). The exact text representation of the task in Project Navigator is required. For a complete list of process tasks, see Table 3-4.
R Chapter 3: Tcl Table 3-4: Process Tasks “Translate” “Map” “Generate Post-Map Static Timing” “Generate Post-Map Simulation Model” “Place & Route” “Generate Primetime Netlist” “Generate Post-Place & Route Static Timing” “Generate Post-Place & Route Simulation Model” “Generate IBIS Model” “Back-Annotate Pin Locations” “Generate Programming File” project (create and manage projects) The project command creates and manages ISE projects. A project contains all files and data related to a design.
R Tcl Commands for General Usage close (close the ISE project) The project close command closes the current ISE project. It is not necessary to specify the name of the project to close, since only one ISE project can be open at a time. % project close project is the name of the Xilinx Tcl command. close is the name of the project subcommand. Example: % project close Description: In this example, the current ISE project is closed.
R Chapter 3: Tcl instance_name specifies the name of the instance you wish to know the available processes for. Example: % project get_processes [-instance Inst_dcm1] Description: In this example, the project get_processes command is used to list all of the available processes for only the instance, Inst_dcm1. Tcl Return: The available processes as a text string. In this example, a list of processes for Inst_dcm1 is returned.
R Tcl Commands for General Usage properties (list project properties) The project properties command lists all of the project properties for the specified process or instance. % project properties [-process ][-instance limits the properties listed to only those for the specified process.
R Chapter 3: Tcl Note: Some batch application options only work when other options are specified. For example, in XST, the Synthesize Constraints File option only works if the Use Synthesis Constraints File option is also specified. Example: % project set “Map Effort Level” high Description: In this example, the project set command is used to set the map effort level to high. Map Effort Level is the name of the MAP option. High is the value set for the option.
R Tcl Commands for General Usage device_family_name specifies the device family to use with the current ISE project. Example: % project set family Virtex2p Description: In this example, the device family for the current project is set to Virtex2p. Tcl Return: The previous value. In this example, the previous device family setting is returned. set package (set device package) The project set package command specifies the device package for the current ISE project.
R Chapter 3: Tcl speed_grade specifies the speed for the target device of the current ISE project. Example: % project set speed -7 Description: In this example, the device speed for the current project is set to -7. Tcl Return: The previous value. In this example, the previous speed grade setting is returned. set top (set the top-level module/entity) The project set top command specifies the top-level module or entity in the design hierarchy.
R Tcl Commands for General Usage analysis_name specifies the name of the analysis to delete. Example: % timing_analysis delete stopwatch_timing Description: In this example, the timing_analysis delete command is used to remove the stopwatch_timing analysis, which was previously created with the timing_analysis new command. Tcl Return: 0 if the analysis was deleted, 1 otherwise.
R Chapter 3: Tcl component_name specifies the name of the components to be disabled. Example: % timing_analysis disable_cpt stopwatch_timing reg_sr_clk “ureg_1 ureg_2 ureg_3” Description: In this example, the specified components, ureg_1, ureg_2, and ureg_3 are disabled for the timing path analysis. Tcl Return: Number of components that were disabled.
R Tcl Commands for General Usage Example: % timing_analysis enable_cpt stopwatch_timing reg_sr_clk “ureg_1 ureg_2 ureg_3” Description: In this example, the specified components, ureg_1, ureg_2, and ureg_3 are enabled for the timing path analysis. Tcl Return: Number of components that were enabled. get (get analysis property) The timing_analysis get command returns the value of the specified property.
R Chapter 3: Tcl The following table lists the analysis properties for the timing_analysis command. A description of each analysis property is also included in the table. Table 3-5: Timing Analysis Properties and Descriptions Analysis Property analysis_type Description Determines which of the following analysis types will be run: auto_generated—for an analysis that discards any constraints from the UCF/PCF and instead uses constraints automatically generated by the timing wizard.
R Tcl Commands for General Usage Table 3-5: Timing Analysis Properties and Descriptions Analysis Property Description show_longest_paths CPLD report option that determines whether the longest paths are shown. show_delay_over CPLD report option that specifies only paths above the specified delay are shown in the report. show_delay_under CPLD report option that specifies that only paths below the specified delay are shown in the report.
R Chapter 3: Tcl reset (reset path filters and constraints) The timing_analysis reset command resets all existing path filters and custom constraints for the analysis. % timing_analysis reset timing_analysis is the name of the Xilinx Tcl command. reset is the name of the timing_analysis subcommand. analysis_name specifies the name of the analysis previously created with the timing_analysis new command.
R Tcl Commands for General Usage analysis_name specifies the name of the analysis previously created with the timing_analysis new command. new_file_name specifies the file name for the analysis report. Example: % timing_analysis saveas stopwatch_timing stopwatch_report Description: In this example, the timing_analysis saveas command is used to save the stopwatch_timing analysis to a report file named stopwatch_report. Tcl Return: Name of the report file.
R Chapter 3: Tcl ♦ padgroup—group definition on pad set ♦ offset—offset in/out constraint constraint_details specifies the details for the specified constraint type as follows: ♦ maxdelay—timing in ns ♦ period—time in ns and clock pad ♦ padgroup—group name and pads to be included in group ♦ offset—[timegroup] P2S|C2P [C2P|P2S ] [<“data pad or pad group”>] Note: There are two types of offset constraints: P2S, which is pad-to-synchronous
R Tcl Commands for General Usage set_filter (set filter for analysis) The timing_analysis set_filter command sets a net filter to exclude or include the specified nets from a path analysis. % timing_analysis set_filter timing_analysis is the name of the Xilinx Tcl command. set_filter is the name of the timing_analysis subcommand. analysis_name specifies the name of the analysis previously created with the timing_analysis new command.
R Chapter 3: Tcl query_items specifies the items to query. For example, -ld specifies how many longest delay nets should be displayed in the report; -hf specifies how many highest fanout nets should be displayed in the report. See the example below.
R Tcl Commands for General Usage file_name specifies the name of the source file(s) you wish to add to the current ISE project. Path names and wildcards can be used to specify one or more files to add to the project. Tcl commands support two wildcard characters: asterisk (*) to indicate multiple characters, or a question mark (?) to indicate a single character. Example: % xfile add *.vhd /mysource/mysub_dir timing.
R Chapter 3: Tcl file_name specifies the name of the file you wish to remove from the project. Example: % xfile remove stopwatch.vhd Description: In this example, the stopwatch.vhd file is removed from the current ISE project. Tcl Return: True if the file was removed; false otherwise. Note: When you remove a file, objects within the current ISE project may be invalidated (e.g., partitions and instances).
R Tcl Commands for Advanced Scripting collection_variable specifies the name of the collection variable, which references the collection. If the collection variable does not exist, then it is created. objects_to_append specifies an object or a collection of objects to be added to the collection. -unique optionally adds only objects that are not already in the collection. If the -unique option is not used, then duplicate objects may be added to the collection.
R Chapter 3: Tcl Example 2: % set colVar_2 [collection copy $colVar_1] Description: In this example, the set command creates the collection variable colVar_2. The nested collection copy command makes a duplicate of the colVar_1 collection and assigns it to the colVar2 collection variable, making it a completely separate collection. Tcl Return: A new collection. equal (compare two collections) The collection equal command compares the contents of two collections.
R Tcl Commands for Advanced Scripting foreach (iterate over elements in a collection) The collection foreach command iterates over each object in a collection through an iterator variable. The iterator variable specifies the collection to interate over and the set of commands or script to apply at each iteration. % collection foreach {body} collection is the name of the Xilinx Tcl command. foreach is the name of the collection subcommand.
R Chapter 3: Tcl Note: See also the collection set command for more information on property values for the collection command. index (extract a collection object) Given a collection and an index into it, the collection index command extracts the object at the specified index and returns the object, if the index is in range. The base collection is unchanged. The range for an index is zero (0) to one less (-1) the size of the collection obtained with the collection sizeof command.
R Tcl Commands for Advanced Scripting properties is the name of the collection subcommand. There are two collection properties: display_line_limit and display_type. These properties are supported with the collection get and collection set commands. Example: % collection properties Description: In this example, the collection properties command is used to display a list of available collection properties. Tcl Return: A list of available collection properties.
R Chapter 3: Tcl property_name and property_value specify the property name and value for all of the collection variables in the current ISE project. There are two available property settings for the collection set command, they are: display_line_limit–specifies the number of lines that can be displayed by a collection variable. This property setting is useful for very large collections, which may have thousands, if not millions of objects. The default value for this property is 100.
R Tcl Commands for Advanced Scripting get (get object properties) The object get command returns the value of the specified property. % object get object is the name of the Xilinx Tcl command. name is the name of the object subcommand. object_name specifies the object to get the property of. The object name will always be a Tcl variable. The set command is used to create a Tcl variable, as shown in the following example.
R Chapter 3: Tcl object_name specifies the object to return the name of. The object name will always be a string. The set command can be used to create a Tcl variable, as shown in the following example. Example: % set colVar [search * -type instance] % object name [collection index $colVar 1] Description: In this example, the set command is first used to create the colVar collection variable.
R Tcl Commands for Advanced Scripting type (type of object) The object type command returns the type of any Xilinx object. % object type object is the name of the Xilinx Tcl command. name is the name of the object subcommand. object_name specifies the object to return the type of. The object name will always be a Tcl variable. The set command is used to create a Tcl variable, as shown in the following example.
R Chapter 3: Tcl Example: % search “/stopwatch” -type instance Description: In this example, the search command is used to find all instances in the design. Tcl Return: A collection of objects that match the search criteria. If no matches are found, an empty collection is returned. Note: Use the collection foreach command to list or get access to each object in a collection. See foreach (iterate over elements in a collection) for more information.
R Project Properties and Options Table 3-7: XST Options Option Name Synthesis Tool “Cores Search Directories” XST “Cross Clock Analysis” XST “Custom Compile File List” XST “Decoder Extraction” XST “Equivalent Register Removal” XST “FSM Encoding Algorithm” XST “FSM Style” XST “Generate RTL Schematic” XST “Global Optimization Goal” XST “HDL INI File” XST “Hierarchy Separator” XST “Keep Hierarchy” XST “Library Search Order” XST “Logical Shifter Extraction” XST “Max Fanout” XST
R Chapter 3: Tcl Table 3-7: XST Options Option Name “Resource Sharing” XST “ROM Extraction” XST “ROM Style” XST “Safe Implementation” XST “Shift Register Extraction” XST “Slice Packing” XST “Slice Utilization Ration” XST “Synthesis Constraints File” XST “Use Clock Enable” XST “Use DSP48” XST “Use Synchronous Reset” XST “Use Synchronous Set” XST “Use Synthesis Constraints File” XST “Verilog 2001” XST “Verilog Include Directories” XST “Work Directory” XST “Write Timing Cons
R Project Properties and Options Table 3-9: MAP Options Option Name Implementation Tool “Allow Logic Optimization Across Hierarchy” MAP “CLB Pack Factor Percentage” MAP “Disable Register Ordering” MAP “Equivalent Register Removal” MAP “Extra Effort” MAP “Generate Detailed MAP Report” MAP “Global Optimization” MAP “Map Effort Level” MAP “Map Guide Design File (.
R Chapter 3: Tcl Table 3-10: PAR Options Option Name 96 Implementation Tool “Extra Effort (Highest PAR level only)” PAR “Generate Asynchronous Delay Report” PAR “Generate Clock Region Report” PAR “Generate Post-Place & Route Simulation Model” PAR “Generate Post-Place & Route Static Timing Report” PAR “Nodelist File (Unix Only)” PAR “Number of PAR Iterations (1-100)” PAR “Number of Results to Save (0-100)” PAR “Other Place & Route Command Line Options” PAR “PAR Guide Design File (.
R Example Tcl Scripts Example Tcl Scripts This section provides two example Tcl scripts. The first example is a “Sample Tcl Script for General Usage”. The second example is a “Sample Tcl Script for Advanced Scripting”. You can run these example Tcl scripts the following ways: • Enter each statement interactively at the xtclsh prompt (%). You can access the xtclsh prompt (%) from the command line by typing xtclsh, or from the Tcl Console tab in Project Navigator.
R Chapter 3: Tcl # get project properties available set props2 [project properties] puts "Project Properties for top-level module $top" $props2 # inspect the current value for the following batch application options set map_guide_mode [project get "MAP Guide Mode"] puts "MAP Guide Mode = $map_guide_mode" set par_guide_mode [project get "PAR Guide Mode"] puts "PAR Guide Mode = $par_guide_mode" # set batch application options : # 1. set synthesis optimization goal to speed # 2.
R Example Tcl Scripts # rerun with only out-of-date partitions re-implemented process run "Implement Design" # close project project close Sample Tcl Script for Advanced Scripting # create a new project and set device properties project new watchvhd.ise project set family virtex2p project set device xc2VP2 project set package fG25 project get package project set speed -7 # add the watch vhd files xfile add dve_ccir_top.v xfile add stopwatch.vhd statmatch.vhd cnt60.vhd dcm1.vhd decode.
R Chapter 3: Tcl # run with default values process run "Implement Design" # close project project close 100 www.xilinx.
R Chapter 4 PARTGen The PARTGen program is compatible with the following Xilinx devices. • Virtex™, Virtex™-E • Virtex™-II • Virtex™-II Pro, Virtex™-II Pro X • Virtex™-4 • Virtex™-5 LX • Spartan™-II, Spartan™-IIE • Spartan™-3, Spartan™-3E, Spartan™-3L • CoolRunner™ XPLA3, CoolRunner™-II • XC9500™, XC9500XL™, XC9500XV™ This chapter describes PARTGen. The chapter contains the following sections.
R Chapter 4: PARTGen PARTGen Input Files PARTGen does not have any user input files. PARTGen Output Files PARTGen outputs two file types: partlist and PKG. Partlist and PKG files are produced with the -p and -v command line options. The -p option generates a terse version of the file, while the -v option generates a verbose version of the file. Note: Partlist files are generated in both ASCII and XML formats.
R PARTGen Options Table 4-1: Values for architecture_name architecture_name Corresponding Device Product Name spartan2e Spartan-IIE spartan3 Spartan-3 spartan3e Spartan-3E xc9500 XC9500 xc9500xl XC9500XL xc9500xv XC9500XV xpla3 CoolRunner XPLA3 xbr CoolRunner-II For example, entering the command partgen -arch virtex displays the following information: Build: /build/bcxfndry/HEAD/rtf command: partgen -arch virtex Release 8.2i - PartGen HEAD Copyright (c) 1995-2006 Xilinx, Inc.
R Chapter 4: PARTGen v200 SPEEDS: -6 -5 -4 SPEEDS: -6 -5 -4 SPEEDS: -6 -5 -4 SPEEDS: -6 -5 -4 SPEEDS: -6 -5 -4 SPEEDS: -6 -5 -4 bg256 bg352 fg256 fg456 pq240 v300 bg352 bg432 fg456 pq240 v400 bg432 bg560 fg676 hq240 v600 bg432 bg560 fg676 fg680 hq240 v800 bg432 bg560 fg676 fg680 hq240 v1000 bg560 fg680 –i (Print a List of Devices, Packages, and Speeds) The –i option prints out a list of devices, packages, and speeds that have been installed.
R PARTGen Options 2s30 SPEEDS: -6 -5 -5Q SPEEDS: -6 -5 -5Q SPEEDS: -6 -5 -5Q SPEEDS: -6 -5 -5Q SPEEDS: -6 -5 -5Q SPEEDS: -7 -6 -6Q SPEEDS: -7 -6 -6Q SPEEDS: -7 -6 -6Q SPEEDS: -7 -6 -6Q SPEEDS: -7 -6 -6Q cs144 tq144 pq208 vq100 2s50 tq144 fg256 pq208 2s100 tq144 fg256 fg456 pq208 2s150 fg456 fg256 pq208 2s200 fg256 fg456 pq208 2s50e ft256 pq208 tq144 2s100e ft256 fg456 pq208 tq144 2s150e ft256 fg456 pq208 2s200e ft256 fg456 pq208 2s300e ft256 fg456 pq208 Developmen
R Chapter 4: PARTGen 2s400e SPEEDS: -7 -6 -6Q SPEEDS: -7 -6 -6Q SPEEDS: -4 SPEEDS: -4 SPEEDS: -4 SPEEDS: -4 SPEEDS: -4 SPEEDS: -4 SPEEDS: -4 SPEEDS: -4 SPEEDS: -6 -5 -4 ft256 fg456 fg676 2s600e fg456 fg676 3s50 pq208 tq144 vq100 3s200 ft256 pq208 tq144 vq100 3s400 fg456 ft256 pq208 tq144 3s1000 fg456 fg676 ft256 3s1500 fg456 fg676 3s2000 fg676 fg900 3s4000 fg900 fg1156 3s5000 fg900 fg1156 v50 bg256 cs144 fg256 pq240 tq144 106 www.xilinx.
R PARTGen Options –intstyle (Integration Style) –intstyle {ise | xflow | silent} The –intstyle option reduces screen output based on the integration style you are running. When using the –intstyle option, one of three modes must be specified: ise, xflow, or silent. The mode sets the way information is displayed in the following ways: –intstyle ise This mode indicates the program is being run as part of an integrated design environment.
R Chapter 4: PARTGen –v (Creates Package and Partlist Files) –v name The –v option generates a partlist file in ASCII and XML format for the specified name and also creates package files. Valid name entries include architectures, devices, parts. Following are example command line entries of each type: –v virtex (Architecture) –v xcv400 (Device) –v v400bg432 (Part) If no architecture, device, or part is specified with the –v option, information for every installed device is submitted to the partlist.
R Partlist File Header The first part is a header for the entry. The format of the entry looks like the following: part architecture family partname diename packagefilename Following is an example for the XCV50bg256: partVIRTEX V50bg256 NA.die v50bg256.pkg Device Attributes The header is followed by a list of device attributes. Not all attributes are applicable to all devices.
R Chapter 4: PARTGen • External Clock IOB pins: ♦ For Virtex, Virtex-E, Spartan-II, and Spartan-3E GCLKBUF0=PAD#, GCLKBUF1=PAD#, GCLKBUF2=PAD#, GCLKBUF3=PAD# ♦ For Virtex-II, Virtex-II Pro, and Virtex-4: BUFGMUX0P=PAD#, BUFGMUX1P=PAD#, BUFGMUX2P=PAD#, BUFGMUX3P=PAD#, BUFGMUX4P=PAD#, BUFGMUX5P=PAD#, BUFGMUX6P=PAD#, BUFGMUX7P=PAD# • Block RAM: NUM_BLK_RAMS=# BLK_RAM_COLS=# BLK_RAM_COL0=# BLK_RAMCOL1=# BLK_RAM_COL2=# BLK_RAM_COL_3=# BLK_RAM_SIZE=4096x1 BLK_RAM_SIZE=2048x2 BLK_RAM_SIZE=512x8 BLK_RAM_SIZ
R PKG File • Number of internal 3-state buffers in a device: NUM_TBUFS PER ROW=# • If unavailable on a particular device or package, PartGen reports: NUM_PPC=# NUM_GT=# NUM_MONITOR=# NUM_DPM=# NUM_PMCD=# NUM_DSP=# NUM_FIFO=# NUM_EMAC=# NUM_MULT=# PKG File The PKG files correlate IOBs with output pin names. The –p option generates a three column entry describing the pins. The –v option adds six more columns of descriptive pin information.
R Chapter 4: PARTGen Following are examples of the verbose pin descriptors in PARTGen: package 2v40fg256 pkpin N.C. D9 -1 N.C. pkpin DONE M12 -1 DONE pkpin VCCO N1 -1 VCCO . . . 112 N.A. N.A. N.A. www.xilinx.com N.A. N.A. N.A.
R Chapter 5 Logical Design Rule Check This program is compatible with the following families: • Virtex™, Virtex™-E • Virtex™-II • Virtex™-II Pro, Virtex™-II Pro X • Virtex™-4 • Virtex™-5 LX • Spartan™-II, Spartan™-IIE • Spartan™-3, Spartan™-3E, Spartan™-3L • CoolRunner™ XPLA3, CoolRunner™-II • XC9500™, XC9500XL™, XC9500XV™ This chapter describes the Logical Design Rule Check (DRC).
R Chapter 5: Logical Design Rule Check Logical DRC Checks The Logical DRC performs the following types of checks: • Block check • Net check • Pad check • Clock buffer check • Name check • Primitive pin check The following sections describe these checks. Block Check The block check verifies that each terminal symbol in the NGD hierarchy (that is, each symbol that is not resolved to any lower-level components) is an NGD primitive. A block check failure is treated as an error.
R Logical DRC Checks • If the PAD is an output pad, the signal it is attached to can only be connected to one of the following primitive outputs: ♦ A single buffer primitive output ♦ A single 3-state primitive output ♦ A single BSCAN primitive In addition, the signal can also be connected to one of the following primitives: ♦ A single PULLUP primitive ♦ A single PULLDOWN primitive ♦ A single KEEPER primitive Any other primitive output connections on the signal results in an error.
R Chapter 5: Logical Design Rule Check Primitive Pin Check The primitive pin check verifies that certain pins on certain primitives are connected to signals in the design. The following table shows which pins are tested on each NGD primitive type.
R Chapter 6 NGDBuild This program is compatible with the following families: • Virtex™, Virtex™-E • Virtex™-II • Virtex™-II Pro, Virtex™-II Pro X • Virtex™-4 • Virtex™-5 LX • Spartan™-II, Spartan™-IIE • Spartan™-3, Spartan™-3E, Spartan™-3L • CoolRunner™ XPLA3, CoolRunner™-II • XC9500™, XC9500XL™, XC9500XV™ This chapter describes the NGDBuild program.
R Chapter 6: NGDBuild The following figure shows a simplified version of the NGDBuild design flow. NGDBuild invokes other programs that are not shown in the following figure.
R NGDBuild Syntax NGDBuild Syntax The following command reads the design into the Xilinx Development system and converts it to an NGD file: ngdbuild [options] design_name [ngd_file[.ngd]] options can be any number of the NGDBuild command line switches listed in “NGDBuild Options”. They can be listed in any order. Separate multiple options with spaces. design_name is the top-level name of the design file you want to process.
R Chapter 6: NGDBuild • UCF file—The User Constraints File is an ASCII file that you create. You can create this file by hand or by using the Constraints Editor. See the online Help provided with the Constraints Editor for more information. The UCF file contains timing and layout constraints that affect how the logical design is implemented in the target device. The constraints in the file are added to the information in the output NGD file.
R NGDBuild Output Files NGDBuild Output Files NGDBuild creates the following files as output: • NGD file—This binary file contains a logical description of the design in terms of both its original components and hierarchy and the NGD primitives to which the design is reduced. • BLD file—This build report file contains information about the NGDBuild run and about the subprocesses run by NGDBuild. Subprocesses include EDIF2NGD, and programs specified in the URF.
R Chapter 6: NGDBuild –aul (Allow Unmatched LOCs) By default (without the –aul option), NGDBuild generates an error if the constraints specified for pin, net, or instance names in the UCF or NCF file cannot be found in the design. If this error occurs, an NGD file is not written. If you enter the –aul option, NGDBuild generates a warning instead of an error for LOC constraints and writes an NGD file.
R NGDBuild Options –insert_keep_hierarchy This option automatically attaches the KEEP_HIERARCHY constraint to each input netlist. It should only be used when performing a bottom-up synthesis flow, where separate netlists are created for each piece of hierarchy. It is highly recommended that when using this option, good design practices are used as described in the Synthesis and Simulation Design Guide.
R Chapter 6: NGDBuild –modular assemble (Module Assembly) –modular assemble -pimpath pim_directory_path –use_pim module_name1 –use_pim module_name2 ... Note: This option supports current FPGA device families. The –modular assemble option starts the final phase of the Modular Design flow. In this “Final Assembly” phase, the team leader uses this option to create a fully expanded NGD file that contains logic from the top-level design and each of the Physically Implemented Modules (PIMs).
R NGDBuild Options –modular module (Active Module Implementation) –modular module -active module_name Note: This option supports current FPGA devices. You cannot use NCD files from previous software releases with Modular Design in this release. You must generate new NCD files with the current release of the software. The –modular module option starts the second phase of the Modular Design flow.
R Chapter 6: NGDBuild 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 NGDBuild Options –uc (User Constraints File) –uc ucf_file[.ucf] The –uc option specifies a User Constraints File (UCF) for the Netlist Launcher to read. The UCF file contains timing and layout constraints that affect the way 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 .
R Chapter 6: NGDBuild 128 www.xilinx.
R Chapter 7 MAP This program is compatible with the following families: • Virtex™, Virtex™-E • Virtex™-II • Virtex™-II Pro, Virtex™-II Pro X • Virtex™-4 • Virtex™-5 LX • Spartan™-II, Spartan™-IIE • Spartan™-3, Spartan™-3E, Spartan™-3L This chapter describes the MAP program, which is used during the implementation process to map a logical design to a Xilinx FPGA.
R Chapter 7: MAP The output from MAP is an NCD (Native Circuit Description) file—a physical representation of the design mapped to the components in the targeted Xilinx FPGA. The mapped NCD file can then be placed and routed using the PAR program.
R MAP Input Files • If the physical constraints file already exists, MAP reads the file, checks it for syntax errors, and overwrites the schematic-generated section of the file. MAP also checks the user-generated section for errors and corrects errors by commenting out physical constraints in the file or by halting the operation. If no errors are found in the usergenerated section, the section is unchanged. Note: For a discussion of the output file name and its location, see “–o (Output File Name)”.
R Chapter 7: MAP • MRP (MAP report)—a file that contains information about the MAP run. The MRP file lists any errors and warnings found in the design, lists design attributes specified, and details on how the design was mapped (for example, the logic that was removed or added and how signals and symbols in the logical design were mapped into signals and components in the physical design). The file also supplies statistics about component usage in the mapped design.
R MAP Options Table 7-1: Map Options and Architectures Options Architectures –retiming Virtex-4 architectures –t All FPGA architectures –timing All FPGA architectures –tx Not used for Virtex-4, Spartan-3, Spartan3E, or Spartan-3L architectures –u All FPGA architectures –xe All FPGA architectures –bp (Map Slice Logic) The block RAM mapping option is enabled when the –bp option is specified.
R Chapter 7: MAP The default packfactor value is 100%. This value applies if you do not specify the –c option, or enter the –c option without a packfactor value. Processing a design with the –c 0 option is a good way to get a first estimate of the number of CLBs required by your design. –cm (Cover Mode) –cm {area | speed | balanced} The –cm option specifies the criteria used during the cover phase of MAP. In this phase, MAP assigns the logic to CLB function generators (LUTs).
R MAP 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 “–f (Execute Commands File)” in Chapter 1. –gf (Guide NCD File) –gf guidefile The –gf option specifies the name of an existing NCD file (from a previous MAP run) to be used as a guide for the current MAP run. Guided mapping also uses an NGM file.
R Chapter 7: MAP Note: The Incremental Design flow is being deprecated and will not be available in future releases of Xilinx software. New in 8.2i are Partitions, which provide significant flexibility and functionality for design preservation. Information on Partitions can be found in the online help included in the 8.2i software and in the “TCL chapter” of this book. Incremental Design using the map and par -gm incremental option will still work in 8.
R MAP Options The syntax for the Spartan 3/3E/3L, Virtex-4/-FX/-LX/-SX, Virtex-II, Virtex-II Pro/-X architectures follows: –k {4 |5 |6| 7| 8} You can specify the maximum size function that is covered. The default is 4. Covering to 5, 6, 7 or 8 input functions results in the use of F5MUX, F6MUX, and FXMUX. By mapping input functions into single CLBs, the –k option may produce a mapping with fewer levels of logic, thus eliminating a number of CLB-to-CLB delays.
R Chapter 7: MAP • If you do not specify an output file name with the –o option, the output file has the same name as the input file, with a .ncd extension. The file is placed in the input file’s directory • If you specify an output file name with no path specifier (for example, cpu_dec.ncd instead of /home/designs/cpu_dec.ncd), the NCD file is placed in the current working directory. • If you specify an output file name with a full path specifier (for example, /home/designs/cpu_dec.
R MAP Options –pr (Pack Registers in I/O) –pr {i | o | b} By default (without the –pr option), MAP only places flip-flops or latches within an I/O cell if your design entry method specifies that these components are to be placed within I/O cells. For example, if you create a schematic using IFDX (Input D Flip-Flop) or OFDX (Output D Flip-Flop) design elements, the physical components corresponding to these design elements must be placed in I/O cells.
R Chapter 7: MAP –timing (Timing-Driven Packing and Placement) Timing-driven packing and placement is recommended to improve design performance, timing, and packing for highly utilized designs. If the unrelated logic number (shown in the Design Summary section of the MAP report) is non-zero, then the –timing option is useful for packing more logic in the device. Timing-driven packing and placement is also recommended when there are local clocks present in the design.
R MAP Process • • The aggressive setting transforms the entire bus. ♦ Buses A, B have the same result as the on setting. ♦ Bus C is implemented entirely by CY chain. (30 ≤ the default upper limit for carry chain transformation) The limit setting is the most conservative. It transforms only that portion of the number of CLB(s) or BUFT(s) per row in a device. Note: The –tx option is not used for devices that do not have TBUFs, which include Virtex-4, Spartan-3, and Spartan-3E device families.
R Chapter 7: MAP 4. Removes unused logic. All unused components and nets are removed, unless the following conditions exist: ♦ A Xilinx S (Save) constraint has been placed on a net during design entry. If an unused net has an S constraint, the net and all used logic connected to the net (as drivers or loads) is retained. All unused logic connected to the net is deleted. For a more complete description of the S constraint, see the Constraints Guide.
R Register Ordering A CLB (Virtex/-E/-II/-II PRO or Spartan-II/IIE slice) has two flip-flops, so two register bits can be mapped into one CLB. For PAR (Place And Route) to place a register in the most effective way, you want as many pairs of contiguous bits as possible to be mapped together into the same CLBs (for example, bit 0 and bit 1 together in one CLB, bit 2 and bit 3 in another). MAP pairs register bits (performing register ordering) if it recognizes that a series of flipflops comprise a register.
R Chapter 7: MAP Because of the way signals are checked, make sure you don’t use an underscore as your bus delimiter. If you name a bus signal data0_01 and a non-bus signal data1, MAP sees them as data0 and data1 and register orders them even though you do not want them register ordered. Guided Mapping In guided mapping, an existing NCD is used to guide the current MAP run. The guide file may be from any stage of implementation: unplaced or placed, unrouted or routed.
R Simulating Map Results In the EXACT mode the mapping in the guide file is followed exactly. Any logic in the input NGD file that matches logic mapped into the physical components of the NCD guide file is implemented exactly as in the guide file. Mapping (including signal to pin assignments), placement and routing are all identical. Logic that is not matched to any guide component is mapped by a subsequent mapping step.
R Chapter 7: MAP This command creates a back-annotated simulation netlist using the logical-to-physical cross-reference file named mapped.ngm. This cross-reference file contains information about the logical design netlist, and the back-annotated simulation netlist (mapped.nga) is actually a back-annotated version of the logical design. However, if MAP makes a physical error, for example, implements an Active Low function for an Active High function, this error will not be detected in the mapped.
R MAP Report (MRP) File One way to detect the error is by running the NetGen command without using the mapped.ngm cross-reference file. netgen mapped.ncd –o mapped.nga As a result, physical simulations using the mapped.nga file should detect a physical error. However, the type of error is not always easily recognizable. To pinpoint the error, use the FPGA Editor or call Xilinx Customer Support. In some cases, a reported error may not really exist, and the CLB configuration is actually correct.
R Chapter 7: MAP • • Blocks trimmed—A trimmed block is removed because it is along a path that has no driver or no load. Trimming is recursive. For example, if Block A becomes unnecessary because logic to which it is connected has been trimmed, then Block A is also trimmed. ♦ Blocks removed—A block is removed because it can be eliminated without changing the operation of the design. Removal is recursive.
R MAP Report (MRP) File • Configuration String Information—This section, produced with the -detail option, shows configuration strings and programming properties for special components like DCMs, BRAMS, GTs and similar components. Configuration strings for slices and IOBs marked “SECURE” are not shown. • Additional Device Resource Counts—This section contains raw design statistics for Xilinx analysis purposes. Note: The MAP Report is formatted for viewing in a monospace (non-proportional) font.
R Chapter 7: MAP Table of Contents ----------------Section 1 - Errors Section 2 - Warnings Section 3 - Informational Section 4 - Removed Logic Summary Section 5 - Removed Logic Section 6 - IOB Properties Section 7 - RPMs Section 8 - Guide Report Section 9 - Area Group Summary Section 10 - Modular Design Summary Section 11 - Timing Report Section 12 - Configuration String Information Section 13 - Additional Device Resource Counts Section 1 - Errors -----------------Section 2 - Warnings -------------------W
R MAP Report (MRP) File Section 6 - IOB Properties -------------------------- IOB Name Type Direction I/O Standard Drive Strength Slew Rate CLK IOB Input LVTTL ONESOUT<0> IOB Output LVTTL 12 SLOW ONESOUT<1> IOB Output LVTTL 12 SLOW ONESOUT<2> IOB Output LVTTL 12 SLOW ONESOUT<3> IOB Output LVTTL 12 SLOW ONESOUT<4> IOB Output LVTTL 12 SLOW ONESOUT<5> IOB Output LVTTL 12 SLOW ONESOUT<6> IOB Output LVTTL 12 SLOW RESET IOB Input LVTTL STRTSTOP IOB Inpu
R Chapter 7: MAP Section 7 - RPMs ---------------xcounter/hset Section 8 - Guide Report -----------------------Guide not run on this design. Section 9 - Area Group Summary -----------------------------No area groups were found in this design. Section 10 - Modular Design Summary ----------------------------------Modular Design not used for this design. Section 11 - Timing Report -------------------------This design was not run using timing mode.
R Halting MAP MULT_ANDs = 0 4 input LUTs used as Route-Thrus = 0 4 input LUTs = 54 Slice Latches not driven by LUTs = 0 Slice Latches = 0 Slice Flip Flops not driven by LUTs = 3 Slice Flip Flops = 17 Slices = 29 Number of LUT signals with 4 loads = 4 Number of LUT signals with 3 loads = 0 Number of LUT signals with 2 loads = 4 Number of LUT signals with 1 load = 44 NGM Average fanout of LUT = 1.52 NGM Maximum fanout of LUT = 9 NGM Average fanin for LUT = 3.
R Chapter 7: MAP 154 www.xilinx.
R Chapter 8 Physical Design Rule Check This program is compatible with the following families: • Virtex™, Virtex™-E • Virtex™-II • Virtex™-II Pro, Virtex™-II Pro X • Virtex™-4 • Virtex™-5 LX • Spartan™-II, Spartan™-IIE • Spartan™-3, Spartan™-3E, Spartan™-3L The chapter describes the physical Design Rule Check program.
R Chapter 8: Physical Design Rule Check DRC Syntax The following command runs physical DRC: drc [options] file_name.ncd options can be any number of the DRC options listed in “DRC Options”. They do not need to be listed in any particular order. Separate multiple options with spaces. file_name is the name of the NCD file on which DRC is to be run. DRC Input File The input to DRC is an NCD file. The NCD file is a mapped, physical description of your design. DRC Output File The output of DRC is a TDR file.
R DRC Checks –z (Report Incomplete Programming) The –z option reports incomplete programming as errors. Certain DRC violations are considered errors when the DRC runs as part of the BitGen command but are considered warnings at all other times the DRC runs. These violations usually indicate the design is incompletely programmed (for example, a logic cell has been only partially programmed or a signal has no driver).
R Chapter 8: Physical Design Rule Check DRC Errors and Warnings A DRC error indicates a condition in which the routing or component logic does not operate correctly (for example, a net without a driver or a logic block that is incorrectly programmed). A DRC warning indicates a condition where the routing or logic is incomplete (for example, a net is not fully routed or a logic block has been programmed to process a signal but there is no signal on the appropriate logic block pin).
R Chapter 9 PAR The Place and Route (PAR) program is compatible with the following families: • Virtex™, Virtex™-E • Virtex™-II • Virtex™-II Pro, Virtex™-II Pro X • Virtex™-4 • Virtex™-5 LX • Spartan™-II, Spartan™-IIE • Spartan™-3, Spartan™-3E, Spartan™-3L The chapter contains the following sections: • “Place and Route Overview” • “PAR Process” • “Guided PAR” • “PAR Syntax” • “PAR Input Files” • “PAR Output Files” • “PAR Options” • “PAR Reports” • “Multi Pass Place and Route
R Chapter 9: PAR PAR places and routes a design based on the following considerations: • Timing-driven—The Xilinx timing analysis software enables PAR to place and route a design based upon timing constraints. See the “Timing-driven PAR” section of this chapter for more information. • Non Timing-driven (cost-based)—Placement and routing are performed using various cost tables that assign weighted values to relevant factors such as constraints, length of connection, and available routing resources.
R PAR Process PAR Process This section provides information on how placing and routing are performed by PAR, as well as information on timing-driven PAR and automatic timespecing. Placing The PAR placer executes multiple phases of the placer. PAR writes the NCD after all the placer phases are complete. During placement, PAR places components into sites based on factors such as constraints specified in the PCF file, the length of connections, and the available routing resources.
R Chapter 9: PAR If no timing constraints are found for the design or the Project Navigator "Use Timing Constraints" option is unchecked (-x option), timing constraints are automatically generated for all internal clocks. These constraints will be adjusted to get better performance as PAR runs. The level of performance achieved is in direct relation to the setting of the PAR effort level.
R Guided PAR Example 4: The following command runs PAR (using the Turns Engine) on all nodes listed in the allnodes file. It runs 10 place and route passes at placer effort level med and router effort level std on the mydesign.ncd file. par –m allnodes –pl med –rl std –n 10 mydesign.ncd output.dir Note: This command is not supported on Windows operating systems.
R Chapter 9: PAR • Any matching component in the new design is placed in the site corresponding to the location of the matching guide component, if possible. • Matching component pins are swapped to match those of the guide component with regard to matching signals, if possible. • All of the connections between matching driver and load pins of the matching signals have the routing information preserved from the guide file with the exception of Vcc and GND signals.
R PAR Syntax • Signals that differ only by additional loads in the input design have the corresponding pins routed according to the reference design in the guide file. • Guide summary information in the PAR report describes the amount of logic from the reference design that matches logic in the input design. For detailed information about designing with PCI Cores, refer to the Xilinx PCI web page at http://www.xilinx.com/systemio/pciexpress/index.htm.
R Chapter 9: PAR • PAR file—a PAR report including summary information of all placement and routing iterations. • PAD file—a file containing I/O pin assignments in a parsable database format. • CSV file—a file containing I/O pin assignments in a format supported by spreadsheet programs. • TXT file—a file containing I/O pin assignments in a ASCII text version for viewing in a text editor. • GRF (Guide Report File)— a file that is created when you use the –gf option.
R PAR Options Table 9-2: General Options Option Function Range Default –nopad Suppresses the creation of the PAD files in all three formats N/A Generate all PAD files –p Do not run the Placer N/A Run Placement –power Power Aware PAR N/A Off –r Do not run the Router N/A Run Router –ub Use bonded IOB sites for unbonded IOBs N/A Do not use bonded IOB sites –w existing_file Overwrite existing output files that have the same name and path N/A Do not overwrite –x Ignore any timing
R Chapter 9: PAR Table 9-4: Multi Pass Place and Route (MPPR) Options Option –n iteration Function Number of Placement Cost Tables to run in Multi Pass Place and Route Range Default 0-100 One (1) place and route run Note: When the value is set to 0, PAR runs up to all 100 cost tables until one meets timing.
R PAR Options –gm (Guide Mode) –gm {exact | leverage | incremental} The –gm option specifies the type of guided placement and routing PAR uses—exact, leverage, or incremental. The default is exact mode. For more information on the guide modes, see “Guided PAR”. Note: Support for the leverage guide flow (–gm incremental), without a timing-driven map run of your design, specified with the map –timing option, will not be supported in future releases of Xilinx software.
R Chapter 9: PAR –m (Multi-Tasking Mode) –m nodefile_name The –m option allows you to specify the nodes on which to run jobs when using the PAR Turns Engine. You must use this option with the -n (Number of PAR Iterations) option. par -m nodefile_name -ol high -n 10 mydesign.ncd output.dir Note: The –m option is not supported on Windows operating systems. –n (Number of PAR Iterations) –n iterations By default (without the –n option), one place and route iteration is run.
R PAR Options You can override the placer level set by the –ol option by entering a –pl (Placer Effort Level) option, and you can override the router level by entering a –rl (Router Effort Level) option. par -ol high design.ncd output.ncd design.pcf –p (No Placement) The –p option bypasses the placer and proceeds to the routing phase. A design must be fully placed when using this option or PAR will issue an error message and exit.
R Chapter 9: PAR –s (Number of Results to Save) –s number_to_save –n iterations The –s option is used with the –n option to save the number of results that you specify. By default (with no –s option), all results are saved. The valid range for the number_to_save is 1–100. The –s option compares the results of each iteration and saves the best output NCD files. The best NCDs are determined by a score assigned to each output design.
R PAR Reports –x (Performance Evaluation Mode) par –x design.ncd output.ncd design.pcf The -x option is used if there are timing constraints specified in the physical constraints file, and you want to execute a PAR run with tool-generated timing constraints instead to evaluating the performance of each clock in the design. This operation is referred to as "Performance Evaluation" mode. This mode is entered into either by using the -x option or when no timing constraints are used in a design.
R Chapter 9: PAR As the command is performed, PAR records a summary of all placement and routing iterations in one PAR file at the same level as the directory you specified, then places the output files (in NCD format) in the specified directory. Also, a Place and Route Report File and a PAD file are created for each NCD file, describing in detail each individual iteration. Note: Reports are formatted for viewing in a monospace (non-proportional) font.
R PAR Reports Number of LOCed IOBs 78 out of 80 Number of RAMB16s Number of SLICEs Overall effort level (-ol): Placer effort level (-pl): Placer cost table entry (-t): Router effort level (-rl): 1 out of 12 26 out of 1408 97% 8% 1% High (set by user) High (set by user) 1 High (set by user) Starting initial Timing Analysis. REAL time: 31 secs Finished initial Timing Analysis.
R Chapter 9: PAR Phase 12.5 Phase 12.5 (Checksum:7270df4) REAL time: 47 secs Writing design to file c:\test\par0.ncd Total REAL time to Placer completion: 47 secs Total CPU time to Placer completion: 8 secs The router portion of the PAR report shows that the router has been invoked. It displays each phase of the router and reports the number of unrouted nets, in addition to an approximate timing score in parenthesis.
R PAR Reports ************************** Generating Clock Report ************************** +---------------------+--------------+------+------+------------+----------+ | Clock Net | Resource |Locked|Fanout|Net Skew(ns)|Max Delay(ns) +---------------------+--------------+------+------+------------+----------+ |test_lutram_bram/CLK | | | | | | 1X | BUFGMUX1P| No | 43 | 0.023 | 0.724 +---------------------+--------------+------+------+------------+----------+ | clk_bram_BUFGP | BUFGMUX6S| No | 6 | 0.
R Chapter 9: PAR The last portion of the PAR report shows how many timing constraints were met and whether PAR was able to place and route the design successfully. The total time used to complete the PAR run is displayed in both REAL time and CPU time. Any errors and a message summary are also shown. All constraints were met. INFO:Timing:2761 - N/A entries in the Constraints list may indicate that the constraint does not cover any paths or that it has no requested value. Generating Pad Report.
R Multi Pass Place and Route (MPPR) One strategy for using MPPR is to set the placer effort level to high and router effort level to std to ensure a quality placement and a quick route. This strategy enables PAR to run the cost tables effectively and reduces the total runtime of all place and route iterations. When a design is very close to reaching its timing goals and can run for a long period through all the cost tables, another strategy is to use the following: par –n 0 -ol high, -xe n address.
R Chapter 9: PAR Xplorer Xplorer is a TCL script that seeks the best design performance using ISE implementation software. After synthesis generates an EDIF or NGC (XST) file, the design is ready for implementation. During this phase, you can use Project Navigator or the command line to manually apply design constraints and explore different implementation tool settings for achieving your timing goals; alternatively, you can use Xplorer.
R Xplorer Result: Xplorer implements the design with different architecture-specific optimization strategies and timing-driven placement and routing for optimal design performance. The results are summarized in the output Xplorer report (.rpt). The best run is identified at the end of the report file. Timing Closure Mode If you have a design with timing constraints and your intent is for the tools to meet the specified constraints, use the Timing Closure Mode.
R Chapter 9: PAR options can be any number of the Xplorer options listed in “Xplorer Options.” Use the -clk option for Best Performance Mode and the -uc option for Timing Closure Mode. Separate multiple options with spaces. part_name is the complete name of the Xilinx part, specified with the –p option. Note: You can also run Xplorer from the Xilinx TCL Shell, accessible through the TCL Console tab in Project Navigator.
R Xplorer Table 9-5: Xplorer Options Option Function –max_runs Specifies the maximum number of implementation iterations that Xplorer runs on a design. Limiting the number of runs may adversely affect the final achieved frequency. The number of runs can be any number between 1 and 20. By default, this option is set to 7. –no_retiming Disables retiming in MAP. The default value for this option is to perform retiming. –p Specifies the complete Xilinx part name.
R Chapter 9: PAR --------------------------------------------------------------------Run 2 --------------------------------------------------------------------Map options : Par options : -w -ol high -xe n Achieved Timing Score : 1618.00 Current Best (Lowest) Timing Score : 1002.
R ReportGen Current Best (Lowest) Timing Score : 1002.00 Current Best Run : 1 ----------------------------------------------------------------------------------------------------------------------------------------BestRun : Run 1 --------------------------------------------------------------------Map options : -timing -ol high -xe n Par options : -w -ol high Achieved Timing Score : 1002.
R Chapter 9: PAR Files output by ReportGen are placed in the current working directory or the path that is specified on the command line with the -o option. ReportGen Options. The output pad files have the same root name as the output design file, but the .txt and .csv files have the tag “pad” added to the output design name. For example, output_pad.txt. ReportGen Options You can customize ReportGen output by specifying options when you run ReportGen from the command line.
R Turns Engine (PAR Multi-Tasking Option) Turns Engine (PAR Multi-Tasking Option) This Xilinx Development System option allows you to use multiple systems (nodes) that are networked together for a multi-run PAR job, significantly reducing the total amount of time to completion. You can specify this multi-tasking option from the command line. Turns Engine Overview Before the Turns Engine was developed for the Xilinx Development System, PAR could only run multiple jobs in a linear way.
R Chapter 9: PAR As the jobs finish, the remaining jobs are started on the five nodes until all 10 jobs are complete. Since each job takes approximately one hour, all 10 jobs complete in approximately two hours. Note: You cannot determine the relative benefits of multiple placements by running the Turns Engine with options that generate multiple placements, but do not route any of the placed designs (the –r PAR option specifies no routing). The design score you receive is the same for each placement.
R Turns Engine (PAR Multi-Tasking Option) Turns Engine Output Files The naming convention for the NCD file, which may contain placement and routing information in varying degrees of completion, is placer_level_router_level_cost_table.ncd. If any of these elements are not used, they are represented by an x. For example, for the first design file run with the options –n 5 –t 16 –rl std –pl high, the NCD output file name would be high_std_16.ncd. The second file would be named high_std_17.ncd.
R Chapter 9: PAR Example for C shell: setenv PAR_M_SETUPFILE /net/${nodename}/home/jim/parmsetup Example for Bourne shell: PAR_M_SETUPFILE=/net/${nodename}/home/jim/parmsetup export PAR_M_SETUPFILE Turns Engine Environment Variables The following environment variables are interpreted by the Turns Engine manager. • PAR_AUTOMNTPT—Specifies the network automount point. The Turns Engine uses network path names to access files. For example, a local path name to a file may be designs/cpu.
R Turns Engine (PAR Multi-Tasking Option) • PAR_M_DEBUG—Causes the Turns Engine to run in debug mode. If the Turns Engine is causing errors that are difficult to correct, you can run PAR in debug mode as follows: ♦ Set the PAR_M_DEBUG variable: setenv PAR_M_DEBUG 1 • ♦ Create a node list file containing only a single entry (one node).
R Chapter 9: PAR Screen Output When PAR is running multiple jobs and is not in multi-tasking mode, output from PAR is displayed on the screen as the jobs run. When PAR is running multiple jobs in multitasking mode, you only see information regarding the current status of the Turns Engine. For example, when the job described in “Turns Engine Overview” is executed, the following screen output would be generated.
R Turns Engine (PAR Multi-Tasking Option) 5. Stop using a node — allows you to remove a node from the list so that no job runs on that node. If you select Stop using a node, you must also select from the following options. Which node do you wish to stop using? 1. jupiter 2. mars 3. mercury Enter number identifying the node.( to ignore) Enter the number identifying the node. If you enter a legal number, you are asked to make a selection from this menu. Do you wish to 1.
R Chapter 9: PAR A few of the entries are described as follows: ♦ jupiter has been running job high_high_10 for approximately 2 1/2 hours. ♦ mars has been running job high_high_11 for approximately 2 1/2 hours. ♦ mercury has been deactivated by the user with the Stop using a node option or it was not an existing node or it was not running. Nodes are pinged to see if they exist and are running before attempting to start a job. ♦ neptune has been halted immediately with job resubmission.
R Halting PAR If you use this option, you may continue the PAR operation at a later time. To do this, you must look in the PAR report file to find the point at which you interrupted the PAR run. You can then run PAR on the output NCD file produced by the interrupted run, setting command line options to continue the run from the point at which it was interrupted.
R Chapter 9: PAR 196 www.xilinx.
R Chapter 10 XPower This program is compatible with the following device families: • Virtex™, Virtex™-E • Virtex™-II • Virtex™-II Pro, Virtex™-II Pro X • Virtex™-4 • Virtex™-5 LX • Spartan™-II, Spartan™-IIE • Spartan™-3, Spartan™-3E, Spartan™-3L • CoolRunner™ XPLA3, CoolRunner™-II • XC9500™, XC9500XL™, XC9500XV™ For a complete list of supported devices: Run xpwr -ls [-arch] from the command line. See “-ls (List Supported Devices)” for additional information on this option.
R Chapter 10: XPower Files Used by XPower XPower uses the following file types: • CXT - File produced by CPLDfit and used by XPower to calculate and display power consumption. • NCD - An physical design file produced by MAP and PAR that contains information on an FPGA. Xilinx recommends using a fully placed and routed NCD design (produced by PAR) to get the most accurate power estimate. Using a mapped-only NCD (produced by MAP) file may compromise accuracy.
R Using XPower options is one or more of the XPower options listed in “Command Line Options”. Separate multiple options with spaces. design name is the name of the output power report file with a .pwr extension. If a file name is not specified with the -o option, by default XPower generates a .pwr file with the same root name as the infile. Using XPower This section describes the settings necessary to obtain accurate power and thermal estimates, and the methods that XPower allows.
R Chapter 10: XPower Other Methods of Data Entry All asynchronous signals are set using an absolute frequency in MHz. All synchronous signals are set using activity rates. An activity rate is a percentage between 0 and 100. It refers to how often the output of a registered element changes with respect to the active edges of the clock. For example, a 100MHz clock going to a flip flop with a 100% activity rate has an output frequency of 50MHz.
R Command Line Options -s (Specify VCD file) -s [simdata.vcd] Sets activity rates and signal frequencies using data from the VCD file. If no file is specified, XPower searches for an input design file with a .vcd extension. -tb (Turn On Time Based Reporting) -tb [number][unit] Turns on time-based reporting. Must be used with the -s option. XPower generates a file with a .txt extension. The specified number and unit control the time base of how often the total power is reported.
R Chapter 10: XPower Command Line Examples The following command produces a standard report, mydesign.pwr, in which the VCD file specifies the activity rates and frequencies of signals. The output loading has not been changed; all outputs assume the default loading of 10pF. The design is for FPGAs. xpwr mydesign.ncd mydesign.pcf -s timesim.vcd The following command does all of the above and generates a settings file called mysettings.xml.
R Power Reports • A Decoupling Network Summary, which contains capacitance values, recommendations, and a total for each voltage source broken down in individual capacitance ranges. • A footer containing the analysis completion date and time. Detailed Reports A detailed power report includes all of the information in a standard power report, plus power details listed for logic, signals, clocks, inputs, and outputs of the design.
R Chapter 10: XPower 204 www.xilinx.
R Chapter 11 PIN2UCF This program is compatible with the following families: • Virtex™, Virtex™-E • Virtex™-II • Virtex™-II Pro, Virtex™-II Pro X • Virtex™-4 • Virtex™-5 LX • Spartan™-II, Spartan™-IIE • Spartan™-3, Spartan™-3E, Spartan™-3L • CoolRunner™ XPLA3, CoolRunner™-II • XC9500™, XC9500XL™, XC9500XV™ This chapter describes the PIN2UCF program.
R Chapter 11: PIN2UCF The following figure shows the flow through PIN2UCF. NCD (Placed and Routed -- For FPGAs) or GYD (Pin Freeze File -- for CPLDs) PIN2UCF Report File UCF File X8629 Figure 11-1: PIN2UCF Flow The PIN2UCF program is used to back-annotate pin-locking constraints to the UCF from a successfully placed and routed design for an FPGA or a successfully fitted design for a CPLD.
R PIN2UCF Syntax PIN2UCF writes to an existing UCF under the following conditions: • The contents in the PINLOCK section are all pin lock matches, and there are no conflicts between the PINLOCK section and the rest of the UCF. • The PINLOCK section contents are all comments and there are no conflicts outside of the PINLOCK section. • There is no PINLOCK section and no other conflicts in the UCF. Note: Comments inside an existing PINLOCK section are never preserved by a new run of PIN2UCF.
R Chapter 11: PIN2UCF PIN2UCF Options This section describes the PIN2UCF command line options. –o (Output File Name) –o outfile.ucf By default (without the –o option), PIN2UCF writes an ncd_file.ucf file. The –o option specifies the name of the output UCF for the design. You can use the –o option if the UCF used for the design has a different root name than the design name.
R PIN2UCF Scenarios Table 11-1: PIN2UCF Scenarios Scenario PIN2UCF Behavior UCF is present. The UCF contains some user-specified pin-locking constraints either inside or outside of the PINLOCK section. Files Created or Updated PIN2UCF does not write the PINLOCK section. Instead, it exits after providing an error message. It writes a list of conflicting constraints. pinlock.rpt PIN2UCF writes a new PINLOCK section in the UCF after deleting the existing PINLOCK section.
R Chapter 11: PIN2UCF 210 www.xilinx.
R Chapter 12 TRACE The Timing Reporter and Circuit Evaluator (TRACE) program is compatible with the following device families: • Virtex™, Virtex™-E • Virtex™-II • Virtex™-II Pro/X • Virtex™-4 • Virtex™-5 LX • Spartan™, Spartan™-II, Spartan™-IIE • Spartan™-3, Spartan™-3E, Spartan™-3L • CoolRunner™ XPLA3, CoolRunner™-II • XC9500™, XC9500XL™, XC9500XV™ This chapter contains the following sections: • “TRACE Overview” • “TRACE Syntax” • “TRACE Input Files” • “TRACE Output Files” • “T
R Chapter 12: TRACE The following figure shows the primary inputs and outputs to TRACE. The NCD file is the output design file from MAP or PAR, which has a .ncd extension. The optional PCF is the physical constraints file, which has a .pcf extension. The TWR file is the timing report file, which has a .twr extension.
R TRACE Output Files Input files to TRACE: • NCD file—A mapped, a placed, or a placed and routed design. The type of timing information TRACE provides depends on whether the design is unplaced (after MAP), placed only, or placed and routed. • PCF—An optional, user-modifiable, physical constraints file produced by MAP. The PCF contains timing constraints used when TRACE performs a static timing analysis.
R Chapter 12: TRACE TRACE Options This section describes the TRACE command line options. –a (Advanced Analysis) The –a option is only used if you are not supplying any timing constraints (from a PCF) to TRACE. The –a option writes out a timing report with the following information: • An analysis that enumerates all clocks and the required OFFSETs for each clock. • An analysis of paths having only combinatorial logic, ordered by delay.
R TRACE Options –intstyle (Integration Style) –intstyle {ise | xflow | silent} The –intstyle option reduces screen output based on the integration style you are running. When using the –intstyle option, one of three modes must be specified: ise, xflow, or silent. The mode sets the way information is displayed in the following ways: –intstyle ise This mode indicates the program is being run as part of an integrated design environment.
R Chapter 12: TRACE –run (Run Timing Analyzer Macro) –run macro.xtm [design.ncd] [constraints.pcf] Commands used to generate custom timing reports with Timing Analyzer can be saved in a macro file and run in batch mode with the TRACE program. The –run option uses a Timing Analyzer macro file (XTM) to produce timing reports based on the commands specified in the XTM file. The –run option also generates a log file (macro_file.log) that lists all of the Timing Analyzer macro commands and any status messages.
R TRACE Options –stamp (Generates STAMP timing model files) –stamp stampfile design.ncd When you specify the –stamp option, TRACE generates a pair of STAMP timing model files--stampfile.mod and stampfile.data--that characterize the timing of a design. Note: The stamp file entry must precede the NCD file entry on the command line. The STAMP compiler can be used for any printed circuit board when performing static timing analysis.
R Chapter 12: TRACE In the TRACE report, the following information is included for the unconstrained path analysis constraint. • The minimum period for all of the uncovered paths to sequential components. • The maximum delay for all of the uncovered paths containing only combinatorial logic. • For a verbose report only, a listing of periods for sequential paths and delays for combinatorial paths.
R TRACE Reports The following command verifies the timing characteristics for the design named design1.ncd using the timing constraints contained in the timing file .pcf, and generates an error report. The error report lists the three worst errors for each constraint in timing .pcf. The error report file is called design1.twr. trce –e 3 design1.ncd timing.
R Chapter 12: TRACE Timing Verification with TRACE TRACE checks the delays in the input NCD file against your timing constraints. If delays are exceeded, TRACE issues the appropriate timing error. Note: Xilinx recommends limiting timing constraint values to 2 ms (milliseconds). Timing Constraint values more than 2 ms may result in bad values in the timing report.
R TRACE Reports The following table lists the terminology for path delay constraints: Table 12-1: Term Path Delay Constraint Terminology Definition logicdelay Pin-to-pin delay through a component. routedelay Signal delay between component pins in a path. This is an estimated delay if the design is placed but not routed. setuptime For clocked paths only, the time that data must be present on an input pin before the arrival of the triggering edge of a clock signal.
R Chapter 12: TRACE In the following figure, the clock skew Tsk is the delay from the clock input (CLKIOB) to Table 12-2: Terms Clock Skew and Setup Checking Terminology Definition constraint The required time interval for the path, either specified explicitly by you with a FROM TO constraint, or derived from a PERIOD constraint. Tpath The summation of component and connection delays along the path. Tsu (setup) The setup requirement for the destination register.
R TRACE Reports Because the total clock path delay determines the clock arrival times at the source register (TclkS) and the destination register (TclkD), this check still applies if the source and destination clocks originate at the same chip input but travel through different clock buffers and routing resources, as shown in the following figure.
R Chapter 12: TRACE The clock skew Tsk is not accounted for in setup checks covered by PERIOD constraints where the clock paths to the source and destination registers originate at different clock inputs. Reporting with TRACE The timing report produced by TRACE is a formatted ASCII (TWR) file prepared for a particular design. It reports statistics on the design, a summary of timing warnings and errors, and optional detailed net and path delay reports.
R TRACE Reports The tilde (~) also means that the path may exceed the numerical value listed next to the tilde by as much as 20%. You can use the PENALIZE TILDE constraint to penalize these delays by a specified percentage (see the Constraints Guide for a description of the PENALIZE TILDE constraint). • In a timing report, an “e” preceding a delay value shows that the delay value is estimated because the path is not routed.
R Chapter 12: TRACE Data Sheet Report The Data Sheet report summarizes the external timing parameters for your design. Only inputs, outputs and clocks that have constraints appear in the Data Sheet report for verbose and error reports. Tables shown in the Data Sheet report depend on the type of timing paths present in the design, as well as the applied timing constraints.
R TRACE Reports The maximum setup and hold times of device data inputs are listed relative to each clock input. When two or more paths from a data input exist relative to a device clock input, the worst-case setup and hold times are reported. One worst-case setup and hold time is reported for each data input and clock input combination in the design.
R Chapter 12: TRACE Following is an example of clock-to-output propagation delays in the data sheet report: Clock ck1_i to Pad ------------ ---+----------+ |clk (edge)| Destination Pad |to PAD | ------------- --+----------+ out1_o | 16.
R TRACE Reports Report Legend The following table lists descriptions of what X, R, and F mean in the data sheet report. Note: Applies to FPGA designs only.
R Chapter 12: TRACE Setup Times The external setup time is defined as the setup time of DATAPAD within IOB relative to CLKPAD within CLKIOB. When a guaranteed external setup time exists in the speed files for a particular DATAPAD and the CLKPAD pair and configuration, this number is used in timing reports.
R TRACE Reports Summary Report (Without a Physical Constraints File Specified) The following sample summary report represents the output of this TRACE command. trce –o summary.twr ramb16_s1.ncd The name of the report is summary.twr. No preference file is specified on the command line, and the directory containing the file ram16_s1.ncd did not contain a PCF called ramb16_s1.pcf. -----------------------------------------------------------------Xilinx TRACE Copyright (c) 1995-2005 Xilinx, Inc.
R Chapter 12: TRACE Timing summary: --------------Timing errors: 0 Score: 0 Constraints cover 20 paths, 21 nets, and 21 connections (100.0% coverage) Design statistics: Minimum period: 2.840ns (Maximum frequency: 352.113MHz) Maximum combinational path delay: 6.063ns Maximum net delay: 0.
R TRACE Reports Setup/Hold to clock clk ---------------+------------+------------+ | Setup to | Hold to | Source Pad | clk (edge) | clk (edge) | ---------------+------------+------------+ ad0 | 0.263(R)| 0.555(R)| ad1 | 0.263(R)| 0.555(R)| ad10 | 0.263(R)| 0.555(R)| ad11 | 0.263(R)| 0.555(R)| ad12 | 0.263(R)| 0.555(R)| ad13 | 0.263(R)| 0.555(R)| . . .
R Chapter 12: TRACE For errors in which the path delays are broken down into individual net and component delays, the report lists each physical resource and the logical resource from which the physical resource was generated. As in the other three types of reports, descriptive material appears at the top. A timing summary always appears at the end of the reports. The following sample error report (error.twr) represents the output generated with this TRACE command: trce –e 3 ramb16_s1.ncd clkperiod.
R TRACE Reports Data Path: RAMB16.A to d0 Location Delay type Delay(ns) Physical Resource Logical Resource(s) ------------------------------------------------------RAMB16.DOA0 Tbcko 3.006 RAMB16 RAMB16.A IOB.O1 net e 0.100 N$41 (fanout=1) IOB.PAD Tioop 5.481 d0 I$22 d0 ------------------------------------------------------Total 8.587ns (8.487ns logic, 0.100ns route) (98.8% logic, 1.2% route) ----------------------------------------------------------------1 constraint not met.
R Chapter 12: TRACE Clock clk to Pad ---------------+------------+ | clk (edge) | Destination Pad| to PAD | ---------------+------------+ d0 | 9.563(R)| ---------------+------------+ Timing summary: --------------Timing errors: 1 Score: 587 Constraints cover 19 paths, 0 nets, and 21 connections (100.0% coverage) Design statistics: Maximum path delay from/to any node: 8.587ns Maximum input arrival time after clock: 9.
R TRACE Reports The following sample verbose report (verbose.twr) represents the output generated with this TRACE command: trce –v 1 ramb16_s1.ncd clkperiod.pcf –o verbose_report.twr -----------------------------------------------------------------Xilinx TRACE Copyright (c) 1995-2005 Xilinx, Inc. All rights reserved. trce -v 1 ramb16_s1.ncd clkperiod.pcf -o verbose_report.twr Design file: ramb16_s1.ncd Physical constraint file: clkperiod.pcf Device,speed: xc2v250,-5 (ADVANCED 1.
R Chapter 12: TRACE Clock Path: clk to RAMB16.A Location Delay type Delay(ns) Physical Resource Logical Resource(s) ------------------------------------------------------IOB.I Tiopi 0.551 clk clk clk/new_buffer BUFGMUX.I0 net e 0.100 clk/new_buffer (fanout=1) BUFGMUX.O Tgi0o 0.225 I$9 I$9 RAM16.CLKA net e 0.100 CLK (fanout=1) ------------------------------------------------------Total 0.976ns (0.776ns logic, 0.200ns route) (79.5% logic, 20.
R OFFSET Constraints Data Sheet report: ----------------All values displayed in nanoseconds (ns) Setup/Hold to clock clk ---------------+------------+------------+ | Setup to | Hold to | Source Pad | clk (edge) | clk (edge) | ---------------+------------+------------+ ad0 | -0.013(R)| 0.325(R)| ad1 | -0.013(R)| 0.325(R)| ad10 | -0.013(R)| 0.325(R)| ad11 | -0.013(R)| 0.325(R)| . . .
R Chapter 12: TRACE OFFSET IN Constraint Examples This section describes in detail a specific example of an OFFSET IN constraint as shown in the Timing Constraints section of a timing analysis report.
R OFFSET Constraints Data Path Delay: 3.983ns (Levels of Logic = 2) Clock Path Delay: -0.485ns (Levels of Logic = 3) Clock Uncertainty: 0.000ns Data Path: wr_enl to wr_addr[2] ---------------------------------------------------------------------- OFFSET IN Detailed Path Data The first section is the data path. In the following case, the path starts at an IOB, goes through a look-up table (LUT) and is the clock enable pin of the destination flip-flop.
R Chapter 12: TRACE OFFSET IN Detail Path Clock Path The second section is the clock path. In this example the clock starts at an IOB, goes to a DCM, comes out CLK0 of the DCM through a global buffer (BUFGHUX). It ends at a clock pin of a FF. The Tdcmino is a calculated delay. This is the equation: Clock Path: wclk_in to wr_addr[2] Location Delay type Delay(ns) Logical Resource(s) ------------------------------------------------D7.I Tiopi 0.825 ---------------wclk_in write_dcm/IBUFG DCM_X0Y1.
R OFFSET Constraints ---------------------------------------------------------------------Slack: 2.684ns (requirement - (data path - clock path - clock arrival + uncertainty)) Source: wclk_in (PAD) Destination: ffl_reg (FF) Destination Clock: rclk_90 rising at 2.500ns Requirement: 4.000ns Data Path Delay: 3.183ns (Levels of Logic = 5) Clock Path Delay: -0.633ns (Levels of Logic = 3) Clock Uncertainty: 0.
R Chapter 12: TRACE Clock Path: rclk_in to ffl_reg Location Delay type Delay(ns) Logical Resource(s) ------------------------------------------------- ------------------- A8.I rclk_in Tiopi 0.825 read_ibufg CM_X1Y1.CLKIN net (fanout=1) CM_X1Y1.CLK90 Tdcmino UFGMUX5P.I0 net (fanout=1) BUFGMUX5P.O 0.798 -4.290 Tgi0o 0.852 4.OTCLK1 rclk_ibufg read_dcm rclk_90_dcm 0.589 net (fanout=2) 0.
R OFFSET Constraints OFFSET OUT Path Details The example path below passed the timing constraint by .533 ns. The slack equation shows how the slack was calculated. Data delay increases the clock to out time and clock delay also increases the clock to out time. The clock arrival time is also taken into account. In this example the clock arrival time is 0.000 ns; therefore, it does not affect the slack. If the clock edge occurs at a different time, this value is also added to the clock to out time.
R Chapter 12: TRACE BUFGMUX7P.O Tgi0o 0.589 SLICE_X4Y10.CLK net (fanout=4) 0.738 ------------------------------------------------Total logic, 2.388ns route) read_bufg rclk -0.488ns (-2.876ns OFFSET OUT Detail Path Data The second section is the data path. In this case, the path starts at an FF, goes through three look-up tables and ends at the IOB.
R PERIOD Constraints PERIOD Constraints A PERIOD constraint identifies all paths between all sequential elements controlled by the given clock signal name. For additional information on timing constraints, please refer to the Constraints Guide. PERIOD Constraints Examples The following section provides examples and details of the PERIOD constraints shown in the Timing Constraints section of a timing analysis report.
R Chapter 12: TRACE PERIOD Path The detail path section shows all of the details for each path in the analyzed timing constraint. The most important thing it does is identify if the path meets the timing requirement. This information appears on the first line and is defined as the Slack. If the slack number is positive, the path meets timing constraint by the slack amount. If the slack number is negative, the path fails the timing constraint by the slack amount.
R PERIOD Constraints The Clock Uncertainty for an OFFSET constraint might be different than the clock uncertainty on a PERIOD constraint for the same clock. The OFFSET constraint only looks at one clock edge in the equation but the PERIOD constraints takes into account the uncertainty on the clock at the source registers and the uncertainty on the clock at the destination register therefore there are two clock edges in the equation.
R Chapter 12: TRACE At the end of the path is the total amount of the delay followed by a break down of logic vs routing. This is useful information for debugging a timing failure. For more information see Timing Improvement Wizard for suggestions on how to fix a timing issues.
R PERIOD Constraints PERIOD Path with Phase This is similar to the PERIOD constraint (without PHASE). The difference for this path is the source and destination clock. The destination clock defines which PERIOD constraint the path uses. Because the destination clock is the rclk_90, this path is in the TS_rclk90_dcm PERIOD and not the TS_rclk PERIOD constraint. Notice the Requirement is now 2.5 ns and not 10 ns.
R Chapter 12: TRACE ---------------------------------------------------------------------Total 3.389ns route) 5.224ns (1.835ns logic, (35.1% logic, 64.9% route) ---------------------------------------------------------------------- Minimum Period Statistics The Timing takes into account paths that are in a FROM:TO constraints but the minimum period value does not account for the extra time allowed by multi-cycle constraints. An example of how the Minimum Period Statistics are calculated.
R Chapter 13 Speedprint Speedprint is compatible with the following families. • Virtex™, Virtex™-E • Virtex™-II • Virtex™-II Pro, Virtex™-II Pro X • Virtex™-4 • Virtex™-5 LX • Spartan™-II, Spartan™-IIE • Spartan™-3, Spartan™-3E, Spartan™-3L This chapter contains the following sections.
R Chapter 13: Speedprint Speedprint Syntax Use the following syntax to run speedprint: speedprint [options] device_name options can be any number of the Speedprint options listed in “Speedprint Options”. They do not need to be listed in any particular order. Separate multiple options with spaces. Speedprint Options This section describes the options to the Speedprint command.
R Speedprint Example Commands –v (Specify Voltage) –v voltage The –v option specifies the operating voltage of the device in volts. If this option is omitted, the worst-case voltage is used. Speedprint Example Commands The following table describes some example commands: Command Description speedprint Prints usage message speedprint 2v80 Uses the default speed grade speedprint –s -52v80 Both displays block delays for speed grade -5 speedprint -s 5 2v80 speedprint –2v50e -v 1.
R Chapter 13: Speedprint Delays are reported in picoseconds, where a range of delays is given they represent the fastest and slowest paths reported under that name.
R Chapter 14 BitGen BitGen is compatible with the following families: • Virtex™, Virtex™-E • Virtex™-II • Virtex™-II Pro, Virtex™-II Pro X • Virtex™-4 • Virtex™-5 LX • Spartan™-II, Spartan™-IIE • Spartan™-3, Spartan™-3E, Spartan™-3L This chapter contains the following sections: • “BitGen Overview” • “BitGen Syntax” • “BitGen Input Files” • “BitGen Output Files” • “BitGen Options” BitGen Overview BitGen produces a bitstream for Xilinx device configuration.
R Chapter 14: BitGen The following figure shows the BitGen input and output files: NCD Circuit Description (Placed/Routed) PCF (Optional) NKY (Optional) LL (Optional) BGN BitGen MSK (Optional) DRC BIT PROMGen RBT NKY iMPACT X9557 Figure 14-1: BitGen input and output files BitGen Syntax The following syntax creates a bitstream from your NCD file: bitgen [options] infile[.ncd] [outfile] [pcf_file.pcf] options is one or more of the options listed in “BitGen Options”.
R BitGen Input Files pcf_file is the name of a physical constraints file. BitGen uses this file to interpret CONFIG constraints, which control bitstream options. These CONFIG constraints override default behavior and can be overridden by configuration options. See “–g (Set Configuration).” BitGen automatically reads the .pcf file by default. If the PCF is the second file specified on the command line, it must have a .pcf extension. If it is the third file specified, the extension is optional; .
R Chapter 14: BitGen Table 14-1: BitGen Output Files Output File Type Output File Description .msd An ASCII file that contains only mask information for verification, including pad words and frames. No commands are included. Produced when -g Readback is specified. .msk A binary file that contains the same configuration commands as a .bit file, but has mask data where the configuration data is. This data should NOT be used to configure the device.
R BitGen Options The rawbits file consists of ASCII ones and zeros representing the data in the bitstream file. If you are using a microprocessor to configure a single FPGA, you can include the rawbits file in the source code as a text file to represent the configuration data. The sequence of characters in the rawbits file is the same as the sequence of bits written into the FPGA.
R Chapter 14: BitGen ActivateGCLK Allows any partial bitstream for a reconfigurable area to have its registered elements wired to the correct clock domain. Clock domains must be minimally defined in the NCD. Architectures: Virtex, Virtex-E, Virtex-II, Virtex-II Pro, Virtex-4, Spartan-II, Spartan-IIE, Spartan-3, Spartan-3E Settings: No, Yes Default: No ActiveReconfig Prevents the assertions of GHIGH and GSR during configuration.
R BitGen Options Compress This option uses the multiple frame write feature in the bitstream to reduce the size of the bitstream, not just the .bit file. Using the Compress option does not guarantee that the size of the bitstream will shrink. Compression is enabled by setting the BitGen option –g compress; compression is disabled by not setting it. Note that the partial bit files generated with the BitGen –r setting automatically make use of the multiple frame write feature, and are compressed bitstreams.
R Chapter 14: BitGen DCIUpdateMode This option controls how often the Digitally Controlled Impedance circuit attempts to update the impedance match for DCI IOSTANDARDs. This option is preferable to the FreezeDCI option because it has no effect on bitstream size and can be used with Encrypted bitstreams. The setting DCIUpdateMode:Quiet supersedes the setting FreezeDCI:Yes.
R BitGen Options DisableBandgap Disables bandgap generator for DCMs to save power. Architectures: Virtex-II and Virtex-II Pro, Virtex-4, Settings: No, Yes Default: No DONE_cycle Selects the Startup phase that activates the FPGA Done signal. Done is delayed when DonePipe=Yes. Architectures: Virtex, Virtex-E, Virtex-II, Virtex-II Pro, Virtex-4, Spartan-II, Spartan-IIE, Spartan-3, Spartan-3E Settings: 1, 2, 3, 4, 5, 6 Default: 4 DonePin Adds an internal pull-up to the DONE Pin pin.
R Chapter 14: BitGen DriveDone This option actively drives the DONE Pin high as opposed to using a pullup. Architectures: Virtex, Virtex-E, Virtex-II, Virtex-II Pro, Virtex-4, Spartan-II, Spartan-IIE, Spartan-3, Spartan-3E Settings: No, Yes Default: No Encrypt Encrypts the bitstream. Architectures: Virtex-II, Virtex-II Pro, Virtex-4, Settings: No, Yes Default: No Note: For more information on encryption, see the following web site: http://www.xilinx.
R BitGen Options GWE_cycle Selects the Startup phase that asserts the internal write enable to flip-flops, LUT RAMs, and shift registers. It also enables the BRAMS. Before the Startup phase both BRAM writing and reading are disabled.The Done setting asserts GWE when the DoneIn signal is High. DoneIn is either the value of the Done pin or a delayed version if DonePipe=Yes. The Keep setting is used to keep the current value of the GWE signal.
R Chapter 14: BitGen KeyFile Specifies the name of the input encryption file. Architectures: Virtex-II, Virtex-II Pro, Virtex-4, Settings: string Keyseq0, Keyseq1, Keyseq2, Keyseq3, Keyseq4, Keyseq5 Sets the key sequence for keyx. The settings are equal to the following: • S=single • F=first • M=middle • L=last Architectures: Virtex-II, Virtex-II Pro, Virtex-4, Settings: S, F, M, L Default: S LCK_cycle Selects the Startup phase to wait until DLLs/DCMs lock.
R BitGen Options M1Pin Adds an internal pull-up, pull-down or neither to the M1 pin. The following settings are available. The default is PullUp. Select Pullnone to disable both the pull-up resistor and pull-down resistor on the M1 pin. Architectures: Virtex, Virtex-E, Virtex-II, Virtex-II Pro, Virtex-4, Spartan-II, Spartan-IIE, Spartan-3, Spartan-3E Settings: Pullup, Pulldown, Pullnone Default: Pullup M2Pin Adds an internal pull-up, pull-down or neither to the M2 pin. The default is PullUp.
R Chapter 14: BitGen PartialMask0, PartialMask1, PartialMask2 Generates a bitstream comprised of only the major addresses of block type <0, 1, or 2> that have enabled value in the mask. The block type is all non-block ram initialization data frames in the applicable device and its derivatives. The mask is a hex value.
R BitGen Options PowerdownPin Puts the pin into “sleep” mode by specifying whether or not the internal pullup on the pin is enabled. Architectures: Virtex-II, Virtex-II Pro, Virtex-4, Settings: Pullup, Pullnone Default: Pullup ProgPin Adds an internal pull-up to the ProgPin pin. The Pullnone setting -disables the pullup. The pull-up affects the pin after configuration.
R Chapter 14: BitGen SEURepair This option supports single event upset repair by writing bitstreams a single frame at a time, rather than in one packet. Frame Address Register (FAR) headers are written to sequentially. First the FRAME address is written to, followed by the FRAME data. Architectures: Virtex-II, Virtex-II Pro, Virtex-4, Spartan-3, Spartan-3E Settings: No, Yes Default: No StartCBC Sets the starting cipher block chaining (CBC) value.
R BitGen Options Note: In modes where Cclk is an output, the pin is driven by an internal oscillator. TckPin Adds a pull-up, a pull-down or neither to the TCK pin, the JTAG test clock. Selecting one setting enables it and disables the others. The Pullnone setting shows there is no connection to either the pull-up or the pull-down.
R Chapter 14: BitGen UnusedPin Adds a pull-up, a pull-down, or neither to the unused device pins and the serial data output (TDO) for all JTAG instruction and data registers. Selecting one setting enables it and disables the others. The Pullnone setting shows there is no connection to either the pull-up or the pull-down. The following settings are available. The default is Pulldown.
R BitGen Options –l (Create a Logic Allocation File) This option creates an ASCII logic allocation file (design.ll) for the selected design. The logic allocation file shows the bitstream position of latches, flip-flops, IOB inputs and outputs, and the bitstream position of LUT programming and Block RAMs. In some applications, you may want to observe the contents of the FPGA internal registers at different times.
R Chapter 14: BitGen 276 www.xilinx.
R Chapter 15 BSDLAnno BSDLAnno is compatible with the following families: • Virtex™, Virtex™-E • Virtex™-II • Virtex™-II Pro, Virtex™-II Pro X • Virtex™-4 • Virtex™-5 LX • Spartan™-II, Spartan™-IIE • Spartan™-3, Spartan™-3E, Spartan™-3L • CoolRunner™ XPLA3, CoolRunner™-II • XC9500™, XC9500XL™, XC9500XV™ This chapter contains the following sections: • “BSDLAnno Overview” • “BSDLAnno Syntax” • “BSDLAnno Input Files” • “BSDLAnno Output Files” • “BSDLAnno Options” • “BSDLAnno File
R Chapter 15: BSDLAnno For most Xilinx device families, the boundary scan architecture changes after the device is configured because the boundary scan registers sit behind the output buffer and the input sense amplifier: BSCAN Register -> output buffer/input sense amp -> PAD The hardware is arranged in this way so that the boundary scan logic operates at the I/O standard specified by the design. This allows boundary scan testing across the entire range of available I/O standards.
R BSDLAnno File Composition –intstyle (Integration Style) –intstyle {ise | xflow | silent} The –intstyle option reduces screen output based on the integration style you are running. When using the –intstyle option, one of three modes must be specified: ise, xflow, or silent. The mode sets the way information is displayed in the following ways: –intstyle ise This mode indicates the program is being run as part of an integrated design environment.
R Chapter 15: BSDLAnno Logical Port Description The logical port description lists all I/Os on a device and states whether the pin is input, output, bidirectional, or unavailable for boundary scan. Pins configured as outputs are described as inout because the input boundary scan cell remains connected, even when the pin is used only as an output. Describing the output as inout reflects the actual boundary scan capability of the device and allows for greater test coverage.
R BSDLAnno File Composition "P151,P158,P166,P172,P182,P190,P196,P204,P211,P219," & "P227,P233)," & "INIT_P123:P123," & "IO_P3:P3," & "IO_P4:P4," & "IO_P5:P5," & "IO_P6:P6," & BSDLAnno does not modify the package pin-mapping. USE Statement The USE statement calls VHDL packages that contain attributes, types, and constants that are referenced in the BSDL file. For example (from the xcv50e_pq240.bsd file): use STD_1149_1_1994.all; BSDLAnno does not modify USE statements.
R Chapter 15: BSDLAnno Boundary Register Description The boundary register description gives the structure of the boundary scan cells on the device. Each pin on a device may have up to three boundary scan cells, with each cell consisting of a register and a latch. Boundary scan test vectors are loaded into or scanned from these registers. For example (from the xcv50e_pq240.
R BSDLAnno File Composition Explanation: The only modification that is made to single-ended pins is when the pin is configured as an input. In this case, the boundary scan logic is disconnected from the output driver and is unable to drive out on the pin. When a pin is configured as an output, the boundary scan input register remains connected to that pin. As a result, the boundary scan logic has the same capabilities as if the pin were configured as a bidirectional pin.
R Chapter 15: BSDLAnno Modifications to the DESIGN_WARNING Section BSDLAnno adds the following DESIGN_WARNING to the BSDL file: "This BSDL file has been modified to reflect post-configuration"& behavior by BSDLAnno. BSDLAnno does not modify the USER1,"& USER2, or USERCODE registers. For details on the features and" & limitations of BSDLAnno, please consult the Xilinx Development" & System Reference Guide.
R Chapter 16 PROMGen PROMGen is compatible with the following families: • Virtex™, Virtex™-E • Virtex™-II • Virtex™-II Pro, Virtex™-II Pro X • Virtex™-4 • Virtex™-5 LX • Spartan™-II, Spartan™-IIE • Spartan™-3, Spartan™-3E, Spartan™-3L This chapter contains the following sections: • “PROMGen Overview” • “PROMGen Syntax” • “PROMGen Input Files” • “PROMGen Output Files” • “PROMGen Options” • “Bit Swapping in PROM Files” • “PROMGen Examples” PROMGen Overview PROMGen formats a BitGe
R Chapter 16: PROMGen The following figure shows the inputs and the possible outputs of the PROMGen program: BIT PRM Memory Map PROMGen EXO PROM File MCS PROM File TEK PROM File HEX Device Configuration BIN X9560 Figure 16-1: PROMGen There are two functionally equivalent versions of PROMGen. There is a stand-alone version that you can access from an operating system prompt.
R PROMGen Options PROMGen Options This section describes the options that are available for the PROMGen command. –b (Disable Bit Swapping—HEX Format Only) This option only applies if the –p option specifies a HEX file for the output of PROMGen. By default (no –b option), bits in the HEX file are swapped compared to bits in the input BIT files. If you enter a –b option, the bits are not swapped. Bit swapping is described in “Bit Swapping in PROM Files”.
R Chapter 16: PROMGen –n (Add BIT FIles) –n file1[.bit] file2[.bit]... This option loads one or more BIT files up or down from the next available address following the previous load. The first –n option must follow a –u or –d option because -n does not establish a direction. Files specified with this option are not daisy-chained to previous files. Files are loaded in the direction established by the nearest prior –u, –d, or – n option. The following syntax shows how to specify multiple files.
R PROMGen Options –s (PROM Size) –s promsize1 promsize2... This option sets the PROM size in kilobytes. The PROM size must be a power of 2. The default value is 64 kilobytes. The –s option must precede any –u, –d, or –n options. Multiple promsize entries for the –s option indicates the PROM will be split into multiple PROM files. Note: PROMGen PROM sizes are specified in bytes. See the –x option for more information. –t (Template File) –t templatefile.
R Chapter 16: PROMGen –z (Enable Compression) –z version The –z option enables compression for a Xilinx multi-bank PROM. All version will be compressed if one is not specified. Bit Swapping in PROM Files PROMGen produces a PROM file in which the bits within a byte are swapped compared to the bits in the input BIT file.
R PROMGen Examples PROMGen Examples To load the file test.bit up from address 0x0000 in MCS format, enter the following information at the command line: promgen –u 0 test To daisy-chain the files test1.bit and test2.bit up from address 0x0000 and the files test3.bit and test4.bit from address 0x4000 while using a 32K PROM and the Motorola EXORmax format, enter the following information at the command line: promgen –s 32 –p exo –u 00 test1 test2 –u 4000 test3 test4 To load the file test.
R Chapter 16: PROMGen 292 www.xilinx.
R Chapter 17 IBISWriter The IBISWriter program is compatible with the following families: • Virtex™, Virtex™-E • Virtex™-II • Virtex™-II Pro, Virtex™-II Pro X • Virtex™-4 • Virtex™-5 LX • Spartan™-II, Spartan™-IIE • Spartan™-3, Spartan™-3E, Spartan™-3L • CoolRunner™ XPLA3, CoolRunner™-II • XC9500™, XC9500XL™, XC9500XV™ This chapter describes the IBISWriter program.
R Chapter 17: IBISWriter to the 50 ohms impedance assumed by XCITE standards. If not specified, the default impedance value is 50 ohms. The IBIS standard specifies the format of the output information file, which contains a file header section and a component description section. The Golden Parser has been developed by the IBIS Open Forum Group (http://www.eigroup.org/ibis) to validate the resulting IBIS model file by verifying that the syntax conforms to the IBIS data format.
R IBISWriter Input Files IBISWriter Input Files IBISWriter requires a design source file as input. • FPGA Designs Requires a physical description of the design in the form of an NCD file with a .ncd file extension. • CPLD Designs The input is produced by CPLDfit and has a .pnx file extension. IBISWriter Output Files IBISWriter outputs an .ibs ASCII file.
R Chapter 17: IBISWriter Table 17-1: –g Options Architecture Option Value Description Virtex-E OperatingConditions Typical_Slow_Fast, Mixed Use this option to set operating condition parameters. Typical_Slow_Fast refers to operating range defined by temperature, VCCIO, and manufacturing process ranges. If no –g option is given, the default value Typical_Slow_Fast is used.
R IBISWriter Options –pin (Generate Package Parasitics) The –pin option when enabled includes the per pin parasitics information, if available, for the given device-package combination. Some device-package combinations, like Virtex™4, do not have this information available. When –pin is enabled for Virtex™-4 designs, IBISWriter adds a section to the output file that contains RLC parasitics (in a matrix format) for each package pin. The –pin option is useful for analyzing timing and signal integrity.
R Chapter 17: IBISWriter 298 www.xilinx.
R Chapter 18 CPLDfit CPLDfit is compatible with the following families: • CoolRunner™ XPLA3, CoolRunner™-II • XC9500™, XC9500XL™, XC9500XV™ This chapter describes the CPLDfit program.
R Chapter 18: CPLDfit CPLDfit Syntax Following is the command line syntax for running the CPLDfit program: cpldfit infile.ngd [options] options can be any number of the CPLDfit options listed in the “CPLDfit Options” section of this chapter. They do not need to be listed in any particular order. Separate multiple options with spaces. CPLDfit Input Files CPLDfit takes the following file as input: • NGD file—Native Generic Database file output by NGDBuild.
R CPLDfit Options CPLDfit Options CPLDfit uses the following option files: –blkfanin (Specify Maximum Fanin for Function Blocks) -blkfanin [limit:4,40] The -blkfanin option specifies the maximum number of function block inputs to use when fitting a device. If the value is near the maximum, this option reduces the possibility that design revisions will be able to fit without changing the pin-out.
R Chapter 18: CPLDfit –inputs (Number of Inputs to Use During Optimization) -inputs [limit:2,36] The -inputs option specifies the maximum number of inputs for a single equation. The higher this value, the more resources a single equation may use, possibly limiting the number of equations allowed in a single function block. The maximum limit varies with each CPLD architecture.
R CPLDfit Options –nofbnand (Disable Use of Foldback NANDS) This option disables the use of the Foldback Nand when fitting the design. This option is off by default. Architecture Support: CoolRunner XPLA3 –nogclkopt (Disable Global Clock Optimization) The -nogclkopt option turns off automatic global clock inferring. This option is off by default. –nogsropt (Disable Global Set/Reset Optimization) This option turns off automatic global set/reset inferring.
R Chapter 18: CPLDfit –optimize (Optimize Logic for Density or Speed) -optimize density|speed This -optimize option directs CPLDfit to optimize the design for density or speed. Optimizing for density results in a slower speed but uses resource sharing to allow more logic to fit into a device. Optimizing for speed uses less resource sharing but flattens the logic, which results in fewer levels of logic (faster). Density is the default argument for this option.
R CPLDfit Options –slew (Set Slew Rate) -slew [fast|slow|auto] The -slew option specifies the default slew rate for output pins. Fast and slow are selfexplanatory. The auto setting allows CPLDfit to choose which slew rate to use based on the timing constraints. The default setting is fast. –terminate (Set to Termination Mode) -terminate [pullup|keeper|float] The -terminate option globally sets all inputs and tristatable outputs to the specified form of termination.
R Chapter 18: CPLDfit 306 www.xilinx.
R Chapter 19 TSIM TSIM is compatible with the following families: • CoolRunner™ XPLA3, CoolRunner™-II • XC9500™, XC9500XL™, XC9500XV™ This chapter describes the TSIM program. This chapter includes the following sections: • “TSIM Overview” • “TSIM Syntax” • “TSIM Input Files” • “TSIM Output Files” TSIM Overview The TSIM program is a command line executable that takes an implemented CPLD design file (VM6) as input and outputs an annotated NGA file used by the NetGen program.
R Chapter 19: TSIM TSIM Input Files TSIM uses the following file as input: VM6 file—This file is a database file, output by CPLDfit, that contains the mapping of the user design into the target CPLD architecture. TSIM Output Files TSIM outputs the following file: NGA file—This back-annotated logical design file is used as an input file for the NetGen Timing Simulation flow. 308 www.xilinx.
R Chapter 20 TAEngine TAEngine is compatible with the following families: • CoolRunner™ XPLA3, CoolRunner™-II • XC9500™, XC9500XL™, XC9500XV™ This chapter describes the Timing Analysis Engine (TAEngine) program. TAEngine is a command line executable that performs static timing analysis on implemented Xilinx CPLD designs.
R Chapter 20: TAEngine The following figure shows the design flow for the TAEngine program: VM6 Fit CPLD Design TAEngine TIM Static Timing Report X10039 Figure 20-1: TAEngine Design Flow TAEngine Syntax Following is the command line syntax for running TAEngine: taengine design_name.vm6 [options] design_name is the name of the VM6 design file. options can be any number of the TAEngine options listed in the “TAEngine Options” section of this chapter.
R TAEngine Options TAEngine Options This section describes the TAEngine command line options. –detail (Detail Report) –detail The –detail option is used to produce a detail formatted TAEngine report (TIM) that shows static timing analysis for all paths in the design, as well as details for the delays in each path. –iopath (Trace Paths) –iopath The –iopath option instructs TAEngine to trace paths through bi-directional pins. –l (Specify Output Filename) –l output_file.
R Chapter 20: TAEngine 312 www.xilinx.
R Chapter 21 Hprep6 Hprep6 is compatible with the following families: • CoolRunner™ XPLA3, CoolRunner™-II • XC9500™, XC9500XL™, XC9500XV™ This chapter describes the Hprep6 program. Hprep6 is a command line executable that takes an implemented CPLD design file (VM6) as input and generates a programming file for configuring a Xilinx CPLD device.
R Chapter 21: Hprep6 Hprep6 Syntax Following is the command line syntax for running the Hprep6 program: hprep6 –i design_name.vm6 [options] design_name is the name of the input design file. The -i option is required to specify the input .vm6 file. options can be any number of the Hprep6 options listed in the “Hprep6 Options” section of this chapter. They do not need to be listed in any particular order. Separate multiple options with spaces.
R Hprep6 Options –n (Specify Signature Value for Readback) -n [signature] The –signature option is applicable to the XC9500/XL/XV devices only. The value entered in the signature field programs a set of bits in the CPLD that may be read-back via JTAG after programming. This is often used as to identify the version of a design programmed into a device.
R Chapter 21: Hprep6 316 www.xilinx.
R Chapter 22 NetGen The NetGen program is compatible with the following families: • Virtex™, Virtex™-E • Virtex™-II • Virtex™-II Pro, Virtex™-II Pro X • Virtex™-4 • Virtex™-5 LX • Spartan™-II, Spartan™-IIE • Spartan™-3, Spartan™-3E, Spartan™-3L • CoolRunner™ XPLA3, CoolRunner™-II • XC9500™, XC9500XL™, XC9500XV™ This chapter describes the NetGen program and contains the following sections: • “NetGen Overview” • “NetGen Simulation Flow” • “NetGen Functional Simulation Flow” • “NetGe
R Chapter 22: NetGen The flow type that NetGen runs is based on the input design file (NGC, NGD, or NCD). The following table shows the output file types, based on the input design files: Table 22-1: NetGen Output File Types Input Design File Output File Type NGC UNISIM-based functional simulation netlist NGD SIMPRIM-based functional netlist NCA from CPLD SIMPRIM-based netlist, along with a full timing SDF file.
R NetGen Simulation Flow NetGen Supported Flows NetGen can be described as having three fundamental flows: simulation, equivalency checking, and third-party static timing analysis. This chapter contains flow-specific sections that detail the use and features of NetGen support flows and describe any subflows. For example, the simulation flow includes two flows types: functional simulation and timing simulation.
R Chapter 22: NetGen The Functional Simulation flow uses the following files as input: • NGC —This file output by XST is used to create a UNISIM-based netlist suitable for using with IP Cores and performing post-synthesis functional simulation. • NGD—This file output by NGDBuild contains a logical description of the design and is used to create a SIMPRIM-based netlist. Notes on Functional Simulation for UNISIM-based Netlists For XST users, the output NGC file can be entered on the command line.
R NetGen Timing Simulation Flow Input file types depend on whether you are using an FPGA or CPLD design. Please refer to “FPGA Timing Simulation” and “CPLD Timing Simulation” for design-specific information, including input file types. A complete list of command line options for performing NetGen Timing Simulation appears at the end of this section. Syntax for NetGen Timing Simulation The following command runs the NetGen Timing Simulation flow: netgen -sim -ofmt {verilog|vhdl} [options] input_file[.
R Chapter 22: NetGen Output files for FPGA Timing Simulation • SDF file—This SDF 3.0 compliant standard delay format file contains delays obtained from the input design files. • V file—This is a IEEE 1364-2001 compliant Verilog HDL file that contains the netlist information obtained from the input design files. This file is a simulation model of the implemented design and cannot be synthesized or used in any manner other than simulation. • VHD file—This VHDL IEEE 1076.
R NetGen Timing Simulation Flow • V file—This is a IEEE 1364-2001 compliant Verilog HDL file that contains netlist information obtained from the input NGA file. This file is a simulation model of the fitted design and cannot be synthesized or used in any manner other than simulation. • VHD file—This VHDL IEEE 1076.4 VITAL-2000 compliant VHDL file contains netlist information obtained from the input NGA file.
R Chapter 22: NetGen Note: Do not use GR, GSR, PRLD, PRELOAD, or RESET as port names, because these are reserved names in the Xilinx software. This option is ignored by UNISIM-based flows, which use an NGC file as input. –insert_pp_buffers (Insert Path Pulse Buffers) –insert_pp_buffers true|false The –insert_pp_buffers option controls whether path pulse buffers are inserted into the output netlist to eliminate pulse swallowing.
R NetGen Timing Simulation Flow –ofmt (Output Format) -ofmt verilog|vhdl The –ofmt option is a required option that specifies output format of either Verilog or VHDL netlists. –pcf (PCF File) -pcf pcf_file.pcf The –pcf option allows you to specify a PCF (physical constraints file) as input to NetGen. You only need to specify a physical constraints file if prorating constraints (temperature and/or voltage) are used.
R Chapter 22: NetGen –ti (Top Instance Name) –ti top_instance_name The –ti option specifies a user instance name for the design under test in the testbench file created with the –tb option. –tm (Top Module Name) –tm top_module_name By default (without the –tm option), the output files inherit the top module name from the input NCD file. The –tm option changes the name of the top-level module name appearing in the NetGen output files.
R NetGen Timing Simulation Flow When you run this option, NetGen checks that your library path is set up properly. Following is an example of the appropriate path: $XILINX/verilog/src/simprim If you are using compiled libraries, this switch offers no advantage. If you use this switch, do not use the –ul switch. Note: The –ism option is valid for post-translate (NGD), post-map, and post-place and route simulation flows.
R Chapter 22: NetGen –ul (Write uselib Directive) The –ul option causes NetGen to write a library path pointing to the SimPrim library into the output Verilog (.v) file. The path is written as shown below: uselib dir=$XILINX/verilog/src/simprims libext=.v $XILINX is the location of the Xilinx software. If you do not enter a –ul option, the ‘uselib line is not written into the Verilog file.
R NetGen Equivalence Checking Flow –xon (Select Output Behavior for Timing Violations) –xon {true|false} The –xon option specifies the output behavior when timing violations occur on memory elements. If you set this option to true, any memory elements that violate a setup time trigger X on the outputs. If you set this option to false, the signal’s previous value is retained. If you do not set this option, –xon true is run. Note: The –xon option should be avoided as much as possible.
R Chapter 22: NetGen ELF NCD NGM NetGen SVF/VXC V Formal Library Formal Verification Tool X10034 Figure 22-5: Post-Implementation Flow for FPGAs Syntax for NetGen Equivalence Checking. The following command runs the NetGen Equivalence Checking flow: netgen -ecn [tool_name] [options] input_file[.ncd/.ngd] [ngm_file.ngm] options is one or more of the options listed in the “Options for NetGen Equivalence Checking Flow” section.
R NetGen Equivalence Checking Flow Output files for NetGen Equivalence Checking The NetGen Equivalence Checking flow uses the following files as output: • Verilog (.v) file—This is a IEEE 1364-2001 compliant Verilog HDL file that contains the netlist information obtained from the input file. This file is a equivalence checking model and cannot be synthesized or used in any other manner than equivalence checking. • Formality (.
R Chapter 22: NetGen For additional information on equivalence checking and formal verification tools, please refer to the Synthesis and Simulation Design Guide. –fn (Control Flattening a Netlist) The –fn option produces a flattened netlist. –intstyle (Integration Style) –intstyle {ise | xflow | silent} The –intstyle option reduces screen output based on the integration style you are running. When using the –intstyle option, one of three modes must be specified: ise, xflow, or silent.
R NetGen Static Timing Analysis Flow The –ne option replaces invalid characters with underscores, so that name escaping does not occur. For example, the net name “p1$40/empty” becomes “p1$40_empty” when name escaping is not used. The leading backslash does not appear as part of the identifier. The resulting Verilog file can be used if a vendor’s Verilog software cannot interpret escaped identifiers correctly.
R Chapter 22: NetGen The figure below illustrates the NetGen Static Timing Analysis flow. NCD PCF NetGen V/SDF STA Library Static Timing Analysis Tool X10252 Figure 22-6: Static Timing Analysis Flow for FPGAs Input files for Static Timing Analysis The Static Timing Analysis flow uses the following files as input: • NCD file—This physical design file may be mapped only, partially or fully placed, or partially or fully routed. • PCF (optional)—This is a physical constraints file.
R NetGen Static Timing Analysis Flow Options for NetGen Static Timing Analysis Flow This next section describes the supported NetGen command line options for static timing analysis. –aka (Write Also-Known-As Names as Comments) The –aka option includes original user-defined identifiers as comments in the Verilog netlist. This option is useful if user-defined identifiers are changed because of name legalization processes in NetGen. –bd (Block RAM Data File) –bd [filename] [.elf|.
R Chapter 22: NetGen –module (Simulation of Active Module) –module The –module option creates a netlist file based on the active module, independent of the top-level design. NetGen constructs the netlist based only on the active module’s interface signals. To use this option you must specify an NCD file that contains an expanded active module. Note: The –module option is for use with the Modular Design flow.
R Preserving and Writing Hierarchy Files –sta (Generate Static Timing Analysis Netlist) The –sta option writes a static timing analysis netlist. –tm (Top Module Name) –tm top_module_name By default (without the –tm option), the output files inherit the top module name from the input NCD file. The –tm option changes the name of the top-level module name appearing within the NetGen output files. –w (Overwrite Existing Files) The –w option causes NetGen to overwrite the .v file if it exists.
R Chapter 22: NetGen The [module_name] is the name of the hierarchical module from the front-end that the user is already familiar with. There are cases when the [module_name] could differ, they are: • If multiple instances of a module are used in the design, then each instantiation of the module is unique because the timing for the module is different. The names are made unique by appending an underscore followed by a “INST_” string and a count value (e.g., numgen, numgen_INST_1, numgen_INST_2).
R Dedicated Global Signals in Back-Annotation Simulation Global Signals in Verilog Netlist For Verilog, the glbl module is used to model the default behavior of global the GSR and GTS. The glbl.GSR and glbl.GTS can be directly referenced as global GSR/GST signals anywhere in a design or in any library cells. NetGen writes out the glbl module definition in the output Verilog netlist.
R Chapter 22: NetGen When there is a STARTUP block in the design, the STARTUP block hierarchical level is preserved in the output netlist. The output of STARTUP is connected to the global GSR and GTS signals. For information on setting GSR and GTS for FPGAs, see the “Simulating VHDL” section of the Synthesis and Simulation Design Guide. 340 www.xilinx.
R Chapter 23 XFLOW XFLOW is compatible with the following families: • Virtex™, Virtex™-E • Virtex™-II • Virtex™-II Pro, Virtex™-II Pro X • Virtex™-4 • Virtex™-5 LX • Spartan™-II, Spartan™-IIE • Spartan™-3, Spartan™-3E, Spartan™-3L • CoolRunner™ XPLA3, CoolRunner™-II • XC9500™, XC9500XL™, XC9500XV™ This chapter describes the XFLOW program, a scripting tool that allows you to automate implementation, simulation, and synthesis flows using Xilinx programs.
R Chapter 23: XFLOW The following figure shows the inputs and the possible outputs of the XFLOW program. The output files depend on the flow you run.
R XFLOW Input Files Note: If you specify a design name only and do not specify a flow type or option file, XFLOW defaults to the –implement flow type and fast_runtime.opt option file for FPGAs and the –fit flow type and balanced.opt option file for CPLDs. You do not need to specify the complete path for option files. By default, XFLOW uses the option files in your working directory.
R Chapter 23: XFLOW • FLW File—The flow file is an ASCII file that contains the information necessary for XFLOW to run an implementation or simulation flow. When you specify a flow type (described in “XFLOW Flow Types”), XFLOW calls a particular flow file. The flow file contains a program block for each program invoked in the flow. It also specifies the directories in which to copy the output files. You can use the default set of flow files as is, or you can modify them.
R XFLOW Output Files The following table lists files that can be generated for both FPGA and CPLD designs. Table 23-1: XFLOW Output Files (FPGAs and CPLDs) File Name Description To Generate this File... design_name.bld This report file contains information about the NGDBuild run, in which the input netlist is translated to an NGD file. Flow file must include “ngdbuild” (Use the –implement or –fit flow type) time_sim.sdf This Standard Delay Format file contains the timing data for a design.
R Chapter 23: XFLOW The following table lists the output files that can be generated for FPGAs. Table 23-2: XFLOW Output Files (FPGAs) File Name Description To Generate this File... design_name.bgn This report file contains information about the BitGen run, in which a bitstream is generated for Xilinx device configuration. Flow file must include “bitgen” (Use the –config flow type) design_name.
R XFLOW Flow Types The following table lists the output files that can be generated for CPLDs. Table 23-3: XFLOW Output Files (CPLDs) File Name design_name.gyd Description This ASCII file is a CPLD guide file. To Generate this File... Flow file must include “cpldfit” (Use the –fit flow type) design_name.jed design_name.rpt design_name.tim This ASCII file contains configuration data that can be downloaded to a CPLD using iMPACT.
R Chapter 23: XFLOW Xilinx provides the following option files for use with this flow type. These files allow you to optimize your design based on different parameters. Table 23-4: Option Files for –assemble Flow Type Option Files fast_runtime.opt Description Optimized for fastest runtimes at the expense of design performance Recommended for medium to slow speed designs balanced.opt Optimized for a balance between speed and high effort high_effort.
R XFLOW Flow Types Xilinx provides the following option files for use with this flow type. Table 23-5: Option Files for –ecn Flow Type Option Files Description conformal_verilog.opt Option file for equivalence checking for conformal formality_verilog.opt Option file for equivalence checking for formality –fit (Fit a CPLD) –fit option_file This flow type incorporates logic from your design into physical macrocell locations in a CPLD. It invokes the cpld.
R Chapter 23: XFLOW Xilinx provides the following option files, which are targeted to specific vendors, for use with this flow type. Table 23-7: Option Files for –fsim Flow Type Option File Description generic_vhdl.opt Generic VHDL modelsim_vhdl.opt Modelsim VHDL generic_verilog.opt Generic Verilog modelsim_verilog.opt Modelsim Verilog nc_verilog.opt NC Verilog verilog_xl.opt Verilog-XL vcs_verilog.opt VCS Verilog nc_vhdl.opt NC VHDL scirocco_vhdl.
R XFLOW Flow Types Table 23-8: Option Files for –implement Flow Type Option Files Description weekend.opt Multi-pass place and route (MPPR) weekend mode exhaustive.opt Multi-pass place and route (MPPR) exhaustive mode The following example shows how to use the –implement flow type: xflow -p xc2v250fg256-5 -implement balanced.opt testclk.edf –initial (Initial Budgeting of Modular Design) –initial budget.opt Note: This flow type supports FPGA device families only.
R Chapter 23: XFLOW –module (Active Module Implementation) –module option_file –active module_name Note: This flow type supports FPGA device families only. You cannot use NCD files from previous software releases with Modular Design in the current release. You must generate new NCD files with the current release of the software. This flow type runs the second phase of the Modular Design flow.
R XFLOW Flow Types –mppr (Multi-Pass Place and Route for FPGAs) –mppr option_file This flow type runs multiple place and route passes on your FPGA design. It invokes the fpga.flw flow file and runs NGDBuild, MAP, multiple PAR passes, and TRACE. After running the multiple PAR passes, XFLOW saves the “best” NCD file in the subdirectory called mppr.dir. (Do not change the name of this default directory.) This NCD file uses the naming convention placer_level_router_level_cost_table.ncd.
R Chapter 23: XFLOW –synth –synth option_file Note: When using the –synth flow type, you must specify the –p option. This flow type allows you to synthesize your design for implementation in an FPGA, for fitting in a CPLD, or for compiling for functional simulation. The input design file can be a Verilog or VHDL file. You can use the -synth flow type alone or combine it with the -implement, -fit, or -fsim flow type. If you use the -synth flow type alone, XFLOW invokes either the fpga.flw or cpld.
R XFLOW Flow Types If you have multiple VHDL files, you must list all the source files in a text file, one per line and pass that information to XFLOW using the –g (Specify a Global Variable) option. Assume that the file that lists all source files is filelist.txt and design_name.vhd is the top level design. Use the following example: xflow -p xc2v250fg256-5 -g srclist:filelist.txt -synth synplicity_vhdl.opt design_name.vhd The same rule applies for Verilog too.
R Chapter 23: XFLOW Xilinx provides the following option files, which are targeted to specific vendors, for use with this flow type. Table 23-13: Option Files for –tsim Flow Type Option File Description generic_vhdl.opt Generic VHDL modelsim_vhdl.opt Modelsim VHDL generic_verilog.opt Generic Verilog modelsim_verilog.opt Modelsim Verilog scirocco_vhdl.opt Scirocco VHDL nc_verilog.opt NC Verilog verilog_xl.opt Verilog-XL vcs_verilog.opt VCS Verilog nc_vhdl.
R XFLOW Flow Types The following table lists the flow files invoked for each flow type. Table 23-14: Xilinx Flow Files Flow Type Flow File –synth fpga.
R Chapter 23: XFLOW • ReportDir This section specifies the directory in which to copy the report files generated by the programs in the flow. The default directory is your working directory. Note: You can also specify the report directory using the –rd command line option. The command line option overrides the ReportDir specified in the flow file.
R XFLOW Flow Types For example, if you want to run TRACE after MAP and again after PAR, the program blocks for post-MAP TRACE and post-PAR TRACE appear as follows: Program post_map_trce Flag: ENABLED; Executable: trce; Input: _map.ncd; Exports: .twr, .tsi; End Program post_map_trce Program post_par_trce Flag: ENABLED; Executable: trce; Input: .ncd; Reports: .twr, .
R Chapter 23: XFLOW XFLOW Option Files Option files contain the options for all programs run in a flow. These files have an .opt extension. Xilinx provides option files for each flow type, as described in the different sections of “XFLOW Flow Types”. You can also create your own option files. Note: If you want to create your own option files, Xilinx recommends that you make a copy of an existing file, rename it, and then modify it. Option File Format Option files are in ASCII format.
R XFLOW Options XFLOW Options This section describes the XFLOW command line options. These options can be used with any of the flow types described in the preceding section. –active (Active Module) –active active_module The –active option specifies the active module for Modular Design; “active” refers to the module on which you are currently working.
R Chapter 23: XFLOW –norun (Creates a Script File Only) By default, XFLOW runs the programs enabled in the flow file. Use the –norun option if you do not want to run the programs but instead want to create a script file (SCR, BAT, or TCL). XFLOW copies the appropriate flow and option files to your working directory and creates a script file based on these files. This is useful if you want to check the programs and options listed in the script file before executing them.
R XFLOW Options –p (Part Number) –p part By default (without the –p option), XFLOW searches for the part name in the input design file. If XFLOW finds a part number, it uses that number as the target device for the design. If XFLOW does not find a part number in the design input file, it prints an error message indicating that a part number is missing. The –p option allows you to specify a device. For a list of valid ways to specify a part, see “–p (Part Number)” in Chapter 1.
R Chapter 23: XFLOW –wd (Specify a Working Directory) –wd working_directory The default behavior of XFLOW (without the –wd option) is to use the directory from which you invoked XFLOW as the working directory. The –wd option allows you to specify a different directory as the working directory. XFLOW searches for all flow files, option files, and input files in the working directory. It also runs all subprograms and outputs files in this directory.
R Running XFLOW Using the SCR, BAT, or TCL File Every time you run XFLOW, it creates a script file that includes the command line commands of all the programs run. You can use this file for the following: • Review this file to check which commands were run • Execute this file instead of running XFLOW By default, this file is named xflow_script.bat (PC) or xflow_script.scr (UNIX), although you can specify the output script file type by using the $scripts_to_generate option.
R Chapter 23: XFLOW 366 www.xilinx.
R Chapter 24 Data2MEM Data2MEM is compatible with the following families: • Virtex™/-E • Virtex-II™ • Virtex-II Pro™/X • Virtex-4™ • Virtex™-5 LX • Spartan™, Spartan-II™/E • Spartan-3™, Spartan-3E™, Spartan-3L™ This chapter contains the following sections: • “Data2MEM Overview” • “Data2MEM Syntax” • “Data2MEM Input and Output Files” • “Data2MEM Options” Data2MEM Overview Data2MEM is a command line executable that transforms CPU execution code, or pure data, into Block RAM initializat
R Chapter 24: Data2MEM Data2MEM Syntax Use the following syntax to run Data2MEM from the command line: data2mem -bm|bd infile.[bmm|elf|mem][options] options can be any number of the command line options listed in the “Data2MEM Options” section of this chapter. Options need not be listed in any order. Separate multiple options with spaces. See the “Data2MEM Options” section of this chapter. infile specifies the name of the input file. Use the -bm option to specify a .
R Data2MEM Input and Output Files Debugging Information Format DWARF (.drf) files A Debugging Information Format DWARF (.drf) file is a binary data file that contains the executable CPU code image, plus debug information required by symbolic source-level debuggers. These files are produced by the same software compiler tools as .elf files. Data2MEM reads .drf files wherever .elf files can be used. Because .drf files are binary data, they are not directly editable.
R Chapter 24: Data2MEM VHDL (.vhd) files A VHDL (.vhd) file is a simple text file that Data2MEM outputs, which contains “bit_vector” constants to initialize Block RAMs. These constants can be used in “generic maps” to instance an initialized Block RAM. This file is used primarily for pre-synthesis and post-synthesis simulation. Because a .vhd file is a simple text file, it is directly editable. However, because this file is a generated file, editing is not advised.
R Data2MEM Options Table 24-1: Data2MEM Command Line Options Option Description –f filename The -f option specifies the name of an option file. If the file extension is missing, an .opt file extension is assumed. Option files are identical to the command line options, but contained in a text file. An option, and its attributes, must appear on the same text line. The -f option can be specified once on the command line, and must not be contained in the .opt file.
R Chapter 24: Data2MEM Table 24-1: Data2MEM Command Line Options Option –o u|v|h|m filename Description The -o option specifies the name of the output files. The string preceding the file name indicates which file formats are to be output. No spaces can separate the specified file types, and file types can appear in any order. One or more file types can be specified. The file type are: 'u' - specifies a UCF file format, with a .ucf file extension 'v' - specifies a Verilog file format, with a .
R Appendix A Xilinx Development System Files This appendix gives an alphabetic listing of the files used by the Xilinx development system.
R Appendix : Name Type Produced By Description EPL ASCII FPGA Editor FPGA Editor command log file. The EPL file keeps a record of all FPGA Editor commands executed and output generated.
R Name Type Produced By Description MFP ASCII Floorplanner Map Floorplanner File, which is generated by the Floorplanner, specified as an input file with the –fp option. The MFP file is essentially used as a guide file for mapping.
R Appendix : 376 Name Type Produced By Description NGO Data Netlist Readers File containing a logical description of the design in terms of its original components and hierarchy NKY Data BitGen Encryption key file NLF ASCII NetGen NetGen log file that contains information on the NetGen run NMC Binary FPGA Editor Xilinx physical macro library file containing a physical macro definition that can be instantiated into a design OPT ASCII XFLOW Options file used by XFLOW PAD ASCII PAR
R Name Type Produced By Description TCL ASCII User (with text editor) TCL script file TDR ASCII DRC Physical DRC report file TEK Data PROMGen PROM-formatted file in Tektronix’s TEKHEX format TV ASCII NetGen Verilog test fixture file TVHD ASCII NetGen VHDL testbench file TWR ASCII TRACE Timing report file produced by TRACE TWX XML TRACE Timing report file produced by TRACE.
R Appendix : 378 www.xilinx.
R Appendix B EDIF2NGD, and NGDBuild This appendix describes the netlist reader program, EDIF2NGD, and how this program interacts with NGDBuild.
R Appendix : The following figure shows the flow through EDIF2NGD. EDIF2NGD Design Flow You can run EDIF2NGD in the following ways: • Automatically from NGDBuild • From the UNIX or DOS command line, as described in the following sections Note: When creating net or symbol 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 use these names, EDIF2NGD issues an error. 380 www.xilinx.
R EDIF2NGD 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 “EDIF2NGD Options”. 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. If you enter a file name with no extension, EDIF2NGD looks for a file with the name you specified and an .edn extension.
R Appendix : EDIF2NGD Options This section describes the EDIF2NGD command line 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.
R EDIF2NGD –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.
R Appendix : NGDBuild This program is compatible with the following families: • Virtex™, Virtex™-E • Virtex™-II • Virtex™-II Pro, Virtex™-II Pro X • Virtex™-4 • Virtex™-5 LX • Spartan™-II, Spartan™-IIE • Spartan™-3, Spartan™-3E, Spartan™-3L • CoolRunner™ XPLA3, CoolRunner™-II • XC9500™, XC9500XL™, XC9500XV™ NGDBuild performs all the steps necessary to read a netlist file in EDIF format and create an NGD file describing the logical design.
R NGDBuild NGDBuild performs the following steps to convert a netlist to an NGD file: 1. Reads the source netlist To perform this step, NGDBuild invokes the Netlist Launcher (Netlister), 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 format, the Netlist Launcher invokes EDIF2NGD.
R Appendix : Bus Matching 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 lowerlevel 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.
R Netlist Launcher (Netlister) When NGDBuild is invoked, the Netlist launcher goes through the following steps: 1. The Netlist Launcher initializes itself with a set of rules for determining what netlist reader to use 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 “System Rules File”) and in the user rules file (described in “User Rules File”). 2.
R Appendix : Netlist Launcher Rules Files The behavior of the Netlist Launcher is determined by rules defined in the system rules file and the user rule file. These rules determine the following: • What netlist source files are acceptable • Which netlist reader reads each of these netlist files • What the default options are for each netlist reader The system rules file contains the default rules supplied with the Xilinx Development System software.
R Netlist Launcher (Netlister) Following are the keys allowed and the values expected: Note: The value types for the keys are described in “Value Types in Key Statements”. • RuleName—This key identifies the beginning of a rule. It is also used in error messages relating to the rule. It expects a RULENAME value. A value is required. • NetlistFile—This key specifies a netlist or class of netlists that the netlist reader takes as input.
R Appendix : • NetlisterDirectory—This key specifies the directory in which to run the netlist reader. The launcher changes to this directory before running the netlist reader. It expects a DIR value or the keywords $SOURCE, $OUTPUT, or NONE, where the path to the source netlist is substituted for $SOURCE, the directory specified with the -dd option is substituted for $OUTPUT, and the current working directory is substituted for NONE. A value is optional.
R Netlist Launcher (Netlister) RuleName = EDF_RULE; NetlistFile = .edf; TargetExtension = .ngo; Netlister = edif2ngd; NetlisterTopOptions = "[$IGNORE_LOCS] [$ADD_PADS] [$QUIET] [$AUL] {-l $LIBRARIES} $INFILE $OUTFILE"; NetlisterOptions = "-noa [$IGNORE_LOCS] {-l $LIBRARIES} $INFILE $OUTFILE"; NetlisterDirectory = NONE; NetlisterSuccessStatus = 0; RuleName = EDIF_RULE; NetlistFile = .edif; TargetExtension = .
R Appendix : The EDF_RULE instructs the Netlist Launcher to use EDIF2NGD to translate an EDIF 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. Because NetlisterDirectory is NONE, the Netlist Launcher runs EDIF2NGD in the current working directory (the one from which NGDBuild was launched).
R NGDBuild File Names and Locations Example 4: User Rule Following is a another example of a User Rule: // URF Example 4 RuleName = STATE_EDF_RULE; NetlistFile = state.edf; TargetExtension = .ngo; Netlister = state2ngd; Although the NetlistFile is a complete file name, this user rule also matches the system rule EDF_RULE (shown in “Example 1: EDF_RULE System Rule”), because the extensions of NetlistFile and TargetExtension match. When the Netlist Launcher tries to make a file called state.
R Appendix : 394 www.xilinx.
R Glossary Click on a letter, or scroll down to view the entire glossary. ABCDEFGHIJLMNOPRSTUVW A ABEL Advanced Boolean Expression Lanaguage (ABEL) is a high-level language (HDL) and compilation system produced by Data I/O Corporation. adder An adder is a combinatorial circuit that computes the sum of two or more numbers. address An address is the identification of a storage location, such as a register or a memory cell. checked for syntax errors.
R ASIC Application-specific integrated circuit (ASIC), is a full-custom circuit. In which every mask is defined by the customer or a semi-custom circuit (gate array) where only a few masks are defined. attributes Attributes are instructions placed on symbols or nets in an FPGA or CPLD schematic to indicate their placement, implementation, naming, directionality, or other properties.I B back-annotation Back-annotation is the translation of a routed or fitted design to a timing simulation netlist.
R BitGen Is a program that produces a bitstream for Xilinx device configuration. BitGen takes a fully routed NCD (Circuit Description) file as its input and produces a configuration bitstream, a binary file with a.bit extension. bitstream A bitstream is a stream of data that contains location information for logic on a device, that is, the placement of Configurable Logic Blocks (CLBs), Input/Output Blocks (IOBs), (TBUFs), pins, and routing elements.
R buffer A buffer is an element used to increase the current or drive of a weak signal and, consequently, increase the fanout of the signal. A storage element. BUFT A BUFT is a 3-state buffer. bus A group of two or more signals that carry closely-associated signals in an electronic design. byte A binary word consisting of eight bits. When used to store a number value, a byte can represent a number from 0 to 255. C CAE Computer Aided Engineering. The original term for electronic design automation (EDA).
R checksum A checksum is a summation of bits or digits generated according to an arbitrary formula used for checking data integrity. To verify that the data represented by a checksum number has been entered correctly, verify that the checksum number generated after processing is the same as the initial number. CLB The Configurable Logic Block (CLB). Constitutes the basic FPGA cell.
R combinatorial logic Combinatorial logic refers to any primitives with the exception of storage elements such as flip-flops. compiler A compiler is a language interpreter. The Synopsys compiler interprets HDL and makes concurrent process implementations for target architectures. component A component is an instantiation or symbol reference from a library of logic elements that can be placed on a schematic.
R CPLD Complex Programmable Logic Device (CPLD). Is an erasable programmable logic device that can be programmed with a schematic or a behavioral design. CPLDs constitute a type of complex PLD based on EPROM or EEPROM technology. They are characterized by an architecture offering high speed, predictable timing, and simple software. The basic CPLD cell is called a macrocell, which is the CPLD implementation of a CLB. It is composed of AND gate arrays and is surrounded by the interconnect area.
R decimal Decimal refers to a numbering system with a base of 10 digits starting with zero. decoder A decoder is a symbol that translates n input lines of binary information into 2n output lines. It is the opposite of an encoder. Delay Locked Loop (DLL) A digital circuit used to perform clock management functions on and off-chip. density Density is the number of gates on a device.
R E EDA Electronic Design Automation (EDA). A generic name for all methods of entering and processing digital and analog designs for further processing, simulation, and implementation. edge decoder An edge decoder is a decoder whose placement is constrained to precise positions within a side of the FPGA device. EDIF EDIF is the Electronic Data Interchange Format, an industry standard file format for specifying a design netlist. It is generated by a thirdparty design-entry tool.
R EPROM An EPROM is an erasable PROM, which can be reprogrammed many times. Previous programs are simply erased by exposing the chip to ultra-violet light. An EEPROM, or electrically erasable PROM, is another variety of EPROM that can be erased electrically. F FD FD is a D flip-flop used in CLBs. Contrast with IFD. FDSD FDSD is a D flip-flop with Set Direct. FIFO A FIFO is a serial-in/serial-out shift register.
R floorplanning Floorplanning is the process of choosing the best grouping and connectivity of logic in a design. It is also the process of manually placing blocks of logic in an FPGA where the goal is to increase density, routability, or performance. flow The flow is an ordered sequence of processes that are executed to produce an implementation of a design. FMAP An FMAP is a symbol that defines mapping into a 4-input function generator (F or G).
R gate array A gate array is part of the ASIC chip. A gate array represents a certain type of gate repeated all over a VLSI-type chip. This type of logic requires the use of masks to program the connections between the blocks of gates. global buffers Global buffers are low-skew, high-speed buffers that connect to long lines. They do not map logic. There is one BUFGP and one BUFGS in each corner of the chip. Primary buffers must be driven by an IOB.
R H HDL Hardware Description Language. A language that describes circuits in textual code. The two most widely accepted HDLs are VHDL and Verilog. An HDL, or hardware description language, describes designs in a technology-independent manner using a high level of abstraction. The most common HDLs in use today are Verilog and VHDL.
R IEEE Institute of Electrical and Electronics Engineers.Pronounced I triple E. IFD IFD is an IOB flip-flop. impedance Impedance is the sum of all resistance and reactance of a circuit to the flow of alternating current. implementation Implementation is the mapping, placement and routing of a design. A phase in the design process during which the design is placed and routed. incremental design Incremental design refers to the implementation and verification of a small design change using a guide file.
R instance An instance is one specific gate or hierarchical element in a design or netlist. The term "symbol" often describes instances in a schematic drawing. Instances are interconnected by pins and nets. Pins are ports through which connections are made from an instance to a net. A design that is flattened to its lowest level constituents is described with primitive instances. instantiation Instantiation is the act of placing a symbol that represents a primitive or a macro in a design or netlist.
R library A library is a set of macros, such as adders, buffers, and flip-flops that is part of the Xilinx interface. A library is used to create schematic designs. load A load is an input port. logic Logic is one of the three major classes of ICs in most digital electronic systems: microprocessors, memory, and logic. Logic is used for data manipulation and control functions that require higher speed than a microprocessor can provide. logical annotation The method of back-annotation that uses the old .
R M macro A macro is a component made of nets and primitives, flip-flops, or latches that implements high-level functions, such as adders, subtracters, and dividers. Soft macros and Relationally Placed Macros (RPMs) are types of macros. macrocell A macrocell is the CPLD logic cell, which is made of gates only. A macrocell can implement both combinational and registered equations. High-density function block macrocells also contain an arithmetic logic unit (ALU) for implementing arithmetic functions.
R N NCD A Native Circuit Description (NCD). The physical database format for Xilinx Implementation software tools. net A logical connection between two or more symbol instance pins. After routing, the abstract concept of a net is transformed to a physical connection called a wire. An electrical connection between components or nets. It can also be a connection from a single component. It is the same as a wire or a signal. netlist A netlist is a text description of the circuit connectivity.
R oscillator An oscillator is a bi-stable circuit that can be used as a clock. The stable states are 0 and 1. P package A package is the physical packaging of a chip, for example, PG84, VQ100, and PC48. pad A pad is the physical bonding pad on an integrated circuit. All signals on a chip must enter and leave by way of a pad. Pads are connected to package pins in order for signals to enter or leave an integrated circuit package.
R period The period is the number of steps in a clock pattern multiplied by the step size. physical annotation Physical annotation uses just the .ncd file. In this mode, a timing simulation model is generated from the physical device components. PIM Physically Implemented Module pin A pin can be a symbol pin or a package pin. A package pin is a physical connector on an integrated circuit package that carries signals into and out of an integrated circuit.
R primitive A basic logic element, such as a gate (AND, OR, XOR, NAND, or NOR), inverter, flip-flop, or latch. A logic element that directly corresponds, or maps, to one of these basic elements. programming Programming is the process of configuring the programmable interconnect in the FPGA. PROM A PROM is a programmable read-only memory. PROM file A PROM file consists of one or more BIT files (bitstreams) formed into one or more datastreams.
R readback Readback is the process of reading the logic downloaded to an FPGA device back to the source. There are two types of readback. A readback of logic usually accompanied by a comparison check to verify that the design was downloaded in its entirety. A readback of the states stored in the device memory elements to ensure that the device is behaving as expected. register A register is a set of flip-flops used to store data. It is an accumulator used for all arithmetic operations.
R script A script is a series of commands that automatically execute a complex operation such as the steps in a design flow. SDF (standard delay format) Standard Delay Format (SDF) is an industry-standard file format for specifying timing information. It is usually used for simulation. seed A seed is a random number that determines the order of the cells in the design to be placed. set/reset This operation is made possible by the asynchronous set/reset property.
R state A state is the set of values stored in the memory elements of a device (flip-flops, RAMs, CLB outputs, and IOBs) that represent the state of that device at a particular point of the readback cycle. To each state there corresponds a specific set of logical values. state machine A state machine is a set of combinatorial and sequential logic elements arranged to operate in a predefined sequence in response to specified inputs.
R timing simulation This type of simulation takes place after the HDL design has been synthesized and placed and routed. The purpose of this simulation is to check the dynamic timing behavior of the HDL design in the target technology. Use the block and routing delay information from the routed design to assess the circuit behavior under worst-case conditions. timing specifications Timing specifications define the maximum allowable delay on any given set of paths in a design.
R TTL TTL, or transistor-transistor logic, is a technology with specific interchange (communication of digital signals) voltages and currents. Other technologies include ECL, MOS, and CMOS. These types of logic are used as criteria to classify digital integrated circuits. U unbonded Unbonded describes an IOB used for internal logic only. This element does not have an external package pin. Unified Libraries A set of logic macros and functions that are used to define the logic of a design.
R VHDL VHDL is an acronym for VHSIC Hardware Description Language (VHSIC an acronym for Very High-Speed Integrated Circuits). It can be used to describe the concurrent and sequential behavior of a digital system at many levels of abstraction ranging from the algorithmic level to the gate level. VHDL is IEEE standard 1076-1993. A VHDL file has a .vhd or .vhdl extension. VITAL VITAL is an acronym for VHDL Intitiative Toward ASIC Libraries. It is a VHDL-library standard (IEEE 1076.
R 422 www.xilinx.
