New Horizons

Welcome to my blog

My name is Sven Andersson and I
work as a consultant in embedded
system design, implemented in ASIC
and FPGA.
In my spare time I write this blog
and I hope it will inspire others to
learn more about this fantastic field.
I live in Stockholm Sweden and have
my own company


You are welcome to contact me
and ask questions or make comments
about my blog.


New Horizons
What's new
Starting a blog
Writing a blog
Using an RSS reader

Zynq Design From Scratch
Started February 2014
1 Introduction
Changes and updates
2 Zynq-7000 All Programmable SoC
3 ZedBoard and other boards
4 Computer platform and VirtualBox
5 Installing Ubuntu
6 Fixing Ubuntu
7 Installing Vivado
8 Starting Vivado
9 Using Vivado
10 Lab 1. Create a Zynq project
11 Lab 1. Build a hardware platform
12 Lab 1. Create a software application
13 Lab 1. Connect to ZedBoard
14 Lab 1. Run a software application
15 Lab 1. Benchmarking ARM Cortex-A9
16 Lab 2. Adding a GPIO peripheral
17 Lab 2. Create a custom HDL module
18 Lab 2. Connect package pins and implement
19 Lab 2. Create a software application and configure the PL
20 Lab 2. Debugging a software application
21 Running Linux from SD card
22 Installing PetaLinux
23 Booting PetaLinux
24 Connect to ZedBoad via ethernet
25 Rebuilding the PetaLinux kernel image
26 Running a DHCP server on the host
27 Running a TFTP server on the host
28 PetaLinux boot via U-boot
29 PetaLinux application development
30 Fixing the host computer
31 Running NFS servers
32 VirtualBox seamless mode
33 Mounting guest file system using sshfs
34 PetaLinux. Setting up a web server
35 PetaLinux. Using cgi scripts
36 PetaLinux. Web enabled application
37 Convert from VirtualBox to VMware
38 Running Linaro Ubuntu on ZedBoard
39 Running Android on ZedBoard
40 Lab2. Booting from SD card and SPI flash
41 Lab2. PetaLinux board bringup
42 Lab2. Writing userspace IO device driver
43 Lab2. Hardware debugging
44 MicroZed quick start
45 Installing Vivado 2014.1
46 Lab3. Adding push buttons to our Zynq system
47 Lab3. Adding an interrupt service routine
48 Installing Ubuntu 14.04
49 Installing Vivado and Petalinux 2014.2
50 Using Vivado 2014.2
51 Upgrading to Ubuntu 14.04
52 Using Petalinux 2014.2
53 Booting from SD card and SPI flash
54 Booting Petalinux 2014.2 from SD card
55 Booting Petalinux 2014.2 from SPI flash
56 Installing Vivado 2014.3

Chipotle Verification System

EE Times Retrospective Series
It all started more than 40 years ago
My first job as an electrical engineer
The Memory (R)evolution
The Microprocessor (R)evolution

Four soft-core processors
Started January 2012
Table of contents
OpenRISC 1200
Nios II

Using the Spartan-6 LX9 MicroBoard
Started August 2011
Table of contents
Problems, fixes and solutions

FPGA Design From Scratch
Started December 2006
Table of contents
Acronyms and abbreviations

Actel FPGA design
Designing with an Actel FPGA. Part 1
Designing with an Actel FPGA. Part 2
Designing with an Actel FPGA. Part 3
Designing with an Actel FPGA. Part 4
Designing with an Actel FPGA. Part 5

A hardware designer's best friend
Zoo Design Platform

Installing Cobra Command Tool
A processor benchmark

Porting a Unix program to Mac OS X
Fixing a HyperTerminal in Mac OS X
A dream come true

Stockholm by bike

The New York City Marathon

Kittelfjall Lappland

Tour skating in Sweden and around the world
Wild skating
Tour day
Safety equipment
A look at the equipment you need
Skate maintenance
Books, photos, films and videos
Weather forecasts

38000 feet above see level
A trip to Spain
Florida the sunshine state

Photo Albums
Seaside Florida
Ronda Spain
Sevilla Spain
Cordoba Spain
Alhambra Spain
KittelfjÀll Lapland
Landsort Art Walk
Skating on thin ice

100 Power Tips for FPGA Designers

Adventures in ASIC
Computer History Museum
Design & Reuse
d9 Tech Blog
EDA Cafe
EDA DesignLine
Eli's tech Blog
FPGA Arcade
FPGA Central
FPGA developer
FPGA Journal
FPGA World
Lesley Shannon Courses
Mac 2 Ubuntu
Programmable Logic DesignLine
World of ASIC

If you want to be updated on this weblog Enter your email here:

rss feed

Monday, December 05, 2011
FPGA design from scratch. Part 84

Running Xilinx tools using makefiles

When using the Xilinx Platform Studio to design an embedded system we will:

  1. Build the system using the GUI or/and the wizard
  2. Convert the GUI setup to RTL code (Generate Netlist).
  3. Synthesis the RTL code to a netlist (Generate Netlist)
  4. Map the netlist in to LUTs (Generate Bitstream)
  5. Place and route the LUTs (Generate Bitstrem)
  6. Generate the bitstream to configure the FPGA (Generate Bitstream)
  7. 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.

Build flows

Xilinx provides several options to build a design using command-line tools. The most popular options are:

  • Direct invocation
  • Xflow
  • xtclsh
  • PlanAhead

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:

--> xilperl


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.

Running XFLOW

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

XFLOW syntax

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

Using Data2MEM

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
-bd ../../PetaLinux/petalinux-v2.1-final-full/hardware/user-platforms/LX9_MB/workspace/fs-boot_0/Release/fs-boot_0.elf
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

Posted at 11:07 by


Leave a Comment:


Homepage (optional)


Previous Entry Home Next Entry