Chapter 3

 To start designing for Zynq, you will need to obtain the appropriate design tools from
Xilinx.
 There are a number of design tools available:
 Vivado Design Suite: - Vivado can be downloaded as a full version, or with customs
selections of tools and target boards, based on user preferences.
 The Documentation Navigator utility, which provides an easy way to access all of the
relevant user guides and other support documents
 If used in a network license configuration, then the following separate download will
be required for installation on the license server machine: License Management Tools.
 The Vivado design tools are available in different editions, all of which may be
installed from the same set of downloaded files, but which are differentiated by license
type. Licensing is administered online via a Xilinx user account
 There are three licence options for Vivado: - WebPACK, Design Edition, and System
Edition
 The WebPACK edition is a free version, including all of the core software for
creating first designs with Zynq: Vivado Integrated Development Environment
(IDE) for hardware design, SDK and GNU Compiler Connection (GCC) compiler
for software development, and Vivado Simulator for verification.
 Licenses can be configured either as server / floating licenses (i.e. a bank of licenses
hosted on a network license server), or as individual licenses fixed to specific
computers (‘node-locked’). The WebPACK edition is free to obtain, and available as a
node-locked license only
 Vivado IDE is an integrated development environment for creating the hardware
system part of the SoC design, i.e. the processor, memories, peripherals, external
interfaces and bus connections.
 Vivado IDE interacts with other tools in the Vivado Design Suite, and also includes
facilities for integrating and packaging IP, which enhances possibilities for design
reuse
 SDK is a software design suite based on the popular Eclipse platform, which includes
driver support for all Xilinx IPs, GCC library support for ARM and NEON
extensions using the C and C++ languages, and tools for debugging and profiling
 Of the verification and debugging tools, Vivado Simulator represents a Hardware
Description Language (HDL) simulator environment for testing the hardware
components within the system.
 The Vivado Logic Analyser provides facilities for ‘in-system’ verification of the
design: specific additional cores are included in the hardware design and implemented
on the Zynq device to enable probing of on-chip behavior during run-time; the
captured data is then transmitted back to the host PC where it may be viewed in a logic
analyser.
 Vivado Serial I/O Analyser is, as its name suggests, a similar tool catering specifically
for the high speed communications interfaces.
 The Vivado High-Level Synthesis (Vivado HLS) and System Generator for DSP
tools are specifically used for creating, testing and managing IP for inclusion in the
hardware system.
 System Generator is a block-based tool which is used for creating and simulating
DSP designs.
 Vivado HLS is a design tool for hardware synthesis from C-level descriptions. This
method of design creation is potentially a rapid one, allowing subsystems to be described
at a high level of abstraction, and it is particularly relevant in today’s electronics
industry where time-to market is an increasingly important factor.
 The Vivado design suite supports certain third party tools.
 The majority are swappable replacements for certain tools within the Vivado design
suite; for example, a particular HDL simulator (such as Aldec® Active HDL® or
Mentor Graphics® ModelSim® or Questa®) may be preferred in place of the Vivado
Simulator. Likewise there is potential to utilise a third party synthesis tool like
Synopsys® Synplify® or Synplify Pro®.
 A notable exception to the above relates to the System Generator tool. This is hosted in
the MathWorks® MATLAB® / Simulink® environment, and therefore relies on the
MATLAB and Simulink third party software products in order to function.
 Two associated MathWorks components, the Signal Processing Toolbox and DSP
System Toolbox, are additionally needed to support most DSP designs.
 One of the particular advantages of System Generator as a development environment is
that the developer can exploit all of the capabilities of MATLAB and Simulink for
scripting, simulation, visualisation, and file I/O, together with the specific facilities of
any additional toolboxes that may be available (e.g. image processing,
communications, etc.).
 At least 4GB of RAM is recommended for the three smaller devices, while the largest
may require up to 12GB of RAM. Generally speaking, at least a dual-core processor is
recommended, and some of the design tools have multi-core processing support, i.e. they
can exploit processors with multiple cores.
 The computer hardware configuration also requires a USB port for programming the
Zynq over JTAG, and ideally another for PC-Zynq communication via the UART and
Terminal application
 A development board hosts a Zynq device, together with various other resources such
as power circuitry, external memory, interfaces for programming and
communication, simple user I/O such as buttons, LEDs, switches, and usually a
number of other peripheral interfaces and connectors.
 During the debugging stage, designs developed on the computer using the Vivado
design suite can be downloaded onto the development board using a Joint Test
Action Group (JTAG) or ethernet connection, then tested in hardware, using
peripherals and external interfaces if required.
 As in any project, the starting point will be a specification of the system to be
designed, based on an assessment of project requirements.
 Design of the system architecture is usually approached from a top-down perspective.
This means defining the top-level system interface and parameters first, before
identifying the individual subsystems or functional tasks. Subsystem functionality
and required performances, as well the various interactions between them, would then
be defined.
 Then, having defined the functional units, the design must be appropriately
partitioned into hardware and software, and the necessary communications between
different parts of the system defined.
 Generally speaking, software (on the PS) will be used to implement general purpose
sequential processing tasks, an operating system, user applications and GUIs, while
computationally intensive data flow parts of the design are more suitably realised in
the PL.
 One of Zynq’s particular advantages is the close coupling between the processor and
programmable logic, which reside on the same physical device. The low latency, high
 performance AXI links between the PS and PL allow the differing properties of these
two resources to be maximally exploited when partitioning the system into software and
hardware elements.
 The original source of IP blocks implemented in the PL may be:
• The Xilinx library
• Third party sources
• Designed by the User, or by colleagues within the same organization (‘in-house’)
 IP from the Xilinx library is provided on a pre-verified basis, but blocks from third
parties may not be. Any IP you design in-house, together with third party blocks not
already verified, should be validated as standalone blocks before integration into an
embedded system.
 Depending on the design method, this may take place using HDL simulation, or
simulation in MATLAB / Simulink
 The hardware system is usually tested in conjunction with the software that is
deployed upon it, i.e. while the hardware is operational in the context of the integrated
system.
 Another powerful method of testing is Hardware In the Loop (HIL). Using this
method, part of the design runs on a development board and signals are returned to the
simulation environment for inspection.
 Once an iteration of the hardware system has been completed, the project is exported
to SDK for work on the software portion of the design. Further design iterations
may follow, involving a return to Vivado and changes to the IP Integrator design or
further partitioning of software to hardware.
 The project exported from Vivado into SDK represents the customized hardware
upon which the software is based; usually this is referred to as the ‘hardware base
system’ or ‘hardware platform’
 The layer directly above the Hardware Base System is the Board Support Package
(BSP), the set of low-level drivers and functions that are used by the next layer up (the
Operating System) to communicate with the hardware.
 Software Applications run on top of the Operating System — these collectively
represent the uppermost layer in the software stack, and the highest level of abstraction
from hardware.
 The software system can be thought of as a stack, or set of layers, which is built upon
the Hardware Base System.
 When creating the software stack, the first design choice is usually to decide on the
OS to deploy: this can be a fully-fledged OS such as Linux or Android; an embedded
OS; a Real-Time Operating System (RTOS) for deterministic, time-critical
applications; or Standalone, a ‘light’ OS including only the most basic functions.
 It is also possible for applications to communicate directly with hardware, and this is
often referred to as a ‘baremetal’ application.
 The BSP is tuned to the hardware base system, allowing an OS to operate efficiently
on the given hardware.
 The BSP is customized to the combination of base system and operating system, and
includes hardware parameters, device drivers, and low-level OS functions.
 SDK provides the environment for creating BSPs, and developing and testing software
for deployment in the upper layers. It also supports the creation of BSPs for use in
third party development tools such as ARM Development Studio 5 (DS-5), which
may be used in place of Xilinx SDK if desired.
 In terms of testing, SDK contains the Xilinx Microprocessor Debugger (XMD) and
System Debugger (TCF) utilities, which are features for testing software while it is
running on the target hardware platform, i.e. a form of HIL.
 This process can be undertaken by programming the PL part of the Zynq with a
bitstream (*.bit file), and running the software (*.elf file) on the PS.
 Programming is usually accomplished by downloading the files from the host PC
over a JTAG connection, or via Ethernet. In this way, both the PS- and PL based
components of the system are implemented and form part of the test.
 The GDB debugger is a further alternative (built upon XMD) that facilitates remote
debugging. Another alternative is to utilize the in-built Vivado Simulator to recreate
the operations of the PL on the host PC.
 It is important to note that not all designs require both an Executable Linkable
Format (ELF, *.elf) file and a BIT (*.bit) file to configure the device.
 The purpose of ELF files is to program the PS, while BIT files are used to program
the PL. Therefore, if only one part of the Zynq device is used (PS or PL), then only the
corresponding file type is needed.
 System integration is partly accomplished through the development and combined
testing of the software and hardware elements of the design. However, there are other
factors which need to be taken into consideration too.
 System-level debug occurs after the software and hardware components have been
individually tested and verified during their separate development and testing stages.
 During development and debugging, the Zynq is typically configured by downloading
files from the host PC over a JTAG or Ethernet connection. However, this is generally
unsuitable for operation in the field, and it is more usual to boot and configure the
Zynq from flash memory
 A hardware design team responsible for architecting and implementing the
hardware system, including the design, reuse and integration of IP blocks
 A firmware design team responsible for designing the boot loader and implementing
the drivers necessary to interface software and hardware.
 A software design team focusing on designing and coding the software elements of
the system, and integration with other incorporated elements such as standard
operating systems.
 Vivado and IP Integrator provide a framework to make IP integration faster, easier
and less error prone, through support for the industry standard AXI bus interface.
This also makes it easier to share and reuse IP blocks between projects, and to
acquire new IP from third parties.
 Vivado features an extensive library of pre-verified IP blocks than can be used in this
way, and there is also a wide range of third party IP available.
 One of the benefits of the Vivado Design Suite is that its Vivado HLS tool can
synthesise high-level C code to hardware, meaning that conversion of a software
routine to hardware can potentially be undertaken very rapidly based on the existing
C code, without the requirement to develop a hardware coprocessor from scratch.
 IP Integrator is the primary embodiment of this IP-focused design method. IP
Integrator is a feature of the Vivado Design Suite, with which the designer is able to
adopt the same ‘top-down’ approach they would naturally take in conceiving the
system hierarchy.
 The success of the IP integration stage relies on consistent behavior and interfacing
of IPs. To support this, the Vivado Design Suite includes a related feature, IP Packager,
 that enables IP to be consolidated into standard packages (based on the IP-XACT
standard) with the aim of facilitating future design reuse.
 There are several tools and design creation techniques that can be used to generate
IPs. For example, they may be coded from a HDL such as VHDL or Verilog;
generated from a high-level C description by the Vivado HLS tool; or from a System
Generator block diagram.
 On Vivado, its feature the GUI aspect of the tools, all of the design tasks may also be
undertaken using the industry standard Tool Command Language (TCL) scripting
language. This represents a very powerful, repeatable and parameterisable method of
driving the design tools.
 Vivado Synthesis is an enhanced synthesis tool for 7 series and subsequent devices.
 Vivado Power Analyzer is used for evaluating the power consumption of designs
operating on a target device.
 Vivado HLS is tools for developing IP from high-level C, C++ or System-C
descriptions.
 IP Integrator provides an enhanced graphical environment for used to architect
embedded hardware systems using lists, options etc.
 Vivado Logic Analyzer is used for probing and inspection of real-time signal
behaviour on physical devices. The Vivado Logic Analyzer is underpinned by updated
hardware cores.
 Vivado Device Programmer is a tools for scanning the hardware chain and
configuring the identified devices by downloading programming files.
 The constraints file type of Vivado flow is the XDC (*.xdc) file type is adopted (Xilinx
Design Constraints).The new file type brings compatibility with the industry standard
Synopsys Design Constraints, augmented with some specific Xilinx constraint types.
 Evaluation boards play an important role in the development process, and may be used
extensively for incremental testing as the design progresses. They usually have a variety
of peripheral interfaces to facilitate prototyping for communications, DSP, video
processing, and many other applications, and come supplied with reference designs to
demonstrate the use of these facilities.
 The ZYBO (diminutive of Zynq Board) is an ultra-low cost alternative to the
ZedBoard featuring the smallest Zynq device, the Z-7010, which is based on the Artix-
7 PL fabric.
 The MicroZed is a low-cost development board from Avnet which features the
smallest member of the Zynq-7000 series — the Z-7010. It is Third Party Boards
 There are some standard connector types that can be used to extend the capabilities of
your development board by attaching external modules. In this way, additional
functionality can be added — anything from simple input/output devices such as
buttons and LEDs, to fully functioned Software Defined Radio (SDR) modules.
 FPGA Mezzanine Connectors (FMCs): - A standardized FPGA interface for
supporting FMC cards. High data throughput is available, and this type of card is
suitable and widely used for data conversion (DAC and ADC), serial connectivity,
SDR, and video processing.
 Pmods: - This is a simple interface type for adding small peripheral modules (hence
the name Pmod = Peripheral module), using either 6-pin or 12-pin interfaces.
 Typical Pmods are sensors, actuators, data converters, and user I/O devices. There
are also some communications transceivers available. Pmods can also facilitate direct
wire connections.
 XADC Header: - For connecting a board to interface with the on-chip XADC
component for ADC functionality. An example of this type of expansion module is the
AMS101 included within the ZC702 Evaluation Kit.
