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 102
UG585 (v1.11) September 27, 2016
Chapter 3: Application Processing Unit
• Write to the interrupt clear register to clear any residual raw interrupts set.
• Write to the interrupt mask register if it is desired to enable interrupts.
• Write to control register 1 with the LSB set to 1 to enable the cache.
If a write is performed to the auxiliary, tag RAM latency, or data RAM latency control register with the
L2 cache enabled, a SLVERR (error) results. The L2 cache must be disabled by writing to the control
register before writing to these registers.
Cache Lockdown by Way Sequence
These are the steps to be followed for locking code by way:
1. Ensure the code to be locked is in a cacheable memory region. This can be done by programming
page table entry for the region with appropriate memory attributes. Refer to Memory Attributes.
2. Ensure the code to lockdown is in a non-cacheable memory region. For example, the region can
be marked as a strongly ordered region.
The following is the sequence that needs to be implemented in lockdown routine:
3. Disable the interrupts.
4. Clean and invalidate the entire L2 cache. This step is for ensuring that the code to be locked is
not loaded into L2 cache.
5. Find the number of ways required for loading code based on the code size.
6. Unlock the calculated ways and lock all the ways remaining. This is done by writing into data
lockdown registers. Refer to the PL310 L2 Cache Controller Document for information on these
registers.
7. Load the code into the L2 cache using PLD instruction. The PLD instruction always generates data
references; this is the reason for using data lockdown registers. For more information on PLD
instruction, refer to the ARMv7 TRM. This step loads the code into unlocked ways.
8. Lock the loaded ways and unlock the remaining ways by writing into data lockdown registers.
9. Enable Interrupts.
TIP: To check for whether the code is really locked into L2 cache, generate more references to the code
that has been locked. These references can be monitored by the L2 cache instruction hit event. For more
information on the available events of L2 cache and their initialization, refer to the PL310 L2 Cache
Controller document. This event initialization should be done prior to code locking. So more the
references to code, more the instruction hits. For example, the code that is locked can be called from a
timer interrupt handler which generates references as per the number of interrupts programmed.










