Tag Archives: Zynq

ZedBoard Part 3 SDK


For the majority of this blog, we will be using the Xilinx Software Development Kit (SDK). However, there is one last thing we need to do within PlanAhead first, and that is to export the hardware to the SDK. (Note that we will need to do this each time we make a change to the hardware.)

Actually, it might be worth taking a moment to explain this in a little more detail, because this is the sort of thing that can sneak up and bite you on the bottom later if you don’t fully understand what’s going on, so let’s take a small step back…

As we know, the Zynq-7000 All Programmable SoC powering the ZedBoard is composed of two distinct sections: the programmable logic (PL) section and the processing system (PS) section. What we’ve done in my previous blogs is to define the hardware portion of the system — specifically, we’ve established some simple functionality in the programmable logic that will drive some LEDs in the outside world; we’ve specified what we want to use in the processor subsystem (the ARM Cortex-A9, the DDR RAM, the SPI, etc.); and we’ve set up an AXI bus linking the PS and PL sections. Finally, we’ve generated the configuration bit-file that will be used to set up the hardware portion of the system.

When I say that we need to use PlanAhead to “export the hardware to the SDK,” I’m talking about informing the SDK as to the nitty-gritty details of our hardware configuration, including such things as the address ranges of any external memories and the register maps associated with any peripheral functions and hardware accelerators implemented in the programmable fabric (we don’t have any hardware accelerators at this time, but we may add some later).

OK, so we select the “Export Hardware to SDK…” menu item, as illustrated in the screenshot below.

at-0014-01-lg This should result in SDK being opened and the hardware specification being imported, as illustrated in the screenshot below

at-0014-02-lg Once the hardware has been imported, we will need to create a board support package (BSP), as illustrated in the screenshot below


This BSP will be specific to our hardware implementation. In addition to containing drivers for any of the peripherals we are using, it will also include a number of hardware-specific C header files, such as “xparameters.h,” which defines the memory map of the system along with other system configuration parameters. In the case of our example, when creating this BSP, we must make sure to select the target processing system and CPU0.

Now we are at the stage when we can finally start to create our software project, which will use the imported hardware and BSP, as illustrated in the screenshot below.



For the purposes of my first test case, I decided to create a very simple C application to send a message over the UART to the console and flash a pattern on the LEDs connected to the AXI port in the programmable logic side of the device. In order to do this, I selected the “Xilinx C Project” option, as illustrated in the screenshot below



The next step allows you to name the project and select if you want a basic template for a project. Since none of the provided templates offered what I was intending to implement, I opted to go with a blank template, as illustrated below


My goals for this first project were very simple. As I mentioned earlier, all I want to do is to send a message up to the console and flash a pattern on the LEDs, thereby proving to myself that I know how to get PS portion of the Zynq to communicate with its PL counterpart.

If you are unsure of the peripheral drivers within the system — or if you are not sure how to drive them — take a look at the “system.mss” file under your BSP within the project explorer. This also provides a list of helpful links to documentation and examples.

Next, we need to include a number of C header files that contain parameters and functions that can be used by the software developer. The header files I included in my project were as follows:

  • Stdio.h — Defines the standard Input and Output (this should be familiar to anyone who has worked with C).
  • Platform.h — Defines basic functions for the implementation and platform initialization and clean-up.
    Xil_types.h — Defines a number of types needed for Xilinx IP cores.
  • Xgpio.h — Defines the drivers for the AXI bus driving the general purpose input/output (GPIO) module we have connected to the LEDs in the outside world.
  • Xparameters.h — Defines the hardware architecture and configuration for this implementation.

With these files included, I next wrote a small bit of C code to achieve my aims (click here to download a compressed ZIP file containing this C source code). Having written our code and having successfully compiled it, we next wish to download the application into our ZedBoard. In order to do this, we first need to create a linker file script that will specify where the executable is placed in the system memory. My program was tiny and would easily fit in the on-chip memory; however, I decided to place my executable in the external DDR memory so as to demonstrate that this interface was also configured correctly. We can create our linker script by right-clicking on our project and selecting the “Generate Linker Script” option, as illustrated in the screenshot below


We’re almost there. The next task we have to perform is to set up the run configurations using “Project Explorer -> Project -> Run -> Run” in the right-click menu. This is where we can define our STDIO connection to the serial port we are using for the STDIO. Once we are happy, we can apply the configuration and then close the dialog. (Do not click “Run” as we are not quite ready for that.) The final stage is to connect the ZedBoard board to our PC using both the UART USB cable and the programming USB cable. We should now be able to program the ZedBoard via the SDK, as illustrated in the screenshot below


Always make one last check that you are using the correct configuration bit-file (which tells you that I’ve slipped up myself on at least one occasion) and then program the device, as illustrated in the screenshot below


Once the configuration has completed successfully, you will see the “Done LED” illuminate on the ZedBoard. Having completed the configuration, you can now download the ELF file and try out your program. Doing this is as simple as selecting your project within the project explorer, right-clicking “Run As,” and then selecting the “Launch on Hardware” option, as illustrated in the screenshot below.







ZedBoard Part 2 Creating the Embedded System


As you may recall, when we last parted company at the end of part 1 in this mini-series, we were just about to create the processing system.

Having clicked on the “Add or Create Embedded Sources” option, you will be presented with the ability to select a name for the processing system you will be creating, Being original as always, I chose to name mine “processor_subsystem,” as illustrated below:


Following this, you will be taken through a number of stages to create a Base System using what is called the “BSB wizard,” as illustrated below:


Next, you will be pseudo-prompted to select the bus structure you wish to use — AXI or PLB. The reason I say “pseudo-prompted” is that you really don’t have a choice here because the PLB option will be greyed out allowing only the selection of the AXI bus, as illustrated below


The next screen will ask you to confirm the version of the development board we are targeting. As I mentioned previosuly, for some reason or other there is no ZedBoard option at this time, so we shall instead target the Zynq ZC702 Evaluation Platform, as illustrated below.


his will result in the opening of Xilinx Platform Studio, at which time you will be presented with a graphical representation of the processing system within the devices. If, like me, you encounter any licensing issues, then please follow the steps outlined here.

At this stage, we have almost completed the implementation of the processing system. However, as I mentioned earlier, we are currently targeting the Zynq ZC702 Development Board and not the ZedBoard we are actually using. In order to correct this we first need to download the appropriate board definition file by clicking here.

Board definition files define how the Zynq’s processing system interfaces to the external world and includes things like DDR memory timing. If you were developing your own design with the Zynq on a custom PCB, this stage could be quite time consuming. Fortunately, the creators of the ZedBoard have already done this for us — thanks to the board definition file we can easily reconfigure the design for the ZedBoard environment. Having imported this file, you should see some obvious changes — particularly in the I/O peripheral column — as illustrated below.



While in the “System Assembly View” window, select the “Bus Interfaces” tab and check that the “LEDs_8Bits” show they are connected to the “axi4lite” bus — that is, they do not show “not connected” — as illustrated below.


Next, click on the “Ports” tab and check that the LED outputs are declared as external ports and are connected to the external pins, as illustrated below.


The final step within XPS is to run a design rule check to ensure we have created a system which complies with the design rules. We do this by clicking the “Project” menu and selecting the “Design Rule Check” item from the resulting options, as illustrated below.



Once everything has checked out, you can close XPS and return to PlanAhead, which we are going to use to generate the RTL netlist, pin constraints, and a configuration bitfile. At this point, we have defined what the processing system will contain:

  1. The processing system (PS) section with DDR, UART, Ethernet, USB,SD, GPIO, and Flash memory support.
  2. The programmable logic (PL) section containing one AXI slave connected to a GPIO module interfacing to the LEDs.

The final remaining steps before a configuration bitfile can be generated are to generate an HDL netlist and create a constraints file containing pin-out information for the PL side of the Zynq. This can be generated in either VHDL or Verilog as defined via the project settings. Generating this HDL file is as simple as right-clicking on your processing system name and selecting the “Create Top HDL” option, as illustrated below.


The constraints file can be created within PlanAhead by right-clicking on the “Constraints” option in the source window and selecting the “Add Sources” item. This will allow you to create the file. Within this file you will need to type the following to connect the GPIO slaves in the programmable logic section to the correct IO.

Note that you can obtain the schematics for the ZedBoard, along with a wealth of other information from the “Documentation” area on the ZedBoard.org website.

You can now use PlanAhead to generate the configuration bitstream. In order to do anything useful, however, we will first need to write some software — I will cover this topic in my next column



ZedBoard Part 1 Introduction


How exciting! I just took delivery of my very own ZedBoard — a low-cost development board for the Xilinx Zynq-7000 All Programmable SoC (AP SoC).

As I’m sure you will recall, the Zynq itself combines a full hard core implementation of a dual ARM Cortex-A9 microcontroller subsystem (running at up to 1GHz and including floating-point engines, on-chip cache, counters, timers, etc.), coupled with a wide range of hard core interface functions (SPI, I2C, CAN, etc.), and a hard core dynamic memory controller, all augmented with a large quantity of traditional programmable fabric, some programmable analog functionality, and a substantial number of general-purpose input/output (GPIO) pins. In addition to the Zynq, the ZedBoard contains everything necessary to create a Linux, Android, Windows, or other OS/RTOS-based design. Additionally, several expansion connectors expose the processing system and programmable logic I/Os for easy user access.

For my first blogs about the Zynq, I thought would write a simple guide explaining how the design tools integrate and what is needed to get the board up and running with a simple application that can be built upon in both software and hardware terms.

Creating an All Programmable SoC design requires a little more effort than developing a traditional logic-based FPGA design; however, it is still pretty straightforward and the tool chain provides good guidance. To create an All Programmable SoC design, you will need to use, as a minimum, the following:

  1. Xilinx Platform Studio: This is where you create you processing system, be it a PowerPC, Microblaze, or — in this case — the Zynq’s dual core ARM Cortex-A9. Here you define the configuration, interfaces, timing, and address ranges; everything needed to generate a processor system. The output from this process is an HDL netlist defining your system.
  2. Xilinx ISE: Most FPGA engineers are familiar with this tool, which takes your HDL design — including the XPS netlist — and generates the required BIT configuration file.
  3. Xilinx Software Development Kit (SDK): This is where the software that will run on the processing system is developed. To correctly generate the software, the SDK needs to be aware of the hardware configuration of the system.
  4. Impact: Performs the loading of the BIT configuration bitfile into the system.

All of these tools can be used in isolation to create an All Programmable SoC. Rather helpfully, however, Xilinx PlanAhead is capable of integrating them together, thereby allowing for a much simpler development process. It is using this PlanAhead approach that I will focus upon for the rest of this blog.

Zynq devices are split into two distinct sections: the programmable logic (PL) section and the processing system (PS) section. This blog will predominantly focus on implementing a PS system augmented with a simple logic design within the PL fabric, thereby allowing me to demonstrate an implementation that uses both sections of the Zynq.

The first step in this development is to open PlanAhead and create a new RTL project as shown in the following two images



This is fairly straightforward since — as you initially have no existing RTL, IP, or constraints — you can simply keep on selecting the “Next” option until you reach the “Device Selection” dialog. It is at this dialog that you should select the board option — not the device — and target the Xilinx ZC702 Evaluation board as shown below. Yes, I know that this is not the ZedBoard, but we will return to deal with this point in my next blog


Once the project has been created, you will be presented with the default screen in PlanAhead, at which point you need to add a source to the design. You can do this by selecting the “Add Sources” item under the “Project Manager” options in the “Flow Navigator” area, which should be on the left-hand side of the screen as shown below


As we are currently interested in getting the processing system side of the Zynq up and running, select the “Add or Create Embedded Sources” option as shown in the following image. As we shall see, the general-purpose input/output (I/O) for our programmable logic will be called up here as well


This will open yet another dialog, from which we can select the “Create Sub-Design” button as shown in the image below


OK, we’re almost there. Although this may seem a little complicated, it’s actually pretty easy once you get the hang of it. In my next blog we will complete the configuration and use PlanAhead to generate the bitstream and download it into the device.


A Double-Barreled Way to Get the Most from Your Zynq SoC



One of the many benefits
of the Xilinx® Zynq®-7000
All Programmable SoC is
that it is has two ARM®
Cortex™-A9 processors
onboard. However, many
bare-metal applications and simpler operating
systems use only one of the two
ARM cores in the Zynq SoC’s processing
system (PS), a design choice that can potentially
limit system performance.
Depending upon the application in development,
there could, however, be a need
to have both processors running bare-metal
applications, or to run different operating
systems on each of the processors. For
instance, one side could be performing
critical calculations and hence running a
bare-metal/RTOS application while the second
processor is providing HMI and communications
using Linux.

Link here


Calculating Mathematically Complex Functions Issue 87



Thanks to their flexibility and performance,
FPGAs have found
their way into a number of industrial,
science, military and other
applications that require the calculation
of complex mathematical problems
or transfer functions. It is not uncommon to
see tight accuracy and calculation latency
times in the more critical applications.
When using an FPGA to implement mathematical
functions, engineers normally
choose fixed-point mathematics (see Xcell
Journal issue 80, “The Basics of FPGA
Mathematics,” http://issuu.com/xcelljournal/
Also, there are many algorithms, such as
CORDIC, that you can use to calculate transcendental
functions (see Xcell Journal issue
79, “How to Use the CORDIC Algorithm
in Your FPGA,” http://www.xilinx.com/
publications/archives/xcel l/Xcell79.pdf).
However, when confronting functions that
are very mathematically complex, there are
more efficient ways of dealing with them than
by implementing the exact demanding function
within the FPGA. To understand these
alternative approaches—especially one of
them, polynomial approximation—let us first
define the problem.

Link here


How to use Interrupts on the Zynq SoC Issue 87



In embedded processing, an interrupt is
a signal that temporarily halts the processor’s
current activities. The processor
saves its current state and executes
an interrupt service routine to address
the reason for the interrupt. An interrupt can
come from one of the three following places:
• Hardware – An electronic signal connected
directly to the processor
• Software – A software instruction loaded by
the processor
• Exception – An exception generated by the
processor when an error or exceptional
event occurs
Regardless of the source, interrupts can also
be classified as either maskable or non-maskable.
You can safely ignore a maskable interrupt
by setting the appropriate bit in an interrupt
mask register. But you cannot ignore a
non-maskable interrupt, because these are the
types typically used for timers and watchdogs.
Interrupts can be either edge triggered or
level triggered. The Xilinx® Zynq®-7000 All Programmable
SoC supports configuration of the
interrupt either way, as we will see later.

Link here


How to Add a RTOS to your Zynq SoC Design Issue 86



In the quest to gain the maximum benefit from the processing system within a Xilinx® Zynq®-7000 All Programmable SoC, an operating system will get you further than a simple bare-metal solution. Anyone developing a Zynq SoC design has a large number of operating systems to choose from, and depending upon the end application you may opt for a real-time version. An RTOS is your best choice if you are using the Zynq SoC in industrial, military, aerospace or other challenging environments where response times and reliable performance are required to prevent loss of life or injury, or to achieve strict performance goals

Link here


Implementing Analog Mixed Signal on the Zynq SoC



The Xilinx® Zynq® All Programmable
SoC comes with an XADC block
that contains two 12-bit analog-todigital
converters. These ADCs are capable
of sampling at up to 1 Megasample per second
(MSPS), providing an ideal effective
input-signal bandwidth of 500 kHz (250 kHz
on the auxiliary inputs). The XADC can multiplex
among 17 inputs along with a number
of internal voltages and temperatures. If
your design is pin-limited in terms of available
analog-capable inputs for external signals,
you can configure the XADC to drive an
external analog multiplexer and sequence
through all the inputs in the desired order.

Link here


How to Boost Zynq Performance by Creating Your Own Peripheral issue 84




One of the real advantages of the Xilinx® Zynq™-
7000 All Programmable SoC is the ability to
increase the performance of the processing system
(PS) side of the device by creating a peripheral within
the programmable logic (PL) side. At first you might
think this would be a complicated job. However, it is surprisingly
simple to create your own peripheral.
Adding a peripheral within the PL can be of great
help when you’re trying to speed up the performance
of your processing system or when you’re using the
PS to control the behavior of the design within the
programmable logic side. For example, the PS might
use a number of memory-mapped registers to control
operations or options for the design within the programmable

Link here


How to Configure Your Zynq SoC Bare-Metal Solution Issue 83




Because of its unique mix of ARM processing
clout and FPGA logic in a single device, the
Zynq™-7000 All Programmable SoC requires a
twofold configuration process, one that takes into
account both the processor system and the programmable
logic. Engineers will find that the configuration
sequence differs slightly from that of traditional
Xilinx® FPGAs. Nevertheless, the methodology is
familiar and it’s not at all difficult to generate a boot
image and program the configuration memory.
Where standard FPGA configuration practices normally
require only the FPGA bit file, you will need to
add a second type of configuration file to get the maximum
benefit from your Zynq SoC: the SW Executable
and Linakble Format (ELF) file. The FPGA bit file
defines the behavior of the programmable logic section
of your design, while ELF file is the software program
that the processing system will execute.
So let’s have a look at how to implement a baremetal
(no operating system) software application on
your Zynq SoC.

Link here