datasheets.com EBN.com EDN.com EETimes.com Embedded.com PlanetAnalog.com TechOnline.com  
Events
UBM Tech
UBM Tech

Design Article

Tell us What You Think

We want to know what you thought about this Design. Let us know by adding a comment.

ADD A COMMENT >

Getting your Zynq SoC design up and running using PlanAhead

Adam Taylor, EADS Astrium

2/8/2013 11:22 AM EST

Editor's Note: This article first appeared in Issue 82 of Xcell Journal, and is reproduced here with the kind permission of Mike Santarini, Publisher / Sr. Manager Xcell Journal & Editorial Services, Worldwide Communications, Xilinx.


This is the first in a planned series of hands-on Zynq-700 All Programmable SoC tutorials by Adam Taylor. A frequent contributor to Xcell Journal, Adam is also a blogger at All Programmable Planet (www.programmableplanet.com)

The Zynq-7000 All Programmable SoC is the first of a new class of Xilinx devices that marry a dual-core ARM Cortex-A9 processor with programmable logic on a single chip (see cover story, Xcell Journal issue 75). As such, the device offers a great leap forward in not only system flexibility, but also performance and integration. This system-on-chip platform does, however, require the FPGA engineer to consider a slightly different development path than is customary for logic-based FPGAs.

The good news is that development is not as difficult as you might think, thanks in large part to the availability of the Xilinx PlanAhead tool. Let’s take a closer look at the steps involved in generating a Zynq-7000 system that you can load via JTAG.

Lots of FPGA resources
The Zynq-7000 family combines the dual-core ARM Cortex-A9 processor – the chip’s processing system (PS) – with programmable logic (PL) resources equivalent to devices from the Xilinx Artix or Kintex families. Depending upon the device and speed grade you select, it is possible for the processing system to operate at frequencies up to 1 GHz.

The processing system side of the Zynq SoC provides supporting hardware for a number of memory and communications peripherals. This architecture allows the PS to be the master and to operate autonomously, without the need to even power up or configure the programmable logic system. The key features the processing system supports are:
  • Dynamic RAM interface – double-data-rate SDRAM, supporting both DDR2 and DDR 3 standards, including LPDDR2.
  • Static RAM interfaces – support for SRAM devices along with NAND, NOR and QSPI flash memories.
  • Communications interfaces – UART, CAN, I2C, SPI, USB, Gigabit Ethernet and SD/SDIO.
  • General-purpose I/O – support for up to four 32-bit general-purpose I/Os.

With the exception of the DRAM link, the remaining interfaces utilize the Multiuse I/O, a bank of 54 I/O pins that you can assign to different functions as required. This does, of course, mean you cannot implement all peripherals at once. However, you can extend this interface into the programmable logic if you wish.
Communication between the processing system and programmable logic sides is comprehensive, and includes:
  • Advanced Microcontroller Bus Architecture (AMBA) and Advanced eXtensible Interface (AXI), with both master and slave interfaces, including direct links to external DDR and on-chip memory. In addition, the Accelerator Coherency Port (ACP) provides coherent access to the CPU memory space from the programmable logic side.  
  • Extended Multiuse I/O, which allows you to increase the number of processing system peripherals by using programmable logic I/O.
  • Direct memory access and interrupts, including 16 interrupts from the PL to the PS, along with four DMA channels.
  • Four clocks and resets from the processing system to the programmable logic.

Zynq configuration differs from the process of configuring many of the previous families of Xilinx FPGAs, even those that contained hard macro processors like the Virtex-2 Pro, Virtex-4 and Virtex-5 families. Within the Zynq system, the processing side is the master and therefore boots following a normal software boot process, loading in the application from nonvolatile memory and then either executing in place or cross-loading the application into faster DDR memory using a more complex boot loader. The programmable logic side of the Zynq loads via the Processor Configuration Access Port (PCAP), which allows both partial and full configuration. As always, you can also configure the device through the JTAG interface. Because of this added complexity, the Zynq device has more mode pins than you normally find on an FPGA to support all of these various configuration methods.

What tools do we need?

Creating a system-on-chip (SoC) requires a little more effort than developing a logic-based FPGA design. However, it is still pretty straightforward and the tool chain provides good guidance. To create a Zynq SoC design you will need four tools at a minimum: Xilinx Platform Studio, the ISE Design Suite, Xilinx’s Software Development Kit (SDK) and iMPACT.

Xilinx Platform Studio is the place where you create your processing system, be it PowerPC, MicroBlaze or, in this case, the Zynq PS. Here, in XPS, 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.

Most FPGA engineers are familiar with ISE. This Xilinx tool chain takes your HDL design, including the XPS netlist, and generates the required bit file. The Software Development Kit, meanwhile, is where you will develop the software for the processing system. To correctly generate the software, the SDK needs to be aware of the hardware configuration of the system. Finally, the iMPACT tool allows you to program the bit file into the system and generate the bitstream format.

While you can use these four tools in isolation to create an All Programmable SoC, rather helpfully Xilinx’s Plan¬Ahead tool is capable of integrating them all, delivering a much simpler development process. Therefore, let’s focus on this PlanAhead approach as we dig deeper into the Zynq flow.

Creating the hardware
The first step in the development process is to open PlanAhead and create a new RTL project. This is a fairly straightforward matter. Since you will have no existing RTL, IP or constraints initially, keep selecting “next option” until you reach the device selection tab. If you are using a development board, then select the board you intend to target. Otherwise, select the device you wish to target for your system.

Once you have created the project, you will see the default screen within PlanAhead. At this point you will need to add a source file to the design. You can do this by selecting “add sources” under project management options on the flow options tab, which should be on the left-hand side of the screen. Initially we are interested in getting the processing system side of the Zynq up and running; therefore, select the “add or create embedded sources” option. This will open yet another tab from which you can select the “create subdesign” button, and then enter the selected name for the processing system.

The tool will now take you through a number of stages to create a base system using what is called the Base System Builder (BSB) Wizard, as shown in Figure 1 (click here to see a larger, more detailed version of this image):


Figure 1. The Base System Builder for the AXI bus.


This step will open Xilinx Platform Studio, which will present you with a graphical representation of the processing system within the device as illustrated in Figure 2 (click here to see a larger, more detailed version of this image):


Figure 2. The XPS view of the processing system.


If you have targeted a development board, the tool will automatically configure the peripheral interfaces for your board. However, if you are targeting a single device you will need to implement your own peripherals within this system – for example, DDR timings and the MIO connections. Doing so is very straightforward, and you can make sure you have made no errors by running the design rule checker before you leave XPS and return to PlanAhead.

Once back in PlanAhead, you will need to generate an RTL netlist for the processing system in either VHDL or Verilog, picking your choice of language via the project settings. Generating this HDL file is as simple as right-clicking on the name of your processing system and selecting the “generate HDL” option.

You can then create RTL designs for the programmable logic side of the device within PlanAhead as well, using the “add sources” option. Once you have created the RTL you require, you will need to define the top-level module by right-clicking on it and selecting the “set top” option. If your design has both a processing system and a programmable logic system, you will need to create a top-level RTL file to connect them together as you desire.

The final remaining step before the SoC is complete and a bit file can be generated is to create a constraints file with pinout information for the PL side of the Zynq-7000 device. Do this within PlanAhead by right-clicking on the constraints option within the source window and selecting “add sources.” This action will allow you to create the file. Now it is time to implement the design using the “run implementation” button.

Creating the software
Having defined your system using PlanAhead and Xilinx Platform Studio, you now need to create the software that is to run on the processing system. For the majority of this development you will be using the Software Development Kit. However, there’s one more thing you need to do within PlanAhead—namely, export the hardware configuration to the SDK by means of the export options within PlanAhead.

Performing this export should result in the opening of the SDK and the importation of the hardware specification, as seen in Figure 3 (click here to see a larger, more detailed version of this image):


Figure 3. Importing the hardware to the SDK.


Once you have imported the hardware, you will need to create a board support package for your hardware, as shown in Figure 4 (click here to see a larger, more detailed version of this image):


Figure 4. Creating the board support package.


This BSP will be specific to your hardware implementation. It will contain drivers for peripherals along with 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. When creating the BSP, be sure to select your target processing system and CPU0. (We are examining a simple system and will leave multicore operations to another day.)

The next step is to create the actual software project itself. At this point, you will get to choose a language, either C or C++, and a number of templates ranging from a simple “hello world” to a first-stage boot loader. You can also choose whether to implement the project on a bare-metal system – that is, one with no operating system – or within the Linux OS. Once you have completed this step and created your project, you are free to begin writing code for your application.

If you are new to developing embedded software, the task may at first seem a little daunting. However, the SDK provides plenty of support and assistance to both first-time and experienced developers. Should you be unsure of the peripheral drivers within your system or how to drive them, the system.mss file under your BSP within the tool’s Project Explorer will show the memory map. This view also offers a list of helpful links to documentation and examples.

There are a large number of C header files for you to call into a project. However, certain commonly used files contain parameters and functions to drive peripherals.
  • Stdio.h defines the standard input and output. This file should be familiar to many people who have used C before.
  • Platform.h defines basic functions for the implementation and platform initialization, and for cleanup.
  • Xil_types.h defines a number of types needed for the Xilinx IP.
  • Xgpio.h defines the drivers for the AXI-connected general-purpose I/O module.
  • Xparameters.h defines the hardware architecture and configuration for this implementation.

Having written your code and successfully compiled it, you will then of course wish to download the application to your board. To do this, you first need to create a linker file script that will determine where the executable is placed within the system memory. While your first program may be small and would fit within the on-chip memory, it is often best to place it within the DDR memory (if used) to demonstrate that this interface was also correctly configured. You can create the linker script by right-clicking on your project and selecting “generate linker script.”

The final thing to do is to set up the run configurations (project explorer -> project -> run -> run, as within the right-click menu). Here you can define your STDIO connection – the serial port you are using for the STDIO (if any). Once you are happy, you can apply the configuration and then close it (do not click “run,” as we are not quite ready for that). The final stage is to attach the board to your PC, connecting the JTAG cable and all other cables you may need, including an RS232 serial cable, and programming the hardware via the Xilinx tools (use the “program FPGA” option). Check that the bit file is the correct one and then program the device.

Having completed the configuration, you can now download the ELF file and try out your program. This is as simple as selecting your project within PlanAhead’s Project Explorer, right-clicking “run as” and then “launch on hardware.” If you have not previously built or compiled your code, running this command will automatically build your design, provided it is error-free.

The Zynq-7000 device introduces a new type of all programmable system-on-chip development flow that may seem complicated to the new user. However, the tool chain is integrated within, and accessible from, Xilinx’s PlanAhead tool, creating a seamless, stage-by-stage development process that ensures you will be able to create a Zynq system with relative ease.

About the author

Adam Taylor is a Principal Hardware Engineer at Europe's leading space company, Astrium, where he has a dual role as leader of the electronic design group and a responsible engineer leading product development. He has spent the last 12 years developing both hardware and FPGA solutions for radar, safety critical systems, and thermal imaging, among others.

Adam now focuses on space-based telecommunications and cryptographic processors, and he is interested in reliable design methods upon which he intends to write a book (if he ever gets around to it). He is a Chartered Engineer and a Fellow of the Institute of Engineering and Technology, and he holds a First Class Bachelor of Engineering Degree from Sheffield Hallam University. Adam can be contacted at aptaylor@theiet.org


If you found this article to be of interest, visit Programmable Logic Designline where – in addition to my Max's Cool Beans blogs – you will find the latest and greatest design, technology, product, and news articles with regard to programmable logic devices of every flavor and size (FPGAs, CPLDs, CSSPs, PSoCs...).

Also, you can obtain a highlights update delivered directly to your inbox by signing up for my weekly newsletter – just Click Here to request this newsletter using the Manage Newsletters tab (if you aren't already a member you'll be asked to register, but it's free and painless so don't let that stop you [grin]).




Please sign in to post comment

Navigate to related information

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)