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

Thursday, July 12, 2007
FPGA design from scratch. Part 38

Writing software for our embedded system

I think we are ready to start writing some software to drive our embedded test controller. To make the application software easier to write and understand we will first come up with a software device driver for the ETC.

Writing a software device driver

As it says in the Xilinx Documentation:
Many of you have used embedded microprocessors in your recent FPGA designs. Some of you are experienced embedded processor users, and some of you are beginners to this method of design in FPGAs. Most embedded processor designers will at some stage decide that they need to incorporate a block of custom hardware into the processor system and then control it from software running on the processor. This is often a daunting task, and one that causes much confusion to the designer. This TechXclusive takes a step-by-step approach to designing a custom peripheral for use in an embedded processor system, then looks at some more advanced topics, including writing software device drivers for the created peripheral.

Software development overview

The embedded software platform defines, for each processor, the drivers associated with the peripherals we include in our hardware platform (the board support package), selected libraries, standard input/output devices, interrupt handler routines, and other related software features. Your Xilinx Platform Studio (XPS) project further defines software applications to run on each processor, which are based on the software platform.

Device Driver Programmer Guide

The purpose of this document is to describe the Xilinx device driver environment. This includes the device driver architecture, the
Application Programmer Interface (API) conventions, the scheme for configuring the drivers to work with reconfigurable hardware devices, and the infrastructure that is common to all device drivers.
This document is intended for the software engineer that is using the Xilinx device drivers. It contains design and implementation details necessary for using the drivers. The guide can be found here: EDK_install_dir/doc/usenglish/xilinx_drivers_guide.pdf and in html format :

We will use this guide and the TechXclusive to help us write a device driver for the ETC peripheral.

Platform Specification Format Reference Manual

EDK tools are designed to operate in a data-driven manner. There are various meta-data files that capture information, for example, about various IPs, drivers, and software libraries being used in the EDK tools. Files are also used to capture both hardware and software aspects of our design information. These are ASCII files. The set of all these meta-data formats is referred to as the
Platform Specification Format or PSF.

Microprocessor Driver Definition (MDD)

An MDD file contains directives for customizing software drivers. Each device driver has an MDD file and a Tcl (Tool Command Language) file associated with it. The MDD file is used by the Tcl file to customize the driver, depending on different options configured in the MSS file.

Libraries and driver generation

As it says in the Xilinx Documentation:
The MHS and the MSS files define a system. For each processor in the system, Libgen finds the list of addressable peripherals. For each processor, a unique list of drivers and libraries are built. Libgen does the following for each processor:
  • Builds the directory structure as shown here below.
  • Copies the necessary source files for the drivers, OSs, and libraries into the processor instance specific area: OUTPUT_DIR/processor_instance_name/libsrc.
  • Calls the design rule check (defined as an option in the MDD or MLD file) procedure for each of the drivers, OSs, and libraries visible to the processor.
  • Calls the generate Tcl procedure (if defined in the Tcl file associated with an MDD or MLD file) for each of the drivers, OSs, and libraries visible to the processor. This generates the necessary configuration files for each of the drivers, OSs, and libraries in the include directory of the processor.
  • Calls the post_generate Tcl procedure (if defined in the Tcl file associated with an MDD or MLD file) for each of the drivers, OSs, and libraries visible to the processor.
  • Runs make (with targets include and libs) for the OSs, drivers, and libraries specific to the processor. On Unix platforms (Linux and Solaris), the gmake utility is used, while on NT platforms, make is used for compilation.
  • Calls the execs_generate Tcl procedure (if defined in the Tcl file associated with an MDD or MLD file) for each of the drivers, OSs, and libraries visible to the processor.
For more information about library generation read chapter 4 in the  Embedded System Tools Reference Manual.

Device driver architecture

The architecture of the device drivers is designed as a layered architecture as shown in the figure . The layered architecture accommodates the many use cases of device drivers while at the same time providing portability across operating systems, toolsets, and processors. The layered architecture provides seamless integration with an
RTOS (Layer 2), high-level device drivers that are full-featured and portable across operating systems and processors (Layer 1), and low-level drivers for simple use cases (Layer 0).

 Layer 2, RTOS adaptation
 Layer 1, High level drivers
 Layer 0, Low level drivers


This source file centralizes basic configuration constants for all drivers within the system. Browsing this file gives the user an overall view of the system architecture. The device drivers and Board Support Package (BSP) utilize the information contained here to configure the system at runtime.
The amount of configuration information varies by device, but at a minimum the following items should be defined for each device:
  • Number of device instances
  • Device ID for each instance
  • A Device ID uniquely identifies each hardware device which maps to a device driver. A Device ID is used during initialization to perform the mapping of a device driver to a hardware device.
  • Device IDs are typically assigned either by the user or by a system generation tool. It is currently defined as a 16-bit unsigned integer.
  • Device base address for each instance
  • Device interrupt assignment for each instance if interrupts can be generated.
Here is an example:

/* Definitions for peripheral RS232_UART */

#define XPAR_RS232_UART_BASEADDR 0x40600000
#define XPAR_RS232_UART_BAUDRATE 9600

The xparameters.h file can be found in the include directory.

Software driver source code

During the library generation (
libgen) run, the source code for every driver used, is copied to the SDK project directory libsrc, from the Xilinx source code repository. The old code will be overwritten and therefore we will never make any changes to the code in the libsrc directory. Here is the libgen log file.

Source code repository

Software device drivers used

To find out which software device drivers are used we can open Software Platform Settings and select Drivers. In the Xilinx Platform Studio SDK select Xilinx Tools->Software Platform Settings. The ETC peripheral has a generic driver assigned as default. We will add our own driver.

SDK project directory

The specified version of the driver source code is stored in the libsrc directory.

Let's take the GPIO driver as an example and look at different source files and their usage.

Header source file (xgpio.h and xgpio_l.h)

header files contain the interfaces for a component. There will always be external interfaces which is what an application that utilizes the component invokes.
  • The external interfaces for the high level drivers (Layer 1) are contained in a header file with the file name format x<component name>.h.
  • The external interfaces for the low level drivers (Layer 0) are contained in a header file with the file name format x<component name>_l.h.
The xgpio.h file contains the follwing type definitions.

/**************************** Type Definitions ******************************/

 * This typedef contains configuration information for the device.
typedef struct
    Xuint16  DeviceId;          /* Unique ID  of device */
    Xuint32  BaseAddress;       /* Device base address */
    Xboolean InterruptPresent;  /* Are interrupts supported in h/w */
    Xboolean IsDual;            /* Are 2 channels supported in h/w */
} XGpio_Config;

 * The XGpio driver instance data. The user is required to allocate a
 * variable of this type for every GPIO device in the system. A pointer
 * to a variable of this type is then passed to the driver API functions.
typedef struct
    Xuint32  BaseAddress;       /* Device base address */
    Xuint32  IsReady;           /* Device is initialized and ready */
    Xboolean InterruptPresent;  /* Are interrupts supported in h/w */
    Xboolean IsDual;            /* Are 2 channels supported in h/w */
} XGpio;

It also contains a number of
function prototypes. The functions themselves are defined in the different .c files found in the gpio source directory.

/************************** Function Prototypes *****************************/

 * Initialization functions in xgpio_sinit.c
XStatus XGpio_Initialize(XGpio *InstancePtr, Xuint16 DeviceId);
XGpio_Config *XGpio_LookupConfig(Xuint16 DeviceId);

 * API Basic functions implemented in xgpio.c
XStatus XGpio_CfgInitialize(XGpio *InstancePtr, XGpio_Config *Config,
                            Xuint32 EffectiveAddr);
void    XGpio_SetDataDirection(XGpio *InstancePtr, unsigned Channel,
                               Xuint32 DirectionMask);
Xuint32 XGpio_DiscreteRead(XGpio *InstancePtr, unsigned Channel);
void    XGpio_DiscreteWrite(XGpio *InstancePtr, unsigned Channel, Xuint32 Mask);

Configuration table xgpio_g.c

This file contains configuration tables for all devices that uses the GPIO device driver.

* The configuration table for devices

XGpio_Config XGpio_ConfigTable[] =

Adding the ETC software device driver

From the Xilinx documentation it isn't 100% clear how to add a new device driver. Here is how I did it and it seems to work.

1. Edit the ETC_system.mss file and add the etc driver. Like this:


2. Add a new directory called drivers and the subdirectories as shown here:

3. Copy template files to src and data directories. We will use the gpio device driver source code as our template files. It is important to copy the .tcl and .mdd files to the data directory. Libgen will complain if it doesn't find these files.

4. Rename and edit the template files. For the moment we will not bother about writing working code. We will only rename everything called <gpio> to <etc>. Don't forget to make changes to the Makefile. Libgen will use the Makefile during library generation to compile and link the ETC device driver source code.

5. Edit the .mdd and .tcl files. Find out more

6. Run library generation. Select Software->Generate Libraries and BSPs in the Xilinx Platform Studio. Libgen will search inside the drivers or pcores directories for device driver source code.

7. The ETC software device driver source code will be compiled into the library libxil.a together with all other device drivers.

Top  Next  Previous

Posted at 09:34 by

August 30, 2007   09:10 PM PDT
Hi Svend,
I like your work.
You should listen to your wife and publish a book.
August 30, 2007   05:19 PM PDT
Super great Svend. A resource like this is one young engineers need to catch the trade. Don't you think it will be a good idea to make all these resources downloadable by one click. i mean like a pdf zip file where all the resouces can be downloaded and read at convenience without sitting in front of the computer all the time
August 9, 2007   08:26 AM PDT
I have no plans today to add more vendors like Altera and Actel. I will finish this tutorial and then we will see. I spend a lot of unpaid time blogging and my wife thinks I should bring home some money instead. I have looked at and I open source is always good.

Leave a Comment:


Homepage (optional)


Previous Entry Home Next Entry