User manual
Table Of Contents
- Zynq-7000 All Programmable SoC
- Table of Contents
- Ch. 1: Introduction
- Ch. 2: Signals, Interfaces, and Pins
- Ch. 3: Application Processing Unit
- Ch. 4: System Addresses
- Ch. 5: Interconnect
- Ch. 6: Boot and Configuration
- Ch. 7: Interrupts
- Ch. 8: Timers
- Ch. 9: DMA Controller
- Introduction
- Functional Description
- DMA Transfers on the AXI Interconnect
- AXI Transaction Considerations
- DMA Manager
- Multi-channel Data FIFO (MFIFO)
- Memory-to-Memory Transfers
- PL Peripheral AXI Transactions
- PL Peripheral Request Interface
- PL Peripheral - Length Managed by PL Peripheral
- PL Peripheral - Length Managed by DMAC
- Events and Interrupts
- Aborts
- Security
- IP Configuration Options
- Programming Guide for DMA Controller
- Programming Guide for DMA Engine
- Programming Restrictions
- System Functions
- I/O Interface
- Ch. 10: DDR Memory Controller
- Introduction
- AXI Memory Port Interface (DDRI)
- DDR Core and Transaction Scheduler (DDRC)
- DDRC Arbitration
- Controller PHY (DDRP)
- Initialization and Calibration
- DDR Clock Initialization
- DDR IOB Impedance Calibration
- DDR IOB Configuration
- DDR Controller Register Programming
- DRAM Reset and Initialization
- DRAM Input Impedance (ODT) Calibration
- DRAM Output Impedance (RON) Calibration
- DRAM Training
- Write Data Eye Adjustment
- Alternatives to Automatic DRAM Training
- DRAM Write Latency Restriction
- Register Overview
- Error Correction Code (ECC)
- Programming Model
- Ch. 11: Static Memory Controller
- Ch. 12: Quad-SPI Flash Controller
- Ch. 13: SD/SDIO Controller
- Ch. 14: General Purpose I/O (GPIO)
- Ch. 15: USB Host, Device, and OTG Controller
- Introduction
- Functional Description
- Programming Overview and Reference
- Device Mode Control
- Device Endpoint Data Structures
- Device Endpoint Packet Operational Model
- Device Endpoint Descriptor Reference
- Programming Guide for Device Controller
- Programming Guide for Device Endpoint Data Structures
- Host Mode Data Structures
- EHCI Implementation
- Host Data Structures Reference
- Programming Guide for Host Controller
- OTG Description and Reference
- System Functions
- I/O Interfaces
- Ch. 16: Gigabit Ethernet Controller
- Ch. 17: SPI Controller
- Ch. 18: CAN Controller
- Ch. 19: UART Controller
- Ch. 20: I2C Controller
- Ch. 21: Programmable Logic Description
- Ch. 22: Programmable Logic Design Guide
- Ch. 23: Programmable Logic Test and Debug
- Ch. 24: Power Management
- Ch. 25: Clocks
- Ch. 26: Reset System
- Ch. 27: JTAG and DAP Subsystem
- Ch. 28: System Test and Debug
- Ch. 29: On-Chip Memory (OCM)
- Ch. 30: XADC Interface
- Ch. 31: PCI Express
- Ch. 32: Device Secure Boot
- Appx. A: Additional Resources
- Appx. B: Register Details
- Overview
- Acronyms
- Module Summary
- AXI_HP Interface (AFI) (axi_hp)
- CAN Controller (can)
- DDR Memory Controller (ddrc)
- CoreSight Cross Trigger Interface (cti)
- Performance Monitor Unit (cortexa9_pmu)
- CoreSight Program Trace Macrocell (ptm)
- Debug Access Port (dap)
- CoreSight Embedded Trace Buffer (etb)
- PL Fabric Trace Monitor (ftm)
- CoreSight Trace Funnel (funnel)
- CoreSight Intstrumentation Trace Macrocell (itm)
- CoreSight Trace Packet Output (tpiu)
- Device Configuration Interface (devcfg)
- DMA Controller (dmac)
- Gigabit Ethernet Controller (GEM)
- General Purpose I/O (gpio)
- Interconnect QoS (qos301)
- NIC301 Address Region Control (nic301_addr_region_ctrl_registers)
- I2C Controller (IIC)
- L2 Cache (L2Cpl310)
- Application Processing Unit (mpcore)
- On-Chip Memory (ocm)
- Quad-SPI Flash Controller (qspi)
- SD Controller (sdio)
- System Level Control Registers (slcr)
- Static Memory Controller (pl353)
- SPI Controller (SPI)
- System Watchdog Timer (swdt)
- Triple Timer Counter (ttc)
- UART Controller (UART)
- USB Controller (usb)
Zynq-7000 AP SoC Technical Reference Manual www.xilinx.com 649
UG585 (v1.11) September 27, 2016
Chapter 22: Programmable Logic Design Guide
22.2.3 PL Acceleration Limits
The achievable speedup of an accelerator can be limited by I/O, resource, and latency requirements.
I/O Rate Limits
A key observation is that processing cannot proceed faster than the speed of the data transfers to
and from the functional unit. For functions with a high ratio of operations to I/O the data rates are
not a limiting factor, however for operations with a low ratio of operations to I/O, dataflow limits the
maximum performance attainable.
For example, assume 12 bytes of input data is being read from DDR and 4 bytes of results are written
back to DDR. DDR3 at 32-bits, 1,066 Mb/s and 75% utilization is limited to roughly 3,200 Mb/s. If 16
bytes are required per operation, the dataflow limits the performance to 3,200/16, or 200M
function/sec. Note that this is independent of the complexity of the function. Even a simple 3 input
adder is limited by the DDR bandwidth to 200M operations/sec and is not likely to be faster than an
ARM A9 CPU. If however, the function consists of several thousands of operations all of which can
proceed in parallel, or in a pipelined fashion, then the PL can often achieve speedups of a 10-100x.
Resource Limits
While potential speedup can be quite high, the amount of logic in the PL can limit the achievable
speedup. For instance, an application which requires 100 DSP slices to achieve a speedup of 24x
might be limited to a 12x speedup if only 50 DSP slices are available.
Latency Limits
The examples above assume that the PL can effectively proceed without intervention by the ARM
processor. This is the case in situations where the PL implements a predetermined algorithm and
dataflow using pre-allocated buffers and data is not resident in caches. In cases where the processor
is creating data for the PL accelerator, additional CPU tasks might be required before the PL can
begin working on the data. The CPU might need to allocate buffers and pass physical buffer
addresses to the PL, or data might be flushed from cache to DDR or OCM or signal the PL to start
processing. These additional steps add delays (called latency) to the total processing time. If these
delays are significant, the potential acceleration is reduced. Typically it takes 100-200 clocks for the
ARM processor to write a few words of data to a PL function. In general, CPU to PL calling latency is
not a significant impact for applications processing more than 4 KB of data.
22.2.4 Power Offload
The PL can be used to implement individual functions at lower energy cost than when executed on
the ARM A9 application processors. Less energy per operation is required because when a function
is implemented in the PL, data is transferred from operator to operator in a local assembly line
fashion using short, low capacitance local connections.
The same function implemented on a processor requires an instruction and data fetch from local
caches or external memory and a result to be written back to registers or the memory system over
longer, higher capacitance interfaces. When functions require data to be stored in memory, block