Running Xilinx tools using makefiles
When using the Xilinx Platform Studio to design an embedded system we will:
- Build the system using the GUI or/and the wizard
- Convert the GUI setup to RTL code (Generate Netlist).
- Synthesis the RTL code to a netlist (Generate Netlist)
- Map the netlist in to LUTs (Generate Bitstream)
- Place and route the LUTs (Generate Bitstrem)
- Generate the bitstream to configure the FPGA (Generate Bitstream)
- Download the bitstream to the FPGA (Download Bitstream)
Steps 2-6 are controlled from an auto-generated makefile (LX9_LXN_system.make) together with the include file (LX9_LXN_system_incl.make).
To start the make we use the following command:
--> cd .../LX9_LXN
--> make -f LX9_LXN_system.make <target>
Running the complete flow
To run the complete flow we will execute the following commands:
--> make -f LX9_LXN_system.make netlist
--> make -f LX9_LXN_system.make bits
--> make -f LX9_LXN_system.make download
Setting up our own make environment
In the XPS environment the makefiles will be auto-generated every time we start a make.
To setup our own environment and make changes to the makefile, we have to copy the following files from the XPS run directory to a new directory. From here we can run all the targets and we don't need the XPS GUI.
Running Xilinx tools using scripting
Xilinx Design Suite tools are one of many EDA tools that can be controlled using scripting. Why would we want to do that? Well, we often make an edit to our source code, then re-implement it only to find that the synthesis/layout doesn't do the same as it did before. This is a constant danger if repeatability depends on remembering to click on the correct boxes and menus in the user interface. If we create a command file we can run that same file many times, thus guaranteeing that we are issuing the same commands to the tool each time.
Why using command-line mode
- When FPGAs become larger, so do the designs built around them and the design teams themselves. In many cases GUI tools become a limiting factor that hinders team productivity.
- GUI tools do not provide a good support for a distributed computing environment. It can take several hours or even days to build a large FPGA design. To improve the run-time dedicated Linux servers are used to run batch jobs. Third party job-scheduling is used to provide flexible build scheduling, load balancing and fine-grained control.
- The GUI tools are memory and CPU resource hungry. They can take up several hundreds of Mbytes of memory when running.
- Many FPGA designers have an ASIC design background. These engineers are accustomed to using command-line tool flows and scripts to control the build process.
Xilinx provides several options to build a design using command-line tools. The most popular options are:
- Direct invocation
The direct invocation method calls tools in the following sequence: (xst, ngdbuild, map, place-and-route, tree and bitgen). The script can be auto-generated from ISE or EDK.
The Xflow utility provides another way to build a design. It is more integrated than direct invocation and doesn't require as much tool knowledge. The Xflow command accepts a number of build options. Depending on those options, Xflow can run synthesis, implemenatation, bitgen or a combination of all three. For more information see Xilinx Command Line Tools User Guide (chapter 23).
The following figure shows the inputs and the possible outputs of the XFLOW program. The output files depend on the flow we run.
PlanAhead design and analysis tool
The PlanAhead tool is a design and analysis product that provides an intuitive environment for the entire FPGA design and implementation process. To allow a seamless design experience for Xilinx FPGA designers, the PlanAhead tool is integrated with:
- Xilinx ISE® Design Suite software tools for synthesis and implementation
- Xilinx® Synthesis Technology (XST) tool
- CORE GeneratorTM tool
- ChipScopeTM Pro debugging tool
- ISE Simulator (ISim) tool
- XPower Analyzer tool
- FPGA Editor tool
- iMPACT device programming tool
The PlanAhead tool lets you improve circuit performance by analyzing the design Register Transfer Level(RTL) sources, synthesized netlists, and implementation results. You can experiment with different implementation options, refine timing constraints, and apply physical constraints with floorplanning techniques to help improve design results. Early estimates of resource utilization, interconnect delay, power consumption, and routing connectivity can assist with appropriate logic design, device selection and floorplanning.
The PlanAhead tool includes a hierarchical data model that enables an incremental design capability referred to as Design Preservation. By partitioning the design, unchanged modules can be preserved, providing consistent results and in some cases reduced runtimes. Also, with appropriate licensing, the PlanAhead tool provides access to the Partial Reconfiguration design application. For more information see the PlanAhead User Guide.
Designs can also be built using Tcl scripts invoked from the Xilinx xtclsh script handler. Each of the xst, nbdbbuild, map, place-and-route, tree and bitgen tool options has its Tcl equivalent property. The tool is invoked using the Tcl "process run" command.
Scripting language choices
Xilinx command-line tools can run on both Windows and Linux operating systems, and can be invoked using different scripting languages.
Perl is a popular scripting language used by a wide range of EDA and other tools. Xilinx Design Suite installation contains a customized Perl distribution. Use the following command:
Tcl scripting language
Tcl (originally from "Tool Command Language", but conventionally rendered as "Tcl" rather than "TCL"; pronounced as "tickle" or "tee-see-ell") is a scripting language created by John Ousterhout. It is commonly used for rapid prototyping, scripted applications, GUIs and testing. Tcl is used on embedded systems platforms, both in its full form and in several other small-footprinted versions. Tcl is de facto standard scripting language of ASIC and FPGA design tools.
Running a Tcl script
There are two ways of running a Tcl script in the Xilinx environment:
- Within the GUI there is a Tcl command window, in which we can source (i.e. call/run) a script.
- We can issue the command "xtclsh scriptname" in a linux shell and avoid the overhead of a graphical interface completely.
For more information see: Command Line Tools User Guide (chapter 27).
Setting up a Tcl script
The Xilinx software Tcl command language is designed to complement and extend the ISE/EDK graphical user interface (GUI). For new users and projects, the GUI provides an easy interface to set up a project, perform initial implementations, explore available options, set constraints, and visualize the design.
Alternatively, for users who know exactly what options and implementation steps they wish to perform, the Xilinx Tcl commands provide a batch interface that makes it convenient to execute the same script or steps repeatedly. Since the syntax of the Xilinx Tcl commands match the GUI interaction as closely as possible, Xilinx Tcl commands allow an easy transition from using the GUI to running the tools in script or batch mode.
XFLOW is a command line program that automates Xilinx synthesis, implementation, and simulation flows. XFLOW reads a design file as input as well as a flow file and an option file. Xilinx provides a default set of flow files that automate which Xilinx programs are run to achieve a specific design flow. For example, a flow file can specify that NGDBuild, MAP, PAR, and TRACE are run to achieve an implementation flow for an FPGA. We can use the default set of flow files as is, or we can customize them. See XFLOW Flow Types and Flow Files for more information. Option files specify which command line options are run for each of the programs listed in the flow file. We can use the default set of option files provided by Xilinx, or we can create our own
Following is the command line syntax for XFLOW:
xflow [-p partname ] [flow type] [option file[.opt]] [xflow options ] design_name
- flow type can be any of the flow types listed in XFLOW Flow Types. Specifying a flow type prompts XFLOW to read a certain flow file. You can combine multiple flow types on one command line, but each flow type must have its own option file.
- option file can be any of the option files that are valid for the specified flow type. See XFLOW Option Files for more information. In addition, option files are described in the applicable flow type section.
- xflow options can be any of the options described in XFLOW Options. Enter options in any order, preceded them with a dash (minus sign on the keyboard) and separate them with spaces.
- design_name is the name of the top-level design file you want to process. See XFLOW Input Files in the Overview section for a description of input design file formats.
Let's take our design and run the implementation flow to generate the bitstream file. XFLOW commands will execute from the terminal window prompt or they can be included in a script file.
--> cd .../LX9_LXN
--> xflow -p xc6slx9csg324-2 -implement balanced.opt -config bitgen implementation/LX9_LXN_system.ngc
XFLOW output files
XFLOW always outputs the following files and writes them to your working directory.
- HIS file - The xflow.his file is an ASCII file that contains the XFLOW command we entered to execute the flow, the flow and option files used, the command line commands of programs that were run, and a list of input files for each program in the flow.
- LOG file - The xflow.log file is an ASCII file that contains all the messages generated during the execution of XFLOW.
- TCL file - This script file contains the command line commands of all the programs run in a flow. This file is created for our convenience, in case we want to review all the commands run, or if we want to execute the script file at a later time. The default output file is xflow_script.scr.
The bitstream file LX9_LXN_system.bit is stored in the run directory.
Synthesize our design using Platgen
The Hardware Platform Generation tool (Platgen) customizes and generates the embedded processor system, in the form of hardware netlists files. By default, Platgen synthesizes each processor IP core instance found in our embedded hardware design using the XST compiler. Platgen also generates the system-level HDL file that interconnects all the IP cores, to be synthesized later as part of the overall Xilinx Integrated Software Environment (ISE) implementation flow. For more information see Embedded System Tools Reference Manual.
The following command is used to synthesize our design starting from the .mhs file.
--> platgen -p xc6slx9csg324-2 -lang vhdl -msg xmsgprops.lst LX9_LXN_system.mhs
Data2MEM is a data translation tool for contiguous blocks of data across multiple block RAMs which constitute a contiguous logical address space. With the inclusion of embedded CPU on a single chip, Data2MEM incorporates CPU software images into FPGA bitstreams. As a result, CPU software can be executed from block RAM-built memory within a FPGA bitstream. This provides a powerful and flexible means of merging parts of CPU software and FPGA design tool flows.
Use this command to merge the FPGA configuration bitstream with first-stage boot loader software image:
--> data2mem -intstyle xflow -bm implementation/LX9_LXN_system_bd -p xc6slx9csg324-2 -bt LX9_LXN_system.bit
tag microblaze_0 -o b download.bit
Configure the FPGA using iMPACT
Use the following command to configure the FPGA with the LX9_LXN_system.bit bitstream file.
impact -batch etc/download_xflow.cmd
The complete configuration script
By analyzing the makefiles and the log files generated during the make run we came up with the following script file. This script will take the MHS file from XPS and process it to a bitstream file and configure the FPGA in one run.
Top Previous Next