Development with Zynq – Part 1 – Overview

This blog series describe the selection, set-up and usage of a development environment for Zynq.

Overview of Zynq

The Zynq-7000 Family is an Extensible Processing Platform. It is the newest try from Xilinx to interconnect a Processor System (PS) with Programmable Logic (PL) to a System-on-Chip. Zynq combine a dual core arm and a FPGA.

The first processor/FPGA concepts concentrate on the PL side. They were developed by FPGA companies and so the integration of a hard processor core was a logical development step. Without a programmed PL it was not possible to run the PS. Running an operating system requires close collaboration of software and hardware developers. Two worlds collide.

Altogether high development cost meets high unit costs. The result was not a wonder.

New concepts like Xilinx Zynq or the Altera SoCs are processor concentrated. The processor runs with minimal PL programming. Flexibility is lost, but parallel hardware and software development direct from project start is possible.

Overview of Zynq PL development

Many instructions for creating a Development Platform for Zynq can be found on the internet. This instruction differs in the used development environment for the PL and the Cross Compiler Platform for the PS.

Almost all instruction uses Xilinx PlanAhead, Xilinx XPS and Xilinx ISE. ISE is used for Programming with VHDL or Verilog. XPS is a graphical tool used to configure and connect IP Cores. PlanAhead is a project tool based on defined hardware platforms to combine XPS blocks with pinning and synthesizing the entire project.

In normal workflow a project for a specific hardware is defined with PlanAhead. Own code is developed and simulated with ISE and packet to a core. Xilinx cores and own cores are combined in XPS to a block and synthesized to a bit-file in PlanAhead. But other workflows are used too. So it is possible to import a PlanAhead project in ISE and connect it to own VHDL/Verilog Code.

What is the real gain of using three tools and different workflows? All I can say, I do not like the concept.

Since release 2013.2 Xilinx Vivado supports the Zynq. Vivado is a newer development environment which integrates the Zynq PL developing in one tool. Vivado provide better synthesis results and has a better graphical user interface.

Overview of Zynq PS development

The following own assessments are based on practical testing and information from ug821-zynq-7000-swdev.

Operating System

Depending on the used operating system the PS developments vary greatly. Let’s take a look on the variants.


Running without an operating system. Without OS overhead it is possible to write fast programs. Also no OS booting is needed. The disadvantage is that realizing complex systems with components like webserver, FTP-server, USB support and so on is not really possible.

For development an arm toolchain with eabi support is needed. Xilinx SDK provides such a toolchain.

Real-Time Operating System

For applications with strict time constraints an OS with real-time support is needed. Most RTOS are commercial.


A suitable Linux distribution provides the greatest flexibility. Many libraries and software package with tutorials are provided by the big Linux developer and user community.

Because Zynq use a dual-core processor it is possible to run two variations simultaneous. For more information, please see Multi-OS.

Linux distribution

My plan is to develop an embedded system configured via web browser with USB und FTP support. Therefore I use a Linux distribution. Petalinux from Xilinx is the best solution but I want a free solution and not paying $7,000 USD per seat, per year.

I am not an expert in embedded Linux distribution. I search the internet and Ubuntu provided by Linaro was often used for Zynq.


For Linux development a compiler is needed. Different methods of compiling are possible.


Crosscompiling is standard in development. This is due to the fact that earlier target systems were unsuitable to handle source code. A valid advantage is that the crosscompiler did not affect the target.

For Zynq different crossscompiler are suitable. I only compare the features, so I cannot provide benchmark information.

Xilinx SDK included version

Includes current Sourcery CodeBench Lite Edition with additional Vector Floating Point (VFP) and NEON™ optimized libraries

Sourcery CodeBench Lite Edition

Smaller installation package than Xilinx version. But libraries not optimized.

Sourcery CodeBench Lite 2011.09-50 for Xilinx

Download xilinx-2011.09-50-arm-xilinx-linux-gnueabi.bin. Used in many tutorials. The Xilinx SDK included version is newer and has the same features. I think this version is obsolete.

Linaro Crosscompiler

Small installation package with VFP and NEON™ support. It supported full hardware floating point mode (-mfloat-abi=-hard) which will be discussed later. More information under CrossbuildingQuickStart.

Sourcery CodeBench Xilinx Edition

I only want to use free versions. Therefore I have not tested it.

Compiling on Target

Using the target system as development environment

The PS is fast enough to install a Linux distribution with IDE for programming. Disadvantages are

  • Not ideal GUI speed
  • GUI IDE with dependencies increase footprint
  • Custom PL is critical
    • because the Linux distribution needs certain components (e.g. HDMI)
    • troubleshooting is difficult, because of system freezes

Remote compiling and debugging/ shared project

Remote compiling need only a compiler and debugger on the target system. No GUI IDE is needed because the source code is edited on the development system. I tested both with Eclipse 4.3. Remote compiling works but Source Code only on the target is critical. Shared projects are a nice concept. Source code is saved on the development system and synchronized to target before compiling. In Eclipse Shared projects are quite buggy and git is needed on the target.

First I used the Xilinx SDK included Crosscompiler. I get big problems binding a library to my project. I find out, that since version 12.04 Linaro provides ARM hard float (armhf) images. These images only run with a hardware floating point unit. This is a forward-looking decision because floating point operations running faster with hard-float. A disadvantage is that hard-float libraries are only compatible to other hard float libraries. More information under ArmHardFloatPort

For hard float I have to compile my project with compiler flag “-mfloat-abi=hard”. The free Crosscompiler from Xilinx did not compile my source code. Therefore I setup a remote compiling and a shared project environment. But for me the handling was bad. Searching an armhf crosscompiler results in the successfully usage of the Linaro Crosscompiler.

My next blog entry explains how to setup the chosen development environment.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.