Application Note: Zynq-7000 AP SoC

XAPP1309 (v1.0) March 7, 2017

Measured Boot of Zynq-7000 All
Programmable SoCs
Author: Lester Sanders

Summary
The secure boot functionality for the Zynq®-7000 All Programmable (AP) SoC provides thecapability to authenticate all partitions loaded at boot using RSA-2048 authentication. It also
supports advanced encryption standard (AES) encryption of partitions that need confidentiality.
The Zynq-7000 AP SoC immutable BootROM includes security functions to provide a hardware
root of trust (HROT) to protect against early load attacks.
This application note discusses a method to add measured boot capability to Zynq-7000 AP
SoCs used in a connected environment. A server provides remote attestation that theembedded systems boot with trusted software over a secure network. The method uses atrusted platform module (TPM) to enhance the HROT functionality. The TPM provides
cryptographic functions in a cost-effective, tamper-resistant device which are an effective
complement to Zynq-7000 SoC security functions.
Download the reference design files for this application note from the Xilinx website.

Introduction
In most current applications, Xilinx FPGAs and SoCs are programmed once at the factory andoften not reconfigured for the life cycle of the device. A method to add functionality and/or
reduce the total cost of ownership (TCO) of an embedded system is to support field updates. In
Zynq-7000 AP SoCs, the SoC and programmable logic can be updated, so field updates can bevery effective. Field updates are typically done over the Internet, which opens up attacks on anembedded system to anyone with network access. Measured boot and network security are
critical in firmware updates.
Figure 1 shows an example system environment that uses measured boot. A server manages
the software load, update, and validation of fielded, embedded systems based on the
Zynq-7000 AP SoC. The embedded systems connect to the server using Ethernet. In addition to
updating software on the embedded systems, the server verifies that the correct, trusted
software is loaded. This verification by the server, done at boot and run time, is remoteattestation.

XAPP1309 (v1.0) March 7, 20171www.xilinx.com

Introduction
X-Ref Target - Figure 1

Server Remote AttestationstrongSwan TNC, IMC/IMVWind River Pulsar Linux
Integrity Measurement Architecture

IPsec Network Security

Infineon 9670 TPM
Zynq-7000 AP SoC
Avnet IIOT Kit

Infineon 9670 TPM
Zynq-7000 AP SoC
Avnet IIOT Kit

Infineon 9670 TPM
Zynq-7000 AP SoC
Avnet IIOT Kit

Client 1

Client 2

Client N
X18727-021417

Figure 1:

Measured Boot of Zynq-7000 AP SoC Embedded Systems

Remote attestation capability has been in Linux starting with 2.6.3, and is generally known as
integrity measurement architecture (IMA). The Linux extended verification module (EVM) is
used in conjunction with IMA. The term measured boot is used because the client returns avalue, typically a secure hash algorithm-1 (SHA-1) digest, of each of the partitions loaded. In
remote attestation, the server compares the measured logs with known good measurements.
The attestation server knows the characteristics (measurements) of the partitions loaded on theembedded systems, including partition size and digests. At load, the embedded systems sendlog files to the server containing partition measurements. The server verifies the measurement,
and if a client loads software that is different than what is expected, the server executes a policy
set up by the server administrator. A policy is a set of actions taken by the server based on
measurement results. Policies in the reference design include Allowed, Quaranteed, Blocked, andIsolated.
An example of a policy is to keep the embedded system off the network, update the software,
re-run remote attestation, and allow the client to connect to the network if the software can betrusted. Isolating a corrupted embedded system from the network limits its ability to corrupt
other embedded systems. This is a typical policy of a server in remote attestation, not the only
policy, because the policy is generally defined by the application.
Measured boot is done in addition to, not in place of, secure boot. Measured boot does notprevent malicious software from being loaded. The TPM enhances the HROT and increases the
security of the software load/update process. The TPM is placed on the same board as theZynq-7000 AP SoC. A device ID is associated with the Zynq-7000 SoC-TPM platform. The TPM
provides cryptographic functions used in measure boot. The HROT is enhanced with the TPM
because an adversary has to defeat both the Zynq-7000 AP SoC and the tamper-resistant TPM
for a successful attack.

XAPP1309 (v1.0) March 7, 20172www.xilinx.com

Introduction
Figure 2 shows functional components of the Zynq-7000 AP SoC and the Infineon OPTIGA SLB
9670 TPM on the client platform.
X-Ref Target - Figure 2

Zynq-7010 AP SoC

Infineon SLB9670 OPTIGA TPM

strongSWAN Client

Platform Configuration
Registers

TrouSerSWind River Pulsar Linuxwith TPM Driver

CPU
SPI

Crypto Engine
Non-Volatile Memory

U-BootTamper Detection Circuitry
FSBL – TPM SPI, TPM
Tools

Random Number Generator

X18730-020317

Figure 2:

Functional Diagram of Client Platform Based on Zynq-7000 AP SoC

At power-up, the Zynq-7000 AP SoC on-chip BootROM code loads the first stage boot loader(FSBL). The FSBL loads U-boot, and U-Boot loads the Linux kernel, root file system, device tree,
and Linux application software. In one approach to booting with a chain of trust, the BootROM
authenticates/measures the FSBL, the FSBL authenticates/measures U-Boot, and U-Bootauthenticates/measures the Linux partitions.
The SHA-1 measurement logs are stored in the TPM platform configuration registers (PCRs).
Measurements of the BootROM and the FSBL are done by the FSBL and placed in the PCRs using
a serial peripheral interface (SPI) connection. The measurements are transmitted to the server
for remote attestation. The TPM cryptographically signs the SHA-1 values in PCRs so thatpartition measurements are not transmitted from the embedded system in plain text.
For remote attestation of firmware updates, the network connection between the attestation
server and clients must be secure. IPsec functionality, including a privacy certificate authority(CA) that generates X.509 certificates, implements the transport layer security (TLS) handshake
between the server and client(s). The network security used in the measured boot reference
design is discussed in Network Security in Measured Boot, page 12.

XAPP1309 (v1.0) March 7, 20173www.xilinx.com

Hardware and Software Requirements

Hardware and Software Requirements
The hardware and software requirements for the reference system include the following:•

Avnet Industrial Internet of Things (IIoT) starter kit with MicroZed board•

Infineon OPTIGA TPM 1.2 SLB 9670 peripheral module (Pmod) compatible board•

Two USB type-A to USB mini-B cables (for UART and JTAG communication)•

Micro Secure Digital (microSD) memory card (16 GB)•

Ethernet cable•

Xilinx Software Development Kit 2017.1•

Xilinx Vivado® Design Suite 2017.1 (optional)•

Wind River Pulsar Linux 8.0•

VirtualBox 5.0.26 or higher (or VMware equivalent)•

Ubuntu or Ubuntu command line virtual machine image in Open Virtual Appliance format•

strongSwan TNC software•

Tera Term or equivalent communication terminal software

Depending on the system setup, all of the software listed above might not be necessary.

XAPP1309 (v1.0) March 7, 20174www.xilinx.com

Reference System Description

Reference System Description
Figure 3 shows a desktop setup for the single client system used in the reference design.The
client in the Avnet IIoT drives a communication terminal. The strongSwan attestation server
runs from VirtualBox. A browser is used to view the measurements and the implementation of
the policy.
X-Ref Target - Figure 3

X18725-020317

Figure 3:

Measured Boot Reference Design

XAPP1309 (v1.0) March 7, 20175www.xilinx.com

Reference System Description
Figure 4 shows the Avnet IIoT starter kit with the MicroZed board mounted on the Avnet
Arduino carrier card. It also shows the Infineon OPTIGA TPM 1.2 SLB 9670 Pmod plugged into
the J2 PS PMOD connector.
X-Ref Target - Figure 4

X18724-020317

Figure 4:

Avnet IIOT Starter Board with Infineon OPTIGA SLB 9670 TPM Connection

The Infineon OPTIGA SLB 9760 attached to PMOD connector J2 communicates to theZynq-7000 AP SoC using the processing system (PS) serial peripheral interface (SPI) driver.
Wind River Pulsar Linux (WRPL) 8.0 runs on MicroZed and includes the strongSwan client
software. Prior to booting WRPL, the Zynq-7000 AP SoC runs the FSBL. The FSBL runs pre-bootauthentication on the BootROM and FSBL.
The FSBL then executes PCR extend commands to log BootROM and FSBL SHA-1 digests into
the PCR[0] and PCR[4]. The PCR extend command is similar to a write command. It differs fromthe write value in that the value loaded into the PCR is an SHA of all cumulative SHA values
loaded into the PCR. Because a PCR extend rather than a write is done, an adversary is unable
to read PCRs and get “expected” values.

XAPP1309 (v1.0) March 7, 20176www.xilinx.com

Hardware Root of Trust
Figure 5 shows three possible system setups. The strongSwan software running on an Ubuntu
server does both the remote attestation and the network security. The Ethernet connection canbe either direct from the PC to the Avnet board or dynamic host configuration protocol (DHCP)
using Ethernet wall sockets. In (a), the server is run on an Ubuntu installation on either
VirtualBox or VMware on the PC. In (b), an Ubuntu-based PC runs the strongSwan server. In (c),the server runs on an Amazon web server (AWS). Xilinx does not provide the AWS account.
X-Ref Target - Figure 5

ClientServerLaptopVirtual Box
UbuntuIIoTStarter Kit

strongSwan

MicroZed(a)

LaptopUbuntustrongSwan

730

IIoT Starter Kit
MicroZed730(b)

Laptop
IIoTStarter Kit

AWSstrongSwan

MicroZed(c)730
X18732-030617

Figure 5:

Reference System Hardware Setup Options

The reference system provides methods for a measured boot of a single client, providing
remote attestation of early load software (BootROM, FSBL) which is new functionality forembedded systems. An actual connected system has multiple embedded devices, and thestrongSwan server measures all Linux partitions loaded, not just the early load software.

Hardware Root of Trust
In Zynq-7000 AP SoCs, the HROT is based on the first code executed by the ARM® CPU0 at
power-on. The code is stored in on-chip, metal-masked ROM, and is referred to as BootROM
code. BootROM code is immutable, and its principle function is to perform device initializationand load the FSBL into read/writable on-chip memory (OCM). Neither the BootROM nor the
OCM are accessible at device pins. The BootROM Configuration Flowchart figure in Zynq-7000
All Programmable SoC Technical Reference Manual (UG585) [Ref 1] provides the flow of the
BootROM code functionality. If secure boot is specified, the BootROM authenticates the FSBL
using the RSA-2048 standard prior to execution of the FSBL. The Zynq-7000 AP SoC HROT isenhanced by adding a TPM to the embedded platform. The TPM provides partition
measurements, cryptographic functions, and secure key storage for keys used by the Zynq-7000
AP SoC.

XAPP1309 (v1.0) March 7, 20177www.xilinx.com

Measured BootIn Zynq-7000 AP SoCs, the term secure boot is used to define the secure loading of thebitstream and software at power-on. The bitstream is loaded into on-chip configuration
memory. Software partitions encrypted in non-volatile memory (NVM) are generally
authenticated, decrypted, and copied to DDR memory. As shown in Figure 6, the RSA-2048
authentication uses a chain of trust sequentially on each partition loaded. Each partition canuse its own private/public key pair. Partitions can optionally be authenticated using keyed-hashmessage authentication code (HMAC). In its simplest form, all partitions loaded by the FSBL areauthenticated using RSA-2048 from the XILRSA library. In an alternative boot flow, U-Boot hasaccess to the XILRSA library. In secure boot, if either RSA or HMAC authentication fails, theZynq-7000 AP SoC transitions to a lockdown state.
A malicious actor needs to steal the RSA private key, which is not stored in the device, and the
HMAC key. To protect against an insider attack, the SDK Bootgen key management can be split
so that independent parties handle RSA, AES, and HMAC keys.
X-Ref Target - Figure 6

BootROM

FSBL

U-BootLinux
KernelRoot
File
SystemLinux
App(s)

X18731-020317

Figure 6:

Zynq-7000 AP SoC Chain of Trust Boot

Measured Boot
Measured boot is recommended when embedded systems are connected to a network. Secureboot should still be used in systems which use measured boot. Secure boot and measured bootfunctionality are complementary. Connecting embedded systems to a network provides amethod for firmware updates. Embedded systems connected to a network have a wider attack
surface than closed systems. Hackers with network access are a common security threat.
Remote attestation addresses this vulnerability during boot and run time. In secure andmeasured boot, all files/partitions are authenticated and measured.
The basics of measured boot are discussed in Integrity Measurement Architecture. The
measured boot in the reference design uses a TPM for added security. Trusted Platform Module,
Zynq 7000 SoC-TPM Interface, and Network Security in Measured Boot discuss measured bootusing a TPM. Secure boot and measured boot do not use programmable logic resources, so theZynq-7000 AP SoC unit cost is not affected when measured boot is used.
Using measurements, an attestation server can periodically execute run-time integrity checks
on clients, and execute a policy based on the results. This is important in connected systems
because the probability of an attack during run time is high. The ability to implement a policy
is an improvement over the runtime integrity checker (RTIC) described in Run Time Integrity andAuthentication Check of Zynq-7000 AP SoC System Memory (XAPP1225) [Ref 2].

XAPP1309 (v1.0) March 7, 20178www.xilinx.com

Integrity Measurement Architecture

Integrity Measurement Architecture
IMA provides the basis for measured boot. An overview of IMA is provided in strongSwan
documentation [Ref 3].
In remote attestation with IMA, the server compares measurements received from clients withreference integrity measurements (RIMs) and acts according to a predefined policy. In thereference design, this is referred to as the policy decision point (PDP). After running measuredboot, a server website provides a summary of measurements and policy for the reference
design.
In an IMA implementation, the client runs integrity measurement collection (IMC). The server
runs integrity measurement verification (IMV). Figure 7 shows an example log when all Linuxpartitions are measured.
X-Ref Target - Figure 7

X18726-020317

Figure 7:

Integrity Measurement Architecture Evidence Log

XAPP1309 (v1.0) March 7, 20179www.xilinx.com

Trusted Platform Module

Trusted Platform Module
Documentation on TPM functionality is provided by the Trusted Computing Group (TCG),
beginning with the TPM Main Specification [Ref 4]. TPM 1.2 was the most commonly used TPM
in 2016. The Infineon OPTIGA SLB9670 TPM supports TPM 1.2 and 2.0. TPMs are very small,cost-efficient devices that provide root of trust for reporting (RTR) and root of trust for storage(RTS) security. This application note focuses on the RTR in which the measurement log file heldin the TPM’s PCRs is reported to the server.
In addition to support for RTR, TPMs provide capability that might be useful in Zynq-7000 SoC
applications. TPMs provide re-programmable non-volatile memory. The TPM hardened
cryptographic functions allow a key to be securely transmitted to the Zynq-7000 device on
demand. TPMs provide a random number generator (RNG). RNGs can be used to generate keys.
The TPM RTR support operates within the IMA framework, providing significant security
enhancements. When a TPM is added, the server’s remote attestation of a client is based on aquote. A quote is measurement or evidence on the partitions booted. In TPM 1.2, an SHA-1
digest is used as the measurement for partitions loaded. In TPM 2.0, an SHA-2 digest is used as
the measurement log for partitions loaded. The SHA digests are stored in the PCRs. Figure 8
shows the server-client communication for remote attestation.
X-Ref Target - Figure 8

ClientServerQuote Request, Including Nonce

Zynq-7000 AP
SoC

Quote – Signed Evidence, with Nonce

TPM

Attestation

X18729-020317

Figure 8:

Remote Attestation Using a TPM

The flow in Figure 8 is outlined below.
1. The strongSwan attestation server requests a quote from the client. When requesting thequote, the server sends a nonce, which is a random number used to protect against
playback attacks.
2. The client or Zynq-7000 SoC/TPM generates the evidence for the partitions loaded. The
SHA-1 hashes are stored in the TPM PCRs. The SHA-1 of the BootROM code is stored in
PCR[0], and the SHA-1 digest of the FSBL is stored in PCR[4].
3. The Zynq-7000 SoC/TPM client sends the quote to the server. This includes signed evidence
and includes the original nonce.
4. The strongSwan server appraises the quote and, based on the results, follows a policy setup
by the system administrator.

XAPP1309 (v1.0) March 7, 201710www.xilinx.com

Zynq 7000 SoC-TPM Interface

Zynq 7000 SoC-TPM Interface
The Zynq-7000 SoC-TPM interface provides the communication between the Zynq-7000 device
and the Infineon OPTIGA SLB9670 TPM. The interface uses commands from a tpm_toolbox. The
tpm_toolbox supports the following categories of commands:•

PCR reset•

Physical presence•

Get capability•

TPM startup/activate/physical enable•

PCR read/PCR extend

There are multiple commands in each category. A subset of the commands is used in thereference design. The Zynq-7000 AP SoC connects to the SLB9670 TPM using the SPI bus. The
Zynq-7000 AP SoC contains a hardened SPI IP in the PS and a soft AXI SPI IP in the
programmable logic (PL). The PS SPI is used in the reference design because it saves PL
resources.
Figure 9 shows SPI-TPM functions implemented in the FSBL for the reference design.
X-Ref Target - Figure 9

Calculate
SHA-1
BootROM
CRC

Calculate
SHA-1
FSBL

TPM
Take
Ownership

TPM
Activate

TPM
Startup

Extend PCR0
SHA-1
BootROM
CRC

Extend
PCR4
SHA-1
FSBL

X18733-020317

Figure 9:

FSBL TPM SPI Driver Functional Diagram

In the measured boot reference design, the FSBL is modified to calculate the SHA-1 of the
BootROM and the FSBL, and then extend the SHA-1 digests into the TPM’s PCRs. The SHA-1
values are calculated in sha1.c. Code to take ownership and activate the TPM is inslb9670_tpm_spi.c. The PCRs are extended in slb9670_spi_tpm.c. Other files added to
fsbl/src include tpm_tools.h, tpm_tools.c, tpm_spi.c, tpm_spi_tis.c, and tpm.h.
Because BootROM code is not accessible by the FSBL, the SHA-1 calculated for the BootROM iscalculated on the cyclic redundancy check (CRC) written by the BootROM code.
The FSBL TPM driver can be encrypted when stored in NVM and then decrypted and run from
OCM. The reason for the FSBL extending the TPM PCRs with early load measurements is to limit
the malicious attacker’s time to change the code.
In the Avnet Starter IIoT board, the PS SPI interfaces to the SLB9670 Pmod using an MIO
connection. To drive the pin reset of the TPM, the Zynq-7000 AP SoC hardware design includes
a PS GPIO which is used to drive the TPM reset pin. The ResetTPM function is in main.c.

XAPP1309 (v1.0) March 7, 201711www.xilinx.com

Network Security in Measured Boot

Network Security in Measured Boot
Software updates and remote attestation require a secure connection between a server and theembedded system clients. The network has a large attack surface because it can be attacked byany adversary with access to the Internet. For firmware updates, a server to client(s) connection
is used. In some factory automation environments, client-to-client communication is alsoneeded to coordinate operational procedures.
Figure 10 shows a high-level view of strongSwan’s implementation of TCG’s trusted network
connect (TNC). In the TNC architecture, the server connects to clients in the integrity evaluation
layer. The client does integrity measurement collection (IMC), and the server does integrity
measurement verification (IMV). The software on the client is the platform trusted service (PTS),
trust software stack (Trousers), and the TPM tools.
PTS uses the Trousers library to access the TPM and IMA measurements. The reports use
standard PTS formats for interoperability between applications and vendors.
X-Ref Target - Figure 10

ServerClientPlatform Trust
Service

Policy Decision/
Enforcer

Trousers
TPM Tools

Integrity
Measurement
Verifier

Integrity
Measurement
Collector

IPsec
TNC Server

TNC ClientX18728-020317

Figure 10:

Trusted Network Connect for Remote Attestation

The policy decision point (PDP) defines the action taken by the server after measurement
verification. A typical policy/action is to limit network access until remediation is done. A
different policy is used when availability is a critical driver, and some out-of-range measurement
verifications are not treated as critical. The TPM Main Specification [Ref 4] provides an overview
of the TNC architecture.
The underlying security for TNC in the reference design uses IPsec. This includes conventional
technology such as Internet key exchange (IKEv2), public key infrastructure (PKI), and thetransport layer security (TLS) handshake in which the encryption and authentication algorithms
are negotiated and pre-shared keys are exchanged. A virtual private network is set up in thestrongSwan architecture. A privacy CA generates the x509 certificates. The strongSwan
Readme.txt provides information on the IPsec flow.

XAPP1309 (v1.0) March 7, 201712www.xilinx.com

Reference Design Functional Overview

Reference Design Functional Overview
The following steps are done in the reference design to set up IMA, TPM, and network security.
•

Activate IMA in the Linux kernel•

Configure the IMA policy•

Activate the TPM•

Set up the privacy certificate authority (CA)•Set up the attestation client (Zynq-7000 AP SoC)•

Generate an attestation identity key (AIK)•

Configure the integrity measurement collectors•

Configure the TNC client•

Configure the VPN connection•

Set up/configure the attestation server (strongSwan VPN/TNC server)•

Collect measurement values•

Register the device with the policy manager

The process is defined on the strongSwan website.

Conclusion
Zynq-7000 AP SoCs provide significant advantages in their ability to program both hardware
and software on the same device. Cost-effective firmware updates are a key to increasing
embedded system capability and providing maintenance to reduce the TCO. Remote firmware
updates rely on using the Internet, opening the embedded system to cryptographic attacks.
This application provides mechanisms that provide proven-in-use security for connected
devices.

References
1. Zynq-7000 All Programmable SoC Technical Reference Manual (UG585)
2. Run Time Integrity and Authentication Check of Zynq-7000 AP SoC System Memory(XAPP1225)
3. Linux Integrity Measurement Architecturewiki.strongswan.org/projects/strongswan/wiki/IMA
4. TPM Main Specification www.trustedcomputinggroup.org/tpm-main-specification

XAPP1309 (v1.0) March 7, 201713www.xilinx.com

Revision History
5. Secure Boot of the Zynq-7000 All Programmable SoC (XAPP1175)

Revision History
The following table shows the revision history for this document.
Date

Version03/07/2017

1.0

Revision
Initial Xilinx release.

Please Read: Important Legal Notices
The information disclosed to you hereunder (the “Materials”) is provided solely for the selection and use of Xilinx products. To the
maximum extent permitted by applicable law: (1) Materials are made available “AS IS” and with all faults, Xilinx hereby DISCLAIMS ALL
WARRANTIES AND CONDITIONS, EXPRESS, IMPLIED, OR STATUTORY, INCLUDING BUT NOT LIMITED TO WARRANTIES OF
MERCHANTABILITY, NON-INFRINGEMENT, OR FITNESS FOR ANY PARTICULAR PURPOSE; and (2) Xilinx shall not be liable (whether incontract or tort, including negligence, or under any other theory of liability) for any loss or damage of any kind or nature related to,arising under, or in connection with, the Materials (including your use of the Materials), including for any direct, indirect, special,incidental, or consequential loss or damage (including loss of data, profits, goodwill, or any type of loss or damage suffered as a resultof any action brought by a third party) even if such damage or loss was reasonably foreseeable or Xilinx had been advised of thepossibility of the same. Xilinx assumes no obligation to correct any errors contained in the Materials or to notify you of updates to theMaterials or to product specifications. You may not reproduce, modify, distribute, or publicly display the Materials without prior writtenconsent. Certain products are subject to the terms and conditions of Xilinx’s limited warranty, please refer to Xilinx’s Terms of Sale which
can be viewed at http://www.xilinx.com/legal.htm#tos; IP cores may be subject to warranty and support terms contained in a license
issued to you by Xilinx. Xilinx products are not designed or intended to be fail-safe or for use in any application requiring fail-safe
performance; you assume sole risk and liability for use of Xilinx products in such critical applications, please refer to Xilinx’s Terms ofSale which can be viewed at http://www.xilinx.com/legal.htm#tos.
Automotive Applications Disclaimer
XILINX PRODUCTS ARE NOT DESIGNED OR INTENDED TO BE FAIL-SAFE, OR FOR USE IN ANY APPLICATION REQUIRING FAIL-SAFEPERFORMANCE, SUCH AS APPLICATIONS RELATED TO: (I) THE DEPLOYMENT OF AIRBAGS, (II) CONTROL OF A VEHICLE, UNLESS THERE
IS A FAIL-SAFE OR REDUNDANCY FEATURE (WHICH DOES NOT INCLUDE USE OF SOFTWARE IN THE XILINX DEVICE TO IMPLEMENT THE
REDUNDANCY) AND A WARNING SIGNAL UPON FAILURE TO THE OPERATOR, OR (III) USES THAT COULD LEAD TO DEATH ORPERSONAL INJURY. CUSTOMER ASSUMES THE SOLE RISK AND LIABILITY OF ANY USE OF XILINX PRODUCTS IN SUCH APPLICATIONS.
© Copyright 2017 Xilinx, Inc. Xilinx, the Xilinx logo, Artix, ISE, Kintex, Spartan, Virtex, Vivado, Zynq, and other designated brands
included herein are trademarks of Xilinx in the United States and other countries. All other trademarks are the property of theirrespective owners.

XAPP1309 (v1.0) March 7, 201714www.xilinx.com