UltraScale Architecture

FPGAs Memory IP v1.0

LogiCORE IP Product Guide
Vivado Design Suite
PG150 September 30, 2015

Table of Contents
SECTION I: SUMMARY
IP Facts
SECTION II: DDR3/DDR4
Chapter 1: Overview
Feature Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Licensing and Ordering Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Chapter 2: Product Specification

Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Resource Utilization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Port Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

15
15
15
16

Chapter 3: Core Architecture

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Memory Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ECC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PHY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17
18
23
26

Chapter 4: Designing with the Core

Clocking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Resets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
PCB Guidelines for DDR3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
PCB Guidelines for DDR4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Pin and Bank Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Pin Mapping for x4 RDIMMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Protocol Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

DIMM Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

Chapter 5: Design Flow Steps

Customizing and Generating the Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I/O Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Constraining the Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Synthesis and Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

167
176
177
178
179

Chapter 6: Example Design

Simulating the Example Design (Designs with Standard User Interface). . . . . . . . . . . . . . . . . . . .
Project-Based Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simulation Speed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Synplify Pro Black Box Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CLOCK_DEDICATED_ROUTE Constraints and BUFG Instantiation . . . . . . . . . . . . . . . . . . . . . . . . .

182
183
191
192
193

Chapter 7: Test Bench

Stimulus Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bus Utilization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Example Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simulating the Performance Traffic Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

195
196
197
200

SECTION III: QDR II+ SRAM

Chapter 8: Overview
Feature Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Licensing and Ordering Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

Chapter 9: Product Specification

Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Resource Utilization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Port Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

206
206
206
207

Chapter 10: Core Architecture

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
PHY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209

Chapter 11: Designing with the Core

Clocking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

Resets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PCB Guidelines for QDR II+ SRAM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pin and Bank Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocol Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

219
219
219
224

Chapter 12: Design Flow Steps

Customizing and Generating the Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I/O Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Constraining the Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Synthesis and Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

229
234
234
236
236

Chapter 13: Example Design

Simulating the Example Design (Designs with Standard User Interface). . . . . . . . . . . . . . . . . . . .
Project-Based Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simulation Speed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Synplify Pro Black Box Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CLOCK_DEDICATED_ROUTE Constraints and BUFG Instantiation . . . . . . . . . . . . . . . . . . . . . . . . .

239
240
251
252
253

Chapter 14: Test Bench

SECTION IV: RLDRAM 3
Chapter 15: Overview
Feature Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Licensing and Ordering Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

Chapter 16: Product Specification

Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Resource Utilization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Port Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

259
259
259
260

Chapter 17: Core Architecture

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Memory Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
User Interface Allocation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PHY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

261
263
263
263

Chapter 18: Designing with the Core

Clocking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Resets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PCB Guidelines for RLDRAM 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pin and Bank Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protocol Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

267
272
272
272
276

Chapter 19: Design Flow Steps

Customizing and Generating the Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I/O Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Constraining the Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Synthesis and Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

285
290
290
292
292

Chapter 20: Example Design

Simulating the Example Design (Designs with Standard User Interface). . . . . . . . . . . . . . . . . . . .
Project-Based Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simulation Speed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CLOCK_DEDICATED_ROUTE Constraints and BUFG Instantiation . . . . . . . . . . . . . . . . . . . . . . . . .

295
296
304
305

Chapter 21: Test Bench

SECTION V: TRAFFIC GENERATOR
Chapter 22: Traffic Generator
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Simple Traffic Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Advanced Traffic Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309

SECTION VI: MULTIPLE IP CORES

Chapter 23: Multiple IP Cores
Creating a Design with Multiple IP Cores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sharing of a Bank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sharing of Input Clock Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
XSDB and dbg_clk Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MMCM Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

333
333
334
334
334

SECTION VII: DEBUGGING

Chapter 24: Debugging
Finding Help on Xilinx.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
Debug Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
Hardware Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343

SECTION VIII: APPENDICES

Appendix A: Migrating and Upgrading
Appendix B: Additional Resources and Legal Notices
Xilinx Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Please Read: Important Legal Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

516
516
517
528

SECTION I: SUMMARY
IP Facts

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

IP Facts

Introduction
The Xilinx UltraScale architecture FPGAs
Memory IP core is a combined pre-engineered
controller and physical layer (PHY) for
interfacing UltraScale architecture FPGA user
designs to DDR3 and DDR4 SDRAM, QDR II+
SRAM, and RLDRAM 3 devices.
This product guide provides information about
using, customizing, and simulating a
LogiCORE IP DDR3 or DDR4 SDRAM, QDR II+
SRAM, or a RLDRAM 3 interface core for
UltraScale architecture FPGAs. It also describes
the core architecture and provides details on
customizing and interfacing to the core.

Features
For feature information on the DDR3/DDR4
SDRAM, QDR II+ SRAM, and RLDRAM 3
interfaces, see the following sections:

Feature Summary in Chapter 1 for DDR3/

DDR4 SDRAM

Feature Summary in Chapter 8 for QDR II+

SRAM

Feature Summary in Chapter 15 for

RLDRAM 3

LogiCORE IP Facts Table

Core Specifics
Supported
Device Family (1)

Virtex and Kintex UltraScale Families

Supported User
Interfaces

User

Resources

See Table 2-1, Table 2-2, Table 9-1, and

Table 16-1.

Provided with Core

Design Files

RTL

Example Design

Verilog

Test Bench

Verilog

Constraints File

XDC

Simulation
Model

Not Provided

Supported
S/W Driver

N/A

Tested Design Flows(2)

Design Entry

Vivado Design Suite

Simulation(3)

For supported simulators, see the

Xilinx Design Tools: Release Notes Guide.

Synthesis

Vivado Synthesis

Support
Provided by Xilinx at the Xilinx Support web page.

Notes:
1. For a complete listing of supported devices, see the
Vivado IP catalog.
2. For the supported versions of the tools, see the
Xilinx Design Tools: Release Notes Guide .
3. Behavioral simulations are only supported and netlist
(post-synthesis and post-implementation) simulations are
not supported.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

8
Product Specification

Send Feedback

SECTION II: DDR3/DDR4

Overview
Product Specification
Core Architecture
Designing with the Core
Design Flow Steps
Example Design
Test Bench

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

Chapter 1

Overview
The Xilinx UltraScale architecture includes the DDR3/DDR4 SDRAM cores. These cores
provide solutions for interfacing with these SDRAM memory types. Both a complete
Memory Controller and a physical (PHY) layer only solution are supported. The UltraScale
architecture for the DDR3/DDR4 cores are organized in the following high-level blocks:

Controller The controller accepts burst transactions from the user interface and
generates transactions to and from the SDRAM. The controller takes care of the SDRAM
timing parameters and refresh. It coalesces write and read transactions to reduce the
number of dead cycles involved in turning the bus around. The controller also reorders
commands to improve the utilization of the data bus to the SDRAM.

Physical Layer The physical layer provides a high-speed interface to the SDRAM. This
layer includes the hard blocks inside the FPGA and the soft blocks calibration logic
necessary to ensure optimal timing of the hard blocks interfacing to the SDRAM.
The new hard blocks in the UltraScale architecture allow interface rates of up to
2,400 Mb/s to be achieved. The application logic is responsible for all SDRAM
transactions, timing, and refresh.

These hard blocks include:

-

Data serialization and transmission

Data capture and deserialization

High-speed clock generation and synchronization

Coarse and fine delay elements per pin with voltage and temperature tracking

The soft blocks include:

-

Memory Initialization The calibration modules provide a JEDEC -compliant

initialization routine for the particular memory type. The delays in the
initialization process can be bypassed to speed up simulation time, if desired.

Calibration The calibration modules provide a complete method to set all

delays in the hard blocks and soft IP to work with the memory interface. Each bit
is individually trained and then combined to ensure optimal interface
performance. Results of the calibration process are available through the Xilinx
debug tools. After completion of calibration, the PHY layer presents raw
interface to the SDRAM.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

10

Chapter 1: Overview

Application Interface The user interface layer provides a simple FIFO-like interface
to the application. Data is buffered and read data is presented in request order.
The above user interface is layered on top of the native interface to the controller. The
native interface is not accessible by the user application and has no buffering and
presents return data to the user interface as it is received from the SDRAM which is not
necessarily in the original request order. The user interface then buffers the read and
write data and reorders the data as needed.

X-Ref Target - Figure 1-1

8OWUD6FDOH$UFKLWHFWXUH)3*$V
8VHU,QWHUIDFH
UVW

3K\VLFDO,QWHUIDFH
8OWUD6FDOH$UFKLWHFWXUH)3*$V0HPRU\
,QWHUIDFH6ROXWLRQ

GGUBDGGU

FON

GGUBED

DSSBDGGU

GGUBFDVBQ

DSSBFPG

GGUBFN

DSSBHQ
DSSBDXWRSUHFKDUJH
DSSBZGIBGDWD

8VHU
,QWHUIDFH
%ORFN

0HPRU\
&RQWUROOHU

GGUBFNBQ

3K\VLFDO
/D\HU

GGUBFNH
GGUBFVBQ

DSSBZGIBHQG

GGUBGP

DSSBZGIBPDVN
8VHU
)3*$
/RJLF

GGUBRGW

DSSBZGIBZUHQ
DSSBUG\

1DWLYH,QWHUIDFH

0&3+<,QWHUIDFH

,2%

GGUBSDULW\

''5''5
6'5$0

GGUBUDVBQ

DSSBUGBGDWD

GGUBUHVHWBQ

DSSBUGBGDWDBHQG

GGUZHQ

DSSBUGBGDWDBYDOLG
DSSBZGIBUG\

GGUBGT

DSSBUHIBUHT

GGUBGTVBQ

DSSBUHIBDFN

GGUBGTV

DSSB]TBUHT
DSSB]TBDFN

Figure 1-1:

UltraScale Architecture FPGAs Memory Interface Solution

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

11

Chapter 1: Overview

Feature Summary
DDR3 SDRAM

Component support for interface width of 8 to 80 bits (RDIMM, UDIMM, and SODIMM
support)

Maximum component limit is 9 and this restriction is valid for components only and
not for DIMMs

DDR3 (1.5V) and DDR3L (1.35V)

Dual slot support for RDIMMs and UDIMMs

Quad rank RDIMM support

8 GB density device support

8-bank support

x4 (x4 devices must be used in even multiples), x8, and x16 device support
Note: x4 devices are not supported for AXI interface.

8:1 DQ:DQS ratio support for x8 and x16 devices

4:1 DQ:DQS ratio support for x4 devices

8-word burst support

Support for 5 to 14 cycles of column-address strobe (CAS) latency (CL)

On-die termination (ODT) support

Support for 5 to 10 cycles of CAS write latency

Write leveling support for DDR3 (fly-by routing topology required component designs)

JEDEC -compliant DDR3 initialization support

Source code delivery in Verilog

4:1 memory to FPGA logic interface clock ratio

Open, closed, and transaction based pre-charge controller policy

Interface calibration and training information available through the Vivado hardware
manager

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

12

Chapter 1: Overview

DDR4 SDRAM

Component support for interface width of 8 to 80 bits (RDIMM, UDIMM, and SODIMM
support)

Maximum component limit is 9 and this restriction is valid for components only and
not for DIMMs

8 GB density device support

x4 (x4 devices must be used in even multiples), x8, and x16 device support
Note: x4 devices are not supported for AXI interface.

8:1 DQ:DQS ratio support for x8 and x16 devices

4:1 DQ:DQS ratio support for x4 devices

Dual slot support for DDR4 RDIMMs and UDIMMs

8-word burst support

Support for 9 to 24 cycles of column-address strobe (CAS) latency (CL)

ODT support

Support for 9 to 18 cycles of CAS write latency

Write leveling support for DDR4 (fly-by routing topology required component designs)

JEDEC-compliant DDR4 initialization support

Source code delivery in Verilog

4:1 memory to FPGA logic interface clock ratio

Open, closed, and transaction based pre-charge controller policy

Interface calibration and training information available through the Vivado hardware
manager

Licensing and Ordering Information

This Xilinx LogiCORE IP module is provided at no additional cost with the Xilinx Vivado
Design Suite under the terms of the Xilinx End User License. Information about this and
other Xilinx LogiCORE IP modules is available at the Xilinx Intellectual Property page. For
information about pricing and availability of other Xilinx LogiCORE IP modules and tools,
contact your local Xilinx sales representative.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

13

Chapter 1: Overview

License Checkers
If the IP requires a license key, the key must be verified. The Vivado design tools have
several license checkpoints for gating licensed IP through the flow. If the license check
succeeds, the IP can continue generation. Otherwise, generation halts with error. License
checkpoints are enforced by the following tools:

Vivado synthesis

Vivado implementation

write_bitstream (Tcl command)

IMPORTANT: IP license level is ignored at checkpoints. The test confirms a valid license exists. It does

not check IP license level.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

14

Chapter 2

Product Specification
Standards
This core supports DRAMs that are compliant to the JESD79-3F, DDR3 SDRAM Standard and
JESD79-4, DDR4 SDRAM Standard, JEDEC Solid State Technology Association [Ref 1].
For more information on UltraScale architecture documents, see References, page 516.

Performance
Maximum Frequencies
For more information on the maximum frequencies, see Kintex UltraScale FPGAs Data Sheet,
DC and AC Switching Characteristics (DS892) [Ref 2].

Resource Utilization
Kintex UltraScale Devices
Table 2-1 and Table 2-2 provide approximate resource counts using Kintex UltraScale
devices.
Table 2-1:

Device Utilization Kintex UltraScale FPGAs for DDR3

Parameter
Values

Device Resources
Memory LUTs RAMB36E2/
RAMB18E2

Interface Width

FFs

LUTs

72

13,423

11,940

1,114

25.5

32

8,099

7,305

622

25.5

16

6,020

5,621

426

25.5

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

BUFGs

PLLE3_ADV MMCME3_ADV

Send Feedback

15

Chapter 2: Product Specification

Table 2-2:

Device Utilization Kintex UltraScale FPGAs for DDR4

Parameter
Values

Device Resources
Memory LUTs RAMB36E2/
RAMB18E2

Interface Width

FFs

LUTs

BUFGs

PLLE3_ADV MMCME3_ADV

72

13,535

11,905

1,105

25.5

32

8,010

7,161

622

25.5

16

5,864

5,363

426

25.5

Resources required for the UltraScale architecture FPGAs DDR3/DDR4 SRAM core have been
estimated for the Kintex UltraScale devices. These values were generated using Vivado IP
catalog. They are derived from post-synthesis reports, and might change during
implementation.

Port Descriptions
For a complete Memory Controller solution there are three port categories at the top-level
of the memory interface core called the user design.

The first category is the memory interface signals that directly interfaces with the
SDRAM. These are defined by the JEDEC specification.

The second category is the application interface signals. These are described in the
Protocol Description, page 97.

The third category includes other signals necessary for proper operation of the core.
These include the clocks, reset, and status signals from the core. The clocking and reset
signals are described in their respective sections.
The active-High init_calib_complete signal indicates that the initialization and
calibration are complete and that the interface is now ready to accept commands for the
interface.

For a PHY layer only solution, the top-level application interface signals are replaced with
the PHY interface. These signals are described in the PHY Only Interface, page 127.
The signals that interface directly with the SDRAM and the clocking and reset signals are the
same as for the Memory Controller solution.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

16

Chapter 3

Core Architecture
This chapter describes the UltraScale device FPGAs Memory Interface Solutions core with
an overview of the modules and interfaces.

Overview
The UltraScale architecture FPGAs Memory Interface Solutions is shown in Figure 3-1.
X-Ref Target - Figure 3-1

8OWUD6FDOH$UFKLWHFWXUH)3*$V
8OWUD6FDOH$UFKLWHFWXUH)3*$V0HPRU\,QWHUIDFH6ROXWLRQ

0HPRU\
&RQWUROOHU



8VHU)3*$
/RJLF

8VHU
LQWHUIDFH

''5''5
6'5$0

3K\VLFDO
/D\HU

,QLWLDOL]DWLRQ
&DOLEUDWLRQ
&DO'RQH

5HDG'DWD

Figure 3-1:

UltraScale Architecture FPGAs Memory Interface Solution Core

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

17

Chapter 3: Core Architecture

Memory Controller
The Memory Controller (MC) is designed to take Read, Write, and Read-Modify-Write
transactions from the user interface (UI) block and issues them to memory efficiently with
low latency, meeting all DRAM protocol and timing requirements, while using minimal FPGA
resources. The controller operates with a DRAM to system clock ratio of 4:1 and can issue
one Activate, one CAS, and one Precharge command on each system clock cycle.
The controller supports an open page policy and can achieve very high efficiencies with
workloads with a high degree of spatial locality. The controller also supports a closed page
policy and the ability to reorder transactions to efficiently schedule workloads with address
patterns that are more random. The controller also allows a degree of control over low-level
functions with a UI control signal for AutoPrecharge on a per transaction basis as well as
signals that can be used to determine when DRAM refresh commands are issued.
The key blocks of the controller command path include:
1. The Group FSMs that queue up transactions, check DRAM timing, and decide when to
request Precharge, Activate, and CAS DRAM commands.
2. The "Safe" logic and arbitration units that reorder transactions between Group FSMs
based on additional DRAM timing checks while also ensuring forward progress for all
DRAM command requests.
3. The Final Arbiter that makes the final decision about which commands are issued to the
PHY and feeds the result back to the previous stages.
There are also maintenance blocks that generate refresh and ZQCS commands as well as
commands needed for VT tracking. Also, there is an optional block that implements a
SECDED ECC for 72-bit wide data buses.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

18

Chapter 3: Core Architecture

Figure 3-2 shows the Memory Controller block diagram.
X-Ref Target - Figure 3-2

0&

5G'DWD

5HDG'DWD

'DWD
(&&
:ULWH'DWD

:U'DWD

&0'$GGU

*URXS)60

3UH
$FW
&$6

8,

3+<
3UHFKDUJH
3UH
*URXS)60

$FW
&$6

5HDG:ULWH
7UDQVDFWLRQ

6DIH/RJLF
DQG
5HRUGHU
$UELWUDWLRQ

$FWLYDWH

)LQDO
$UE

&0'$GGUHVV

3UH
*URXS)60

$FW
&$6

&$6
3UH
*URXS)60

$FW
&$6

0DLQWHQDQFH
5HIUHVK=4&6
977UDFNLQJ

Figure 3-2:

Memory Controller Block Diagram

Native Interface
The UI block is connected to the Memory Controller by the native interface, and provides
the controller with address decode and read/write data buffering. On writes, data is
requested by the controller one cycle before it is needed by presenting the data buffer
address on the native interface. This data is expected to be supplied by the UI block on the
next cycle. Hence there is no buffering of any kind for data (except due to the barrel shifting
to place the data on a particular DDR clock).
On reads, the data is offered by the MC on the cycle it is available. Read data, along with a
buffer address is presented on the native interface as soon as it is ready. The data has to be
accepted by the UI block.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

19

Chapter 3: Core Architecture

Read and write transactions are mapped to an mcGroup instance based on bank group and
bank address bits of the decoded address from the UI block. Although there are no groups
in DDR3, the name group represents either a real group in DDR4 x4 and x8 devices (which
serves four banks of that group). For DDR3, each mcGroup module would service two
banks.
In the case of DDR4 x16 interface, the mcGroup represents 1-bit of group (there are only
one group bit in x16) and 1-bit of bank, whereby the mcGroup serves two banks.
The total number of outstanding requests depends on the number of mcGroup instances, as
well as the round trip delay from the controller to memory and back. When the controller
issues an SDRAM CAS command to memory, an mcGroup instance becomes available to
take a new request, while the previous CAS commands, read return data, or write data might
still be in flight.

Control and Datapaths

Control Path
The control path starts at the mcGroup instances. The mapping of SDRAM group and bank
addresses to mcGroup instance ensures that transactions to the same full address map to
the same mcGroup instance. Because each mcGroup instance processes the transactions it
receives in order, read-after-write and write-after-write address hazards are prevented.

Datapath
Read and write data pass through the Memory Controller. If ECC is enabled, a SECDEC code
word is generated on writes and checked on reads. For more information, see ECC, page 23.
The MC generates the requisite control signals to the mcRead and mcWrite modules telling
them the timing of read and write data. The two modules acquire or provide the data as
required at the right time.

Read and Write Coalescing

The controller prioritizes reads over writes when reordering is enabled. If both read and
write CAS commands are safe to issue on the SDRAM command bus, the controller selects
only read CAS commands for arbitration. When a read CAS issues, write CAS commands are
blocked for several SDRAM clocks specified by parameter tRTW. This extra time required for
a write CAS to become safe after issuing a read CAS allows groups of reads to issue on the
command bus without being interrupted by pending writes.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

20

Chapter 3: Core Architecture

Reordering
Requests that map to the same mcGroup are never reordered. Reordering between the
mcGroup instances is controlled with the ORDERING parameter. When set to "NORM,"
reordering is enabled and the arbiter implements a round-robin priority plan, selecting in
priority order among the mcGroups with a command that is safe to issue to the SDRAM.
The timing of when it is safe to issue a command to the SDRAM can vary on the target bank
or bank group and its page status. This often contributes to reordering.
When the ORDERING parameter is set to "STRICT," all requests have their CAS commands
issued in the order in which the requests were accepted at the native interface. STRICT
ordering overrides all other controller mechanisms, such as the tendency to coalesce read
requests, and can therefore degrade data bandwidth utilization in some workloads.

Group Machines
In the Memory Controller, there are four group state machines. These state machines are
allocated depending on technology (DDR3 or DDR4) and width (x4, x8, and x16). The
following summarizes the allocation to each group machine. In this description, GM refers
to the Group Machine (0 to 3), BG refers to group address, and BA refers to bank address.
Note that group in the context of a group state machine denotes a notional group and does
not necessarily refer to a real group (except in case of DDR4, part x4 and x8).

DDR3, any part Total of eight banks

GM 0: BA[2:1] == 2'b00; services banks 0 and 1

GM 1: BA[2:1] == 2'b01; services banks 2 and 3

GM 2: BA[2:1] == 2'b10; services banks 4 and 5

GM 3: BA[2:1] == 2'b11; services banks 6 and 7

DDR4, x4 and x8 parts Total of 16 banks

GM 0: services BG 0; four banks per group

GM 1: services BG 1; four banks per group

GM 2: services BG 2; four banks per group

GM 3: services BG 3; four banks per group

DDR4, x16 parts Total of eight banks

GM 0: services BG 0, BA[0] == 0; 2 banks per group

GM 1: services BG 0, BA[0] == 1; 2 banks per group

GM 2: services BG 1, BA[0] == 0; 2 banks per group

GM 3: services BG 1, BA[0] == 1; 2 banks per group

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

21

Chapter 3: Core Architecture

Figure 3-3 shows the Group FSM block diagram for one instance. There are two main
sections to the Group FSM block, stage 1 and stage 2, each containing a FIFO and an FSM.
Stage 1 interfaces to the UI, issues Precharge and Activate commands, and tracks the DRAM
page status.
Stage 2 issues CAS commands and manages the RMW flow. There is also a set of DRAM
timers for each rank and bank used by the FSMs to schedule DRAM commands at the
earliest safe time. The Group FSM block is designed so that each instance queues up
multiple transactions from the UI, interleaves DRAM commands from multiple transactions
onto the DDR bus for efficiency, and executes CAS commands strictly in order.
X-Ref Target - Figure 3-3

$FWLYDWH5HTXHVW
6WDJH
7UDQVDFWLRQ
*URXS)60

HPSW\

3UHFKDUJH5HTXHVW

IXOO

'5$0
&RPPDQGV

3DJH
6WDWXV

:LQQLQJ
&RPPDQG
IHHGEDFN

W5&'
W53
W5$6
7LPHUV

'5$0
&RPPDQGV

6WDJH
&$6
*URXS)60

3DJH7DEOH
IXOO

HPSW\

'5$0$GGUHVVIRU
1HZ8,7UDQVDFWLRQ

SXVK

SRS

SXVK

SRS

'5$0$GGUHVV
6WDJH),)2

&$65HTXHVW

&$6$GGUHVV
6WDJH),)2

$FWLYDWH3UHFKDUJH$GGUHVV

Figure 3-3:

Group FSM Block Diagram

When a new transaction is accepted from the UI, it is pushed into the stage 1 transaction
FIFO. The page status of the transaction at the head of the stage 1 FIFO is checked and
provided to the stage 1 transaction FSM. The FSM decides if a Precharge or Activate
command needs to be issued, and when it is safe to issue them based on the DRAM timers.
When the page is open and not already scheduled to be closed due to a pending RDA or
WRA in the stage 2 FIFO, the transaction is transferred from the stage 1 FIFO to the stage 2
FIFO. At this point, the stage 1 FIFO is popped and the stage 1 FSM begins processing the
next transaction. In parallel, the stage 2 FSM processes the CAS command phase of the
transaction at the head of the stage 2 FIFO. The stage 2 FSM issues a CAS command request
when it is safe based on the tRCD timers. The stage 2 FSM also issues both a read and write
CAS request for RMW transactions.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

22

Chapter 3: Core Architecture

ECC
The MC supports an optional SECDED ECC scheme that detects and corrects read data
errors with 1-bit error per DQ bus burst and detects all 2-bit errors per burst. The 2-bit
errors are not corrected. Three or more bit errors per burst might or might not be detected,
but are never corrected. Enabling ECC adds four DRAM clock cycles of latency to all reads,
whether errors are detected/corrected or not.
A Read-Modify-Write (RMW) scheme is also implemented to support Partial Writes when
ECC is enabled. Partial Writes have one or more user interface write data mask bits set High.
Partial Writes with ECC disabled are handled by sending the data mask bits to the DRAM
Data Mask (DM) pins, so the RMW flow is used only when ECC is enabled. When ECC is
enabled, Partial Writes require their own command, wr_bytes or 0x3, so the MC knows
when to use the RMW flow.

Read-Modify-Write Flow
When a wr_bytes command is accepted at the user interface it is eventually assigned to a
group state machine like other write or read transactions. The group machine breaks the
Partial Write into a read phase and a write phase. The read phase performs the following:
1. First reads data from memory.
2. Checks for errors in the read data.
3. Corrects single bit errors.
4. Stores the result inside the Memory Controller.
Data from the read phase is not returned to the user interface. If errors are detected in the
read data, an ECC error signal is asserted at the native interface. After read data is stored in
the controller, the write phase begins as follows:
1. Write data is merged with the stored read data based on the write data mask bits.
2. New ECC check bits are generated for the merged data and check bits are written to
memory.
3. Any multiple bit errors in the read phase results in the error being made undetectable in
the write phase as new check bits are generated for the merged data. This is why the ECC
error signal is generated on the read phase even though data is not returned to the user
interface. This allows the system to know if an uncorrectable error has been turned into
an undetectable error.
When the write phase completes, the group machine becomes available to process a new
transaction. The RMW flow ties up a group machine for a longer time than a simple read or
write, and therefore might impact performance.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

23

Chapter 3: Core Architecture

ECC Module
The ECC module is instantiated inside the DDR3/DDR4 Memory Controller. It is made up of
five submodules as shown in Figure 3-4.
X-Ref Target - Figure 3-4

HFFBHUUBDGGU>@

HFFBPXOWLSOH
HFFBVLQJOH

FRUUHFWBHQ

UGBGDWDBSK\PF>'4B:,'7+@

'DWD,Q

UGBGDWDBPFQL>3$</2$'B:,'7+@
'DWD2XW

'HFRGHDQG)L[

HFFBVWDWXVBYDOLG

UGBGDWDBHQBPFQL

'

'

'

UGBGDWDBHQBSK\PF

UPZBUGBGRQH
:ULWH'DWD

:ULWH(QDEOH

(&&%XIIHU

ZULWHBDGGUBSK\PF>@

:ULWHDGGU>@
;
3$</2$'B:,'7+Q&.B3(5B&/.

'

UGBGDWDBDGGUBSK\PF>@

5HDGDGGU>@
5HDG'DWD

UGBPHUJHBGDWD>3$</2$'B:,'7+@

ZUBGDWDBHQF[RU
>'4B:,'7+@

ZULWHBGDWDBQLPF>3$</2$'B:,'7+@
'DWD,Q

0HUJHDQG(QFRGH

'DWD2XW

;25%ORFN
(UURU
,QMHFWLRQ

ZUBGDWDBPFSK\>'4B:,'7+@

ZULWHBGDWDBPDVNBQLPF

(&&*HQ
+0DWUL[*HQHUDWLRQ

Figure 3-4:

ECC Block Diagram

Read data and check bits from the PHY are sent to the Decode block, and on the next
system clock cycle data and error indicators ecc_single/ecc_multiple are sent to the
NI. ecc_single asserts when a correctable error is detected and the read data has been
corrected. ecc_multiple asserts when an uncorrectable error is detected.
Read data is not modified by the ECC logic on an uncorrectable error. Error indicators are
never asserted for periodic reads, which are read transactions generated by the controller
only for the purposes of VT tracking and are not returned to the user interface or written
back to memory in an RMW flow.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

24

Chapter 3: Core Architecture

Write data is merged in the Encode block with read data stored in the ECC Buffer. The merge
is controlled on a per byte basis by the write data mask signal. All writes use this flow, so full
writes are required to have all data mask bits deasserted to prevent unintended merging.
After the Merge stage, the Encode block generates check bits for the write data. The data
and check bits are output from the Encode block with a one system clock cycle delay.
The ECC Gen block implements an algorithm that generates an H-matrix for ECC check bit
generation and error checking/correction. The generated code depends only on the
PAYLOAD_WIDTH and DQ_WIDTH parameters, where DQ_WIDTH = PAYLOAD_WIDTH +
ECC_WIDTH. Currently only DQ_WIDTH = 72 and ECC_WIDTH = 8 is supported.

Error Address
Each time a read CAS command is issued, the full DRAM address is stored in a FIFO in the
decode block. When read data is returned and checked for errors, the DRAM address is
popped from the FIFO and ecc_err_addr[44:0] is returned on the same cycle as signals
ecc_single and ecc_multiple for the purposes of error logging or debug. Table 3-1 is
a common definition of this address for DDR3 and DDR4.
Table 3-1:

ECC Error Address Definition

ecc_err_addr
44
[44:0]

43:42

41:40 39:24

23:22 21:18 17:8

DDR4 (x4/x8)

RMW

RSVD

Row[17:0]

RSVD

RSVD

DDR (x16)

RMW

RSVD

Row[17:0]

RSVD

RSVD

DDR3

RMW

RSVD

RSVD

Col[13:0]

Row
[15:0]

7:6

5:4

1:0

Col
[9:0]

RSVD

Rank
[1:0]

Group
[1:0]

Col
[9:0]

RSVD

Rank
[1:0]

RSVD

Group
[0]

RSVD

Rank
[1:0]

RSVD

Bank[2:0]

Bank
[1:0]
Bank
[1:0]

Latency
When the parameter ECC is ON, the ECC modules are instantiated and read and write data
latency through the MC increases by one system clock cycle. When ECC is OFF, the data
buses just pass through the MC and all ECC logic should be optimized out.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

25

Chapter 3: Core Architecture

PHY
PHY is considered the low-level physical interface to an external DDR3 or DDR4 SDRAM
device as well as all calibration logic for ensuring reliable operation of the physical interface
itself. PHY generates the signal timing and sequencing required to interface to the memory
device.
PHY contains the following features:

Clock/address/control-generation logics

Write and read datapaths

Logic for initializing the SDRAM after power-up

In addition, PHY contains calibration logic to perform timing training of the read and write
datapaths to account for system static and dynamic delays.
The PHY is included in the complete Memory Interface Solution core, but can also be
implemented as a standalone PHY only block. A PHY only solution can be selected if you
plan to implement a custom Memory Controller. For details about interfacing to the PHY
only block, see the PHY Only Interface, page 127.

Overall PHY Architecture

The UltraScale architecture PHY is composed of dedicated blocks and soft calibration logic.
The dedicated blocks are structured adjacent to one another with back-to-back
interconnects to minimize the clock and datapath routing necessary to build high
performance physical layers.
The Memory Controller and calibration logic communicate with this dedicated PHY in the
slow frequency clock domain, which is either divided by four or divided by two. This
depends on the DDR3 or DDR4 memory clock. A more detailed block diagram of the PHY
design is shown in Figure 3-5.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

26

Chapter 3: Core Architecture

X-Ref Target - Figure 3-5

8OWUD6FDOH$UFKLWHFWXUH)3*$V0HPRU\,QWHUIDFH6ROXWLRQ

''5$GGUHVV
&RQWURO:ULWH'DWD
DQG0DVN
&0':ULWH'DWD

LQIUDVWUXFWXUH

SOOFONV

SOO

0HPRU\&RQWUROOHU

SOO*DWH

FDOBWRS

8VHU
,QWHUIDFH


FDOBULX

0LFUR%OD]H
PFV

[LSK\

FDO

LRE

PFBSL


FDO$GGU'HFRGH

&DO'RQH
&DO'HEXJ
6XSSRUW

5HDG'DWD

5HDG'DWD
VWDWXV
&DO'RQH

Figure 3-5:

PHY Block Diagram

The Memory Controller is designed to separate out the command processing from the
low-level PHY requirements to ensure a clean separation between the controller and
physical layer. The command processing can be replaced with custom logic if desired, while
the logic for interacting with the PHY stays the same and can still be used by the calibration
logic.
Table 3-2:

PHY Modules

Module Name

Description

<module>_...cal_top.sv

Contains <module>_...cal_top.sv, <module>_...mc_pi.sv, and MUXes

between the calibration and the Memory Controller.

<module>_...cal_riu.sv

Contains the MicroBlaze processing system and associated logic.

<module>_...mc_pi.sv

Adjusts signal timing for the PHY for reads and writes.

<module>_...cal_addr_decode.sv

FPGA logic interface for the MicroBlaze processor.

<module>_...config_rom.sv

Configuration storage for calibration options.

microblaze

MicroBlaze processor

<module>_...iob.sv

Instantiates all byte IOB modules.

<module>_...iob_byte.sv

Generates the I/O buffers for all the signals in a given byte lane.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

27

Chapter 3: Core Architecture

Table 3-2:

PHY Modules (Contd)

Module Name

Description

<module>_...debug_microblaze.sv

Simulation-only file to parse debug statements from software running in

MicroBlaze to indicate status and calibration results to the log.

<module>_...cal_cplx.sv

RTL state machine for complex pattern calibration.

<module>_...cal_cplx_data.sv

Data patterns used for complex pattern calibration.

<module>_...xiphy.sv

Top-level XIPHY module.

<module>_...phy.sv

Top-level of the PHY, contains pll and xiphy.sv modules.

The PHY architecture encompasses all of the logic contained in <module>_...phy.sv.

The PHY contains wrappers around dedicated hard blocks to build up the memory interface
from smaller components. A byte lane contains all of the clocks, resets, and datapaths for a
given subset of I/O. Multiple byte lanes are grouped together, along with dedicated
clocking resources, to make up a single bank memory interface. Each nibble in the PHY
contains a Register Interface Unit (RIU), a dedicated integrated block in the XIPHY that
provides an interface to the general interconnect logic for changing settings and delays for
calibration. For more information on the hard silicon physical layer architecture, see the
UltraScale Architecture FPGAs SelectIO Resources User Guide (UG571) [Ref 3].
The memory initialization is executed in Verilog RTL. The calibration and training are
implemented by an embedded MicroBlaze processor. The MicroBlaze Controller System
(MCS) is configured with an I/O Module and a block RAM. The
<module>_...cal_addr_decode.sv module provides the interface for the processor to
the rest of the system and implements helper logic. The <module>_...config_rom.sv
module stores settings that control the operation of initialization and calibration, providing
run time options that can be adjusted without having to recompile the source code.
The address unit connects the MCS to the local register set and the PHY by performing
address decode and control translation on the I/O module bus from spaces in the memory
map and MUXing return data (<module>_...cal_addr_decode.sv). In addition, it
provides address translation (also known as mapping) from a logical conceptualization of
the DRAM interface to the appropriate pinout-dependent location of the delay control in
the PHY address space.
Although the calibration architecture presents a simple and organized address map for
manipulating the delay elements for individual data, control and command bits, there is
flexibility in how those I/O pins are placed. For a given I/O placement, the path to the FPGA
logic is locked to a given pin. To enable a single binary software file to work with any
memory interface pinout, a translation block converts the simplified RIU addressing into
the pinout-specific RIU address for the target design (see Table 3-3). The specific address
translation is written by DDR3/DDR4 SDRAM after a pinout is selected and cannot be
modified. The code shows an example of the RTL structure that supports this.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

28

Chapter 3: Core Architecture

Casez(io_address)// MicroBlaze I/O module address
// static address decoding skipped
//========================================//
//===========DQ ODELAYS===================//
//========================================//
//Byte0
28h0004100: begin //c0_ddr4_dq[0] IO_L20P_T3L_N2_AD1P_44
riu_addr_cal = 6hD;
riu_nibble = h6;
end
// additional dynamic addressing follows

In this example, DQ0 is pinned out on Bit[0] of nibble 0 (nibble 0 according to instantiation
order). The RIU address for the ODELAY for Bit[0] is 0x0D. When DQ0 is addressed
indicated by address 0x000_4100), this snippet of code is active. It enables nibble 0
(decoded to one-hot downstream) and forwards the address 0x0D to the RIU address bus.
The MicroBlaze I/O module interface is not always fast enough for implementing all of the
functions required in calibration. A helper circuit implemented in
<module>_...cal_addr_decode.sv is required to obtain commands from the
registers and translate at least a portion into single-cycle accuracy for submission to the
PHY. In addition, it supports command repetition to enable back-to-back read transactions
and read data comparison.
Table 3-3:

XIPHY RIU Addressing and Description

RIU Address

Name

Description

0x00

NIBBLE_CTRL0

Nibble Control 0. Control for enabling DQS gate in the XIPHY, GT_STATUS
for gate feedback, and clear gate which resets gate circuit.

0x01

NIBBLE_CTRL1

Nibble Control 1. TX_DATA_PHASE control for every bit in the nibble.

0x02

CALIB_CTRL

Calibration Control. XIPHY control and status for BISC.

0x03

Reserved

Reserved

0x04

Reserved

Reserved

0x05

BS_CTRL

Bit slice reset. Resets the ISERDES and IFIFOs in a given nibble.

0x06

Reserved

Reserved

0x07

PQTR

Rising edge delay for DQS.

0x08

NQTR

Falling edge delay for DQS.

0x09

Reserved

Reserved

0x0A

TRISTATE_ODELAY

Output delay for 3-state.

0x0B

ODELAY0

Output delay for bit slice 0.

0x0C

ODELAY1

Output delay for bit slice 1.

0x0D

ODELAY2

Output delay for bit slice 2.

0x0E

ODELAY3

Output delay for bit slice 3.

0x0F

ODELAY4

Output delay for bit slice 4.

0x10

ODELAY5

Output delay for bit slice 5.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

29

Chapter 3: Core Architecture

Table 3-3:

XIPHY RIU Addressing and Description (Contd)

RIU Address

Name

Description

0x11

ODELAY6

Output delay for bit slice 6.

0x12

IDELAY0

Input delay for bit slice 0.

0x13

IDELAY1

Input delay for bit slice 1.

0x14

IDELAY2

Input delay for bit slice 2.

0x15

IDELAY3

Input delay for bit slice 3.

0x16

IDELAY4

Input delay for bit slice 4.

0x17

IDELAY5

Input delay for bit slice 5.

0x18

IDELAY6

Input delay for bit slice 6.

0x19

PQTR Align

BISC edge alignment computation for rising edge DQS.

0x1A

NQTR Align

BISC edge alignment computation for falling edge DQS.

0x1B to 0x2B

Reserved

Reserved

0x2C

WL_DLY_RNK0

Write Level register for Rank 0. Coarse and fine delay, WL_TRAIN.

0x2D

WL_DLY_RNK1

Write Level register for Rank 1. Coarse and fine delay.

0x2E

WL_DLY_RNK2

Write Level register for Rank 2. Coarse and fine delay.

0x2F

WL_DLY_RNK3

Write Level register for Rank 3. Coarse and fine delay.

0x30

RL_DLY_RNK0

DQS Gate register for Rank 0. Coarse and fine delay.

0x31

RL_DLY_RNK1

DQS Gate register for Rank 1. Coarse and fine delay.

0x32

RL_DLY_RNK2

DQS Gate register for Rank 2. Coarse and fine delay.

0x33

RL_DLY_RNK3

DQS Gate register for Rank 3. Coarse and fine delay.

0x34 to 0x3F

Reserved

Reserved

Memory Initialization and Calibration Sequence

After deassertion of the system reset, PHY performs some required internal calibration
steps first.
1. The built-in self-check of the PHY (BISC) is run. BISC is used in the PHY to compute
internal skews for use in voltage and temperature tracking after calibration is
completed.
2. After BISC is completed, calibration logic performs the required power-on initialization
sequence for the memory.
3. This is followed by several stages of timing calibration for the write and read datapaths.
4. After calibration is completed, PHY calculates internal offsets to be used in voltage and
temperature tracking.
5. PHY indicates calibration is finished and the controller begins issuing commands to the
memory.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

30

Chapter 3: Core Architecture

Figure 3-6 shows the overall flow of memory initialization and the different stages of
calibration.
X-Ref Target - Figure 3-6

6\VWHP5HVHW

;,3+<%,6&

;6'%6HWXS

''5''56'5$0,QLWLDOL]DWLRQ

'46*DWH&DOLEUDWLRQ
'46*DWH
6DQLW\&KHFN
:ULWH/HYHOLQJ
<HV

5DQN
"
1R

5HDG7UDLQLQJ3HUELWGHVNHZ

5HDG'46&HQWHULQJ6LPSOH
5HDG
6DQLW\&KHFN

<HV

5DQN
"

:ULWH'46WR'4'HVNHZ

:ULWH'46WR'0'%,'HVNHZ
1R

:ULWH'46WR'46LPSOH

:ULWH'46WR'0'%,6LPSOH

,WHUDWLYHORRSWR
FDOLEUDWHPRUHUDQNV

:ULWH/DWHQF\&DOLEUDWLRQ

:ULWH5HDG
6DQLW\&KHFN

5HDG'46&HQWHULQJ&RPSOH[
:ULWH5HDG
6DQLW\&KHFN
5HDG95()7UDLQLQJ''52QO\
:ULWH5HDG
6DQLW\&KHFN

<HV

5DQN
"
1R

:ULWH'46WR'4&RPSOH[
:ULWH5HDG
6DQLW\&KHFN

:ULWH95()7UDLQLQJ''52QO\
:ULWH5HDG
6DQLW\&KHFN
5HDG'46&HQWHULQJ0XOWL5DQN$GMXVWPHQW
:ULWH5HDG
6DQLW\&KHFN

1R

$OO
'RQH"

5DQNFRXQW

<HV

0XOWL5DQN&KHFNVDQG$GMXVWPHQWV0XOWL5DQN2QO\
:ULWH5HDG
6DQLW\&KHFN
(QDEOH977UDFNLQJ
6DQLW\&KHFNUXQVIRUPXOWLUDQNDQGIRUDUDQNRWKHUWKDQWKH
ILUVWUDQN)RUH[DPSOHLIWKHUHZHUHWZRUDQNVLWZRXOGUXQRQ
WKHVHFRQGRQO\
6DQLW\&KHFNUXQVIRUPXOWLUDQNDQGJRHVWKURXJKDOORIWKH
UDQNV

Figure 3-6:

&DOLEUDWLRQ'RQH

PHY Overall Initialization and Calibration Sequence

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

31

Chapter 3: Core Architecture

When simulating a design out of DDR3/DDR4 SDRAM, the calibration it set to be bypassed
to enable you to generate traffic to and from the DRAM as quickly as possible. When
running in hardware or simulating with calibration, enabled signals are provided to indicate
what step of calibration is running or, if an error occurs, where an error occurred.
The first step in determining calibration status is to check the CalDone port. After the
CalDone port is checked, the status bits should be checked to indicate the steps that were
ran and completed. Calibration halts on the very first error encountered, so the status bits
indicate which step of calibration was last run. The status and error signals can be checked
through either connecting the Vivado analyzer signals to these ports or through the XSDB
tool (also through Vivado).
The calibration status is provided through the XSDB port, which stores useful information
regarding calibration for display in the Vivado IDE. The calibration status and error signals
are also provided as ports to allow for debug or triggering. Table 3-4 lists the
pre-calibration status signal description.
Table 3-4:

Pre-Calibration XSDB Status Signal Description

XSDB Status Register

DDR_PRE_CAL_STATUS

XSDB Bits[8:0]

Description

Pre-Calibration Step

Done

MicroBlaze has started up

Done

Reserved

Done

Reserved

Done

Reserved

Done

XSDB Setup Complete

Reserved

Reserved

Reserved

Reserved

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

32

Chapter 3: Core Architecture

Table 3-5 lists the status signals in the port as well as how they relate to the core XSDB data.
Table 3-5:

XSDB Status Signal Descriptions

XSDB Status Register

DDR_CAL_STATUS_RANKx_0

DDR_CAL_STATUS_RANKx_1

DDR_CAL_STATUS_RANKx_2

Status
XSDB
Port
Description Calibration Stage Name
Bits[8:0]
Bits[40:0]

Calibration
Stage
Number

Start

DQS Gate

Done

Start

Check for DQS gate

Done

Start

Write leveling

Done

Start

Read Per-bit Deskew

Done

Start

Reserved

Done

10

Start

Read DQS Centering (Simple)

11

Done

12

Start

Read Sanity Check

13

Done

14

Start

Write DQS-to-DQ Deskew

15

Done

16

Start

Write DQS-to-DM Deskew

17

Done

18

Start

Write DQS-to-DQ (Simple)

10

19

Done

20

Start

Write DQS-to-DM (Simple)

11

21

Done

22

Start

Reserved

12

23

Done

24

Start

Write Latency Calibration

13

25

Done

26

Start

Write/Read Sanity Check 0

14

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

33

Chapter 3: Core Architecture

Table 3-5:

XSDB Status Signal Descriptions (Contd)

XSDB Status Register

DDR_CAL_STATUS_RANKx_3

DDR_CAL_STATUS_RANKx_4

DDR_CAL_STATUS_RANKx_5

Status
XSDB
Port
Description Calibration Stage Name
Bits[8:0]
Bits[40:0]

Calibration
Stage
Number

27

Done

28

Start

Read DQS Centering

(Complex)

15

29

Done

30

Start

Write/Read Sanity Check 1

16

31

Done

32

Start

Reserved

17

33

Done

34

Start

Write/Read Sanity Check 2

18

35

Done

36

Start

Write DQS-to-DQ (Complex)

19

37

Done

38

Start

Write DQS-to-DM (Complex)

20

39

Done

40

Start

Write/Read Sanity Check 3

21

41

Done

42

Start

Reserved

22

43

Done

44

Start

Write/Read Sanity Check 4

23

45

Done

46

Start

Read Level Multi-Rank

Adjustment

24

47

Done

48

Start

Write/Read Sanity Check 5

(For More than 1 Rank)

25

49

Done

50

Start

Multi-Rank Adjustments and

Checks

26

51

Done

52

Start

Write/Read Sanity Check 6 (All

Ranks)

27

53

Done

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

34

Chapter 3: Core Architecture

Table 3-6 lists the post-calibration XSDB status signal descriptions.
Table 3-6:

Post-Calibration XSDB Status Signal Description

XSDB Status Register

DDR_POST_CAL_STATUS

XSDB Bits[8:0]

Description

Post-Calibration Step

Running

Idle

Fail

Running

Read Margin Check (Reserved)

Running

Write Margin Check (Reserved)

Reserved

Reserved

Reserved

Reserved

DQS Gate Tracking

Table 3-7 lists the error signals and a description of each error. To decode the error first look
at the status to determine which calibration stage failed (the start bit would be asserted, the
associated done bit deasserted) then look at the error code provided. The error asserts the
first time an error is encountered.
Table 3-7:

Error Signal Descriptions

STAGE_NAME

DQS Gate

Stage

Code

DDR_CAL_
ERROR_1

DDR_CAL_
ERROR_0

Error

0x1

Byte

RIU Nibble

Calibration uses the calculated latency from

the MPR register as a starting point and then
backs off and begins sampling. If the sample
occurs too late in the DQS burst and there
are no taps left to decrement for the latency,
then an error has occurred.

0x2

Byte

RIU Nibble

Expected pattern was not found on

GT_STATUS.

0x3

Byte

RIU Nibble

CAS latency is too low. Calibration starts at a

CAS latency (CL) 3. For allowable CAS
latencies, see EXTRA_CMD_DELAY
Configuration Settings, page 145.

0x4

Byte

RIU Nibble

Pattern not found on GT_STATUS, all 0s were

sampled. Expecting to sample the preamble.

0x5

Byte

RIU Nibble

Pattern not found on GT_STATUS, all 1s were

sampled. Expecting to sample the preamble.

0x6

Byte

RIU Nibble

Could not find the 0->1 transition with fine

taps in at least 1 tck (estimated) of fine taps.

0x7

Byte

RIU Nibble

Underflow of coarse taps when trying to limit

maximum coarse tap setting.

0x8

Byte

RIU Nibble

Violation of maximum read latency limit.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

35

Chapter 3: Core Architecture

Table 3-7:

Error Signal Descriptions (Contd)

STAGE_NAME

Stage

Code

DDR_CAL_
ERROR_1

DDR_CAL_
ERROR_0

Error

DQS Gate Sanity

Check

0xF

N/A

N/A

PHY fails to return same number of data

bursts as expected

0x1

Byte

N/A

Cannot find stable 0.

0x2

Byte

N/A

Cannot find stable 1.

0x3

Byte

N/A

Cannot find the left edge of noise region with

fine taps.

0x4

Byte

N/A

Could not find the 0->1 transition with fine

taps in at least 1 tck (estimated) of ODELAY
taps.

0x1

Nibble

Bit

No valid data found for a given bit in the

nibble when running the deskew pattern.

0xF

Nibble

Bit

Timeout error waiting for read data bursts to

return.

0x1

Nibble

Bit

No valid data found for a given bit in the

nibble.

0x2

Nibble

Bit

Could not find the left edge of the data valid

window to determine window size. All
samples returned valid data.

0xF

Nibble

Bit

Timeout error waiting for read data to return.

0x1

Nibble

Read data comparison failure.

0xF

N/A

N/A

Timeout error waiting for read data to return.

0x1

Byte

Bit

DQS deskew error. No valid data found;

therefore, ran out of taps during search.

0x2

Byte

Bit

DQ deskew error. Failure point not found.

0xF

Byte

Bit

Timeout error waiting for all read data bursts

to return.

0x1

Byte

Bit

DQS deskew error. No valid data found;

therefore, ran out of taps during search.

0x2

Byte

Bit

DM/DBI deskew error. Failure point not

found.

0xF

Byte

Bit

Timeout error waiting for all read data bursts

to return.

0x1

Byte

N/A

No valid data found; therefore, ran out of

taps during search.

0xF

Byte

N/A

Timeout error waiting for read data to return.

0x1

Byte

N/A

No valid data found; therefore, ran out of

taps during search.

0xF

Byte

N/A

Timeout error waiting for all read data bursts

to return.

Write Leveling

Read Per-Bit Deskew

Read DQS Centering

Read Sanity Check

Write DQS-to-DQ
Deskew

Write DQS-to-DM/
DBI Deskew

Write DQS-to-DQ
(Simple)

Write DQS-to-DM
(Simple)

10

11

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

36

Chapter 3: Core Architecture

Table 3-7:

Error Signal Descriptions (Contd)

STAGE_NAME

Write Latency
Calibration

Stage

13

Write Read Sanity

Check

14

Read_Leveling
(Complex)

15

Write Read Sanity

Check

16

Read V REF Training

17

Write Read Sanity

Check

18

Write DQS-to-DQ
(Complex)

19

Write Read Sanity

Check

Write V REF Training

21

22

Write Read Sanity

Check

23

Write Read Sanity

Check

25

Code

DDR_CAL_
ERROR_1

DDR_CAL_
ERROR_0

Error

0x1

Byte

N/A

Could not find the data pattern within the

allotted number of taps.

0x2

Byte

N/A

Data pattern not found. Data late at the start,

instead of F0A55A96, found 00F0A55A.

0x3

Byte

N/A

Data pattern not found. Data too early, not

enough movement to find pattern. Found
pattern of "A55A96FF," "5A96FFFF," or
"96FFFFFF."

0x4

Byte

N/A

Data pattern not found. Multiple reads to the

same address resulted in a read mismatch.

0xF

Byte

N/A

Timeout error waiting for read data to return.

0x1

Nibble

Read data comparison failure.

0xF

N/A

N/A

Timeout error waiting for read data to return.

See Read DQS Centering error codes.

0x1

Nibble

N/A

Read data comparison failure.

0xF

N/A

N/A

Timeout error waiting for all read data bursts

to return.

0x1

Byte

N/A

No valid window found for any VREF value.

0xF

Nibble

N/A

Timeout error waiting for read data to return.

0x1

Nibble

Read data comparison failure.

0xF

N/A

N/A

Timeout error waiting for read data to return.

See Write DQS-to-DQ (Simple) error codes.

0x1

Nibble

N/A

Read data comparison failure.

0xF

N/A

N/A

Timeout error waiting for all read data bursts

to return.

0x1

Byte

N/A

No valid window found for any VREF value.

0x2

Byte

N/A

Readback Write VREF value from the DRAM

does not match expected.

0xF

Byte

N/A

Timeout error waiting for read data to return.

0x1

Nibble

N/A

Read data comparison failure.

0xF

N/A

N/A

Timeout error waiting for all read data bursts

to return.

0x1

Nibble

Read data comparison failure.

0xF

N/A

N/A

Timeout error waiting for read data to return.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

37

Chapter 3: Core Architecture

Table 3-7:

Error Signal Descriptions (Contd)

STAGE_NAME

Multi-Rank Adjust
and Checks

Write Read Sanity

Check

Stage

Code

DDR_CAL_
ERROR_1

DDR_CAL_
ERROR_0

Error

0x1

Byte

RIU Nibble

Could not find common setting across ranks

for general interconnect read latency setting
for given byte. Variance between ranks could
not be compensated with coarse taps.

0x2

Byte

RIU Nibble

DQS Gate skew between ranks for a given

byte larger than 360.

0x3

Byte

RIU Nibble

Write skew between ranks for a given byte

larger than 180. Check Write Latency Coarse
settings.

0x4

Byte

N/A

Could not decrement coarse taps enough to

limit coarse tap setting for all ranks.

0x5

Byte

N/A

Violation of maximum read latency limit.

0x1

Nibble

RIU Nibble

Read data comparison failure.

0xF

N/A

N/A

Timeout error waiting for read data to return.

0x1

Byte

Rank

Underflow of the coarse taps used for

tracking.

0x2

Byte

Rank

Overflow of the coarse taps used for tracking.

26

27

DQS Gate Tracking

DQS Gate
The XIPHY is used to capture read data from the DRAM by using the DQS strobe to clock in
read data and transfer the data to an internal FIFO using that strobe. The first step in
capturing data is to evaluate where that strobe is so the XIPHY can open the gate and allow
the DQS to clock the data into the rest of the PHY.
The XIPHY uses an internal clock to sample the DQS during a read burst and provides a
single binary value back called GT_STATUS. This sample is used as part of a training
algorithm to determine where the first rising edge of the DQS is in relation to the sampling
clock.
Calibration logic issues individual read commands to the DRAM and asserts the
clb2phy_rd_en signal to the XIPHY to open the gate which allows the sample of the DQS
to occur. The clb2phy_rd_en signal has control over the timing of the gate opening on a
DRAM-clock-cycle resolution (DQS_GATE_READ_LATENCY_RANK#_BYTE#). This signal is
controlled on a per-byte basis in the PHY and is set in the ddr_mc_pi block for use by both
calibration and the controller.
Calibration is responsible for determining the value used on a per-byte basis for use by the
controller. The XIPHY provides for additional granularity in the time to open the gate
through coarse and fine taps. Coarse taps offer 90 DRAM clock-cycle granularity (16
available) and each fine tap provides a 2.5 to 15 ps granularity for each tap (512 available).
BISC provides the number of taps for 1/4 of a DDR clock cycle by taking

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

38

Chapter 3: Core Architecture

(BISC_PQTR_NIBBLE#-BISC_ALIGN_PQTR_NIBBLE#) or
(BISC_NQTR_NIBBLE#-BISC_ALIGN_NQTR_NIBBLE#). These are used to estimate the per-tap
resolution for a given nibble.
The search for the DQS begins with an estimate of when the DQS is expected back. The total
latency for the read is a function of the delay through the PHY, PCB delay, and the
configured latency of the DRAM (CAS latency, Additive latency, etc.). The search starts three
DRAM clock cycles before the expected return of the DQS. The algorithm must start
sampling before the first rising edge of the DQS, preferably in the preamble region. DDR3
and DDR4 have different preambles for the DQS as shown in Figure 3-7.
X-Ref Target - Figure 3-7

3XOOHG+LJK

'46
3UHDPEOH

''5
''5
6WDWH

Figure 3-7:

DDR3/DDR4 DQS Preamble

The specification for the DDR3 preamble is longer (3/4 of a DRAM clock cycle) and starts
from the terminated 3-state while the DDR4 preamble is shorter (1/2 of a DRAM clock cycle)
and starts from the rail terminated level. For DDR4, the preamble training mode is enabled
during DQS gate calibration, so the DQS is driven low whenever the DQS is idle. This allows
for the algorithm to look for the same sample pattern on the DQS for DDR3/DDR4 where
the preamble is larger than half a clock cycle for both cases.
Given that DDR3 starts in the 3-state region before the burst, any accepted sample taken
can either be a 0 or 1. To avoid this result, 20 samples (in hardware) are taken for each
individual sample such that the probability of the 3-state region or noise in the sampling
clock/strobe being mistaken for the actual DQS is low. This probability is given by the
binomial probability shown in the binomial probability equation.
X = expected outcome
n= number of tries
P = probability of a single outcome
nx
n!
x
P ( X = x ) = ------------------- p ( 1 p )
x! ( n x )!

When sampling in the 3-state region the result can be 0 or 1, so the probability of 20
samples all arriving at the same value is roughly 9.5 10 -6. Figure 3-8 shows an example of
samples of a DQS burst with the expected sampling pattern to be found as the coarse taps
are adjusted. The pattern is the expected level seen on the DQS over time as the sampling
clock is adjusted in relation to the DQS.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

39

Chapter 3: Core Architecture

X-Ref Target - Figure 3-8

&DQEHDRU
([SHFWHG3DWWHUQ

;;;;
''5
''5
3UHDPEOH
7UDLQLQJ0RGH

&RDUVH
5HVROXWLRQ
&RDUVH
7DSV



0HPRU\
&ORFN&\FOH

Figure 3-8:

Example DQS Gate Samples Using Coarse Taps

Each individual element of the pattern is 20 read bursts from the DRAM and samples from
the XIPHY. The gate in the XIPHY is opened and a new sample is taken to indicate the level
seen on the DQS. If each of the samples matches with the first sample taken, the value is
accepted. If all samples are not the same value that value is marked as X in the pattern.
The X in the pattern shown is to allow for jitter and DCD between the clocks, and to deal
with uncertainty when dealing with clocks with an unknown alignment. Depending on how
the clocks line up they can resolve to all 0s, all 1s, or a mix of values, and yet the DQS
pattern can still be found properly.
The coarse taps in the XIPHY are incremented and the value recorded at each individual
coarse tap location, looking for the full pattern 00X1X0X1X0. For the algorithm to
incorrectly calculate the 3-state region as the actual DQS pattern, you would have to take 20
samples of all 0s at a given coarse tap, another 20 samples of all 0s at another, then 20
coarse taps of all 1s for the initial pattern (00X1). The probability of this occurring is
8.67 10 -19. This also only covers the initial scan and does not include the full pattern
which scans over 10 coarse taps.
While the probability is fairly low, there is a chance of coupling or noise being mistaken as
a DQS pattern. In this case, each sample is no longer random but a signal that can be fairly
repeatable. To guard against mistaking the 3-state region in DDR3 systems with the actual
DQS pulse, an extra step is taken to read data from the MPR register to validate the gate
alignment. The read path is set up by BISC for capture of data, placing the capture clock
roughly in the middle of the expected bit time back from the DRAM.
Because the algorithm is looking for a set pattern and does not know the exact alignment
of the DQS with the clock used for sampling the data, there are four possible patterns, as
shown in Figure 3-9.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

40

Chapter 3: Core Architecture

X-Ref Target - Figure 3-9

,QLWLDO6FDQ2YHU6HYHQ&RDUVH7DSV
;;;;
3RVVLEOH
3DWWHUQV

;;;;;
;;;;;;
;;;;;;;

&RDUVH
7DSV


0HPRU\
&ORFN&\FOH

Figure 3-9:

DQS Gate Calibration Possible Patterns

To speed up the pattern search, only the initial seven coarse taps are used to determine if
the starting pattern is found. This eliminates the need to search additional coarse taps if the
early samples do not match the expected result. If the result over the first coarse seven
coarse taps is not one of the four shown in Figure 3-9, the following occurs:

Coarse taps are reset to 0

clb2phy_rd_en general interconnect control is adjusted to increase by one DRAM

clock cycle

Search starts again (this is the equivalent of starting at coarse tap four in Figure 3-9)

For DDR4, if the algorithm samples 1XX or 01X this means it started the sampling too late
in relation to the DQS burst. The algorithm decreases the clb2phy_rd_en general
interconnect control and try again. If the clb2phy_rd_en is at the low limit already it
issues an error.
If all allowable values of clb2phy_rd_en for a given latency are checked and the expected
pattern is still not found, the search begins again from the start but this time the sampling
is offset by an estimated 45 using fine taps (half a coarse tap). This allows the sampling to
occur at a different phase than the initial relationship. Each time through if the pattern is
not found, the offset is reduced by half until all offset values have been exhausted.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

41

Chapter 3: Core Architecture

Figure 3-10 shows an extreme case of DCD on the DQS that would result in the pattern not
being found until an offset being applied using fine taps.
X-Ref Target - Figure 3-10


''5
''5
3UHDPEOH
7UDLQLQJ0RGH

)DLOVWR)LQG
3DWWHUQ

&RDUVH
7DSV




)LQH2IIVHW
3DWWHUQ
)RXQG



Figure 3-10:

DQS Gate Calibration Fine Offset Example

After the pattern has been found, the final coarse tap (DQS_GATE_COARSE_RANK#_BYTE#)
is set based on the alignment of the pattern previously checked (shown in Figure 3-9). The
coarse tap is set to be the last 0 seen before the 1 (3 is used to indicate an unstable region,
where multiple samples return 0 and 1) was found in the pattern shown in Figure 3-11.
During this step, the final value of the coarse tap is set between 3 to 6. If the coarse value
of 7 to 9 is chosen, the coarse taps are decremented by 4 and the general interconnect read
latency is incremented by 1, so the value falls in the 3 to 5 range instead.
X-Ref Target - Figure 3-11

''5
'46

,QLWLDO3DWWHUQ

;;;;

(VWLPDWHG5HVWRIWKH3DWWHUQ
%DVHGRQ3UHYLRXV

9DOXH&KHFNHG
2SWLRQ

;;;;;
6WDUW)LQH6HDUFK

2SWLRQ

;;;;;
;;;;;
6WDUW)LQH6HDUFK

Figure 3-11:

DQS Gate Coarse Setting Before Fine Search

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

42

Chapter 3: Core Architecture

From this point the clb2phy_rd_en (DQS_GATE_READ_LATENCY_RANK#_BYTE#) is
increased by 1 to position the gate in the final location before the start of the fine sweep.
This is done to ensure the proper timing of the gate in relation to the full DQS burst during
normal operation. Because this is sampling the strobe with another signal it can have jitter
in relation to one another.
For example, when they are lined up taking multiple samples it might give you a different
result each time as a new sample is taken. The fine search begins in an area where all
samples returned a 0 so it is relatively stable, as shown in Figure 3-12. The fine taps are
incremented until a non-zero value is returned (which indicates the left edge of the
unstable region) and that value recorded as shown in Figure 3-14
(DQS_GATE_FINE_LEFT_RANK#_BYTE#).
X-Ref Target - Figure 3-12

6WDEOH5HJLRQ

'46

6DPSOH&ORFN

Figure 3-12:

DQS Gate Fine Adjustment, Sample a 0

The fine taps are then incremented until all samples taken return a 1, as shown in
Figure 3-13. This is recorded as the right edge of the uncertain region as shown in
Figure 3-14 (DQS_GATE_FINE_RIGHT_RANK#_BYTE#).
X-Ref Target - Figure 3-13

6WDEOH5HJLRQ

'46

6DPSOH&ORFN

Figure 3-13:

DQS Gate Fine Adjustment, Sample a 1

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

43

Chapter 3: Core Architecture

X-Ref Target - Figure 3-14

/HIWRI1RLVH
5HJLRQ

5LJKWRI1RLVH
5HJLRQ

'46

'46

6DPSOH&ORFN

6DPSOH&ORFN

Figure 3-14:

DQS Gate Fine Adjustment, Uncertain Region

The final fine tap is computed as the midpoint of the uncertain region, (right left)/2 + left
(DQS_GATE_FINE_CENTER_RANK#_BYTE#). This ensures optimal placement of the gate in
relation to the DQS. For simulation, speeding up a faster search is implemented for the fine
tap adjustment. This is performed by using a binary search to jump the fine taps by larger
values to quickly find the 0 to 1 transition.
For multi-rank systems, separate control exists in the XIPHY for each rank and every rank
can be trained separately for coarse and fine taps. After calibration is complete,
adjustments are made so that for each byte, the clb2phy_rd_en
(DQS_GATE_READ_LATENCY_RANK#_BYTE#) value for a given byte matches across all ranks.
The coarse taps are incremented/decremented accordingly to adjust the timing of the gate
signal to match the timing found in calibration. If a common clb2phy_rd_en setting
cannot be found for a given byte across all ranks, an error is asserted.

DQS Gate Sanity Check

After completion of DQS gate calibration for all bytes in a given rank, read return timing is
calculated and 10 read bursts with gaps between them are issued. Logic then checks that
the FIFO is read 10 times. There is no data checking at this stage. This is just a basic
functional check of the FIFO read port control logic, which is configured using the DQS gate
calibration results. Read return timing is updated after DQS gate calibration for each rank.
The final setting is determined by largest DQS gate delay out of all DQS lanes and all ranks.

Write Leveling
The DDR3/DDR4 SDRAM memory modules use a fly-by topology on clocks, address,
commands, and control signals to improve signal integrity. This topology causes a skew
between DQS and CK at each memory device on the module. Write leveling is a feature in
DDR3/DDR4 SDRAMs that allows the controller to adjust each write DQS phase
independently with respect to the clock (CK) forwarded to the DDR3/DDR4 device to
compensate for this skew and meet the tDQSS specification [Ref 1].

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

44

Chapter 3: Core Architecture

During write leveling, DQS is driven by the FPGA memory interface and DQ is driven by the
DDR3/DDR4 SDRAM device to provide feedback. To start write leveling, an MRS command
is sent to the DRAM to enable the feedback feature, while another MRS command is sent to
disable write leveling at the end. Figure 3-15 shows the block diagram for the write leveling
implementation.
X-Ref Target - Figure 3-15

)3*$



WRVHULDOL]HU

2'(/$<
6HWWR
''5''56'5$0

3//&ORFN

&RDUVH'HOD\LQ
&ORFN*HQ6HWWR



WRVHULDOL]HU

&.
&.

'

'46
'46

2'(/$<

)(('%$&.
:ULWH'DWD

3//&ORFN

WRVHULDOL]HU

2'(/$<

:5/9/B02'(

&RDUVH'HOD\LQ
&ORFN*HQIRU:ULWH
/HYHOLQJ

'4

:/B75$,1
$GMXVW'46
'4'HOD\
XQWLOWR
WUDQVLWLRQ

,),)2

5(*8/$5

'H
VHULDOL]HU
&DSWXUH:UOYO
'4)HHGEDFN

Figure 3-15:

'46

Write Leveling Block Diagram

The XIPHY is set up for write leveling by setting various attributes in the RIU. WL_TRAIN is
set to decouple the DQS and DQ when driving out the DQS. This allows the XIPHY to
capture the returning DQ from the DRAM. Because the DQ is returned without the returning
DQS strobe for capture, the RX_GATE is set to 0 in the XIPHY to disable DQS gate operation.
While the write leveling algorithm acts on a single DQS at a time, all the XIPHY bytes are set
up for write leveling to ensure there is no contention on the bus for the DQ.
DQS is delayed with ODELAY and coarse delay (WL_DLY_CRSE[12:9] applies to all bits in a
nibble) provided in the RIU WL_DLY_RNKx register. The WL_DLY_FINE[8:0] location in the
RIU is used to store the ODELAY value for write leveling for a given nibble (used by the
XIPHY when switching ranks).

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

45

Chapter 3: Core Architecture

A DQS train of pulses is output by the FPGA to the DRAM to detect the relationship of CK
and DQS at the DDR3/DDR4 memory device. DQS is delayed using the ODELAY and coarse
taps in unit tap increments until a 0 to 1 transition is detected on the feedback DQ input.
A single typical burst length of eight pattern is first put out on the DQS (four clock pulses),
followed by a gap, and then 100 bursts length of eight patterns are sent to the DRAM
(Figure 3-16).
The first part is to ensure the DRAM updates the feedback sample on the DQ being sent
back, while the second provides a clock that is used by the XIPHY to clock into the XIPHY
the level seen on the DQ. Sampling the DQ while driving the DQS helps to avoid ringing on
the DQS at the end of a burst that can be mistaken as a clock edge by the DRAM.
X-Ref Target - Figure 3-16

%/%XUVWVRI'46

%/%XUVWRI'46

&.&.

''5'46
'46

6DPSOH'42QFH*R2XW

Figure 3-16:

Write Leveling DQS Bursts

To avoid false edge detection around the CK negative edge due to jitter, the DQS delays the
entire window to find the large stable 0 and 1 region (Stable 0 or 1 indicates all samples
taken return the same value). Check that you are to the left of this stable 1 region as the
right side of this region is the CK negative edge being captured with the DQS, as shown in
Figure 3-17.
X-Ref Target - Figure 3-17

6WDEOH5HJLRQ

1RLVH
5HJLRQ

6WDEOH5HJLRQ

1RLVH
5HJLRQ

6WDEOH5HJLRQ

&.
&.

'46
'46

Figure 3-17:

Write Leveling Regions

Write leveling is performed in the following two steps:

1. Find the transition from 0 to 1 using coarse taps and ODELAY taps (if needed).
During the first step, look for a static 0 to be returned from all samples taken. This
means 64 samples were taken and it is certain the data is a 0. Record the coarse tap
setting and keep incrementing the coarse tap.

If the algorithm receives another stable 0, update the setting

(WRLVL_COARSE_STABLE0_RANK_BYTE) and continue.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

46

Chapter 3: Core Architecture

If the algorithm receives a non-zero result (noise) or a stable 1 reading

(WRLVL_COARSE_STABLE0_RANK_BYTE), the search has gone too far and the delay is
backed up to the last coarse setting that gave a stable 0. This reference allows you
to know the algorithm placed the coarse taps to the left of the transition desired.
If the algorithm never sees a transition from a stable 0 to the noise or stable 1
using the coarse taps, the ODELAY of the DQS is set to an offset value (first set at
45, WRLVL_ODELAY_INITIAL_OFFSET_BYTE) and the coarse taps are checked again
from 0. Check for the stable 0 to stable 1 transition (the algorithm might need
to perform this if the noise region is close to 90 or there is a large amount of DCD).
If the transition is still not found, the offset is halved and the algorithm tries again.
The final offset value used is stored at WRLVL_ODELAY_LAST_OFFSET_RANK_BYTE.
Because the algorithm is aligning the DQS with the nearest clock edge the coarse
tap sweep is limited to five, which is 1.25 clock cycles. The final coarse setting is
stored at WRLVL_COARSE_STABLE0_RANK_BYTE.

2. Find the center of the noise region around that transition from 0 to 1 using ODELAY
taps.
The second step is to sweep with ODELAY taps and find both edges of the noise region
(WRLVL_ODELAY_STABLE0_RANK_BYTE, WRLVL_ODELAY_STABLE1_RANK_BYTE while
WRLVL_ODELAY_CENTER_RANK_BYTE holds the final value). The number of ODELAY taps
used is determined by the initial alignment of the DQS and CK and the size of this noise
region as shown in Figure 3-18.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

47

Chapter 3: Core Architecture

X-Ref Target - Figure 3-18

&RDUVH
7DS

&.
&.

'46
'46

 &RDUVH

 &RDUVH

 &RDUVH
5HTXLUHG
2'(/$<PD[

&RDUVH
7DS

&.
&.

'46
'46
5HTXLUHG
2'(/$<
PLQ

Figure 3-18:

Worst Case ODELAY Taps (Maximum and Minimum)

After the final ODELAY setting is found, the value of ODELAY is loaded in the RIU in the
WL_DLY_RNKx[8:0] register. This value is also loaded in the ODELAY register for the DQ and
the DM to match the DQS. If any deskew has been performed on the DQS/DQ/DM when
reaching this point (multi-rank systems), the deskew information is preserved and the offset
is applied.
The lowest ODELAY value is stored at WRLVL_ODELAY_LOWEST_COMMON_BYTE, which is
used to preserve the WRLVL element with the deskew portion of ODELAY for a given byte.
During normal operation in a multi-rank system, the XIPHY is responsible for loading the
ODELAY with the value stored for a given rank.
After write leveling, the MPR command is sent to the DRAM to disable the write leveling
feature, the WL_TRAIN is set back to the default off setting, and the DQS gate is turned
back on to allow for capture of the DQ with the returning strobe DQS.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

48

Chapter 3: Core Architecture

Read DQS Deskew and Centering

After the gate has been trained and Write Leveling has completed, the next step is to ensure
reliable capture of the read data with the DQS. This stage of Read Leveling is divided into
two phases, Per-Bit Deskew and Read DQS Centering. Read DQS Centering utilizes the DDR3
and DDR4 Multi Purpose Register (MPR). The MPR contains a pattern that can be used to
train the read DQS and DQ for read capture. While DDR4 allows for several patterns, DDR3
only has a single repeating pattern available.
To perform per-bit deskew, a non-repeating pattern is useful to deal with or diagnose cases
of extreme skew between different bits in a byte. Because this is limited by the DDR3 MPR
pattern, a long pattern is first written to the DRAM and then read back to perform per-bit
deskew (only done on the first rank of a multi-rank system). When per-bit deskew is
complete, the simple repeating pattern available through both DDR3 and DDR4 MPR is
used to center the DQS in the DQ read eye.
The XIPHY provides separate delay elements (2.5 to 15 ps per tap, 512 total) for the DQS to
clock the rising and falling edge DQ data (PQTR for rising edge, NQTR for falling edge) on
a per-nibble basis (four DQ bits per PQTR/NQTR). This allows the algorithm to center the
rising and falling edge DQS strobe independently to ensure more margin when dealing with
DCD. The data captured in the PQTR clock domain is transferred to the NQTR clock domain
before being sent to the read FIFO and to the general interconnect clock domain.
Due to this transfer of clock domains, the PQTR and NQTR clocks must be roughly 180 out
of phase. This relationship between the PQTR/NQTR clock paths is set up as part of the BISC
start-up routine, and thus calibration needs to maintain this relationship as part of the
training (BISC_ALIGN_PQTR, BISC_ALIGN_NQTR, BISC_PQTR, BISC_NQTR).

Read Per-bit Deskew

First, write 0x00 to address 0x000. Because the write latency calibration has not yet been
performed, the address DQ is held for eight clock cycles before and after the expected write
latency is expected. The DQS toggles extra time before/after is shown in Figure 3-19. This
ensures the data is written to the DRAM if the burst does not occur at the correct time the
DRAM expects it.
X-Ref Target - Figure 3-19

$GGUHVV [

'46
'46





























[

'4

Figure 3-19:

Per-bit Deskew Write 0x00 to Address 0x000

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

49

Chapter 3: Core Architecture

Next, write 0xFF to a different address to allow for back-to-back reads (Figure 3-20). For
DDR3 address 0x008 is used, while for DDR4 address 0x000 and bank group 0x1 is used. At
higher frequencies, DDR4 requires a change in the bank group to allow for back-to-back
bursts of eight.
X-Ref Target - Figure 3-20

'46
'46





























[))

'4

Figure 3-20:

Per-bit Deskew Write 0xFF to Other Address

After the data is written, back-to-back reads are issued to the DRAM to perform per-bit
deskew (Figure 3-21).
X-Ref Target - Figure 3-21

$GGUHVV [

$GGUHVV [

$GGUHVV [

'46
'46


'4

[

Figure 3-21:

















[))









[

Per-bit Deskew Back-to-Back Reads (No Gaps)

Using this pattern each bit in a byte is left edge aligned with the DQS strobe (PQTR/NQTR).
More than a bit time of skew can be seen and corrected as well.
RECOMMENDED: In general, a bit time of skew between bits is not ideal. Ensure the DDR3/DDR4 trace
matching guidelines within DQS byte are met. See PCB Guidelines for DDR3, page 78 and PCB
Guidelines for DDR4, page 78.

At the start of deskew, the PQTR/NQTR are decreased down together until one of them hits
0 (to preserve the initial relationship setup by BISC). Next, the data for a given bit is checked
for the matching pattern. Only the rising edge data is checked for correctness. The falling
edge comparison is thrown away to allow for extra delay on the PQTR/NQTR relative to the
DQ.
While in the ideal case, the PQTR/NQTR are edge aligned with the DQ when the delays are
set to 0. Due to extra delay in the PQTR/NQTR path, the NQTR might be pushed into the
next burst transaction at higher frequencies and so it is excluded from the comparison
(Figure 3-22 through Figure 3-23). More of the rising edge data of a given burst would need
to be discarded to deal with more than a bit time of skew. If the last part of the burst was
not excluded, the failure would cause the PQTR/NQTR to be pushed instead of the DQ
IDELAY.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

50

Chapter 3: Core Architecture

X-Ref Target - Figure 3-22

3475
1475

[))

[

'4

[

$%XUVWRI


Figure 3-22:

Per-bit Deskew Delays Set to 0 (Ideal)

X-Ref Target - Figure 3-23

3475
1475

'4

[))

[

[

$%XUVWRI


([FOXGHIDOOLQJHGJHGDWD

Figure 3-23:

Per-bit Deskew Delays Set to 0

If the pattern is found, the given IDELAY on that bit is incremented by 1, then checked again.
If the pattern is not seen, the PQTR/NQTR are incremented by 1 and the data checked again.
The algorithm checks for the passing and failing region for a given bit, adjusting either the
PQTR/NQTR delays or the IDELAY for that bit.
To guard against noise in the uncertain region, the passing region is defined by a minimum
window size (10), hence the passing region is not declared as found unless the PQTR/NQTR
are incremented and a contiguous region of passing data is found for a given bit. All of the
bits are cycled through to push the PQTR/NQTR out to align with the latest bit in a given
nibble. Figure 3-24 through Figure 3-27 show an example of the PQTR/NQTR and various
bits being aligned during the deskew stage.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

51

Chapter 3: Core Architecture

X-Ref Target - Figure 3-24

3475
1475

'4

'4

'4
(DUO\





)

'4
/DWH

Figure 3-24:


Per-bit Deskew Initial Relationship Example

The algorithm takes the result of each bit at a time and decides based on the results of that
bit only. The common PQTR/NQTR are delayed as needed to align with each bit, but is not
decremented. This ensures it gets pushed out to the latest bit.
X-Ref Target - Figure 3-25

3475
1475

'4

'4

'4
(DUO\

'4
/DWH

)
Figure 3-25:

'4'HOD\HGWR
DOLJQZLWK'46

'4'HOD\HGWR
DOLJQZLWK'46

'4'HOD\HGWR
DOLJQZLWK'46


Per-bit Deskew Early Bits Pushed Out

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

52

Chapter 3: Core Architecture

X-Ref Target - Figure 3-26

3475
1475

'4

'4

'4
(DUO\

'4
/DWH

Figure 3-26:




'46'HOD\HG
WRDOLJQZLWK'4

Per-bit Deskew PQTR/NQTR Delayed to Align with Late Bit

When completed, the PQTR/NQTR are pushed out to align with the latest DQ bit
(RDLVL_DESKEW_PQTR_nibble, RDLVL_DESKEW_NQTR_nibble), but DQ bits calibrated first
might have been early as shown in the example. Accordingly, all bits are checked once again
and aligned as needed (Figure 3-27).
X-Ref Target - Figure 3-27

3475
1475

'4

'4

'4
(DUO\

'4
/DWH

Figure 3-27:

'4'HOD\HGWR
DOLJQZLWK'46

'4'HOD\HGWR
DOLJQZLWK'46

'4'HOD\HGWR
DOLJQZLWK'46


Per-bit Deskew Push Early Bits as Needed to Align

The final DQ IDELAY value from deskew is stored at RDLVL_DESKEW_IDELAY_Byte_Bit.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

53

Chapter 3: Core Architecture

Read DQS Centering

When the data is deskewed, the PQTR/NQTR delays need to be adjusted to center in the
aggregate data valid window for a given nibble. The DRAM MPR register is used to provide
the data pattern for centering. Therefore, the pattern changes each bit time and does not
rely on being written into the DRAM first, eliminating some uncertainty. The simple clock
pattern is used to allow for the same pattern checking for DDR3 and DDR4. Gaps in the
reads to the DRAM are used to stress the initial centering to incorporate the effects of ISI on
the first DQS pulse as shown in Figure 3-28.
X-Ref Target - Figure 3-28

'46
'46

'4
'4

Figure 3-28:

Gap between MPR Reads

To properly account for jitter on the data and clock returned from the DRAM, multiple data
samples are taken at a given tap value. 64 read bursts are used in hardware while five are
used in simulation. More samples mean finding the best alignment in the data valid
window.
Given that the PHY has two capture strobes PQTR/NQTR that need to be centered
independently yet moved together, calibration needs to take special care to ensure the
clocks stay in a certain phase relationship with one another.
The data and PQTR/NQTR delays start with the value found during deskew. Data is first
delayed with IDELAY such that both the PQTR and NQTR clocks start out just to the left of
the data valid window for all bits in a given nibble so the entire read window can be scanned
with each clock (Figure 3-29, RDLVL_IDELAY_VALUE_Rank_Byte_Bit). Scanning the window
with the same delay element and computing the center with that delay element helps to
minimize uncertainty in tap resolution that might arise from using different delay lines to
find the edges of the read window.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

54

Chapter 3: Core Architecture

X-Ref Target - Figure 3-29

3475

1475

2ULJLQDO'4

)


'4


)

)


'HOD\WKHGDWDXVLQJ,'(/$<

Figure 3-29:

Delay DQ Thus PQTR and NQTR in Failing Region

At the start of training, the PQTR/NQTR and data are roughly edge aligned, but because the
pattern is different from the deskew step the edge might have changed a bit. Also, during
deskew the aggregate edge for both PQTR/NQTR is found while you want to find a separate
edge for each clock.
After making sure both PQTR/NQTR start outside the data valid region, the clocks are
incremented to look for the passing region (Figure 3-30). Rising edge data is checked for
PQTR while falling edge data is checked for NQTR, with a separate check being kept to
indicate where the passing region/falling region is for each clock.
X-Ref Target - Figure 3-30

3475

1475

'4

Figure 3-30:

PQTR and NQTR Delayed to Find Passing Region (Left Edge)

When searching for the edge, a minimum window size of 10 is used to guarantee the noise
region has been cleared and the true edge is found. The PQTR/NQTR delays are increased
past the initial passing point until the minimum window size is found before the left edge
is declared as found. If the minimum window is not located across the entire tap range for
either clock, an error is asserted.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

55

Chapter 3: Core Architecture

After the left edge is found (RDLVL_PQTR_LEFT_Rank_Nibble,
RDLVL_NQTR_LEFT_Rank_Nibble), the right edge of the data valid window can be searched
starting from the left edge + minimum window size. A minimum window size is not used
when searching for the right edge, as the starting point already guarantees a minimum
window size has been met.
Again, the PQTR/NQTR delays are incremented together and checked for error
independently to keep track of the right edge of the window. Because the data from the
PQTR domain is transferred into the NQTR clock domain in the XIPHY, the edge for NQTR is
checked first, keeping track of the results for PQTR along the way (Figure 3-31).
When the NQTR edge is located, a flag is checked to see if the PQTR edge is found as well.
If the PQTR edge was not found, the PQTR delay continues to search for the edge, while the
NQTR delay stays at its right edge (RDLVL_PQTR_RIGHT_Rank_Nibble,
RDLVL_NQTR_RIGHT_Rank_Nibble). For simulation, the right edge detection is sped up by
having the delays adjusted by larger than one tap at a time.
X-Ref Target - Figure 3-31

34755LJKW

3475

14755LJKW

1475

'4

/HIW(GJH0LQLPXP
:LQGRZ6L]H

Figure 3-31:

PQTR and NQTR Delayed to Find Failing Region (Right Edge)

After both rising and falling edge windows are found, the final center point is calculated
based on the left and right edges for each clock. The final delay for each clock
(RDLVL_PQTR_CENTER_Rank_Nibble, RDLVL_NQTR_CENTER_Rank_Nibble) is computed by:
left + ((right left)/2).
For multi-rank systems deskew only runs on the first rank, while read DQS centering using
the PQTR/NQTR runs on all ranks. After calibration is complete for all ranks, for a given DQ
bit the IDELAY is set to the center of the range of values seen for all ranks
(RDLVL_IDELAY_FINAL_BYTE_BIT). The PQTR/NQTR final value is also computed based on
the range of values seen between all of the ranks (RDLVL_PQTR_CENTER_FINAL_NIBBLE,
RDLVL_NQTR_CENTER_FINAL_NIBBLE).

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

56

Chapter 3: Core Architecture

IMPORTANT: For multi-rank systems, there must be overlap in the read window computation. Also,

there is a limit in the allowed skew between ranks, see the PCB Guidelines for DDR3 in Chapter 4 and
PCB Guidelines for DDR4 in Chapter 4.

Read Sanity Check

After read DQS centering but before Write DQS-to-DQ, a check of the data is made to
ensure the previous stage of calibration did not inadvertently leave the alignment of the
read path in a bad spot. A single MPR read command is sent to the DRAM, and the data is
checked against the expected data across all bytes before continuing.

Write DQS-to-DQ
Note: The calibration step is only enabled for the first rank in a multi-rank system.
The DRAM requires the write DQS to be center-aligned with the DQ to ensure maximum
write margin. Initially the write DQS is set to be roughly 90 out of phase with the DQ using
the XIPHY TX_DATA_PHASE set for the DQS. The TX_DATA_PHASE is an optional per-bit
adjustment that uses a fast internal XIPHY clock to generate a 90 offset between bits. The
DQS and DQ ODELAY are used to fine tune the 90 phase alignment to ensure maximum
margin at the DRAM.
A simple clock pattern of 10101010 is used initially because the write latency has not yet
been determined. Due to fly-by routing on the PCB/DIMM module, the command to data
timing is unknown until the next stage of calibration. Just as in read per-bit deskew when
issuing a write to the DRAM, the DQS and DQ toggles for eight clock cycles before and after
the expected write latency. This is used to ensure the data is written into the DRAM even if
the command-to-write data relationship is still unknown. Write DQS-to-DQ is completed in
two stages, per-bit deskew and DQS centering.

Write DQS-to-DQ Per-bit Deskew

Initially all DQ bits have the same ODELAY setting based on the write leveling results, but
the ODELAY for each bit might need to be adjusted to account for skew between bits.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

57

Chapter 3: Core Architecture

Figure 3-32 shows an example of the initial timing relationship between a write DQS and
DQ.
X-Ref Target - Figure 3-32

7;B&/.B3+$6(VHWWRIRU'46
7;B&/.B3+$6(VHWWRIRU'4
:ULWH'46

'4

'4

'4Q

Figure 3-32:

Initial Write DQS and DQ with Skew between Bits

1. Set TX_DATA_PHASE to 1 for DQ to add the 90 shift on the DQS relative to the DQ for
a given byte (Figure 3-33). The data read back on some DQ bits are 10101010 while
other DQ bits might be 01010101.
X-Ref Target - Figure 3-33

7;B&/.B3+$6(VHWWRIRU'46
7;B&/.B3+$6(VHWWRIRU'4
:ULWH'46

'4

'4

'4Q

Figure 3-33:

Add 90 Shift on DQ

2. If all the data for the byte does not match the expected data pattern, increment DQS
ODELAY one tap at a time until the expected data pattern is found on all bits and save
the delay as WRITE_DQS_TO_DQ_DESKEW_DELAY_Byte (Figure 3-34). As the DQS
ODELAY is incremented, it moves away from the edge alignment with the CK. The
deskew data is the inner edge of the data valid window for writes.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

58

Chapter 3: Core Architecture

X-Ref Target - Figure 3-34

7;B&/.B3+$6(VHWWRIRU'46
7;B&/.B3+$6(VHWWRIRU'4
:ULWH'46

'4

'4

'4Q

2'(/$<VKLIWIRU'46
GTVBGHVNHZ

Figure 3-34:

Increment Write DQS ODELAY until All Bits Captured with Correct Pattern

3. Increment each DQ ODELAY until each bit fails to return the expected data pattern (the
data is edge aligned with the write DQS, Figure 3-35).
X-Ref Target - Figure 3-35

7;B&/.B3+$6(VHWWRIRU'46
7;B&/.B3+$6(VHWWRIRU'4
:ULWH'46

'4

'4

'4Q

2'(/$<VKLIWIRU'4

2'(/$<VKLIWIRU'4

Figure 3-35:

Per-bit Write Deskew

4. Return the DQ to the original position at the 0 shift using the TX_DATA_PHASE. Set DQS
ODELAY back to starting value (Figure 3-36).

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

59

Chapter 3: Core Architecture

X-Ref Target - Figure 3-36

7;B&/.B3+$6(VHWWRIRU'46
7;B&/.B3+$6(VHWWRIRU'4
:ULWH'46

'4

'4

'4Q

Figure 3-36:

DQ Returned to Approximate 90 Offset with DQS

Write DQS-to-DQ Centering

After per-bit write deskew, the next step is to determine the relative center of the DQS in the
write data eye and compensate for any error in the TX_DATA_PHASE 90 offset.
1. Issue a set of write and read bursts with the data pattern "10101010" and check the read
data. Just as in read write per-bit deskew when issuing a write to the DRAM, the DQS and
DQ toggles for eight clock cycles before and after the expected write latency. This is
used to ensure the data is written into the DRAM even if the command-to-write data
relationship is still unknown.
2. Increment DQ ODELAY taps together until the read data pattern on all DQ bits changes
from the expected data pattern 10101010. The amount of delay required to find the
failing point is saved as WRITE_DQS_TO_DQ_PRE_ADJUST_MARGIN_LEFT_BYTE as shown
in Figure 3-37.
X-Ref Target - Figure 3-37

:ULWH
'46

'4>Q@

'4>Q@
'HOD\HG


)

Figure 3-37:

)



)

Write DQS Centering Left Edge

3. Return DQ ODELAY taps to their original value.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

60

Chapter 3: Core Architecture

4. Find the right edge of the window by incrementing the DQS ODELAY taps until the data
changes from the expected data pattern "10101010." The amount of delay required to
find the failing point is saved as
WRITE_DQS_TO_DQ_PRE_ADJUST_MARGIN_RIGHT_BYTE as shown in Figure 3-38.
X-Ref Target - Figure 3-38

:ULWH
'46

:ULWH'46
'HOD\HG

'4>Q@

Figure 3-38:

Write DQS Centering Right Edge

5. Calculate the center tap location for the DQS ODELAY, based on deskew and left and
right edges.
New DQS delay = deskew [(dly0 dly1)/2]
Where dly0 is the original DQS delay + left margin and dly1 is the original DQS delay +
right margin.
The final ODELAY tap setting for DQS is indicated by
WRITE_DQS_TO_DQ_DQS_ODELAY_BYTE while the DQ is WRITE_DQS_TO_DQ_DQ_ODELAY.
The final computed left and right margin are WRITE_DQS_TO_DQ _MARGIN_LEFT_BYTE and
WRITE_DQS_TO_DQ _MARGIN_RIGHT_BYTE.

Write DQS-to-DM
Note: The calibration step is only enabled for the first rank in a multi-rank system.
During calibration the Data Mask (DM) signals are not used, they are deasserted during any
writes before/after the required amount of time to ensure they have no impact on the
pattern being written to the DRAM. If the DM signals are not used, this step of calibration
is skipped.
Two patterns are used to calibrate the DM pin. The first pattern is written to the DRAM with
the DM deasserted, ensuring the pattern is written to the DRAM properly. The second
pattern overwrites the first pattern at the same address but with the DM asserted in a
known position in the burst, as shown in Figure 3-40.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

61

Chapter 3: Core Architecture

Because this stage takes place before Write Latency Calibration when issuing a write to the
DRAM, the DQS and DQ/DM toggles for eight clock cycles before and after the expected
write latency. This is used to ensure the data is written into the DRAM even though the
command-to-write data relationship is still unknown.
X-Ref Target - Figure 3-39

)LUVW:ULWH

'46

'4

B

'0
''5

'0
''5

Figure 3-39:

DM Base Data Written

X-Ref Target - Figure 3-40

6HFRQG:ULWH

'46

'4

%%%%%%%%B%%%%%%%%

'0

'0''5
'0''5

Figure 3-40:

DM Asserted

The read back data for any given nibble is "5B5B_5B5B," where the location of the "5" in the
burst indicates where the DM is asserted. Because the data is constant during this step, the
DQS-to-DQ alignment is not stressed. Only the DQS-to-DM is checked as the DQS and DM
phase relationship is adjusted with each other.

Write DQS-to-DM Per-Bit Deskew

This step is similar to Write DQS-to-DQ Per-Bit Deskew but involves the DM instead of the
DQ bits. See Write DQS-to-DQ, page 57 for an in-depth overview of the algorithm. The DQS
ODELAY value used to edge align the DQS with the DM is stored as
WRITE_DQS_TO_DM_DESKEW_BYTE. The ODELAY value for the DM is stored as
WRITE_DQS_TO_DM_DM_ODELAY_BYTE.

Write DQS-to-DM Centering

This step is similar to Write DQS-to-DQ Centering but involves the DM instead of the DQ
bits. See Write DQS-to-DQ, page 57 for an in-depth overview of the algorithm. The tap
value DM was set at to find the left edge is saved as
WRITE_DQS_TO_DM_PRE_ADJUST_MARGIN_LEFT_BYTE. The tap value DQS was set at to find
the right edge is saved as WRITE_DQS_TO_DM_PRE_ADJUST_MARGIN_RIGHT_BYTE.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

62

Chapter 3: Core Architecture

The final DM margin is stored at WRITE_DQS_TO_DM_MARGIN_LEFT_BYTE and
WRITE_DQS_TO_DM_MARGIN_RIGHT_BYTE.
Because the DQS ODELAY can only hold a single value, compute the aggregate smallest
left/right margin between the DQ and DM. The DQS ODELAY value is set in the middle of
this aggregate window. The final values of the DQS and DM can be found at
WRITE_DQS_ODELAY_FINAL and WRITE_DM_ODELAY_FINAL.

Write Latency Calibration

Write latency calibration is required to align the write DQS to the correct CK edge. During
write leveling, the write DQS is aligned to the nearest rising edge of CK. However, this might
not be the edge that captures the write command. Depending on the interface type
(UDIMM, RDIMM, or component), the DQS could be up to three CK cycles later than, or
aligned to the CK edge that captures the write command.
Write latency calibration makes use of the coarse tap in the WL_DLY_RNK of the XIPHY for
adjusting the write latency on a per byte basis. Write leveling uses up a maximum of three
coarse taps of the XIPHY delay to ensure each write DQS is aligned to the nearest clock
edge. Memory Controller provides the write data 1TCK early to the PHY, which is then
delayed by write leveling up to one memory clock cycle. This means for the zero PCB delay
case of a typical simulation the data would be aligned at the DRAM without additional delay
added from write calibration.
Write latency calibration can only account for early data, because in the case where the data
arrives late at the DRAM there is no push back on the controller to provide the data earlier.
With 16 XIPHY coarse taps available (each tap is 90), four memory clock cycles of shift are
available in the XIPHY with one memory clock used by write leveling. This leaves three
memory clocks of delay available for write latency calibration.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

63

Chapter 3: Core Architecture

Figure 3-41 shows the calibration flow to determine the setting required for each byte.
X-Ref Target - Figure 3-41

6WDUW:ULWH/DWHQF\&DOLEUDWLRQ
%\WH 

5HDG&RDUVH7DSIURP;,3+<IRU&XUUHQW
%\WH

:ULWH3DWWHUQWR$GGUHVV[

5HDGIURP$GGUHVV[

12

12
0D[&RDUVH
7DSV"

'DWD0DWFK"

&RDUVH &RDUVH

<(6

<(6

(5525

12
$OO%\WHV'RQH"

%\WH %\WH

<(6
:ULWH/DWHQF\
&DOLEUDWLRQ
'RQH

Figure 3-41:

Write Latency Calibration Flow

The write DQS for the write command is extended for longer than required to ensure the
DQS is toggling when the DRAM expects it to clock in the write data. A specific data pattern
is used to check when the correct data pattern gets written into the DRAM, as shown in
Figure 3-42.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

64

Chapter 3: Core Architecture

In the example at the start of write latency calibration for the given byte. the target write
latency falls in the middle of the data pattern. The returned data would be
55AA9966FFFFFFFF rather than the expected FF00AA5555AA9966. The write DQS and data
are delayed using the XIPHY coarse delay and the operation is repeated, until the correct
data pattern is found or there are no more coarse taps available. After the pattern is found,
the amount of coarse delay required is indicated by
WRITE_LATENCY_CALIBRATION_COARSE_Rank_Byte.
X-Ref Target - Figure 3-42

7DUJHW
F:/
&.
&.

'46
'46

'4

&RDUVH

[

))



$$





$$





[))
'DWD5HDG%DFN$$))))))))

'46
'46

&RDUVH

'4

[

))



$$





$$





[))

'DWD5HDG%DFN$$$$))))
'46
'46

'4

&RDUVH

[

))



$$





$$





[))

'DWD5HDG%DFN))$$$$

Figure 3-42:

Write Latency Calibration Alignment Example

If the data pattern is not found for a given byte, the data pattern found is checked to
see if the data at the maximum delay available still arrives too early (indicating not
enough adjustment was available in the XIPHY to align to the correct location) or if the
first burst with no extra delay applied is already late (indicating at the start the data
would need to be pulled back). The following data pattern is checked:

Expected pattern on a per-nibble basis: F0A55A96

Late Data Comparison: 00F0AA55A

Early Data Comparison: A55A96FF, 5A96FFFF, 96FFFFFF

If neither of these cases holds true, an attempt is made to try to reclassify the error as
either a write or a read failure. A single write burst is sent to the DRAM followed by 20
read bursts. The data from the first read burst is stored for comparison with the
remaining 19 read bursts.

If all the read data matches, the error is classified as a write failure.

If the data does not match, it is marked as a read failure.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

65

Chapter 3: Core Architecture

Write/Read Sanity Check

After Write DQS-to-DQ, a check of the data is made to ensure the previous stage of
calibration did not inadvertently leave the write or read path in a bad spot. A single write
burst followed by a single read command to the same location is sent to the DRAM, and the
data is checked against the expected data across all bytes before continuing. During this
step, the expected data pattern as seen on a nibble is 937EC924.

Read DQS Centering (Complex)

Note: Only enabled for data rates above 1,600 Mb/s.
Complex data patterns are used for advanced read DQS centering for memory systems to
improve read timing margin. Long and complex data patterns on both the victim and
aggressor DQ lanes impact the size and location of the data eye. The objective of the
complex calibration step is to generate the worst case data eye on each DQ lane so that the
DQS signal can be aligned, resulting in good setup/hold margin during normal operation
with any work load.
There are two long data patterns stored in a block RAM, one for a victim DQ lane, and an
aggressor pattern for all other DQ lanes. These patterns are used to generate write data, as
well as expected data on reads for comparison and error logging. Each pattern consists of
157 8-bit chunks or BL8 bursts.
Each DQ lane of 1-byte takes a turn at being the victim. An RTL state machine automatically
selects each DQ lane in turn, MUXing the victim or aggressor patterns to the appropriate
DQ lanes, issues the read/write transactions, and records errors. The victim pattern is only
walked across the DQ lanes of the selected byte to be calibrated, and all other DQ lanes
carry the aggressor pattern, including all lanes in un-selected bytes if there is more than
1-byte lane.
Similar steps to those described in Read DQS Centering are performed, with the PQTR/
NQTR starting out at the left edge of the simple window found previously. The complex
pattern is written and read back. All bits in a nibble are checked to find the left edge of the
window, incrementing the bits together as needed or the PQTR/NQTR to find the aggregate
left edge. After the left and right edges are found, it steps through the entire data eye.

Read VREF Calibration

Note: The calibration step is only enabled for the first rank in a multi-rank system.
In DDR4, the read VREF calibration is enabled by default. Before the read V REF calibration,
the default read V REF values in Table 24-29 are used in earlier stages of calibration.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

66

Chapter 3: Core Architecture

During read VREF calibration, the calibration logic looks for the read VREF value with the
maximum eye opening per data byte lane. In UltraScale architecture, each data byte lane
can be programmed to 73 possible V REF values. The VREF search performs five coarse
voltage searches. The five coarse search values are the default read VREF value with offsets
of 10, 5, 0, 5, and 10. For example, if the default read value is 42, the five coarse search
values are 32, 37, 42, 47, and 52.
Figure 3-43 shows five Coarse V REF values checked and Coarse VREF2 has the biggest eye
opening out of the five search voltages. The VREF value with the maximum eye opening is
chosen and used as the read VREF. For DDR4 1866 and above, a fine voltage search with a
range based on the coarse voltage search with 4 voltage value is done. For example, if the
coarse voltage search lands on VREF value of 37, the fine voltage search range is 33, 34, 35,
36, 37, 38, 39, 40, and 41.
X-Ref Target - Figure 3-43

&RDUVH95()
&RDUVH95()
0D[(\H

&RDUVH95()
&RDUVH95()
&RDUVH95()

Figure 3-43:

Coarse Read V REF Search

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

67

Chapter 3: Core Architecture

Figure 3-44 shows nine Fine VREF values checked and the Fine VREF4 has the biggest eye
opening out of the nine search voltages.
X-Ref Target - Figure 3-44

&RDUVH95()
0D[(\H

&RDUVH95()

)LQH95()

&RDUVH95()

)LQH95()
)LQH95()

&RDUVH95()
&RDUVH95()

Figure 3-44:

Fine Read V REF Search for DDR4 1866 and Higher

At each read VREF value, the read VREF calibration takes these steps to check the eye
opening. The DRAM MPR register is used to provide data pattern to search for an eye
opening. The read VREF calibration starts DQS tap values from the PQTR/NQTR delays from
earlier calibration steps. PQTR/NQTR are incremented and traffic is sampled at each PQTR/
NQTR tap value. The PQTR/NQTR increment and traffic sampling repeat until a mismatch is
found for a given PQTR and NQTR tap value. The number of taps incremented for PQTR and
NQTR until data mismatch defines the initial right margins (pqtr_right and
nqtr_right). The sample count taken at each of the PQTR/NQTR tap value described
above is low to reduce sampling time. This is indicated by the blue arrows in Figure 3-45.
To obtain a more accurate edge detection for the final pqtr_right and nqtr_right, the
PQTR/NQTR tap values are decremented from pqtr_right and nqtr_right position
with a high number of samples until there is data match. This is indicated by orange arrows
in Figure 3-45.
X-Ref Target - Figure 3-45

'46LQFUHPHQWWRILQGULJKWHGJH
)RUZDUGVHDUFKDWORZVDPSOHFRXQW

%DFNZDUGVHDUFKDWKLJKVDPSOHFRXQW

5LJKW0DUJLQ

Figure 3-45:

DQS Search for Right Margin

After the right margins are found, left margins, initial pqtr_left and nqtr_left are
found similarly by decrementing PQTR/NQTR with a low sampling until data mismatch is
discovered. Final pqtr_left and nqtr_left are found by incrementing PQTR/NQTR with
a high sampling until data match is discovered. This is indicated in Figure 3-46.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

68

Chapter 3: Core Architecture

X-Ref Target - Figure 3-46

'46GHFUHPHQWWRILQGOHIWHGJHUHDG95()
)RUZDUGVHDUFKDWORZVDPSOHFRXQW

%DFNZDUGVHDUFKDWKLJKVDPSOHFRXQW

/HIW0DUJLQ

Figure 3-46:

DQS Search for Left Margin

Read VREF is adjusted per byte basis. Minimum eye opening of two nibbles are used to
determine the eye size for the byte. For each read V REF value, the total eye width is
determined by the following:
MIN(pqtr_right_nibble0 + pqtr_left_nibble0, nqtr_right_nibble0 + nqtr_left_nibble0.
pqtr_right_nibble1 + pqtr_left_nibble1, nqtr_right_nibble1 + nqtr_left_nibble1)

After optimal read V REF value is determined by the voltage search described previously,
DQS is re-centered at (pqtr_right pqtr_left)/2 for PQTR and (nqtr_right
nqtr_left)/2 for NQTR. Complex data pattern is used for better centering performance.

Write DQS-to-DQ Centering (Complex)

Note: The calibration step is only enabled for the first rank in a multi-rank system. Also, this is only
enabled for data rates above 1,600 Mb/s.

For the same reasons as described in the Read DQS Centering (Complex), a complex data
pattern is used on the write path to adjust the Write DQS-to-DQ alignment. The same steps
as detailed in the Write DQS-to-DQ Centering are repeated just with a complex data
pattern.

Write VREF Calibration

In DDR4, the write VREF calibration is enabled by default. Before the write VREF calibration,
the default write V REF value in Table 24-37 is used in earlier stages of the calibration.
The write VREF is similar to read VREF. Each memory device can be programmed to 51 V REF
values. V REF search performs five coarse voltage search at write VREF value. The five coarse
search values are the default write V REF value with offsets of 10, 5, 0, 5, and 10. For
example, if the default read value is 24, the five coarse search values are 14, 19, 24, 29, and
34.
Figure 3-43 shows five Coarse V REF values checked and Coarse VREF2 has the biggest eye
opening out of the five search voltages. The VREF value with the maximum eye opening is
chosen and used as write VREF. For DDR4 1866 and above, a fine voltage search with a range
based on the coarse voltage search with 4 voltage value is done.
For example, if coarse voltage search lands on V REF value of 29, fine voltage search range is
25, 26, 27, 28, 29, 30, 31, 32, and 33.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

69

Chapter 3: Core Architecture

Figure 3-44 shows nine Fine VREF values checked and Fine V REF4 has the biggest eye
opening out of the nine search voltages. At each write V REF value, the write VREF calibration
takes these steps to check the eye opening. For the right margin, write V REF operates
similarly to the read VREF calibration. The write VREF calibration right margin searches for
dqs_right margin by incrementing the DQS ODELAY tap with a low sample count. Then,
it follows by decrementing DQS ODELAY tap with a high sample count as shown in
Figure 3-45.
Data compare is completed in the device width. For left margin, the write V REF operates
differently than read VREF calibration. DQ_ODELAY is incremented starting from the value
from write DQS-to-DQ per bit deskew until data mismatch is found.
For each DQ_ODELAY tap, low sample count is used to determine the initial left_margin.
DQ_ODELAY is then decremented with a high sample count to determine the final right
margin as shown in Figure 3-47. Data compare is completed using DQ Bit[0] only.
For each VREF value, the total eye width is determined by the following:
MIN(dqs_right + dq_left)
X-Ref Target - Figure 3-47

'4LQFUHPHQWWRILQGOHIWHGJHZULWH95()
)RUZDUGVHDUFKDWORZVDPSOHFRXQW

/HIW0DUJLQ

%DFNZDUGVHDUFKDWKLJKVDPSOHFRXQW

Figure 3-47:

DQ Search for Left Margin

Read Leveling Multi-Rank Adjustment

For multi-rank systems the read DQS centering algorithm is ran on each rank, but the final
delay setting must be common for all ranks. The results of training each rank separately are
stored in XSDB, but the final delay setting is a computed average of the training results
across all ranks. The final PQTR/NQTR delay is indicated by
RDLVL_PQTR_CENTER_FINAL_NIBBLE/ RDLVL_NQTR_CENTER_FINAL_NIBBLE, while the DQ
IDELAY is RDLVL_IDELAY_FINAL_BYTE_BIT.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

70

Chapter 3: Core Architecture

Multi-Rank Adjustments and Checks

DQS Gate Multi-Rank Adjustment
During DQS gate calibration for multi-rank systems, each rank is allowed to calibrate
independently given the algorithm as described in DQS Gate, page 38. After all ranks have
been calibrated, an adjustment is required before normal operation to ensure fast
rank-to-rank switching. The general interconnect signal clb2phy_rd_en (indicated by
DQS_GATE_READ_LATENCY_RANK_BYTE in XSDB) that controls the gate timing on a
DRAM-clock-cycle resolution is adjusted here to be the same for a given byte across all
ranks.
The coarse taps are adjusted so the timing of the gate opening stays the same for any given
rank, where four coarse taps are equal to a single read latency adjustment in the general
interconnect. During this step, the algorithm tries to find a common clb2phy_rd_en
setting where across all ranks for a given byte the coarse setting would not overflow or
underflow, starting with the lowest read latency setting found for the byte during
calibration. If the lowest setting does not work for all ranks, the clb2phy_rd_en
increments by one and the check is repeated. The fine tap setting is < 90, so it is not
included in the adjustment.
If the check reaches the maximum clb2phy_rd_en setting initially found during
calibration without finding a value that works between all ranks for a byte, an error is
asserted (Table 3-8, example #3). If after the adjustment is made and the coarse taps are
larger than 360 (four coarse tap settings), a different error is asserted (Table 3-8, example
#4). For the error codes, see Table 3-7, Error Signal Descriptions, on page 35.
Table 3-8:
Example
#1
#2
#3
#4

Examples of DQS Gate Multi-Rank Adjustment (2 Ranks)

Setting

Calibration

After Multi-Rank Adjustment

Rank 0

Rank 1

Rank 0

Rank 1

Read latency

14

15

15

15

Coarse taps

Read latency

22

21

22

22

Coarse taps

Read latency

10

15

N/A

N/A

Coarse taps

N/A

N/A

Read latency

10

11

10

10

Coarse taps

13

Result
Pass
Pass
Error
Error

For multi-rank systems, the coarse taps must be seven or less so additional delay is added
using the general interconnect read latency to compensate for the coarse tap requirement.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

71

Chapter 3: Core Architecture

Write Latency Multi-Rank Check

The write latency is allowed to fall wherever it can in multi-rank systems, each rank is
allowed to calibrate independently given the algorithms in Write Leveling and Write
Latency Calibration. After all ranks have been calibrated and before it finishes, a check is
made to ensure certain XIPHY requirements are met on the write path. The difference in
write latency between the ranks is allowed to be 180 (or two XIPHY coarse taps).

Enable VT Tracking
After the DQS gate multi-rank adjustment (if required), a signal is sent to the XIPHY to
recalibrate internal delays to start voltage and temperature tracking. The XIPHY asserts a
signal when complete, phy2clb_phy_rdy_upp for upper nibbles and
phy2clb_phy_rdy_low for lower nibbles.
For multi-rank systems, when all nibbles are ready for normal operation there is a
requirement of the XIPHY where two write-read bursts are required to be sent to the DRAM
before starting normal traffic. A data pattern of F00FF00F is used for the first and 0FF00FF0
for the second. The data itself is not checked and is expected to fail.

Write Read Sanity Check (Multi-Rank Only)

For multi-rank systems, a check of the data for each rank is made to ensure the previous
stages of calibration did not inadvertently leave the write or read path in a bad spot. A
single write burst followed by a single read command to the same location is sent to each
DRAM rank. The data is checked against the expected data across all bytes before
continuing.
During this step, the expected data pattern for each rank is shown in Table 3-9.
Table 3-9:

Sanity Check Across All Ranks

Rank

Expected Data Pattern for Single Burst

as Seen on a Nibble

A1E04ED8

B1E04ED8

C1E04ED8

D1E04ED8

After all stages are completed across all ranks without any error, calDone gets asserted to
indicate user traffic can begin. In XSDB, DBG_END contains 0x1 if calibration completes and
0x2 if there is a failure.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

72

Chapter 4

Designing with the Core

This chapter includes guidelines and additional information to facilitate designing with the
core.

Clocking
The memory interface requires one MMCM, one TXPLL per I/O bank used by the memory
interface, and two BUFGs. These clocking components are used to create the proper clock
frequencies and phase shifts necessary for the proper operation of the memory interface.
There are two TXPLLs per bank. If a bank is shared by two memory interfaces, both TXPLLs
in that bank are used.
Note: DDR3/DDR4 SDRAM generates the appropriate clocking structure and no modifications to
the RTL are supported.
The DDR3/DDR4 SDRAM tool generates the appropriate clocking structure for the desired
interface. This structure must not be modified. The allowed clock configuration is as
follows:

Differential reference clock source connected to GCIO

GCIO to MMCM (located in center bank of memory interface)

MMCM to BUFG (located at center bank of memory interface) driving FPGA logic and
all TXPLLs

MMCM to BUFG (located at center bank of memory interface) divide by two mode
driving 1/2 rate FPGA logic

Clocking pair of the interface must be in the same SLR of memory interface for the SSI
technology devices

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

73

Chapter 4: Designing with the Core

Requirements
GCIO

Must use a differential I/O standard

Must be in the same I/O column as the memory interface

Must be in the same SLR of memory interface for the SSI technology devices

MMCM

MMCM is used to generate the FPGA logic system clock (1/4 of the memory clock)

Must be located in the center bank of memory interface

Must use internal feedback

Input clock frequency divided by input divider must be 70 MHz (CLKINx / D

70 MHz)

Must use integer multiply and output divide values

BUFGs and Clock Roots

One BUFG is used to generate the system clock to FPGA logic and another BUFG is used
to divide the system clock by two.

BUFGs and clock roots must be located in center most bank of the memory interface.

For two bank systems, banks with more number of bytes selected is chosen as the
center bank. If the same number of bytes is selected in two banks, then the top
bank is chosen as the center bank.
For four bank systems, either of the center banks can be chosen. DDR3/DDR4
SDRAM refers to the second bank from the top-most selected bank as the center
bank.
Both the BUFGs must be in the same bank.

TXPLL

CLKOUTPHY from TXPLL drives XIPHY within its bank

TXPLL must be set to use a CLKFBOUT phase shift of 90

TXPLL must be held in reset until the MMCM lock output goes High

Must use internal feedback

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

74

Chapter 4: Designing with the Core

Figure 4-1 shows an example of the clocking structure for a three bank memory interface.
The GCIO drives the MMCM located at the center bank of the memory interface. MMCM
drives both the BUFGs located in the same bank. The BUFG (which is used to generate
system clock to FPGA logic) output drives the TXPLLs used in each bank of the interface.
X-Ref Target - Figure 4-1

7;3//

,2%DQN

6\VWHP&ORFNWR)3*$/RJLF

0HPRU\,QWHUIDFH

%8)*
7;3//
00&0

,2%DQN

&/.287
&/.287
%8)*

6\VWHP&ORFN'LYLGHG
E\WR)3*$/RJLF

7;3//

,2%DQN

'LIIHUHQWLDO
*&,2,QSXW

%8)*
,2%DQN

Figure 4-1:

Clocking Structure for Three Bank Memory Interface

The MMCM is placed in the center bank of the memory interface.

For two bank systems, MMCM is placed in a bank with the most number of bytes
selected. If they both have the same number of bytes selected in two banks, then
MMCM is placed in the top bank.

For four bank systems, MMCM is placed in a second bank from the top.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

75

Chapter 4: Designing with the Core

For designs generated with System Clock configuration of No Buffer, MMCM must not be
driven by another MMCM/PLL. Cascading clocking structures MMCM BUFG MMCM
and PLL BUFG MMCM are not allowed.
If the MMCM is driven by the GCIO pin of the other bank, then the
CLOCK_DEDICATED_ROUTE constraint with value "BACKBONE" must be set on the net that
is driving MMCM or on the MMCM input. Setting up the CLOCK_DEDICATED_ROUTE
constraint on the net is preferred. But when the same net is driving two MMCMs, the
CLOCK_DEDICATED_ROUTE constraint must be managed by considering which MMCM
needs the BACKBONE route.
In such cases, the CLOCK_DEDICATED_ROUTE constraint can be set on the MMCM input. To
use the "BACKBONE" route, any clock buffer that exists in the same CMT tile as the GCIO
must exist between the GCIO and MMCM input. The clock buffers that exists in the I/O CMT
are BUFG, BUFGCE, BUFGCTRL, and BUFGCE_DIV. So DDR3/DDR4 SDRAM instantiates BUFG
between the GCIO and MMCM when the GCIO pins and MMCM are not in the same bank
(see Figure 4-1).
If the GCIO pin and MMCM are allocated in different banks, DDR3/DDR4 SDRAM generates
CLOCK_DEDICATED_ROUTE constraints with value as "BACKBONE." If the GCIO pin and
MMCM are allocated in the same bank, there is no need to set any constraints on the
MMCM input.
Similarly when designs are generated with System Clock Configuration as a No Buffer
option, you must take care of the "BACKBONE" constraint and the BUFG/BUFGCE/
BUFGCTRL/BUFGCE_DIV between GCIO and MMCM if GCIO pin and MMCM are allocated in
different banks. DDR3/DDR4 SDRAM does not generate clock constraints in the XDC file for
No Buffer configurations and you must take care of the clock constraints for No Buffer
configurations. For more information on clocking, see the UltraScale Architecture Clocking
Resources User Guide (UG572) [Ref 4].
XDC syntax for CLOCK_DEDICATED_ROUTE constraint is given here:
set_property CLOCK_DEDICATED_ROUTE BACKBONE [get_nets net_name]

For more information on the CLOCK_DEDICATED_ROUTE constraints, see the Vivado Design
Suite Properties Reference Guide (UG912) [Ref 5].
Note: If two different GCIO pins are used for two DDR3/DDR4 SDRAM IP cores in the same bank,

center bank of the memory interface is different for each IP. DDR3/DDR4 SDRAM generates MMCM
LOC and CLOCK_DEDICATED_ROUTE constraints accordingly.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

76

Chapter 4: Designing with the Core

Sharing of Input Clock Source (sys_clk_p)

If the same GCIO pin must be used for two IP cores, generate the two IP cores with the same
frequency value selected for option Reference Input Clock Period (ps) and System Clock
Configuration option as No Buffer. Perform the following changes in the wrapper file in
which both IPs are instantiated:
1. DDR3/DDR4 SDRAM generates a single-ended input for system clock pins, such as
sys_clk_i. Connect the differential buffer output to the single-ended system clock
inputs (sys_clk_i) of both the IP cores.
2. System clock pins must be allocated within the same I/O column of the memory
interface pins allocated. Add the pin LOC constraints for system clock pins and clock
constraints in your top-level XDC.
3. You must add a "BACKBONE" constraint on the net that is driving the MMCM or on the
MMCM input if GCIO pin and MMCM are not allocated in the same bank. Apart from
this, BUFG/BUFGCE/BUFGCTRL/BUFGCE_DIV must be instantiated between GCIO and
MMCM to use the "BACKBONE" route.
Note:

The Ultrascale architecture includes an independent XIPHY power supply and TXPLL
for each XIPHY. This results in clean, low jitter clocks for the memory system.

Skew spanning across multiple BUFGs is not a concern because single point of
contact exists between BUFG TXPLL and the same BUFG System Clock Logic.

System input clock cannot span I/O columns because the longer the clock lines
span, the more jitter is picked up.

TXPLL Usage
There are two TXPLLs per bank. If a bank is shared by two memory interfaces, both TXPLLs
in that bank are used. One PLL per bank is used if a bank is used by a single memory
interface. You can use a second PLL for other usage. To use a second PLL, you can perform
the following steps:
1. Generate the design for the System Clock Configuration option as No Buffer.
2. DDR3/DDR4 SDRAM generates a single-ended input for system clock pins, such as
sys_clk_i. Connect the differential buffer output to the single-ended system clock
inputs (sys_clk_i) and also to the input of PLL (PLL instance that you have in your
design).
3. You can use the PLL output clocks.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

77

Chapter 4: Designing with the Core

Additional Clocks
You can produce up to four additional clocks which are created from the same MMCM that
generates ui_clk. Additional clocks can be selected from the Clock Options section in the
Advanced tab. The GUI lists the possible clock frequencies from MMCM and the
frequencies for additional clocks vary based on selected memory frequency (Memory
Device Interface Speed (ps) value in the Basic tab), selected FPGA, and FPGA speed grade.

Resets
An asynchronous reset (sys_rst) input is provided. This is an active-High reset and the
sys_rst must assert for a minimum pulse width of 5 ns. The sys_rst can be an internal
or external pin.

PCB Guidelines for DDR3

Strict adherence to all documented DDR3 PCB guidelines is required for successful
operation. For more information on PCB guidelines, see the UltraScale Architecture PCB
Design and Pin Planning User Guide (UG583) [Ref 6].

PCB Guidelines for DDR4

Strict adherence to all documented DDR4 PCB guidelines is required for successful
operation. For more information on PCB guidelines, see the UltraScale Architecture PCB
Design and Pin Planning User Guide (UG583) [Ref 6].

Pin and Bank Rules

DDR3 Pin Rules
The rules are for single and multi-rank memory interfaces.

Address/control means cs_n, ras_n, cas_n, we_n, ba, ck, cke, a, parity (valid for
RDIMMs only), and odt. Multi-rank systems have one cs_n, cke, odt, and one ck pair
per rank.

Pins in a byte lane are numbered N0 to N12.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

78

Chapter 4: Designing with the Core

Byte lanes in a bank are designed by T0, T1, T2, or T3. Nibbles within a byte lane are
distinguished by a U or L designator added to the byte lane designator (T0, T1, T2,
or T3). Thus they are T0L, T0U, T1L, T1U, T2L, T2U, T3L, and T3U.

Note: There are two PLLs per bank and a controller uses one PLL in every bank that is being used by
the interface.

1. dqs, dq, and dm location.

a. Designs using x8 or x16 components dqs must be located on a dedicated byte
clock pair in the upper nibble designated with U (N6 and N7). dq associated with
a dqs must be in same byte lane on any of the other pins except pins N1 and N12.
b. Designs using x4 components dqs must be located on the dedicated dqs pair in
the nibble (N0 and N1 in the lower nibble, N6 and N7 in the upper nibble). dqs
associated with a dqs must be in the same nibble on any of the other pins except pin
N12 (upper nibble).
c. dm (if used) must be located on pin N0 in the byte lane with the corresponding dqs.
When dm is disabled, pin N0 can be used for dq and pin N0 must not be used for
address/control signal.
Note: dm is not supported with x4 devices.
2. The x4 components must be used in pairs. Odd numbers of x4 components are not
permitted. Both the upper and lower nibbles of a data byte must be occupied by a x4
dq/dqs group.
3. Byte lanes with a dqs are considered to be data byte lanes. Pins N1 and N12 can be used
for address/control in a data byte lane. If the data byte is in the same bank as the
remaining address/control pins, see rule #4.
4. Address/control can be on any of the 13 pins in the address/control byte lanes. Address/
control must be contained within the same bank.
5. For dual slot configurations of RDIMMs and UDIMMs: cs, odt, cke, and ck port widths
are doubled. For exact mapping of the signals, see the DIMM Configurations.
6. One vrp pin per bank is used and a DCI is required for the interfaces. A vrp pin is
required in I/O banks containing inputs as well as in output only banks. It is required in
output only banks because address/control signals use SSTL15_DCI/SSTL135_DCI to
enable usage of controlled output impedance. A DCI cascade is not permitted. All rules
for the DCI in the UltraScale Architecture FPGAs SelectIO Resources User Guide
(UG571) [Ref 3] must be followed.
7. ck pair(s) must be on any PN pair(s) in the Address/Control byte lanes.
8. reset_n can be on any pin as long as general interconnect timing is met and I/O
standard can be accommodated for the chosen bank reset to DRAM should be pulled
down so it is held Low during power up.
RECOMMENDED: The recommended reset should be a 4.7 pull-down.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

79

Chapter 4: Designing with the Core

9. Banks can be shared between two controllers.
a. Each byte lane is dedicated to a specific controller (except for reset_n).
b. Byte lanes from one controller cannot be placed inside the other. For example, with
controllers A and B, AABB is allowed, while ABAB is not.
10. All I/O banks used by the memory interface must be in the same column.
11. All I/O banks used by the memory interface must be in the same SLR of the column for
the SSI technology devices.
12. Maximum height of interface is five contiguous banks. The maximum supported
interface is 80-bit wide.
a. Maximum component limit is nine and this restriction is valid for components only
and not for DIMMs.
13. Bank skipping is not allowed.
14. Input clock for the MMCM in the interface must come from a GCIO pair in the I/O
column used for the memory interface. For more information, see Clocking, page 73.
15. There are dedicated V REF pins (not included in the rules above). Either internal or
external VREF is permitted. If an external VREF is not used, the V REF pins must be pulled
to ground by a resistor value specified in the UltraScale Architecture FPGAs SelectIO
Resources User Guide (UG571) [Ref 3]. These pins must be connected appropriately for
the standard in use.
16. The interface must be contained within the same I/O bank type (High Range or High
Performance). Mixing bank types is not permitted with the exceptions of the reset_n
in step 7 and the input clock mentioned in step 12.
Note: If PCB compatibility between x4 and x8 based DIMMs is desired, additional restrictions apply.
The upper x4 DQS group must be placed within the lower byte nibble (N0 to N5). This allows DM to
be placed on N0 for the x8 pinout, pin compatibility for al DQ bits, and the added DQS pair for x4 be
placed on N0/N1.
For example, a typical DDR3 x4 based RDIMM data sheet shows the DQS9 associated with DQ4, DQ5,
DQ6, and DQ7. This DQS9_p is used for the DM in an x8 configuration. This nibble must be
connected to the lower nibble of the byte lane. The Vivado generated XDC labels this DQS9 as DSQ1
(for more information, see the Pin Mapping for x4 RDIMMs). Table 4-1 and Table 4-2 include an
example for one of the configurations of x4/x8/x16.

Table 4-1:
I/O Type

Byte Lane View of Bank on FPGA Die for x8 and x16 Support
Byte Lane

Pin Number

Signal Name

T0U

N12

T0U

N11

DQ[7:0]

T0U

N10

DQ[7:0]

T0U

N9

DQ[7:0]

T0U

N8

DQ[7:0]

DQSCC-N

T0U

N7

DQS0_N

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

80

Chapter 4: Designing with the Core

Table 4-1:
I/O Type

Byte Lane View of Bank on FPGA Die for x8 and x16 Support (Contd)
Byte Lane

Pin Number

DQSCC-P

T0U

N6

DQS0_P

T0L

N5

DQ[7:0]

T0L

N4

DQ[7:0]

T0L

N3

DQ[7:0]

T0L

N2

DQ[7:0]

DQSCC-N

T0L

N1

DQSCC-P

T0L

N0

DM0

Table 4-2:
I/O Type

Signal Name

Byte Lane View of Bank on FPGA Die for x4, x8, and x16 Support
Byte Lane

Pin Number

Signal Name

T0U

N12

T0U

N11

DQ[3:0]

T0U

N10

DQ[3:0]

T0U

N9

DQ[3:0]

T0U

N8

DQ[3:0]

DQSCC-N

T0U

N7

DQS0_N

DQSCC-P

T0U

N6

DQS0_P

T0L

N5

DQ[7:4]

T0L

N4

DQ[7:4]

T0L

N3

DQ[7:4]

T0L

N2

DQ[7:4]

DQSCC-N

T0L

N1

/DQS9_N

DQSCC-P

T0L

N0

DM0/DQS9_P

Pin Swapping

Pins can swap freely within each byte group (data and address/control), except for the
DQS pair which must be on the dedicated dqs pair in the nibble (for more information,
see the dqs, dq, and dm location., page 79).

Byte groups (data and address/control) can swap easily with each other.

Pins in the address/control byte groups can swap freely within and between their byte
groups.

No other pin swapping is permitted.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

81

Chapter 4: Designing with the Core

DDR3 Pinout Examples

IMPORTANT: Due to the calibration stage, there is no need for set_input_delay/

set_output_delay on the DDR3 SDRAM. Ignore the unconstrained inputs and outputs for DDR3
SDRAM and the signals which are calibrated.

Table 4-3 shows an example of a 16-bit DDR3 interface contained within one bank. This
example is for a component interface using two x8 DDR3 components.
Table 4-3:
Bank

16-Bit DDR3 (x8/x16 Part) Interface Contained in One Bank

Signal Name

Byte Group

I/O Type

a0

T3U_12

a1

T3U_11

a2

T3U_10

a3

T3U_9

a4

T3U_8

a5

T3U_7

a6

T3U_6

a7

T3L_5

a8

T3L_4

a9

T3L_3

a10

T3L_2

a11

T3L_1

a12

T3L_0

a13

T2U_12

a14

T2U_11

we_n

T2U_10

cas_n

T2U_9

ras_n

T2U_8

ck_n

T2U_7

ck_p

T2U_6

cs_n

T2L_5

ba0

T2L_4

ba1

T2L_3

ba2

T2L_2

sys_clk_n

T2L_1

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

82

Chapter 4: Designing with the Core

Table 4-3:
Bank

16-Bit DDR3 (x8/x16 Part) Interface Contained in One Bank (Contd)

Signal Name

Byte Group

I/O Type

sys_clk_p

T2L_0

cke

T1U_12

dq15

T1U_11

dq14

T1U_10

dq13

T1U_9

dq12

T1U_8

dqs1_n

T1U_7

dqs1_p

T1U_6

dq11

T1L_5

dq10

T1L_4

dq9

T1L_3

dq8

T1L_2

odt

T1L_1

dm1

T1L_0

vrp

T0U_12

dq7

T0U_11

dq6

T0U_10

dq5

T0U_9

dq4

T0U_8

dqs0_n

T0U_7

dqs0_p

T0U_6

dq3

T0L_5

dq2

T0L_4

dq1

T0L_3

dq0

T0L_2

reset_n

T0L_1

dm0

T0L_0

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

83

Chapter 4: Designing with the Core

Table 4-4 shows an example of a 16-bit DDR3 interface contained within one bank. This
example is for a component interface using four x4 DDR3 components.
Table 4-4:
Bank

16-Bit DDR3 Interface (x4 Part) Contained in One Bank

Signal Name

Byte Group

I/O Type

a0

T3U_12

a1

T3U_11

a2

T3U_10

a3

T3U_9

a4

T3U_8

a5

T3U_7

a6

T3U_6

a7

T3L_5

a8

T3L_4

a9

T3L_3

a10

T3L_2

a11

T3L_1

a12

T3L_0

a13

T2U_12

a14

T2U_11

we_n

T2U_10

cas_n

T2U_9

ras_n

T2U_8

ck_n

T2U_7

ck_p

T2U_6

cs_n

T2L_5

ba0

T2L_4

ba1

T2L_3

ba2

T2L_2

sys_clk_n

T2L_1

sys_clk_p

T2L_0

cke

T1U_12

dq15

T1U_11

dq14

T1U_10

dq13

T1U_9

dq12

T1U_8

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

84

Chapter 4: Designing with the Core

Table 4-4:
Bank

16-Bit DDR3 Interface (x4 Part) Contained in One Bank (Contd)

Signal Name

Byte Group

I/O Type

dqs3_n

T1U_7

dqs3_p

T1U_6

dq11

T1L_5

dq10

T1L_4

dq9

T1L_3

dq8

T1L_2

dqs2_n

T1L_1

dqs2_p

T1L_0

vrp

T0U_12

dq7

T0U_11

dq6

T0U_10

dq5

T0U_9

dq4

T0U_8

dqs1_n

T0U_7

dqs1_p

T0U_6

dq3

T0L_5

dq2

T0L_4

dq1

T0L_3

dq0

T0L_2

dqs0_n

T0L_1

dqs0_p

T0L_0

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

85

Chapter 4: Designing with the Core

DDR4 Pin Rules

The rules are for single and multi-rank memory interfaces.

Address/control means cs_n, ras_n (a16), cas_n (a15), we_n (a14), ba, bg, ck, cke,
a, odt, act_n, and parity (valid for RDIMMs only). Multi-rank systems have one
cs_n, cke, odt, and one ck pair per rank.

Pins in a byte lane are numbered N0 to N12.

Byte lanes in a bank are designed by T0, T1, T2, or T3. Nibbles within a byte lane are
distinguished by a U or L designator added to the byte lane designator (T0, T1, T2,
or T3). Thus they are T0L, T0U, T1L, T1U, T2L, T2U, T3L, and T3U.

Note: There are two PLLs per bank and a controller uses one PLL in every bank that is being used by
the interface.

1. dqs, dq, and dm/dbi location.

a. Designs using x8 or x16 components dqs must be located on a dedicated byte
clock pair in the upper nibble designated with U (N6 and N7).dq associated with a
dqs must be in same byte lane on any of the other pins except pins N1 and N12.
b. Designs using x4 components dqs must be located on a dedicated byte clock pair
in the nibble (N0 and N1 in the lower nibble, N6 and N7 in the upper nibble). dq
associated with a dqs must be in same nibble on any of the other pins except pin
N12 (upper nibble). The lower nibble dq and upper nibble dq must be allocated in
the same byte lane.
Note: The dm/dbi port is not supported in x4 DDR4 devices.
c. dm/dbi must be on pin N0 in the byte lane with the associated dqs. Write and read
dbi are required for per pin data rates above 2,133 Mb/s. Therefore, data mask
functionality is not available above 2,133 Mb/s. Write and read dbi modes are not
supported yet.
d. The x16 components must have the ldqs connected to the even dqs and the udqs
must be connected to the ldqs + 1. The first x16 component has ldqs connected
to dqs0 and udqs connected to dqs1 in the XDC file. The second x16 component
has ldqs connected to dqs2 and udqs connected to dqs3. This pattern continues
as needed for the interface. This does not restrict the physical location of the byte
lanes. The byte lanes associated with the dqss might be moved as desired in the
Vivado IDE to achieve optimal PCB routing.
Consider x16 part with data width of 32 and all data bytes are allocated in a single
bank. In such cases, DQS needs to be mapped as given in Table 4-5.
In Table 4-5, the Bank-Byte and Selected Memory Data Bytes indicate byte allocation
in the I/O pin planner. The following example is given for one of the generated
configuration in the I/O pin planner. Based on pin allocation, DQ byte allocation
might vary.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

86

Chapter 4: Designing with the Core

DQS Allocated (in IP on the FPGA) indicates DQS that is allocated on the FPGA end.
Memory device mapping indicates how DQS needs to be mapped on the memory
end.
Table 4-5:

DQS Mapping for x16 Component

Bank-Byte

Selected Memory
Data Bytes

DQS Allocated
(in IP on FPGA)

Memory Device Mapping

BankX_BYTE3

DQ[0-7]

DQS0

Memory Device 0 LDQS

BankX_BYTE2

DQ[8-15]

DQS1

Memory Device 0 UDQS

BankX_BYTE1

DQ[16-23]

DQS2

Memory Device 1 LDQS

BankX_BYTE0

DQ[24-31]

DQS3

Memory Device 1 UDQS

2. The x4 components must be used in pairs. Odd numbers of x4 components are not
permitted. Both the upper and lower nibbles of a data byte must be occupied by a x4
dq/dqs group. Each byte lane containing two x4 nibbles must have sequential nibbles
with the even nibble being the lower number. For example, a byte lane can have nibbles
0 and 1, or 2 and 3, but must not have 1 and 2. The ordering of the nibbles within a byte
lane is not important.
3. Byte lanes with a dqs are considered to be data byte lanes. Pins N1 and N12 can be used
for address/control in a data byte lane. If the data byte is in the same bank as the
remaining address/control pins, see rule #4.
4. Address/control can be on any of the 13 pins in the address/control byte lanes. Address/
control must be contained within the same bank.
5. One vrp pin per bank is used and a DCI is required for the interfaces. A vrp pin is
required in I/O banks containing inputs as well as in output only banks. It is required in
output only banks because address/control signals use SSTL12_DCI to enable usage of
controlled output impedance. A DCI cascade is not permitted. All rules for the DCI in the
UltraScale Architecture FPGAs SelectIO Resources User Guide (UG571) [Ref 3] must be
followed.
6. ck pair(s) must be on any PN pair(s) in the Address/Control byte lanes.
7. reset_n can be on any pin as long as general interconnect timing is met and I/O
standard can be accommodated for the chosen bank reset to DRAM should be pulled
down so it is held Low during power up.
RECOMMENDED: The recommended reset should be a 4.7 pull-down.

8. Banks can be shared between two controllers.

a. Each byte lane is dedicated to a specific controller (except for reset_n).
b. Byte lanes from one controller cannot be placed inside the other. For example, with
controllers A and B, AABB is allowed, while ABAB is not.
9. All I/O banks used by the memory interface must be in the same column.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

87

Chapter 4: Designing with the Core

10. All I/O banks used by the memory interface must be in the same SLR of the column for
the SSI technology devices.
11. For dual slot configurations of RDIMMs and UDIMMs: cs, odt, cke, and ck port widths
are doubled. For exact mapping of the signals, see the DIMM Configurations.
12. Maximum height of interface is five contiguous banks. The maximum supported
interface is 80-bit wide.
a. Maximum component limit is nine and this restriction is valid for components only
and not for DIMMs.
13. Bank skipping is not allowed.
14. Input clock for the MMCM in the interface must come from the a GCIO pair in the I/O
column used for the memory interface. For more information, see Clocking, page 73.
15. The dedicated VREF pins in the banks used for DDR4 must be tied to ground with a
resistor value specified in the UltraScale Architecture FPGAs SelectIO Resources User
Guide (UG571) [Ref 3]. Internal VREF is required for DDR4.
16. The interface must be contained within the same I/O bank type (High Performance).
Mixing bank types is not permitted with the exceptions of the reset_n in step #7 and
the input clock mentioned in step #13.
17. The par input for command and address parity, alert_n input/output, and the TEN
input for Connectivity Test Mode are not supported by this interface. Consult the
memory vendor for information on the proper connection for these pins when not used.
IMPORTANT: Component interfaces should be created with the same component for all components in

the interface. x16 components have a different number of bank groups than the x8 components. For
example, a 72-bit wide component interface should be created by using nine x8 components or five x16
components where half of one component is not used. Four x16 components and one x8 component is
not permissible.

Note: Pins N0 and N6 within the byte lane used by a memory interface can be utilized for other

purposes when not needed for the memory interface. However, the functionality of these pins is not
available until VTC_RDY asserts on the BITSLICE_CONTROL. For more information, see the
UltraScale Architecture FPGAs SelectIO Resources User Guide (UG571) [Ref 3].

Note: If PCB compatibility between x4 and x8 based DIMMs is desired, additional restrictions apply.

The upper x4 DQS group must be placed within the lower byte nibble (N0 to N5). This allows DM to
be placed on N0 for the x8 pinout, pin compatibility for al DQ bits, and the added DQS pair for x4 be
placed on N0/N1.
For example, a typical DDR4 x4 based RDIMM data sheet shows the DQS9 associated with DQ4, DQ5,
DQ6, and DQ7. This DQS9_t is used for the DM/DBI in an x8 configuration. This nibble must be
connected to the lower nibble of the byte lane. The Vivado generated XDC labels this DQS9 as DSQ1
(for more information, see the Pin Mapping for x4 RDIMMs). Table 4-1 and Table 4-2 include an
example for one of the configurations of x4/x8/x16.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

88

Chapter 4: Designing with the Core

Table 4-6:
I/O Type

Byte Lane View of Bank on FPGA Die for x8 and x16 Support
Byte Lane

Pin Number

T0U

N12

T0U

N11

DQ[7:0]

T0U

N10

DQ[7:0]

T0U

N9

DQ[7:0]

T0U

N8

DQ[7:0]

DQSCC-N

T0U

N7

DQS0_c

DQSCC-P

T0U

N6

DQS0_t

T0L

N5

DQ[7:0]

T0L

N4

DQ[7:0]

T0L

N3

DQ[7:0]

T0L

N2

DQ[7:0]

DQSCC-N

T0L

N1

DQSCC-P

T0L

N0

DM0/DBI0

Table 4-7:
I/O Type

Signal Name

Byte Lane View of Bank on FPGA Die for x4, x8, and x16 Support
Byte Lane

Pin Number

Signal Name

T0U

N12

T0U

N11

DQ[3:0]

T0U

N10

DQ[3:0]

T0U

N9

DQ[3:0]

T0U

N8

DQ[3:0]

DQSCC-N

T0U

N7

DQS0_c

DQSCC-P

T0U

N6

DQS0_t

T0L

N5

DQ[7:4]

T0L

N4

DQ[7:4]

T0L

N3

DQ[7:4]

T0L

N2

DQ[7:4]

DQSCC-N

T0L

N1

/DQS9_c

DQSCC-P

T0L

N0

DM0/DBI0/DQS9_t

Pin Swapping

Pins can swap freely within each byte group (data and address/control), except for the
DQS pair which must be on the dedicated dqs pair in the nibble (for more information,
see the dqs, dq, and dm/dbi location., page 86).

Byte groups (data and address/control) can swap easily with each other.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

89

Chapter 4: Designing with the Core

Pins in the address/control byte groups can swap freely within and between their byte
groups.

No other pin swapping is permitted.

DDR4 Pinout Examples

IMPORTANT: Due to the calibration stage, there is no need for set_input_delay/

set_output_delay on the DDR4 SDRAM. Ignore the unconstrained inputs and outputs for DDR4
SDRAM and the signals which are calibrated.

Table 4-8 shows an example of a 32-bit DDR4 interface contained within two banks. This
example is for a component interface using four x8 DDR4 components.
Table 4-8:
Bank

32-Bit DDR4 Interface Contained in Two Banks

Signal Name

Byte Group

I/O Type

Bank 1
1

T3U_12

T3U_11

T3U_10

T3U_9

T3U_8

T3U_7

T3U_6

T3L_5

T3L_4

T3L_3

T3L_2

T3L_1

T3L_0

T2U_12

T2U_11

T2U_10

T2U_9

T2U_8

T2U_7

T2U_6

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

90

Chapter 4: Designing with the Core

Table 4-8:
Bank

32-Bit DDR4 Interface Contained in Two Banks (Contd)

Signal Name

Byte Group

I/O Type

T2L_5

T2L_4

T2L_3

T2L_2

T2L_1

T2L_0

reset_n

T1U_12

dq31

T1U_11

dq30

T1U_10

dq29

T1U_9

dq28

T1U_8

dqs3_c

T1U_7

dqs3_t

T1U_6

dq27

T1L_5

dq26

T1L_4

dq25

T1L_3

dq24

T1L_2

unused

T1L_1

dm3/dbi3

T1L_0

vrp

T0U_12

dq23

T0U_11

dq22

T0U_10

dq21

T0U_9

dq20

T0U_8

dqs2_c

T0U_7

dqs2_t

T0U_6

dq19

T0L_5

dq18

T0L_4

dq17

T0L_3

dq16

T0L_2

T0L_1

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

91

Chapter 4: Designing with the Core

Table 4-8:
Bank
1

32-Bit DDR4 Interface Contained in Two Banks (Contd)

Signal Name

Byte Group

dm2/dbi2

T0L_0

I/O Type
P

Bank 2
2

a0

T3U_12

a1

T3U_11

a2

T3U_10

a3

T3U_9

a4

T3U_8

a5

T3U_7

a6

T3U_6

a7

T3L_5

a8

T3L_4

a9

T3L_3

a10

T3L_2

a11

T3L_1

a12

T3L_0

a13

T2U_12

we_n/a14

T2U_11

cas_n/a15

T2U_10

ras_n/a16

T2U_9

act_n

T2U_8

ck_c

T2U_7

ck_t

T2U_6

ba0

T2L_5

ba1

T2L_4

bg0

T2L_3

bg1

T2L_2

sys_clk_n

T2L_1

sys_clk_p

T2L_0

cs_n

T1U_12

dq15

T1U_11

dq14

T1U_10

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

92

Chapter 4: Designing with the Core

Table 4-8:
Bank

32-Bit DDR4 Interface Contained in Two Banks (Contd)

Signal Name

Byte Group

I/O Type

dq13

T1U_9

dq12

T1U_8

dqs1_c

T1U_7

dqs1_t

T1U_6

dq11

T1L_5

dq10

T1L_4

dq9

T1L_3

dq8

T1L_2

odt

T1L_1

dm1/dbi1

T1L_0

vrp

T0U_12

dq7

T0U_11

dq6

T0U_10

dq5

T0U_9

dq4

T0U_8

dqs0_c

T0U_7

dqs0_t

T0U_6

dq3

T0L_5

dq2

T0L_4

dq1

T0L_3

dq0

T0L_2

cke

T0L_1

dm0/dbi0

T0L_0

Table 4-9 shows an example of a 16-bit DDR4 interface contained within a single bank. This
example is for a component interface using four x4 DDR4 components.
Table 4-9:
Bank

16-Bit DDR4 Interface (x4 Part) Contained in One Bank

Signal Name Byte Group I/O Type

a0

T3U_12

a1

T3U_11

a2

T3U_10

a3

T3U_9

a4

T3U_8

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

93

Chapter 4: Designing with the Core

Table 4-9:
Bank

16-Bit DDR4 Interface (x4 Part) Contained in One Bank (Contd)

Signal Name Byte Group I/O Type

a5

T3U_7

a6

T3U_6

a7

T3L_5

a8

T3L_4

a9

T3L_3

a10

T3L_2

a11

T3L_1

a12

T3L_0

a13

T2U_12

we_n/a14

T2U_11

cas_n/a15

T2U_10

ras_n/a16

T2U_9

act_n

T2U_8

ck_c

T2U_7

ck_t

T2U_6

ba0

T2L_5

ba1

T2L_4

bg0

T2L_3

bg1

T2L_2

odt

T2L_1

cke

T2L_0

cs_n

T1U_12

dq15

T1U_11

dq14

T1U_10

dq13

T1U_9

dq12

T1U_8

dqs3_c

T1U_7

dqs3_t

T1U_6

dq11

T1L_5

dq10

T1L_4

dq9

T1L_3

dq8

T1L_2

dqs2_c

T1L_1

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

94

Chapter 4: Designing with the Core

Table 4-9:
Bank

16-Bit DDR4 Interface (x4 Part) Contained in One Bank (Contd)

Signal Name Byte Group I/O Type

dqs2_t

T1L_0

vrp

T0U_12

dq7

T0U_11

dq6

T0U_10

dq5

T0U_9

dq4

T0U_8

dqs1_c

T0U_7

dqs1_t

T0U_6

dq3

T0L_5

dq2

T0L_4

dq1

T0L_3

dq0

T0L_2

dqs0_c

T0L_1

dqs0_t

T0L_0

Note: System clock pins (sys_clk_p and sys_clk_n) are allocated in different banks.

Pin Mapping for x4 RDIMMs

Table 4-10 is an example showing the pin mapping for x4 DDR3 registered DIMMs between
the memory data sheet and the XDC.
Table 4-10:

Pin Mapping for x4 DDR3 DIMMs

Memory Data Sheet

DDR3 SDRAM XDC

DQ[63:0]

DQ[63:0]

CB3 to CB0

DQ[67:64]

CB7 to CB4

DQ[71:68]

DQS0, DQS0

DQS[0], DQS_N[0]

DQS1, DQS1

DQS[2], DQS_N[2]

DQS2, DQS2

DQS[4], DQS_N[4]

DQS3, DQS3

DQS[6], DQS_N[6]

DQS4, DQS4

DQS[8], DQS_N[8]

DQS5, DQS5

DQS[10], DQS_N[10]

DQS6, DQS6

DQS[12], DQS_N[12]

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

95

Chapter 4: Designing with the Core

Table 4-10:

Pin Mapping for x4 DDR3 DIMMs (Contd)

Memory Data Sheet

DDR3 SDRAM XDC

DQS7, DQS7

DQS[14], DQS_N[14]

DQS8, DQS8

DQS[16], DQS_N[16]

DQS9, DQS9

DQS[1], DQS_N[1]

DQS10, DQS10

DQS[3], DQS_N[3]

DQS11, DQS11

DQS[5], DQS_N[5]

DQS12, DQS12

DQS[7], DQS_N[7]

DQS13, DQS13

DQS[9], DQS_N[9]

DQS14, DQS14

DQS[11], DQS_N[11]

DQS15, DQS15

DQS[13], DQS_N[13]

DQS16, DQS16

DQS[15], DQS_N[15]

DQS17, DQS17

DQS[17], DQS_N[17]

Table 4-11 is an example showing the pin mapping for x4 DDR4 registered DIMMs between
the memory data sheet and the XDC.
Table 4-11:

Pin Mapping for x4 DDR4 DIMMs

Memory Data Sheet

DDR4 SDRAM XDC

DQ[63:0]

DQ[63:0]

CB3 to CB0

DQ[67:64]

CB7 to CB4

DQ[71:68]

DQS0

DQS[0]

DQS1

DQS[2]

DQS2

DQS[4]

DQS3

DQS[6]

DQS4

DQS[8]

DQS5

DQS[10]

DQS6

DQS[12]

DQS7

DQS[14]

DQS8

DQS[16]

DQS9

DQS[1]

DQS10

DQS[3]

DQS11

DQS[5]

DQS12

DQS[7]

DQS13

DQS[9]

DQS14

DQS[11]

DQS15

DQS[13]

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

96

Chapter 4: Designing with the Core

Table 4-11:

Pin Mapping for x4 DDR4 DIMMs (Contd)

Memory Data Sheet

DDR4 SDRAM XDC

DQS16

DQS[15]

DQS17

DQS[17]

Protocol Description
This core has the following interfaces:

User Interface

AXI4 Slave Interface

PHY Only Interface

User Interface
The user interface signals are described in Table 4-12 and connects to an FPGA user design
to allow access to an external memory device. The user interface is layered on top of the
native interface which is described earlier in the controller description.
Table 4-12:

User Interface

Signal

Direction Description

app_addr[ADDR_WIDTH
1:0]

Input

This input indicates the address for the current request.

app_cmd[2:0]

Input

This input selects the command for the current request.

app_autoprecharge (1)

Input

This input instructs the controller to set the A10 autoprecharge bit on
the DRAM CAS command for the current request.

app_en

Input

This is the active-High strobe for the app_addr[], app_cmd[2:0],

app_sz, and app_hi_pri inputs.

app_rdy

Output

This output indicates that the user interface is ready to accept

commands. If the signal is deasserted when app_en is enabled, the
current app_cmd, app_autoprecharge, and app_addr must be retried
until app_rdy is asserted.

app_hi_pri

Input

This input is reserved and should be tied to 0.

app_rd_data
[APP_DATA_WIDTH 1:0]

Output

This provides the output data from read commands.

app_rd_data_end

Output

This active-High output indicates that the current clock cycle is the
last cycle of output data on app_rd_data[].

app_rd_data_valid

Output

This active-High output indicates that app_rd_data[] is valid.

app_sz

Input

This input is reserved and should be tied to 0.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

97

Chapter 4: Designing with the Core

Table 4-12:

User Interface (Contd)

Signal

Direction Description

app_wdf_data
[APP_DATA_WIDTH 1:0]

Input

This provides the data for write commands.

app_wdf_end

Input

This active-High input indicates that the current clock cycle is the last
cycle of input data on app_wdf_data[].

app_wdf_mask
[APP_MASK_WIDTH 1:0]

Input

This provides the mask for app_wdf_data[].

app_wdf_rdy

Output

This output indicates that the write data FIFO is ready to receive data.
Write data is accepted when app_wdf_rdy = 1b1 and app_wdf_wren
= 1b1.

app_wdf_wren

Input

This is the active-High strobe for app_wdf_data[].

app_ref_req (2)

Input

User refresh request.

app_ref_ack(2)

Output

User refresh request completed.

app_zq_req (2)

Input

User ZQCS command request.

Output

User ZQCS command request completed.

ui_clk

Output

This user interface clock must be one quarter of the DRAM clock.

init_calib_complete

Output

PHY asserts init_calib_complete when calibration is finished.

ui_clk_sync_rst

Output

This is the active-High user interface reset.

addn_ui_clkout1

Output

Additional clock outputs provided based on user requirement.

addn_ui_clkout2

Output

Additional clock outputs provided based on user requirement.

addn_ui_clkout3

Output

Additional clock outputs provided based on user requirement.

addn_ui_clkout4

Output

Additional clock outputs provided based on user requirement.

dbg_clk

Output

Debug Clock. Do not connect any signals to dbg_clk and keep the port
open during instantiation.

sl_iport0

Input
[36:0]

Input Port 0 (* KEEP = "true" *)

sl_oport0

Output
[16:0]

Output Port 0 (* KEEP = "true" *)

c0_ddr4_app_correct_en_i

Input

DDR4 Correct Enable Input

app_raw_not_ecc

Input

Reserved for future use. Tie Low.

app_zq_ack

(2)

Notes:
1. This port appears when "Enable Precharge Input" option is enabled in the Vivado IDE.
2. These ports appear upon enabling "Enable User Refresh and ZQCS Input" option in the Vivado IDE.

app_addr[ADDR_WIDTH 1:0]
This input indicates the address for the request currently being submitted to the user
interface. The user interface aggregates all the address fields of the external SDRAM and
presents a flat address space.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

98

Chapter 4: Designing with the Core

The MEM_ADDR_ORDER parameter determines how app_addr is mapped to the SDRAM
address bus and chip select pins. This mapping can have a significant impact on memory
bandwidth utilization. ROW_COLUMN_BANK is the recommended MEM_ADDR_ORDER
setting. Table 4-13 through Table 4-16 show the ROW_COLUMN_BANK mapping for DDR3
and DDR4 with examples. Note that the three LSBs of app_addr map to the column
address LSBs which correspond to SDRAM burst ordering.
The controller does not support burst ordering so these low order bits are ignored, making
the effective minimum app_addr step size hex 8..
Table 4-13:

DDR3 ROW_COLUMN_BANK Mapping

SDRAM

app_addr Mapping

Rank

(RANK == 1) ? 1b0: app_addr[BANK_WIDTH + COL_WIDTH + ROW_WIDTH +: RANK_WIDTH]

Row

app_addr[BANK_WIDTH + COL_WIDTH +: ROW_WIDTH]

Column

app_addr[3 + BANK_WIDTH +: COL_WIDTH 3], app_addr[2:0]

Bank

app_addr[3 +: BANK_WIDTH 1], app_addr[2 + BANK_WIDTH +: 1]

Table 4-14:

DDR3 4 GB (512 MB x8) Single Rank Mapping Example

SDRAM Bus

Row[15:0]

Column[9:0]

Bank[2:0]

app_addr Bits

28 through 13

12 through 6, and 2, 1, 0

4, 3, 5

Table 4-15:

DDR4 ROW_COLUMN_BANK Mapping

SDRAM

app_addr Mapping

Rank

(RANK == 1) ? 1b0: app_addr[BANK_GROUP_WIDTH + BANK_WIDTH +

COL_WIDTH + ROW_WIDTH +: RANK_WIDTH]

Row

app_addr[BANK_GROUP_WIDTH + BANK_WIDTH + COL_WIDTH +: ROW_WIDTH

Column

app_addr[3 + BANK_GROUP_WIDTH + BANK_WIDTH +: COL_WIDTH 3],

app_addr[2:0]

Bank

app_addr[3 + BANK_GROUP_WIDTH +: BANK_WIDTH

Bank Group

app_addr[3 +: BANK_GROUP_WIDTH]

Table 4-16:

DDR4 4 GB (512 MB x8) Single Rank Mapping Example

SDRAM Bus

Row[14:0]

Column[9:0]

Bank[1:0]

Bank Group[1:0]

app_addr Bits

28 through 14

13 through 7, and 2, 1, 0

6, 5

4, 3

The ROW_COLUMN_BANK setting maps app_addr[4:3] to the DDR4 bank group bits or
DDR3 bank bits used by the controller to interleave between its group FSMs. The lower
order address bits equal to app_addr[5] and above map to the remaining SDRAM bank
and column address bits. The highest order address bits map to the SDRAM row. This
mapping is ideal for workloads that have address streams that increment linearly by a
constant step size of hex 8 for long periods. With this configuration and workload,
transactions sent to the user interface are evenly interleaved across the controller group
FSMs, making the best use of the controller resources.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

99

Chapter 4: Designing with the Core

In addition, this arrangement tends to generate hits to open pages in the SDRAM. The
combination of group FSM interleaving and SDRAM page hits results in very high SDRAM
data bus utilization.
Address streams other than the simple increment pattern tend to have lower SDRAM bus
utilization. You can recover this performance loss by tuning the mapping of your design flat
address space to the app_addr input port of the user interface. If you have knowledge of
your address sequence, you can add logic to map your address bits with the highest toggle
rate to the lowest app_addr bits, starting with app_addr[3] and working up from there.
For example, if you know that your workload address Bits[4:3] toggle much less than
Bits[10:9], which toggle at the highest rate, you could add logic to swap these bits so that
your address Bits[10:9] map to app_addr[4:3]. The result is an improvement in how the
address stream interleaves across the controller group FSMs, resulting in better controller
throughput and higher SDRAM data bus utilization.

app_cmd[2:0]
This input specifies the command for the request currently being submitted to the user
interface. The available commands are shown in Table 4-17. With ECC enabled, the
wr_bytes operation is required for writes with any non-zero app_wdf_mask bits. The
wr_bytes triggers a read-modify-write flow in the controller, which is needed only for
writes with masked data in ECC mode.
Table 4-17:

Commands for app_cmd[2:0]

Operation

app_cmd[2:0] Code

Write

000

Read

001

wr_bytes

011

app_autoprecharge
This input specifies the state of the A10 autoprecharge bit for the DRAM CAS command
for the request currently being submitted to the user interface. When this input is Low, the
Memory Controller issues a DRAM RD or WR CAS command. When this input is High, the
controller issues a DRAM RDA or WRA CAS command. This input provides per request
control, but can also be tied off to configure the controller statically for open or closed
page mode operation.

app_en
This input strobes in a request. Apply the desired values to app_addr[], app_cmd[2:0], and
app_hi_pri, and then assert app_en to submit the request to the user interface. This
initiates a handshake that the user interface acknowledges by asserting app_rdy.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

100

Chapter 4: Designing with the Core

app_wdf_data[APP_DATA_WIDTH 1:0]
This bus provides the data currently being written to the external memory.
APP_DATA_WIDTH is 2 nCK_PER_CLK DQ_WIDTH when ECC is disabled (ECC parameter
value is OFF) and 2 nCK_PER_CLK (DQ_WIDTH ECC_WIDTH) when ECC is enabled (ECC
parameter is ON).

app_wdf_end
This input indicates that the data on the app_wdf_data[] bus in the current cycle is the
last data for the current request.

app_wdf_mask[APP_MASK_WIDTH 1:0]
This bus indicates which bits of app_wdf_data[] are written to the external memory and
which bits remain in their current state. APP_MASK_WIDTH is APP_DATA_WIDTH/8.

app_wdf_wren
This input indicates that the data on the app_wdf_data[] bus is valid.

app_rdy
This output indicates whether the request currently being submitted to the user interface is
accepted. If the user interface does not assert this signal after app_en is asserted, the
current request must be retried. The app_rdy output is not asserted if:

PHY/Memory initialization is not yet completed.

All the controller Group FSMs are occupied (can be viewed as the command buffer
being full).

A read is requested and the read buffer is full.

A write is requested and no write buffer pointers are available.

A periodic read is being inserted.

app_rd_data[APP_DATA_WIDTH 1:0]
This output contains the data read from the external memory.

app_rd_data_end
This output indicates that the data on the app_rd_data[] bus in the current cycle is the
last data for the current request.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

101

Chapter 4: Designing with the Core

app_rd_data_valid
This output indicates that the data on the app_rd_data[] bus is valid.

app_wdf_rdy
This output indicates that the write data FIFO is ready to receive data. Write data is accepted
when both app_wdf_rdy and app_wdf_wren are asserted.

app_ref_req
When asserted, this active-High input requests that the Memory Controller send a refresh
command to the DRAM. It must be pulsed for a single cycle to make the request and then
deasserted at least until the app_ref_ack signal is asserted to acknowledge the request
and indicate that it has been sent.

app_ref_ack
When asserted, this active-High input acknowledges a refresh request and indicates that
the command has been sent from the Memory Controller to the PHY.

app_zq_req
When asserted, this active-High input requests that the Memory Controller send a ZQ
calibration command to the DRAM. It must be pulsed for a single cycle to make the request
and then deasserted at least until the app_zq_ack signal is asserted to acknowledge the
request and indicate that it has been sent.

app_zq_ack
When asserted, this active-High input acknowledges a ZQ calibration request and indicates
that the command has been sent from the Memory Controller to the PHY.

ui_clk_sync_rst
This is the reset from the user interface which is in synchronous with ui_clk.

ui_clk
This is the output clock from the user interface. It must be a quarter the frequency of the
clock going out to the external SDRAM, which depends on 4:1 mode selected in Vivado IDE.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

102

Chapter 4: Designing with the Core

init_calib_complete
PHY asserts init_calib_complete when calibration is finished. The application has no need to
wait for init_calib_complete before sending commands to the Memory Controller.

Command Path
When the user logic app_en signal is asserted and the app_rdy signal is asserted from the
user interface, a command is accepted and written to the FIFO by the user interface. The
command is ignored by the user interface whenever app_rdy is deasserted. The user logic
needs to hold app_en High along with the valid command, autoprecharge, and address
values until app_rdy is asserted as shown for the "write with autoprecharge" transaction in
Figure 4-2.
X-Ref Target - Figure 4-2

FON
DSSBFPG

:5,7(

DSSBDGGU

$GGU

DSSBDXWRSUHFKDUJH
DSSBHQ
&RPPDQGLVDFFHSWHGZKHQDSSBUG\LV+LJKDQGDSSBHQLV+LJK
DSSBUG\

Figure 4-2:

User Interface Command Timing Diagram with app_rdy Asserted

A non back-to-back write command can be issued as shown in Figure 4-3. This figure
depicts three scenarios for the app_wdf_data, app_wdf_wren, and app_wdf_end
signals as follows:
1. Write data is presented along with the corresponding write command.
2. Write data is presented before the corresponding write command.
3. Write data is presented after the corresponding write command, but should not exceed
the limitation of two clock cycles.
For write data that is output after the write command has been registered, as shown in
Note 3 (Figure 4-3), the maximum delay is two clock cycles.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

103

Chapter 4: Designing with the Core

X-Ref Target - Figure 4-3

FON
DSSBFPG

:5,7(

DSSBDGGU

$GGU
0D[LPXPDOORZHGGDWDGHOD\IURP
DGGUFPGLVWZRFORFNVDVVKRZQ
LQ(YHQW

DSSBHQ
DSSBUG\
DSSBZGIBPDVN
DSSBZGIBUG\
:

DSSBZGIBGDWD
DSSBZGIBZUHQ

DSSBZGIBHQG
:

DSSBZGIBGDWD
DSSBZGIBZUHQ

DSSBZGIBHQG

:

DSSBZGIBGDWD
DSSBZGIBZUHQ

DSSBZGIBHQG

Figure 4-3:

4:1 Mode User Interface Write Timing Diagram (Memory Burst Type = BL8)

Write Path
The write data is registered in the write FIFO when app_wdf_wren is asserted and
app_wdf_rdy is High (Figure 4-4). If app_wdf_rdy is deasserted, the user logic needs to
hold app_wdf_wren and app_wdf_end High along with the valid app_wdf_data value
until app_wdf_rdy is asserted. The app_wdf_mask signal can be used to mask out the
bytes to write to external memory.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

104

Chapter 4: Designing with the Core

X-Ref Target - Figure 4-4

FON
DSSBFPG

:5,7( :5,7( :5,7( :5,7( :5,7( :5,7( :5,7(

DSSBDGGU

$GGUD $GGUE $GGUF $GGUG $GGUH $GGUI $GGUJ

DSSBHQ
DSSBUG\
DSSBZGIBPDVN
DSSBZGIBUG\
DSSBZGIBGDWD

:D

:E

:F

:G

:H

:I

:J

DSSBZGIBZUHQ
DSSBZGIBHQG

Figure 4-4:

4:1 Mode User Interface Back-to-Back Write Commands Timing Diagram

(Memory Burst Type = BL8)

The timing requirement for app_wdf_data, app_wdf_wren, and app_wdf_end relative

to their associated write command is the same for back-to-back writes as it is for single
writes, as shown in Figure 4-3.
The map of the application interface data to the DRAM output data can be explained with
an example.
For a 4:1 Memory Controller to DRAM clock ratio with an 8-bit memory, at the application
interface, if the 64-bit data driven is 0000_0806_0000_0805 (Hex), the data at the DRAM
interface is as shown in Figure 4-5. This is for a BL8 (Burst Length 8) transaction.
X-Ref Target - Figure 4-5





)))







Figure 4-5:









)))





Data at the DRAM Interface for 4:1 Mode

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

105

Chapter 4: Designing with the Core

The data values at different clock edges are as shown in Table 4-18.
Table 4-18:

Data Values at Different Clock Edges

Rise0

Fall0

Rise1

Fall1

Rise2

Fall2

Rise3

Fall3

05

08

00

00

06

08

00

00

Table 4-19 shows a generalized representation of how DRAM DQ bus data is concatenated
to form application interface data signals. app_wdf_data is shown in Table 4-19, but the
table applies equally to app_rd_data. Each byte of the DQ bus has eight bursts, Rise0
(burst 0) through Fall3 (burst 7) as shown previously in Table 4-18, for a total of 64 data bits.
When concatenated with Rise0 in the LSB position and Fall3 in the MSB position, a 64-bit
chunk of the app_wdf_data signal is formed.
For example, the eight bursts of ddr3_dq[7:0] corresponds to DQ bus byte 0, and when
concatenated as described here, they map to app_wdf_data[63:0]. To be clear on the
concatenation order, ddr3_dq[0] from Rise0 (burst 0) maps to app_wdf_data[0], and
ddr3_dq[7] from Fall3 (burst 7) maps to app_wdf_data[63]. The table shows a second
example, mapping DQ byte 1 to app_wdf_data[127:64], as well as the formula for DQ
byte N.
Table 4-19:

DRAM DQ Bus Data Map

DQ Bus
Byte App Interface Signal

DDR Bus Signal at Each BL8 Burst Position

Fall3

Rise1

Fall0

Rise0

ddr3_dq[(N + 1)
8 1:N 8]

ddr3_dq[(N + 1)
8 1:N 8]

ddr3_dq[(N + 1)
8 1:N 8]

app_wdf_data[(N + 1)
64 1: N 64]

ddr3_dq[(N + 1)
8 1:N 8]

app_wdf_data[127:64]

ddr3_dq[15:8]

ddr3_dq[15:8]

ddr3_dq[15:8]

ddr3_dq[15:8]

app_wdf_data[63:0]

ddr3_dq[7:0]

ddr3_dq[7:0]

ddr3_dq[7:0]

ddr3_dq[7:0]

In a similar manner to the DQ bus mapping, the DM bus maps to app_wdf_mask by

concatenating the DM bits in the same burst order. Example for the first two bytes of the
DRAM bus are shown in Table 4-20, and the formula for mapping DM for byte N is also
given.
Table 4-20:

DRAM DM Bus Data Map

DM Bus App Interface Signal

Byte

DDR Bus Signal at Each BL8 Burst Position

Fall3

Rise1

Fall0

Rise0

app_wdf_mask[(N + 1)
8 1:N 8]

ddr3_dm[N]

ddr3_dm[N]

ddr3_dm[N]

ddr3_dm[N]

app_wdf_mask[15:0]

ddr3_dq[1]

ddr3_dm[1]

ddr3_dm[1]

ddr3_dm[1]

app_wdf_mask[7:0]

ddr3_dq[0]

ddr3_dm[0]

ddr3_dm[0]

ddr3_dm[0]

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

106

Chapter 4: Designing with the Core

Read Path
The read data is returned by the user interface in the requested order and is valid when
app_rd_data_valid is asserted (Figure 4-6 and Figure 4-7). The app_rd_data_end
signal indicates the end of each read command burst and is not needed in user logic.
X-Ref Target - Figure 4-6

FON
DSSBFPG

5($'

DSSBDGGU

$GGU

DSSBDXWRSUHFKDUJH
DSSBHQ
DSSBUG\
5

DSSBUGBGDWD
DSSBUGBGDWDBYDOLG

Figure 4-6:

4:1 Mode User Interface Read Timing Diagram (Memory Burst Type = BL8) #1

X-Ref Target - Figure 4-7

FON
DSSBFPG
DSSBDGGU

5($'
$GGU

$GGU

DSSBDXWRSUHFKDUJH
DSSBHQ
DSSBUG\
DSSBUGBGDWD

5

5

DSSBUGBGDWDBYDOLG

Figure 4-7:

4:1 Mode User Interface Read Timing Diagram (Memory Burst Type = BL8) #2

In Figure 4-7, the read data returned is always in the same order as the requests made on
the address/control bus.

Maintenance Commands
The UI can be configured by the Vivado IDE to enable two DRAM Refresh modes. The
default mode configures the UI and the Memory Controller to automatically generate
DRAM Refresh and ZQCS commands, meeting all DRAM protocol and timing requirements.
The controller interrupts normal system traffic on a regular basis to issue these
maintenance commands on the DRAM bus.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

107

Chapter 4: Designing with the Core

The User mode is enabled by checking the Enable User Refresh and ZQCS Input option in
the Vivado IDE. In this mode, you are responsible for issuing Refresh and ZQCS commands
at the rate required by the DRAM component specification after init_calib_complete asserts
High. You use the app_ref_req and app_zq_req signals on the UI to request Refresh and
ZQCS commands, and monitor app_ref_ack and app_zq_ack to know when the
commands have completed. The controller manages all DRAM timing and protocol for
these commands, other than the overall Refresh or ZQCS rate, just as it does for the default
DRAM Refresh mode. These request/ack ports operate independently of the other UI
command ports, like app_cmd and app_en.
The controller might not preserve the exact ordering of maintenance transactions
presented to the UI on relative to regular read and write transactions. When you request a
Refresh or ZQCS, the controller interrupts system traffic, just as in the default mode, and
inserts the maintenance commands. To take the best advantage of this mode, you should
request maintenance commands when the controller is idle or at least not very busy,
keeping in mind that the DRAM Refresh rate and ZQCS rate requirements cannot be
violated.
Figure 4-8 shows how the User mode ports are used and how they affect the DRAM
command bus. This diagram shows the general idea about this mode of operation and is
not timing accurate. Assuming the DRAM is idle with all banks closed, a short time after
app_ref_req or app_zq_req are asserted High for one system clock cycle, the controller
issues the requested commands on the DRAM command bus. The app_ref_req and
app_zq_req can be asserted on the same cycle or different cycles, and they do not have to
be asserted at the same rate. After a request signal is asserted High for one system clock,
you must keep it deasserted until the acknowledge signal asserts.
X-Ref Target - Figure 4-8

V\VWHPFON
DSSBFPG
DSSBHQ
DSSBUG\
DSSBUHIBUHT
DSSB]TBUHT
DSSBUHIBUHT
DSSB]TBUHT

'5$0FON
'5$0FPG

123

5HIUHVK

=4&6

&6BQ

W5)&

Figure 4-8:

W=4&6

User Mode Ports on DRAM Command Bus Timing Diagram

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

108

Chapter 4: Designing with the Core

Figure 4-9 shows a case where the app_en is asserted and read transactions are presented
continuously to the UI when the app_ref_req and app_zq_req are asserted. The
controller interrupts the DRAM traffic following DRAM protocol and timing requirements,
issues the Refresh and ZQCS, and then continues issuing the read transactions. Note that
the app_rdy signal deasserts during this sequence. It is likely to deassert during a
sequence like this since the controller command queue can easily fill up during tRFC or
tZQCS. After the maintenance commands are issued and normal traffic resumes on the bus,
the app_rdy signal asserts and new transactions are accepted again into the controller.
X-Ref Target - Figure 4-9

V\VWHPFON
DSSBFPG

5HDG

DSSBHQ
DSSBUG\
DSSBUHIBUHT
DSSB]TBUHT
DSSBUHIBUHT
DSSB]TBUHT

'5$0FON
'5$0FPG

5HDG&$6

3UH&KDUJH

5HIUHVK

$FWLYDWH

=4&6

5HDG&$6

&6BQ

W573

Figure 4-9:

W53

W5)&

W=4&6

Read Transaction on User Interface Timing Diagram

Figure 4-9 shows the operation for a single rank. In a multi-rank system, a single refresh
request generates a DRAM Refresh command to each rank, in series, staggered by tRFC/2.
The Refresh commands are staggered since they are relatively high power consumption
operations. A ZQCS command request generates a ZQCS command to all ranks in parallel.

AXI4 Slave Interface

The AXI4 slave interface block maps AXI4 transactions to the UI to provide an
industry-standard bus protocol interface to the Memory Controller. The AXI4 slave interface
is optional in designs provided through the DDR3/DDR4 SDRAM tool. The RTL is consistent
between both tools. For details on the AXI4 signaling protocol, see the ARM AMBA
specifications [Ref 7].
The overall design is composed of separate blocks to handle each AXI channel, which allows
for independent read and write transactions. Read and write commands to the UI rely on a
simple round-robin arbiter to handle simultaneous requests. The address read/address
write modules are responsible for chopping the AXI4 burst/wrap requests into smaller

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

109

Chapter 4: Designing with the Core

memory size burst lengths of either four or eight, and also conveying the smaller burst
lengths to the read/write data modules so they can interact with the user interface.
If ECC is enabled, all write commands with any of the mask bits enabled are issued as
read-modify-write operation.
Also if ECC is enabled, all write commands with none of the mask bits enabled are issued as
write operation.

AXI4 Slave Interface Parameters

Table 4-21 lists the AXI4 slave interface parameters.
Table 4-21:

AXI4 Slave Interface Parameters

Parameter Name

Default Value

Allowable Values

Description

C_S_AXI_ADDR_WIDTH

32

32

This is the width of address read

and address write signals. This
value must be set to 32.

C_S_AXI_DATA_WIDTH

32

32, 64, 128, 256, 512

This is the width of data signals.

Width of APP_DATA_WIDTH is
recommended for better
performance. Using a smaller
width invokes an Upsizer, which
would spend clocks in packing
the data.

C_S_AXI_ID_WIDTH

1 16

This is the width of ID signals for

every channel.

0, 1

This parameter adds logic

blocks to support narrow AXI
transfers. It is required if any
master connected to the
Memory Controller issues
narrow bursts. This parameter is
automatically set if the AXI data
width is smaller than the
recommended value.

RD_PRI_REG

TDM, ROUND_ROBIN,
RD_PRI_REG,
RD_PRI_REG_STARVE_LIMI
T, WRITE_PRIORITY_REG,
WRITE_PRIORITY

This parameter indicates the

Arbitration algorithm scheme.
See Arbitration in AXI Shim,
page 113 for more information.

C_S_AXI_SUPPORTS_NARROW_
BURST

C_RD_WR_ARB_ALGORITHM

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

110

Chapter 4: Designing with the Core

Table 4-21:

AXI4 Slave Interface Parameters (Contd)

Parameter Name

Default Value

C_S_AXI_BASEADDR

Allowable Values

Description

Valid address

This parameter specifies the

base address for the memory
mapped slave interface. Address
requests at this address map to
rank 1, bank 0, row 0, column 0.
The base/high address together
define the accessible size of the
memory. This accessible size
must be a power of two.
Additionally, the base/high
address pair must be aligned to
a multiple of the accessible size.
The minimum accessible size is
4,096 bytes.

C_S_AXI_HIGHADDR

Valid address

This parameter specifies the

high address for the memory
mapped slave interface. Address
requests received above this
value wrap back to the base
address. The base/high address
together define the accessible
size of the memory. This
accessible size must be a power
of two. Additionally, the base/
high address pair must be
aligned to a multiple of the
accessible size. The minimum
accessible size is 4,096 bytes.

C_S_AXI_PROTOCOL

AXI4

AXI4

This parameter specifies the AXI

protocol.

AXI4 Slave Interface Signals

Table 4-22 lists the AXI4 slave interface specific signal. ui_clk and ui_clk_sync_rst to
the interface is provided from the Memory Controller. AXI interface is synchronous to
ui_clk.
Table 4-22:

AXI4 Slave Interface Signals

Name

Width

Direction Active State

Description

ui_clk

Output

Output clock from the core to the

interface.

ui_clk_sync_rst

Output

High

Output reset from the core to the

interface.

aresetn

Input

Low

Input reset to the AXI Shim and it

should be in synchronous with FPGA
logic clock.

s_axi_awid

C_AXI_ID_WIDTH

Input

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Write address ID

Send Feedback

111

Chapter 4: Designing with the Core

Table 4-22:

AXI4 Slave Interface Signals (Contd)

Name

Width

Direction Active State

Description

s_axi_awaddr

C_AXI_ADDR_WIDTH

Input

Write address

s_axi_awlen

Input

Burst length. The burst length gives the

exact number of transfers in a burst.

s_axi_awsize

Input

Burst size. This signal indicates the size

of each transfer in the burst.

s_axi_awburst

Input

Burst type

s_axi_awlock

Input

Lock type. (This is not used in the

current implementation.)

s_axi_awcache

Input

Cache type. (This is not used in the

current implementation.)

s_axi_awprot

Input

Protection type. (Not used in the

current implementation.)

s_axi_awvalid

Input

High

Write address valid. This signal

indicates that valid write address and
control information are available.

High

Write address ready. This signal

indicates that the slave is ready to
accept an address and associated
control signals.

s_axi_awready

Output

s_axi_wdata

C_AXI_DATA_WIDTH

Input

Write data

s_axi_wstrb

C_AXI_DATA_WIDTH/8

Input

Write strobes

s_axi_wlast

Input

High

Write last. This signal indicates the last

transfer in a write burst.

s_axi_wvalid

Input

High

Write valid. This signal indicates that

write data and strobe are available.

s_axi_wready

Output

High

Write ready

s_axi_bid

C_AXI_ID_WIDTH

Output

Response ID. The identification tag of

the write response.

s_axi_bresp

Output

Write response. This signal indicates

the status of the write response.

s_axi_bvalid

Output

High

Write response valid

s_axi_bready

Input

High

Response ready

s_axi_arid

C_AXI_ID_WIDTH

Input

Read address ID

s_axi_araddr

C_AXI_ADDR_WIDTH

Input

Read address

s_axi_arlen

Input

Read burst length

s_axi_arsize

Input

Read burst size

s_axi_arburst

Input

Read burst type

s_axi_arlock

Input

Lock type. (This is not used in the

current implementation.)

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

112

Chapter 4: Designing with the Core

Table 4-22:

AXI4 Slave Interface Signals (Contd)

Name

Width

Direction Active State

Description

s_axi_arcache

Input

Cache type. (This is not used in the

current implementation.)

s_axi_arprot

Input

Protection type. (This is not used in the

current implementation.)

s_axi_arvalid

Input

High

Read address valid

s_axi_arready

Output

High

Read address ready

s_axi_rid

C_AXI_ID_WIDTH

Output

Read ID tag

s_axi_rdata

C_AXI_DATA_WIDTH

Output

Read data

s_axi_rresp

Output

Read response

s_axi_rlast

Output

Read last

s_axi_rvalid

Output

Read valid

s_axi_rready

Input

Read ready

dbg_clk

Output

Debug Clock. Do not connect any

signals to dbg_clk and keep the port
open during instantiation.

Arbitration in AXI Shim

The AXI4 protocol calls for independent read and write address channels. The Memory
Controller has one address channel. The following arbitration options are available for
arbitrating between the read and write address channels.

Time Division Multiplexing (TDM)

Equal priority is given to read and write address channels in this mode. The grant to the
read and write address channels alternate every clock cycle. The read or write requests from
the AXI master has no bearing on the grants. For example, the read requests are served in
alternative clock cycles, even when there are no write requests. The slots are fixed and they
are served in their respective slots only.

Round-Robin
Equal priority is given to read and write address channels in this mode. The grant to the
read and write channels depends on the last served request granted from the AXI master.
For example, if the last performed operation is write, then it gives precedence for read
operation to be served over write operation. Similarly, if the last performed operation is
read, then it gives precedence for write operation to be served over read operation. If both
read and write channels requests at the same time when there are no pending requests, this
scheme serves write channel ahead of read.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

113

Chapter 4: Designing with the Core

Read Priority (RD_PRI_REG)

Read and write address channels are served with equal priority in this mode. The requests
from the write address channel are processed when one of the following occurs:

No pending requests from read address channel.

Read starve limit of 256 is reached. It is only checked at the end of the burst.

Read wait limit of 16 is reached.

Write Quality of Service (QoS) is higher which is non-zero. It is only checked at the end
of the burst.

The requests from the read address channel are processed in a similar method.

Read Priority with Starve Limit (RD_PRI_REG_STARVE_LIMIT)

The read address channel is always given priority in this mode. The requests from the write
address channel are processed when there are no pending requests from the read address
channel or the starve limit for read is reached.

Write Priority (WRITE_PRIORITY, WRITE_PRIORITY_REG)

Write address channel is always given priority in this mode. The requests from the read
address channel are processed when there are no pending requests from the write address
channel. Arbitration outputs are registered in WRITE_PRIORITY_REG mode.

AXI4-Lite Slave Control/Status Register Interface Block

The AXI4-Lite Slave Control register block provides a processor accessible interface to the
ECC memory option. The interface is available when ECC is enabled and the primary slave
interface is AXI4. The block provides interrupts, interrupt enable, ECC status, ECC enable/
disable, ECC correctable errors counter, first failing correctable/uncorrectable data, ECC,
and address. Fault injection registers for software testing is provided when the
ECC_TEST_FI_XOR (C_ECC_TEST) parameter is ON. The AXI4-Lite interface is fixed at 32
data bits and signaling follows the standard AMBA AXI4-Lite specifications [Ref 7].
The AXI4-Lite Control/Status register interface block is implemented in parallel to the AXI4
memory-mapped interface. The block monitors the output of the native interface to
capture correctable (single bit) and uncorrectable (multiple bit) errors. When a correctable
and/or uncorrectable error occurs, the interface also captures the byte address of the failure
along with the failing data bits and ECC bits. Fault injection is provided by an XOR block
placed in the write datapath after the ECC encoding has occurred. Only the first memory
beat in a transaction can have errors inserted. For example, in a memory configuration with
a data width of 72 and a mode register set to burst length 8, only the first 72 bits are
corruptible through the fault injection interface. Interrupt generation based on either a
correctable or uncorrectable error can be independently configured with the register
interface.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

114

Chapter 4: Designing with the Core

ECC Enable/Disable
The ECC_ON_OFF register enables/disables the ECC decode functionality. However,
encoding is always enabled. The default value at start-up can be parameterized with
C_ECC_ONOFF_RESET_VALUE. Assigning a value of 1 for the ECC_ON_OFF bit of this register
results in the correct_en signal input into the mem_intfc to be asserted. Writing a value
of 0 to the ECC_ON_OFF bit of this register results in the correct_en signal to be
deasserted. When correct_en is asserted, decoding is enabled, and the opposite is true
when this signal is deasserted. ECC_STATUS/ECC_CE_CNT are not updated when
ECC_ON_OFF = 0. The FI_D0, FI_D1, FI_D2, and FI_D3 registers are not writable when
ECC_ON_OFF = 0.

Single Error and Double Error Reporting

Two vectored signals from the Memory Controller indicate an ECC error: ecc_single and
ecc_multiple. The ecc_single signal indicates if there has been a correctable error and
the ecc_multiple signal indicates if there has been an uncorrectable error. The widths of
ecc_multiple and ecc_single are based on the C_NCK_PER_CLK parameter. There can
be between 0 and C_NCK_PER_CLK 2 errors per cycle with each data beat signaled by one
of the vector bits. Multiple bits of the vector can be signaled per cycle indicating that
multiple correctable errors or multiple uncorrectable errors have been detected. The
ecc_err_addr signal (discussed in Fault Collection) is valid during the assertion of either
ecc_single or ecc_multiple.
The ECC_STATUS register sets the CE_STATUS bit and/or UE_STATUS bit for correctable error
detection and uncorrectable error detection, respectively.
CAUTION! Multiple bit error is a serious failure of memory because it is uncorrectable. In such cases,

application cannot rely on contents of the memory. It is suggested to not perform any further
transactions to memory.

Interrupt Generation
When interrupts are enabled with the CE_EN_IRQ and/or UE_EN_IRQ bits of the ECC_EN_IRQ
register, and a correctable error or uncorrectable error occurs, the interrupt signal is
asserted.

Fault Collection
To aid the analysis of ECC errors, there are two banks of storage registers that collect
information on the failing ECC decode. One bank of registers is for correctable errors, and
another bank is for uncorrectable errors. The failing address, undecoded data, and ECC bits
are saved into these register banks as CE_FFA, CE_FFD, and CE_FFE for correctable errors.
UE_FFA, UE_FFD, and UE_FFE are for uncorrectable errors. The data in combination with the
ECC bits can help determine which bit(s) have failed. CE_FFA stores the address from the
ecc_err_addr signal and converts it to a byte address. Upon error detection, the data is
latched into the appropriate register. Only the first data beat with an error is stored.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

115

Chapter 4: Designing with the Core

When a correctable error occurs, there is also a counter that counts the number of
correctable errors that have occurred. The counter can be read from the CE_CNT register
and is fixed as an 8-bit counter. It does not rollover when the maximum value is
incremented.

Fault Injection
The ECC Fault Injection registers, FI_D and FI_ECC, facilitates testing of the software drivers.
When set, the ECC Fault Injection register XORs with the DDR3/DDR4 SDRAM DFI datapath
to simulate errors in the memory. The DFI interface lies between the Memory Controller and
the PHY. It is ideal for injection to occur here because this is after the encoding has been
completed. There is only support to insert errors on the first data beat, therefore there are
two to four FI_D registers to accommodate this. During operation, after the error has been
inserted into the datapath, the register clears itself.

AXI4-Lite Slave Control/Status Register Interface Parameters

Table 4-23 lists the AXI4-Lite slave interface parameters.
Table 4-23:

AXI4-Lite Slave Control/Status Register Parameters

Parameter Name

Default
Value

Allowable
Values

Description

C_S_AXI_CTRL_ADDR_WIDTH

32

32, 64

This is the width of the AXI4-Lite address buses.

C_S_AXI_CTRL_DATA_WIDTH

32

32

This is the width of the AXI4-Lite data buses.

C_ECC_ONOFF_RESET_VALUE

0, 1

Controls ECC on/off value at startup/reset.

C_S_AXI_CTRL_BASEADDR

Valid Address

This parameter specifies the base address for

the AXI4-Lite slave interface.

C_S_AXI_CTRL_HIGHADDR

Valid Address

This parameter specifies the high address for

the AXI4-Lite slave interface.

C_S_AXI_CTRL_PROTOCOL

AXI4LITE

AXI4LITE

AXI4-Lite protocol

AXI4-Lite Slave Control/Status Register Interface Signals

Table 4-24 lists the AXI4 slave interface specific signals. Clock/reset to the interface is
provided from the Memory Controller.
Table 4-24:

List of New I/O Signals

Active
State

Name

Width

Direction

s_axi_ctrl_awaddr

C_S_AXI_CTRL_ADDR_WIDTH

Input

Write address

Input

Write address valid. This signal

indicates that valid write address
and control information are
available.

s_axi_ctrl_awvalid

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

High

Description

Send Feedback

116

Chapter 4: Designing with the Core

Table 4-24:

List of New I/O Signals (Contd)

Name

Width

Direction

Active
State

Description

High

Write address ready. This signal

indicates that the slave is ready to
accept an address and associated
control signals.

s_axi_ctrl_awready

Output

s_axi_ctrl_wdata

C_S_AXI_CTRL_DATA_WIDTH

Input

s_axi_ctrl_wvalid

Input

High

Write valid. This signal indicates that

write data and strobe are available.

s_axi_ctrl_wready

Output

High

Write ready

s_axi_ctrl_bvalid

Output

High

Write response valid

s_axi_ctrl_bready

Input

High

Response ready

s_axi_ctrl_araddr

C_S_AXI_CTRL_ADDR_WIDTH

Input

s_axi_ctrl_arvalid

Input

High

Read address valid

s_axi_ctrl_arready

Output

High

Read address

s_axi_ctrl_rdata

C_S_AXI_CTRL_DATA_WIDTH

Output

Read data

s_axi_ctrl_rvalid

Output

Read valid

s_axi_ctrl_rready

Input

Read ready

interrupt

Output

Write data

Read address

High

IP Global Interrupt signal

AXI4-Lite Slave Control/Status Register Map

ECC register map is shown in Table 4-25. The register map is Little Endian. Write accesses to
read-only or reserved values are ignored. Read accesses to write-only or reserved values
return the value 0xDEADDEAD.
Table 4-25:

ECC Control Register Map

Address Offset

Register Name

Access
Type

Default
Value

Description

0x00

ECC_STATUS

R/W

0x0

ECC Status Register

0x04

ECC_EN_IRQ

R/W

0x0

ECC Enable Interrupt Register

0x08

ECC_ON_OFF

R/W

0x0 or
0x1

ECC On/Off Register. If C_ECC_ONOFF_RESET_

VALUE = 1, the default value is 0x1.

0x0C

CE_CNT

R/W

0x0

Correctable Error Count Register

(0x100x9C) Reserved
0x100

CE_FFD[31:00]

0x104

CE_FFD[63:32]
(1)

0x108

CE_FFD[95:64]

0x10C

CE_FFD [127:96](1)

0x0

Correctable Error First Failing Data Register

0x0

Correctable Error First Failing Data Register

0x0

Correctable Error First Failing Data Register

0x0

Correctable Error First Failing Data Register

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

117

Chapter 4: Designing with the Core

Table 4-25:

ECC Control Register Map (Contd)

Address Offset

Register Name

Access
Type

Default
Value

Description

(0x1100x17C) Reserved
0x180

CE_FFE

0x0

Correctable Error First Failing ECC Register

(0x1840x1BC) Reserved
0x1C0

CE_FFA[31:0]

0x0

Correctable Error First Failing Address

0x1C4

CE_FFA[63:32](2)

0x0

Correctable Error First Failing Address

(0x1C80x1FC) Reserved
0x200

UE_FFD [31:00]

0x204

UE_FFD [63:32]

0x208

UE_FFD [95:64]

0x20C

UE_FFD
[127:96](1)

(1)

0x0

Uncorrectable Error First Failing Data Register

0x0

Uncorrectable Error First Failing Data Register

0x0

Uncorrectable Error First Failing Data Register

0x0

Uncorrectable Error First Failing Data Register

(0x2100x27C) Reserved
0x280

UE_FFE

0x0

Uncorrectable Error First Failing ECC Register

(0x2840x2BC) Reserved
0x2C0

UE_FFA[31:0]

0x0

Uncorrectable Error First Failing Address

0x2C4

UE_FFA[63:32](2)

0x0

Uncorrectable Error First Failing Address

(0x2C80x2FC) Reserved
0x300

FI_D[31:0] (3)
(3)

0x0

Fault Inject Data Register

0x0

Fault Inject Data Register

0x304

FI_D[63:32]

0x308

FI_D[95:64] (1)(3)

0x0

Fault Inject Data Register

0x30C

FI_D[127:96] (1)(3)

0x0

Fault Inject Data Register

0x380

FI_ECC (3)

(0x3400x37C) Reserved
W

0x0

Fault Inject ECC Register

Notes:
1. Data bits 64127 are only enabled if the DQ width is 144 bits.
2. Reporting address bits 6332 are only available if the address map is > 32 bits.
3. FI_D* and FI_ECC* are only enabled if ECC_TEST parameter has been set to 1.

AXI4-Lite Slave Control/Status Register Map Detailed Descriptions

ECC_STATUS
This register holds information on the occurrence of correctable and uncorrectable errors.
The status bits are independently set to 1 for the first occurrence of each error type. The
status bits are cleared by writing a 1 to the corresponding bit position; that is, the status bits
can only be cleared to 0 and not set to 1 using a register write. The ECC Status register
operates independently of the ECC Enable Interrupt register.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

118

Chapter 4: Designing with the Core

Table 4-26:

ECC Status Register

Bits

Name

Core
Access

Reset
Value

Description

CE_STATUS

R/W

If 1, a correctable error has occurred. This bit is cleared when a 1

is written to this bit position.

UE_STATUS

R/W

If 1, an uncorrectable error has occurred. This bit is cleared when

a 1 is written to this bit position.

ECC_EN_IRQ
This register determines if the values of the CE_STATUS and UE_STATUS bits in the ECC
Status register assert the Interrupt output signal (ECC_Interrupt). If both CE_EN_IRQ and
UE_EN_IRQ are set to 1 (enabled), the value of the Interrupt signal is the logical OR between
the CE_STATUS and UE_STATUS bits.
Table 4-27:
Bits

ECC Interrupt Enable Register

Name

CE_EN_IRQ

UE_EN_IRQ

Core
Access
R/W

R/W

Reset
Value

Description

If 1, the value of the CE_STATUS bit of ECC Status register is

propagated to the Interrupt signal. If 0, the value of the
CE_STATUS bit of ECC Status register is not propagated to the
Interrupt signal.

If 1, the value of the UE_STATUS bit of ECC Status register is

propagated to the Interrupt signal. If 0, the value of the
UE_STATUS bit of ECC Status register is not propagated to the
Interrupt signal.

ECC_ON_OFF
The ECC On/Off Control register allows the application to enable or disable ECC checking.
The design parameter, C_ECC_ONOFF_RESET_VALUE (default on) determines the reset value
for the enable/disable setting of ECC. This facilitates start-up operations when ECC might or
might not be initialized in the external memory. When disabled, ECC checking is disabled
for read but ECC generation is active for write operations.
Table 4-28:
Bits

ECC On/Off Control Register

Name

ECC_ON_OFF

Core
Reset Value
Access

R/W

Specified by
design
parameter,
C_ECC_ONOFF_
RESET_VALUE

Description
If 0, ECC checking is disabled on read operations. (ECC
generation is enabled on write operations when C_ECC = 1).
If 1, ECC checking is enabled on read operations. All
correctable and uncorrectable error conditions are captured
and status is updated.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

119

Chapter 4: Designing with the Core

CE_CNT
This register counts the number of occurrences of correctable errors. It can be cleared or
preset to any value using a register write. When the counter reaches its maximum value, it
does not wrap around, but instead it stops incrementing and remains at the maximum
value. The width of the counter is defined by the value of the C_CE_COUNTER_WIDTH
parameter. The value of the CE counter width is fixed to eight bits.
Table 4-29:

Correctable Error Counter Register

Bits

Name

Core Access

Reset Value

Description

7:0

CE_CNT

R/W

Holds the number of correctable errors encountered.

CE_FFA[31:0]
This register stores the lower 32 bits of the decoded DRAM address (Bits[31:0]) of the first
occurrence of an access with a correctable error. The address format is defined in Table 3-1,
page 25. When the CE_STATUS bit in the ECC Status register is cleared, this register is
re-enabled to store the address of the next correctable error. Storing of the failing address
is enabled after reset.
Table 4-30:

Correctable Error First Failing Address [31:0] Register

Bits

Name

Core Access

Reset Value

Description

31:0

CE_FFA[31:0]

Address (Bits[31:0]) of the first occurrence of a

correctable error.

CE_FFA[63:32]
This register stores the upper 32 bits of the decoded DRAM address (Bits[55:32]) of the first
occurrence of an access with a correctable error. The address format is defined in Table 3-1,
page 25. In addition, the upper byte of this register stores the ecc_single signal. When
the CE_STATUS bit in the ECC Status register is cleared, this register is re-enabled to store
the address of the next correctable error. Storing of the failing address is enabled after
reset.
Table 4-31:
Bits

Correctable Error First Failing Address [63:32] Register

Name

Core Access

Reset Value

Description

31:24

CD_FFA[63:56]

ecc_single[7:0]. Indicates which bursts of the BL8

transaction associated with the logged address had
a correctable error. Bit[24] corresponds to the first
burst of the BL8 transfer.

23:0

CD_FFA[55:32]

Address (Bits[55:32]) of the first occurrence of a

correctable error.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

120

Chapter 4: Designing with the Core

CE_FFD[31:0]
This register stores the (corrected) failing data (Bits[31:0]) of the first occurrence of an
access with a correctable error. When the CE_STATUS bit in the ECC Status register is cleared,
this register is re-enabled to store the data of the next correctable error. Storing of the
failing data is enabled after reset.
Table 4-32:

Correctable Error First Failing Data [31:0] Register

Bits

Name

Core Access

Reset Value

Description

31:0

CE_FFD[31:0]

Data (Bits[31:0]) of the first occurrence of a

correctable error.

CE_FFD[63:32]
This register stores the (corrected) failing data (Bits[63:32]) of the first occurrence of an
access with a correctable error. When the CE_STATUS bit in the ECC Status register is cleared,
this register is re-enabled to store the data of the next correctable error. Storing of the
failing data is enabled after reset.
Table 4-33:

Correctable Error First Failing Data [63:32] Register

Bits

Name

Core Access

Reset Value

Description

31:0

CE_FFD[63:32]

Data (Bits[63:32]) of the first occurrence of a

correctable error.

CE_FFD[95:64]
Note: This register is only used when DQ_WIDTH == 144.
This register stores the (corrected) failing data (Bits[95:64]) of the first occurrence of an
access with a correctable error. When the CE_STATUS bit in the ECC Status register is cleared,
this register is re-enabled to store the data of the next correctable error. Storing of the
failing data is enabled after reset.
Table 4-34:

Correctable Error First Failing Data [95:64] Register

Bits

Name

Core Access

Reset Value

Description

31:0

CE_FFD[95:64]

Data (Bits[95:64]) of the first occurrence of a

correctable error.

CE_FFD[127:96]
Note: This register is only used when DQ_WIDTH == 144.
This register stores the (corrected) failing data (Bits[127:96]) of the first occurrence of an
access with a correctable error. When the CE_STATUS bit in the ECC Status register is cleared,
this register is re-enabled to store the data of the next correctable error. Storing of the
failing data is enabled after reset.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

121

Chapter 4: Designing with the Core

Table 4-35:

Correctable Error First Failing Data [127:96] Register

Bits

Name

Core Access

Reset Value

Description

31:0

CE_FFD [127:96]

Data (Bits[127:96]) of the first occurrence of a

correctable error.

CE_FFE
This register stores the ECC bits of the first occurrence of an access with a correctable error.
When the CE_STATUS bit in the ECC Status register is cleared, this register is re-enabled to
store the ECC of the next correctable error. Storing of the failing ECC is enabled after reset.
Table 4-36 describes the register bit usage when DQ_WIDTH = 72.
Table 4-36:

Correctable Error First Failing ECC Register for 72-Bit External Memory Width

Bits

Name

Core Access

Reset Value

Description

7:0

CE_FFE

ECC (Bits[7:0]) of the first occurrence of a correctable

error.

Table 4-37 describes the register bit usage when DQ_WIDTH = 144.
Table 4-37:

Correctable Error First Failing ECC Register for 144-Bit External Memory Width

Bits

Name

Core Access

Reset Value

Description

15:0

CE_FFE

ECC (Bits[15:0]) of the first occurrence of a

correctable error.

UE_FFA[31:0]
This register stores the decoded DRAM address (Bits[31:0]) of the first occurrence of an
access with an uncorrectable error. The address format is defined in Table 3-1, page 25.
When the UE_STATUS bit in the ECC Status register is cleared, this register is re-enabled to
store the address of the next uncorrectable error. Storing of the failing address is enabled
after reset.
Table 4-38:

Uncorrectable Error First Failing Address [31:0] Register

Bits

Name

Core Access

Reset Value

Description

31:0

UE_FFA [31:0]

Address (Bits[31:0]) of the first occurrence of an

uncorrectable error.

UE_FFA[63:32]
This register stores the decoded address (Bits[55:32]) of the first occurrence of an access
with an uncorrectable error. The address format is defined in Table 3-1, page 25. In addition,
the upper byte of this register stores the ecc_multiple signal. When the UE_STATUS bit
in the ECC Status register is cleared, this register is re-enabled to store the address of the
next uncorrectable error. Storing of the failing address is enabled after reset.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

122

Chapter 4: Designing with the Core

Table 4-39:
Bits

Uncorrectable Error First Failing Address [31:0] Register

Name

Core Access

Reset Value

Description

31:24

CD_FFA[63:56]

ecc_multiple[7:0]. Indicates which bursts of the BL8

transaction associated with the logged address had
an uncorrectable error. Bit[24] corresponds to the
first burst of the BL8 transfer.

23:0

CD_FFA[55:32]

Address (Bits[55:32]) of the first occurrence of a

correctable error.

UE_FFD[31:0]
This register stores the (uncorrected) failing data (Bits[31:0]) of the first occurrence of an
access with an uncorrectable error. When the UE_STATUS bit in the ECC Status register is
cleared, this register is re-enabled to store the data of the next uncorrectable error. Storing
of the failing data is enabled after reset.
Table 4-40:

Uncorrectable Error First Failing Data [31:0] Register

Bits

Name

Core Access

Reset Value

Description

31:0

UE_FFD[31:0]

Data (Bits[31:0]) of the first occurrence of an

uncorrectable error.

UE_FFD[63:32]
This register stores the (uncorrected) failing data (Bits[63:32]) of the first occurrence of an
access with an uncorrectable error. When the UE_STATUS bit in the ECC Status register is
cleared, this register is re-enabled to store the data of the next uncorrectable error. Storing
of the failing data is enabled after reset.
Table 4-41:

Uncorrectable Error First Failing Data [63:32] Register

Bits

Name

Core Access

Reset Value

Description

31:0

UE_FFD [63:32]

Data (Bits[63:32]) of the first occurrence of an

uncorrectable error.

UE_FFD[95:64]
Note: This register is only used when the DQ_WIDTH == 144.
This register stores the (uncorrected) failing data (Bits[95:64]) of the first occurrence of an
access with an uncorrectable error. When the UE_STATUS bit in the ECC Status register is
cleared, this register is re-enabled to store the data of the next uncorrectable error. Storing
of the failing data is enabled after reset.
Table 4-42:

Uncorrectable Error First Failing Data [95:64] Register

Bits

Name

Core Access

Reset Value

Description

31:0

UE_FFD[95:64]

Data (Bits[95:64]) of the first occurrence of an

uncorrectable error.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

123

Chapter 4: Designing with the Core

UE_FFD[127:96]
Note: This register is only used when the DQ_WIDTH == 144.
This register stores the (uncorrected) failing data (Bits[127:96]) of the first occurrence of an
access with an uncorrectable error. When the UE_STATUS bit in the ECC Status register is
cleared, this register is re-enabled to store the data of the next uncorrectable error. Storing
of the failing data is enabled after reset.
Table 4-43:

Uncorrectable Error First Failing Data [127:96] Register

Bits

Name

Core Access

Reset Value

Description

31:0

UE_FFD[127:96]

Data (Bits[127:96]) of the first occurrence of an

uncorrectable error.

UE_FFE
This register stores the ECC bits of the first occurrence of an access with an uncorrectable
error. When the UE_STATUS bit in the ECC Status register is cleared, this register is
re-enabled to store the ECC of the next uncorrectable error. Storing of the failing ECC is
enabled after reset.
Table 4-44 describes the register bit usage when DQ_WIDTH = 72.
Table 4-44:

Uncorrectable Error First Failing ECC Register for 72-Bit External Memory Width

Bits

Name

Core Access

Reset Value

Description

7:0

UE_FFE

ECC (Bits[7:0]) of the first occurrence of an

uncorrectable error.

Table 4-45 describes the register bit usage when DQ_WIDTH = 144.
Table 4-45:

Uncorrectable Error First Failing ECC Register for 144-Bit External Memory Width

Bits

Name

Core Access

Reset Value

Description

15:0

UE_FFE

ECC (Bits[15:0]) of the first occurrence of an

uncorrectable error.

FI_D0
This register is used to inject errors in data (Bits[31:0]) written to memory and can be used
to test the error correction and error signaling. The bits set in the register toggle the
corresponding data bits (word 0 or Bits[31:0]) of the subsequent data written to the
memory without affecting the ECC bits written. After the fault has been injected, the Fault
Injection Data register is cleared automatically.
The register is only implemented if C_ECC_TEST = ON or ECC_TEST_FI_XOR = ON and
ECC = ON in a DDR3/DDR4 SDRAM design in the Vivado IP catalog.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

124

Chapter 4: Designing with the Core

Injecting faults should be performed in a critical region in software; that is, writing this
register and the subsequent write to the memory must not be interrupted.
Table 4-46:

Fault Injection Data (Word 0) Register

Bits

Name

Core Access

Reset Value

Description

31:0

FI_D0

Bit positions set to 1 toggle the corresponding Bits[31:0] of

the next data word written to the memory. This register is
automatically cleared after the fault has been injected.

Special consideration must be given across FI_D0, FI_D1, FI_D2, and FI_D3 such that only a
single error condition is introduced.

FI_D1
This register is used to inject errors in data (Bits[63:32]) written to memory and can be used
to test the error correction and error signaling. The bits set in the register toggle the
corresponding data bits (word 1 or Bits[63:32]) of the subsequent data written to the
memory without affecting the ECC bits written. After the fault has been injected, the Fault
Injection Data register is cleared automatically.
This register is only implemented if C_ECC_TEST = ON or ECC_TEST_FI_XOR = ON and
ECC = ON in a DDR3/DDR4 SDRAM design in the Vivado IP catalog.
Injecting faults should be performed in a critical region in software; that is, writing this
register and the subsequent write to the memory must not be interrupted.
Table 4-47:
Bits
31:0

Fault Injection Data (Word 1) Register

Name
FI_D1

Core Access
W

Reset Value

Description

Bit positions set to 1 toggle the corresponding

Bits[63:32] of the next data word written to the
memory. This register is automatically cleared after
the fault has been injected.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

125

Chapter 4: Designing with the Core

FI_D2
Note: This register is only used when DQ_WIDTH =144.
This register is used to inject errors in data (Bits[95:64]) written to memory and can be used
to test the error correction and error signaling. The bits set in the register toggle the
corresponding data bits (word 2 or Bits[95:64]) of the subsequent data written to the
memory without affecting the ECC bits written. After the fault has been injected, the Fault
Injection Data register is cleared automatically.
This register is only implemented if C_ECC_TEST = ON or ECC_TEST_FI_XOR = ON and
ECC = ON in a DDR3/DDR4 SDRAM design in the Vivado IP catalog.
Injecting faults should be performed in a critical region in software; that is, writing this
register and the subsequent write to the memory must not be interrupted.
Table 4-48:

Fault Injection Data (Word 2) Register

Bits

Name

Core Access Reset Value Description

31:0

FI_D2

Bit positions set to 1 toggle the corresponding Bits[95:64] of

the next data word written to the memory. This register is
automatically cleared after the fault has been injected.

Special consideration must be given across FI_D0, FI_D1, FI_D2, and FI_D3 such that only a
single error condition is introduced.

FI_D3
Note: This register is only used when DQ_WIDTH =144.
This register is used to inject errors in data (Bits[127:96]) written to memory and can be
used to test the error correction and error signaling. The bits set in the register toggle the
corresponding data bits (word 3 or Bits[127:96]) of the subsequent data written to the
memory without affecting the ECC bits written. After the fault has been injected, the Fault
Injection Data register is cleared automatically.
The register is only implemented if C_ECC_TEST = ON or ECC_TEST_FI_XOR = ON and
ECC = ON in a DDR3/DDR4 SDRAM design in the Vivado IP catalog.
Injecting faults should be performed in a critical region in software; that is, writing this
register and the subsequent write to the memory must not be interrupted.
Table 4-49:
Bits
31:0

Fault Injection Data (Word 3) Register

Name
FI_D3

Core Access
W

Reset Value

Description

Bit positions set to 1 toggle the corresponding

Bits[127:96] of the next data word written to the
memory. The register is automatically cleared after
the fault has been injected.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

126

Chapter 4: Designing with the Core

FI_ECC
This register is used to inject errors in the generated ECC written to the memory and can be
used to test the error correction and error signaling. The bits set in the register toggle the
corresponding ECC bits of the next data written to memory. After the fault has been
injected, the Fault Injection ECC register is cleared automatically.
The register is only implemented if C_ECC_TEST = ON or ECC_TEST_FI_XOR = ON and
ECC = ON in a DDR3/DDR4 SDRAM design in the Vivado IP catalog.
Injecting faults should be performed in a critical region in software; that is, writing this
register and the subsequent write to memory must not be interrupted.
Table 4-50 describes the register bit usage when DQ_WIDTH = 72.
Table 4-50:

Fault Injection ECC Register for 72-Bit External Memory Width

Bits

Name

Core Access

Reset Value

Description

7:0

FI_ECC

Bit positions set to 1 toggle the corresponding bit of the

next ECC written to the memory. The register is
automatically cleared after the fault has been injected.

Table 4-51 describes the register bit usage when DQ_WIDTH = 144.
Table 4-51:

Fault Injection ECC Register for 144-Bit External Memory Width

Bits

Name

Core Access

Reset Value

Description

15:0

FI_ECC

Bit positions set to 1 toggle the corresponding bit of the

next ECC written to the memory. The register is
automatically cleared after the fault has been injected.

PHY Only Interface

This section describes the FPGA logic interface signals and key parameters of the DDR3 and
DDR4 PHY. The goal is to implement a PHY Only solution that connects your own custom
Memory Controller directly to the DDR3/DDR4 SDRAM generated PHY, instead of
interfacing to the user interface or AXI Interface of a DDR3/DDR4 SDRAM generated
Memory Controller. The PHY interface takes DRAM commands, like Activate, Precharge,
Refresh, etc. at its input ports and issues them directly to the DRAM bus.
The PHY does not take in memory transactions like the user and AXI interfaces, which
translate transactions into one or more DRAM commands that meet DRAM protocol and
timing requirements. The PHY interface does no DRAM protocol or timing checking. When
using a PHY Only option, you are responsible for meeting all DRAM protocol requirements
and timing specifications of all DRAM components in the system.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

127

Chapter 4: Designing with the Core

The PHY runs at the system clock frequency, or 1/4 of the DRAM clock frequency. The PHY
therefore accepts four DRAM commands per system clock and issues them serially on
consecutive DRAM clock cycles on the DRAM bus. In other words, the PHY interface has four
command slots: slots 0, 1, 2, and 3, which it accepts each system clock. The command in slot
position 0 is issued on the DRAM bus first, and the command in slot 3 is issued last. The
PHY does have limitations as to which slots can accept read and write CAS commands. For
more information, see CAS Command Timing Limitations, page 146. Except for CAS
commands, each slot can accept arbitrary DRAM commands.
The PHY FPGA logic interface has an input port for each pin on a DDR3 or DDR4 bus. Each
PHY command/address input port has a width that is eight times wider than its
corresponding DRAM bus pin. For example, a DDR4 bus has one act_n pin, and the PHY
has an 8-bit mc_ACT_n input port. Each pair of bits in the mc_ACT_n port corresponds to
a "command slot." The two LSBs are slot0 and the two MSBs are slot3. The PHY address
input port for a DDR4 design with 18 address pins is 144 bits wide, with each byte
corresponding to the four command slots for one DDR4 address pin. There are two bits for
each command slot in each input port of the PHY. This is due to the underlying design of the
PHY and its support for double data rate data buses. But as the DRAM command/address
bus is single data rate, you must always drive the two bits that correspond to a command
slot to the same value. See the following interface tables for additional descriptions and
examples in the timing diagrams that show how bytes and bits correspond to DRAM pins
and command slots.
The PHY interface has read and write data ports with eight bits for each DRAM DQ pin. Each
port bit represents one data bit on the DDR DRAM bus for a BL8 burst. Therefore one BL8
data burst for the entire DQ bus is transferred across the PHY interface on each system
clock. The PHY only supports BL8 data transfers. The data format is the same as the user
interface data format. For more information, see PHY, page 26.
The PHY interface also has several control signals that you must drive and/or respond to
when a read or write CAS command is issued. The control signals are used by the PHY to
manage the transfer of read and write data between the PHY interface and the DRAM bus.
See the following signal tables and timing diagrams.
Your custom Memory Controller must wait until the PHY output calDone is asserted before
sending any DRAM commands to the PHY. The PHY initializes and trains the DRAM before
asserting calDone. For more information on the PHY internal structures and training
algorithms, see the PHY, page 26. After calDone is asserted, the PHY is ready to accept any
DRAM commands. The only required DRAM or PHY commands are related to VT tracking
and DRAM refresh/ZQ. These requirements are detailed in VT Tracking, page 148 and
Refresh and ZQ, page 149.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

128

Chapter 4: Designing with the Core

PHY Interface Signals

The PHY interface signals to the FPGA logic can be categorized into six groups:

Clocking and Reset

Command and Address

Write Data

Read Data

PHY Control

Debug

Clocking and Reset and Debug signals are described in other sections or documents. See
the corresponding references. In this section, a description is given for each signal in the
remaining four groups and timing diagrams show examples of the signals in use.

Clocking and Reset

For more information on the clocking and reset, see the Clocking, page 73 section.

Command and Address

Table 4-52 shows the command and address signals for a PHY only option.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

129

Chapter 4: Designing with the Core

Table 4-52:

Command and Address

Signal

Direction

Description

Input

DRAM ACT_n command signal for four DRAM clock cycles.

Bits[1:0] correspond to the first DRAM clock cycle, Bits[3:2] to the
second, Bits[5:4] to the third, and Bits[8:7] to the fourth.
For center alignment to the DRAM clock with 1N timing, both bits
of a given bit pair should be asserted to the same value.
See timing diagrams for examples. All of the command/address
ports in this table follow the same eight bits per DRAM pin
format. Active-Low. This signal is not used in DDR3 systems.

mc_ADR[ADDR_WIDTH 8 1:0]

Input

DRAM address. Eight bits in the PHY interface for each address bit
on the DRAM bus.
Bits[7:0] corresponds to DRAM address Bit[0] on four DRAM clock
cycles.
Bits[15:8] corresponds to DRAM address Bit[1] on four DRAM
clock cycles, etc.
See the timing diagrams for examples. All of the multi-bit DRAM
signals in this table follow the same format of 1-byte of the PHY
interface port corresponding to four commands for one DRAM
pin. Mixed active-Low and High depending on which type of
DRAM command is being issued, but follows the DRAM pin
active-High/Low behavior. The function of each byte of the
mc_ADR port depends on whether the memory type is DDR4 or
DDR3 and the particular DRAM command that is being issued.
These functions match the DRAM address pin functions.
For example, with DDR4 memory and the mc_ACT_n port bits
asserted High, mc_ADR[135:112] have the function of RAS_n,
CAS_n, and WE_n pins.

mc_RAS_n[7:0]

Input

DDR3 DRAM RAS_n pin. Not used in DDR4 systems.

mc_CAS_n[7:0]

Input

DDR3 DRAM CAS_n pin. Not used in DDR4 systems.

mc_WE_n[7:0]

Input

DDR3 DRAM WE_n pin. Not used in DDR4 systems.

mc_BA[BANK_WIDTH 8 1:0]

Input

DRAM bank address. Eight bits for each DRAM bank address.

mc_BG[BANK_GROUP_WIDTH
8 1:0]

Input

DRAM bank group address. Eight bits for each DRAM pin.

mc_CKE[CKE_WIDTH 8 1:0]

Input

DRAM CKE. Eight bits for each DRAM pin.

mc_CS_n[CS_WIDTH 8 1:0]

Input

DRAM CS_n. Eight bits for each DRAM pin. Active-Low.

mc_ODT[ODT_WIDTH 8 1:0]

Input

DRAM ODT. Eight bits for each DRAM pin. Active-High.

mc_PAR[7:0]

Input

DRAM address parity. Eight bits for one DRAM parity pin.
Note: This signal is valid for RDIMMs only.

mc_ACT_n[7:0]

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

130

Chapter 4: Designing with the Core

Figure 4-10 shows the functional relationship between the PHY command/address input
signals and a DDR4 command/address bus. The diagram shows an Activate command on
system clock cycle N in the slot1 position. The mc_ACT_n[3:2] and mc_CS_n[3:2] are
both asserted Low in cycle N, and all the other bits in cycle N are asserted High, generating
an Activate in the slot1 position roughly two system clocks later and NOP/DESELECT
commands on the other command slots.
On cycle N + 3, mc_CS_n and the mc_ADR bits corresponding to CAS/A15 are set to 0xFC.
This asserts mc_ADR[121:120] and mc_CS_n[1:0] Low, and all other bits in cycle N + 3
High, generating a read command on slot0 and NOP/DESELECT commands on the other
command slots two system clocks later. With the Activate and read command separated by
three system clock cycles and taking into account the command slot position of both
commands within their system clock cycle, expect the separation on the DDR4 bus to be 11
DRAM clocks, as shown in the DDR bus portion of Figure 4-10.
Note: Figure 4-10 shows the relative position of commands on the DDR bus based on the PHY input

signals. Although the diagram shows some latency in going through the PHY to be somewhat
realistic, this diagram does not represent the absolute command latency through the PHY to the DDR
bus, or the system clock to DRAM clock phase alignment. The intention of this diagram is to show the
concept of command slots at the PHY interface.

X-Ref Target - Figure 4-10

&\FOH1

&\FOH1

&\FOH1

&\FOH1

&\FOH1

&\FOH1

6\VWHP&ORFN
PFB$&7BQ>@

[)

[))

[))

[))

[))

[))

5$6$PFB$'5>@

[))

[))

[))

[))

[))

[))

&$6$PFB$'5>@

[))

[))

[))

[)&

[))

[))

:($PFB$'5>@

[))

[))

[))

[))

[))

[))

PFB&6BQ>@

[)

[))

[))

[)&

[))

[))

$FWLYDWH
&RPPDQG
6ORW

5HDG
&RPPDQG
6ORW

'5$0&ORFN
''5B$&7BQ
''5B5$6$
''5B&$6$
''5B:($
''5B&6BQ

W5&' W&.

$FWLYDWH
&RPPDQG

Figure 4-10:

5HDG
&RPPDQG

PHY Command/Address Input Signal with DDR4 Command/Address Bus

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

131

Chapter 4: Designing with the Core

Figure 4-11 shows an example of using all four command slots in a single system clock. This
example shows three commands to rank0, and one to rank1, in cycle N. BG and BA address
pins are included in the diagram to spread the commands over different banks to not
violate DRAM protocol. Table 4-53 lists the command in each command slot.
Table 4-53:

Command Slots

Command Slot

DRAM Command

Read

Activate

Precharge

Refresh

Bank Group

Bank

Rank

X-Ref Target - Figure 4-11

&\FOH1

&\FOH1

&\FOH1

&\FOH1

&\FOH1

&\FOH1

6\VWHP&ORFN
PFB$&7BQ>@

[)

[))

[))

[))

[))

[))

5$6$PFB$'5>@

[)

[))

[))

[))

[))

[))

&$6$PFB$'5>@

[&

[))

[))

[))

[))

[))

:($PFB$'5>@

[&)

[))

[))

[))

[))

[))

PFB%*>@

[&

[))))

[))))

[))))

[))))

[))))

PFB%$>@

[&&

[))))

[))))

[))))

[))))

[))))

PFB&6BQ>@

[)&

[))))

[))))

[))))

[))))

[))))

'5$0&ORFN
''5B$&7BQ
''5B5$6$
''5B&$6$
''5B:($
''5B%*>@

   

''5B%$>@

   

''5B&6BQ>@
''5B&6BQ>@

Figure 4-11:

PHY Command/Address with All Four Command Slots

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

132

Chapter 4: Designing with the Core

To understand how DRAM commands to different command slots are packed together, the
following detailed example shows how to convert DRAM commands at the PHY interface to
commands on the DRAM command/address bus. To convert PHY interface commands to
DRAM commands, write out the PHY signal for one system clock in binary and reverse the
bit order of each byte. You can also drop every other bit after the reversal because the bit
pairs are required to have the same value. In the subsequent example, the mc_BA[15:0]
signal has a cycle N value of 0x0C3C:
Hex

0x0C3C

Binary

16'b0000_1100_0011_1100

Reverse bits in each byte

16'b0011_0000_0011_1100

Take the upper eight bits for DRAM BA[1] and the lower eight bits for DRAM BA[0] and
the expected pattern on the DRAM bus is:

BA[1]

BA[0]

00

11

00

00

Low

High

Low

Low

00

11

11

00

Low

High

High

Low

This matches the DRAM BA[1:0] signal values of 0, 3, 1, and 0 shown in the Figure 4-11.

Write Data
Table 4-54 shows the write data signals for a PHY only option.
Table 4-54:

Write Data

Signal

wrData[DQ_WIDTH 8 1:0]

wrDataMask[DM_WIDTH 8 1:0]

wrDataEn

Direction Description

Input

DRAM write data. Eight bits for each DQ lane on the DRAM
bus. This port transfers data for an entire BL8 write on each
system clock cycle.
Write data must be provided to the PHY one cycle after the
wrDataEn output signal asserts, or two cycles after if the ECC
parameter is set to "ON. This protocol must be followed.
There is no data buffering in the PHY.

Input

DRAM write DM/DBI port. One bit for each byte of the
wrData port, corresponding to one bit for each byte of each
burst of a BL8 transfer. wrDataMask is transferred on the
same system clock cycle as wrData. Active-High.

Output

Write data required. PHY asserts this port for one cycle for
each write CAS command.
Your design must provide wrData and wrDataMask at the
PHY input ports on the cycle after wrDataEn asserts, or two
cycles after if the ECC parameter is set to "ON."

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

133

Chapter 4: Designing with the Core

Table 4-54:

Write Data (Contd)

Signal

Direction Description

wrDataAddr[DATA_BUF_ADDR_WIDTH
1:0]

Output

Optional control signal. PHY stores and returns a data buffer

address for each in-flight write CAS command. The
wrDataAddr signal returns the stored addresses. It is only
valid when the PHY asserts wrDataEn.
You can use this signal to manage the process of sending
write data into the PHY for a write CAS command, but this is
completely optional.

tCWL[5:0]

Output

Optional control signal. This output indicates the CAS write

latency used in the PHY.

dBufAdr[DATA_BUF_ADDR_WIDTH
1:0]

Input

Reserved. Should be tied Low.

Read Data
Table 4-55 shows the read data signals for a PHY only option.
Table 4-55:

Read Data

Signal

rdData[DQ_WIDTH 8 1:0]

rdDataEn

rdDataAddr[DATA_BUF_ADDR_WIDTH
1:0]

per_rd_done

Direction

Description

Output

DRAM read data. Eight bits for each DQ lane on the DRAM
bus. This port transfers data for an entire BL8 read on each
system clock cycle. rdData is only valid when the rdDataEn,
per_rd_done, or rmw_rd_done is asserted. Your design must
consume the read data when rdDataEn one of these data
valid signals asserts. There is no data buffering in the PHY.

Output

Read data valid. This signal asserts High to indicate that the
rdData and rdDataAddr signals are valid. rdDataEn asserts
High for one system clock cycle for each BL8 read, unless the
read was tagged as a special type of read.
See the optional per_rd_done and rmw_rd_done signals for
details on special reads. rdData must be consumed when
rdDataEn asserts or data is lost. Active-High.

Output

Optional control signal. PHY stores and returns a data buffer

address for each in-flight read CAS command. The
rdDataAddr signal returns the stored addresses. It is only
valid when the PHY asserts rdDataEn, per_rd_done, or
rmw_rd_done. Your design can use this signal to manage the
process of capturing and storing read data provided by the
PHY, but this is completely optional.

Output

Optional read data valid signal. This signal indicates that a

special type of read has completed and its associated rdData
and rdDataAddr signals are valid.
When PHY input winInjTxn is asserted High at the same time
as mcRdCAS, the read is tagged as a special type of read, and
per_rd_done asserts instead of rdDataEn when data is
returned.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

134

Chapter 4: Designing with the Core

Table 4-55:

Read Data (Contd)

Signal

Direction

Description

rmw_rd_done

Output

Optional read data valid signal. This signal indicates that a

special type of read has completed and its associated rdData
and rdDataAddr signals are valid.
When PHY input winRmw is asserted High at the same time
as mcRdCAS, the read is tagged as a special type of read, and
rmw_rd_done asserts instead of rdDataEn when data is
returned.

rdDataEnd

Output

Unused. Tied High.

PHY Control
Table 4-56 shows the PHY control signals for a PHY only option.
Table 4-56:

PHY Control

Signal

Direction

Description

calDone

Output

Indication that the DRAM is powered up, initialized, and

calibration is complete. This indicates that the PHY interface is
available to send commands to the DRAM. Active-High.

Input

Read CAS command issued. This signal must be asserted for one
system clock if and only if a read CAS command is asserted on
one of the command slots at the PHY command/address input
ports. Hold at 0x0 until calDone asserts. Active-High.

Input

Write CAS command issued. This signal must be asserted for one
system clock if and only if a write CAS command is asserted on
one of the command slots at the PHY command/address input
ports. Hold at 0x0 until calDone asserts. Active-High.

Input

Target rank for CAS commands. This value indicates which rank a
CAS command is issued to. It must be valid when either mcRdCAS
or mcWrCAS is asserted. The PHY passes the value from this input
to the XIPHY to select the calibration results for the target rank of
a CAS command in multi-rank systems. In a single rank system,
this input port can be tied to 0x0.

Input

CAS command slot select. The PHY only supports CAS commands
on even command slots. mcCasSlot indicates which of these two
possible command slots a read CAS or write CAS was issued on.
mcCasSlot is used by the PHY to generate XIPHY control signals,
like DQ output enables, that need DRAM clock cycle resolution
relative to the command slot used for a CAS command.
Valid values after calDone asserts are 0x0 and 0x2. Hold at 0x0
until calDone asserts. This signal must be valid if mcRdCAS or
mcWrCAS is asserted. For more information, see the CAS
Command Timing Limitations, page 146.

mcRdCAS

mcWrCAS

winRank[1:0]

mcCasSlot[1:0]

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

135

Chapter 4: Designing with the Core

Table 4-56:

PHY Control (Contd)

Signal

mcCasSlot2

winInjTxn

winRmw

winBuf[DATA_BUF_ADDR_WIDTH
1:0]

gt_data_ready

Direction

Description

Input

CAS slot 2 select. mcCasSlot2 serves a similar purpose as the

mcCasSlot[1:0] signal, but mcCasSlot2 is used in timing critical
logic in the PHY. Ideally mcCasSlot2 should be driven from
separate flops from mcCasSlot[1:0] to allow synthesis/
implementation to better optimize timing. mcCasSlot2 and
mcCasSlot[1:0] must always be consistent if mcRdCAS or
mcWrCAS is asserted.
To be consistent, the following must be TRUE:
mcCasSlot2==mcCasSlot[1]. Hold at 0x0 until calDone asserts.
Active-High.

Input

Optional read command type indication. When winInjTxn is

asserted High on the same cycle as mcRdCAS, the read does not
generate an assertion on rdDataEn when it completes. Instead,
the per_rd_done signal asserts, indicating that a special type of
read has completed and that its data is valid on the rdData output.
In DDR3/DDR4 SDRAM controller designs, the winInjTxn/
per_rd_done signals are used to track non-system read traffic by
asserting winInjTxn only on read commands issued for the
purpose of VT tracking.

Input

Optional read command type indication. When winRmw is

asserted High on the same cycle as mcRdCAS, the read does not
generate an assertion on rdDataEn when it completes. Instead,
the rmw_rd_done signal asserts, indicating that a special type of
read has completed and that its data is valid on the rdData output.
In DDR3/DDR4 SDRAM controller designs, the winRmw/
rmw_rd_done signals are used to track reads issued as part of a
read-modify-write flow. The DDR3/DDR4 SDRAM controller
asserts winRmw only on read commands that are issued for the
read phase of a RMW sequence.

Input

Optional control signal. When either mcRdCAS or mcWrCAS is

asserted, PHY stores the value on the winBuf signal. The value is
returned on rdDataAddr or wrDataAddr, depending on whether
mcRdCAS or mcWrCAS was used to capture winBuf.
In DDR3/DDR4 SDRAM controller designs, these signals are used
to track the data buffer address used to source write data or sink
read return data.

Input

Update VT Tracking. This signal triggers the PHY to read RIU

registers in the XIPHY that measure how well the DQS Gate signal
is aligned to the center of the read DQS preamble, and then adjust
the alignment if needed. This signal must be asserted periodically
to keep the DQS Gate aligned as voltage and temperature drift.
For more information, see VT Tracking, page 148. Hold at 0x0
until calDone asserts. Active-High.

Figure 4-12 shows a write command example. On cycle N, write command A is asserted on
the PHY command/address inputs in the slot0 position. The mcWrCAS input is also asserted
on cycle N, and a valid rank value is asserted on the winRank signal. In Figure 4-12, there
is only one CS_n pin, so the only valid winRank value is 0x0. The mcCasSlot[1:0] and
mcCasSlot2 signals are valid on cycle N, and specify slot0.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

136

Chapter 4: Designing with the Core

Write command B is then asserted on cycle N + 1 in the slot2 position, with mcWrCAS,
winRank, mcCasSlot[1:0], and mcCasSlot2 asserted to valid values as well. On cycle
M, PHY asserts wrDataEn to indicate that wrData and wrDataMask values corresponding
to command A need to be driven on cycle M + 1.
Figure 4-12 shows the data and mask widths assuming an 8-bit DDR4 DQ bus width. The
delay between cycle N and cycle M is controlled by the PHY, based on the CWL and AL
settings of the DRAM. wrDataEn also asserts on cycle M + 1 to indicate that wrData and
wrDataMask values for command B are required on cycle M + 2. Although this example
shows that wrDataEn is asserted on two consecutive system clock cycles, you should not
assume this will always be the case, even if mcWrCAS is asserted on consecutive clock cycles
as is shown here. There is no data buffering in the PHY and data is pulled into the PHY just
in time. Depending on the CWL/AL settings and the command slot used, consecutive
mcWrCAS assertions might not result in consecutive wrDataEn assertions.
X-Ref Target - Figure 4-12

&\FOH1

&\FOH1

&\FOH0

&\FOH0

&\FOH0

6\VWHP&ORFN
PFB$&7BQ>@

[))

[))

[))

[))

[))

[))

5$6$PFB$'5>@

[))

[))

[))

[))

[))

[))

&$6$PFB$'5>@

[)&

[&)

[))

[))

[))

[))

:($PFB$'5>@

[)&

[&)

[))

[))

[))

[))

PFB&6BQ>@

[)&

[&)

[))

[))

[))

[))

ZU'DWD>@

'DWD$

'DWD%

ZU'DWD0DVN>@

'0$

'0%

:ULWH
&RPPDQG
$
6ORW

:ULWH
&RPPDQG
%
6ORW

5DQN$

5DQN%

[

[

PF:U&$6
PF5G&$6
ZLQ5DQN>@
PF&DV6ORW>@
PF&DV6ORW

ZU'DWD(Q

Figure 4-12:

Write Command Example

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

137

Chapter 4: Designing with the Core

Figure 4-13 shows a read command example. Read commands are issued on cycles N and
N + 1 in slot positions 0 and 2, respectively. The mcRdCAS, winRank, mcCasSlot, and
mcCasSlot2 are asserted on these cycles as well. On cycles M + 1 and M + 2, PHY asserts
rdDataEn and rdData.
Note: The separation between N and M + 1 is much larger than in the write example (Figure 4-12).
In the read case, the separation is determined by the full round trip latency of command output,
DRAM CL/AL, and data input through PHY.
X-Ref Target - Figure 4-13

&\FOH1

&\FOH0

&\FOH1

&\FOH0

&\FOH0

6\VWHP&ORFN
PFB$&7BQ>@

[))

[))

[))

[))

[))

[))

5$6$PFB$'5>@

[))

[))

[))

[))

[))

[))

&$6$PFB$'5>@

[)&

[&)

[))

[))

[))

[))

:($PFB$'5>@

[))

[))

[))

[))

[))

[))

PFB&6BQ>@

[)&

[&)

[))

[))

[))

[))

'DWD$

'DWD%

5HDG
&RPPDQG
$
6ORW

5HDG
&RPPDQG
%
6ORW

5DQN$

5DQN%

[

[

PF:U&$6
PF5G&$6
ZLQ5DQN>@
PF&DV6ORW>@
PF&DV6ORW

UG'DWD(Q
UG'DWD>@

Figure 4-13:

Read Command Example

Debug
The debug signals are explained in Debug Tools, page 338.

PHY Only Parameters

All PHY parameters are configured by the DDR3/DDR4 SDRAM software. Table 4-57
describes the PHY parameters. These parameter values must not be modified in the DDR3/
DDR4 SDRAM generated designs. The parameters are set during core generation. The core
must be regenerated to change any parameter settings.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

138

Chapter 4: Designing with the Core

Table 4-57:

PHY Only Parameters

Parameter Name

Default Value

Allowable Values

Description

ADDR_WIDTH

18

DDR4 18.. 17
DDR3 16.. 13

Number of DRAM Address pins

BANK_WIDTH

DDR4 2
DDR3 3

Number of DRAM Bank Address pins

BANK_GROUP_WIDTH

DDR4 2.. 1
DDR3 N/A

Number of DRAM Bank Group pins

CK_WIDTH

2.. 1

Number of DRAM Clock pins

CKE_WIDTH

2.. 1

Number of DRAM CKE pins

CS_WIDTH

2.. 1

Number of DRAM CS pins

ODT_WIDTH

4.. 1

Number of DRAM ODT pins

DRAM_TYPE

DDR4

DDR4,
DDR3

DRAM Technology

DQ_WIDTH

16

Minimum = 8
Must be multiple of 8

Number of DRAM DQ pins in the

channel

DQS_WIDTH

Minimum = 1
x8 DRAM 1 per DQ byte
x4 DRAM 1 per DQ nibble

Number of DRAM DQS pins in the

channel

DM_WIDTH

Minimum = 0
x8 DRAM 1 per DQ byte
x4 DRAM 0

Number of DRAM DM pins in the

channel

DATA_BUF_ADDR_WIDTH

Number of data buffer address bits

stored for a read or write transaction

ODTWR

0x8421

0xFFFF .. 0x0000

Reserved for future use

ODTWRDEL

Set to CWL

Reserved for future use

ODTWRDUR

7.. 6

Reserved for future use

ODTRD

0x0000

0xFFFF.. 0x0000

Reserved for future use

ODTRDDEL

11

Set to CL

Reserved for future use

ODTRDDUR

7.. 6

Reserved for future use

ODTWR0DEL
ODTWR0DUR
ODTRD0DEL
ODTRD0DUR
ODTNOP

N/A

N/A

Reserved for future use

MR0

0x630

Legal SDRAM
configuration

DRAM MR0 setting

MR1

0x101

Legal SDRAM
configuration

DRAM MR1 setting

MR2

0x10

Legal SDRAM
configuration

DRAM MR2 setting

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

139

Chapter 4: Designing with the Core

Table 4-57:

PHY Only Parameters (Contd)

Parameter Name

Default Value

Allowable Values

Description

MR3

0x0

Legal SDRAM
configuration

DRAM MR3 setting

MR4

0x0

Legal SDRAM
configuration

DRAM MR4 setting. DDR4 only.

MR5

0x400

Legal SDRAM
configuration

DRAM MR5 setting. DDR4 only.

MR6

0x800

Legal SDRAM
configuration

DRAM MR6 setting. DDR4 only.

0x1

0x1
0x3
0x5
0xF

For more information, see

SLOT0_CONFIG.

0x0

0x0
0x2
0xC
0xA

For more information, see

SLOT0_CONFIG.

SLOT0_CONFIG

SLOT1_CONFIG

SLOT0_FUNC_CS

0x1

0x1
0x3
0x5
0xF

Memory bus CS_n pins used to send

all DRAM commands including MRS
to memory. Each bit of the parameter
represents 1-bit of the CS_n bus, for
example, the LSB indicates CS_n[0],
and the MSB indicates CS_n[3]. For
DIMMs this parameter specifies the
CS_n pins connected to DIMM slot 0.
Note: slot 0 used here should not be
confused with the "command slot0" term
used in the description of the PHY
command/address interface. For more
information, see SLOT0_FUNC_CS .

SLOT1_FUNC_CS

0x0

0x0
0x2
0xC
0xA

REG_CTRL

OFF

"ON"
"OFF"

Enable RDIMM RCD initialization and

calibration

CA_MIRROR

OFF

"ON"
"OFF"

Enable Address mirroring. This

parameter is set to "ON" for the
DIMMs that support address
mirroring.

DDR4_REG_RC03

0x30

Legal RDIMM RCD

configuration

RDIMM RCD control word 03

DDR4_REG_RC04

0x40

Legal RDIMM RCD

configuration

RDIMM RCD control word 04

DDR4_REG_RC05

0x50

Legal RDIMM RCD

configuration

RDIMM RCD control word 05

tCK

938

Minimum 833

DRAM clock period in ps

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

See the SLOT0_FUNC_CS description.

The only difference is that
SLOT1_FUNC_CS specifies CS_n pins
connected to DIMM slot 1.

Send Feedback

140

Chapter 4: Designing with the Core

Table 4-57:

PHY Only Parameters (Contd)

Parameter Name

Default Value

Allowable Values

Description

tXPR

72

Minimum 1.
DRAM tXPR specification in
system clocks

See JEDEC DDR SDRAM specification

[Ref 1].

tMOD

Minimum 1.
DRAM tMOD specification
in system clocks

See JEDEC DDR SDRAM specification

[Ref 1].

tMRD

Minimum 1.
DRAM tMRD specification
in system clocks

See JEDEC DDR SDRAM specification

[Ref 1].

tZQINIT

256

Minimum 1.
DRAM tZQINIT
specification in system
clocks

See JEDEC DDR SDRAM specification

[Ref 1].

TCQ

100

100

Flop clock to Q in ps. For simulation

purposes only.

EARLY_WR_DATA

OFF

OFF

Reserved for future use

2.. 0

Added command latency in system

clocks. Added command latency is
required for some configurations.
See details in CL/CWL section.

OFF

OFF

Enables early wrDataEn timing for

DDR3/DDR4 SDRAM generated
controllers when set to "ON." PHY
only designs must set this to "OFF."

DM_NODBI

NONE
DM_NODBI
DM_DBIRD
NODM_DBIWR
NODM_DBIRD

DDR4 DM/DBI configuration. For

details, see Table 4-59.

EXTRA_CMD_DELAY

ECC

DM_DBI

USE_CS_PORT

0 = no CS_n pins
1 = CS_n pins used

Controls whether or not CS_n pins are

connect to DRAM. If there are no
CS_n pins the PHY initialization and
training logic issues NOPs between
DRAM commands. If there are no
CS_n pins, The DRAM chip select pin
(CS#) must be tied Low externally at
the DRAM.

DRAM_WIDTH

16, 8, 4

DRAM component DQ width

RANKS

2.. 1

Number of ranks in the memory

subsystem

nCK_PER_CLK

Number of DRAM clocks per system

clock

C_FAMILY

kintexu

"kintexu"
"virtexu"

Device information used by

MicroBlaze controller in the PHY.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

141

Chapter 4: Designing with the Core

Table 4-57:

PHY Only Parameters (Contd)

Parameter Name

Default Value

Allowable Values

Description

BYTES

Minimum 3

Number of XIPHY "bytes" used for

data, command, and address

DBYTES

Minimum 1

Number of bytes in the DRAM DQ bus

IOBTYPE

{39'b001_001_00
1_001_001_101_
101_001_001_00
1_001_001_001,
39'b001_001_00
1_001_001_001_
001_001_001_00
1_001_001_001,
39'b000_011_01
1_011_011_111_
111_011_011_01
1_011_001_011,
39'b001_011_01
1_011_011_111_
111_011_011_01
1_011_001_011 }

3'b000 = Unused pin

3'b 001 = Single-ended
output
3'b 010 = Single-ended
input
3'b011 = Single-ended I/O
3'b100 = Unused pin
3'b 101 = Differential
Output
3'b 110 = Differential Input
3'b 111 = Differential
INOUT

IOB setting

PLL_WIDTH

DDR3/DDR4 SDRAM
generated values

Number of PLLs

CLKOUTPHY_MODE

"VCO_2X"

VCO_2X

Determines the clock output

frequency based on the VCO
frequency for the BITSLICE_CONTROL
block

PLLCLK_SRC

0 = pll_clk0
1 = pll_clk1

XIPHY PLL clock source

DIV_MODE

0 = DIV4
1 = DIV2

XIPHY controller mode setting

DATA_WIDTH

XIPHY parallel input data width

CTRL_CLK

0x3

0 = Internal, local div_clk

used
1 = External RIU clock used

Internal or external XIPHY clock for

the RIU

INIT

{(15
BYTES){1'b1}}

1'b0
1'b1

3-state bitslice OSERDES initial value

RX_DATA_TYPE

{15'b000000_00_
00000_00,
15'b000000_00_
00000_00,
15'b011110_10_
11110_01,
15'b011110_10_
11110_01 }

2'b00
2'b01
2'b10
2'b11

=
=
=
=

None
DATA(DQ_EN)
CLOCK(DQS_EN)
DATA_AND_CLOCK

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

XIPHY bitslice setting

Send Feedback

142

Chapter 4: Designing with the Core

Table 4-57:

PHY Only Parameters (Contd)

Parameter Name

Default Value

Allowable Values

Description

TX_OUTPUT_PHASE_90

{13'b111111111
1111,
13'b1111111111
111,
13'b0000011000
010,
13'b1000011000
010}

1'b0 = No offset
1'b1 = 90 offset applied

XIPHY setting to apply 90 offset on a

given bitslice

RXTX_BITSLICE_EN

{13'b111110111
1111,
13'b1111111111
111,
13'b0111101111
111,
13'b1111101111
111 }

1'b0 = No bitslice
1'b1 = Bitslice enabled

XIPHY setting to enable a bitslice

NATIVE_ODLAY_BYPASS

{(13
BYTES){1'b0}}

1'b0 = FALSE
1'b1 = TRUE (Bypass)

Bypass the ODELAY on output

bitslices

EN_OTHER_PCLK

{BYTES{2'b01}}

1'b 0 = FALSE (not used)

1'b 1 = TRUE (used)

XIPHY setting to route capture clock

from other bitslice

EN_OTHER_NCLK

{BYTES{2'b01}}

1'b 0 = FALSE (not used)

1'b 1 = TRUE (used)

XIPHY setting to route capture clock

from other bitslice

RX_CLK_PHASE_P

{{(BYTES
DBYTES){2'b00}},
{DBYTES{2'b11}}}

2'b00 for Address/Control,

2'b11 for Data

XIPHY setting to shift the read clock

DQS_P by 90 relative to the DQ

RX_CLK_PHASE_N

{{(BYTES
DBYTES){2'b00}},
{DBYTES{2'b11}}}

2'b00 for Address/Control,

2'b11 for Data

XIPHY setting to shift the read clock

DQS_N by 90 relative to the DQ

TX_GATING

{{(BYTES
DBYTES){2'b00}},
{DBYTES{2'b11}}}

2'b00 for Address/Control,

2'b11 for Data

Write DQS gate setting for the XIPHY

RX_GATING

{{(BYTES
DBYTES){2'b00}},
{DBYTES{2'b11}}}

2'b00 for Address/Control,

2'b11 for Data

Read DQS gate setting for the XIPHY

EN_DYN_ODLY_MODE

{{(BYTES
DBYTES){2'b00}},
{DBYTES{2'b11}}}

2'b00 for Address/Control,

2'b11 for Data

Dynamic loading of the ODELAY by

XIPHY

BANK_TYPE

"HP_IO"

"HP_IO"
"HR_IO"

Indicates whether selected bank is HP

or HR

SIM_MODE

"FULL"

"FULL", "BFM"

Flag to set if the XIPHY is used

("FULL") or the behavioral model for
simulation speed up.

SELF_CALIBRATE

{(2
BYTES){1'b0}}

{(2 BYTES){1'b0}} for

simulation,
{(2 BYTES){1'b1}} for
hardware

BISC self calibration

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

143

Chapter 4: Designing with the Core

Table 4-57:

PHY Only Parameters (Contd)

Parameter Name

Default Value

Allowable Values

Description

BYPASS_CAL

"FALSE"

"TRUE" for simulation,

"FALSE" for hardware

Flag to turn calibration ON/OFF

CAL_WRLVL

"FULL"

"FULL"

Flag for calibration, write-leveling

setting

CAL_DQS_GATE

"FULL"

"FULL"

Flag for calibration, DQS gate setting

CAL_RDLVL

"FULL"

"FULL"

Flag for calibration, read training

setting

CAL_WR_DQS_DQ

"FULL"

"FULL"

Flag for calibration, write DQS-to-DQ

setting

CAL_COMPLEX

"FULL"

"SKIP", "FULL"

Flag for calibration, complex pattern

setting

CAL_RD_VREF

"SKIP"

"SKIP", "FULL"

Flag for calibration, read VREF setting

CAL_WR_VREF

"SKIP"

"SKIP", "FULL"

Flag for calibration, write VREF setting

CAL_JITTER

"FULL"

"FULL", "NONE"

Reserved for verification. Speed up

calibration simulation. Must be set to
"FULL" for all hardware test cases.

t200us

53305 decimal

0x3FFFF.. 1

Wait period after BISC complete to

DRAM reset_n deassertion in system
clocks

t500us

133263 decimal

0x3FFFF.. 1

Wait period after DRAM reset_n

deassertion to CKE assertion in
system clocks

FULL, BFM

FULL: Run example design

simulations with XIPHY UNISIMs
BFM: Run Fast Mode Simulations
with XIPHY Bus Functional Model

SIM_MODE

BFM

EXTRA_CMD_DELAY Parameter
Depending on the number of ranks, ECC mode, and DRAM latency configuration, PHY must
be programmed to add latency on the DRAM command address bus. This provides enough
pipeline stages in the PHY programmable logic to close timing and to process mcWrCAS.
Added command latency is generally needed at very low CWL in single rank configurations,
or in multi-rank configurations. Enabling ECC might also require adding command latency,
but this depends on whether your controller design (outside the PHY) depends on receiving
the wrDataEn signal a system clock cycle early to allow for generating ECC check bits.
The EXTRA_CMD_DELAY parameter is used to add one or two system clock cycles of delay
on the DRAM command/address path. The parameter does not delay the mcWrCAS or
mcRdCAS signals. This gives the PHY more time from the assertion of mcWrCAS or mcRdCAS
to generate XIPHY control signals. To the PHY, an EXTRA_CMD_DELAY setting of one or two
is the same as having a higher CWL or AL setting.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

144

Chapter 4: Designing with the Core

Table 4-58 shows the required EXTRA_CMD_DELAY setting for various configurations of
CWL, CL, and AL.
Table 4-58:

EXTRA_CMD_DELAY Configuration Settings

DRAM Configuration

Required EXTRA_CMD_DELAY

DRAM CAS Write

Latency CWL

DRAM CAS
Latency CL

DRAM Additive
Latency MR1[4:3]

Single Rank
without ECC

Single Rank with

ECC or Multi-Rank

10

10

10

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

145

Chapter 4: Designing with the Core

Table 4-58:

EXTRA_CMD_DELAY Configuration Settings (Contd)

DRAM Configuration

Required EXTRA_CMD_DELAY

DRAM CAS Write

Latency CWL

DRAM CAS
Latency CL

DRAM Additive
Latency MR1[4:3]

Single Rank
without ECC

Single Rank with

ECC or Multi-Rank

10

10

10

11

11

11

9 to 12

9 to 12

1 or 2

13

13

1 or 2

DM_DBI Parameter
The PHY supports the DDR4 DBI function on the read path and write path. Table 4-59 show
how read and write DBI can be enabled separately or in combination. When write DBI is
enabled, Data Mask is disabled. The DM_DBI parameter only configures the PHY and the
MRS parameters must also be set to configure the DRAM for DM/DBI.
Table 4-59:

DM_DBI PHY Settings

DM_DBI Parameter Value

PHY Read DBI

PHY Write DBI

PHY Write Data Mask

None

Disabled

Disabled

Enabled

DM_NODBI

Disabled

Disabled

Enabled

DM_DBIRD

Enabled

Disabled

Enabled

NODM_DBIWR

Disabled

Enabled

Disabled

NODM_DBIRD

Enabled

Enabled

Disabled

CAS Command Timing Limitations

The PHY only supports CAS commands on even command slots, that is, 0 and 2. This
limitation is due to the complexity of the PHY logic driven by the PHY control inputs, like the
mcWrCAS and mcRdCAS signals, not the actual DRAM command signals like
mc_ACT_n[7:0], which just pass through the PHY after calDone asserts. The PHY logic is
complex because it generates XIPHY control signals based on the DRAM CWL and CL values
with DRAM clock resolution, not just system clock resolution.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

146

Chapter 4: Designing with the Core

Supporting two different command slots for CAS commands adds a significant amount of
logic on the XIPHY control paths. There are very few pipeline stages available to break up
the logic due to protocol requirements of the XIPHY. CAS command support on all four slots
would further increase the complexity and degrade timing.

Minimum Write CAS Command Spacing

The minimum Write CAS to Write CAS command spacing to different ranks is eight DRAM
clocks. This is a PHY limitation. If you violate this timing, the PHY might not have enough
time to switch its internal delay settings and drive Write DQ/DQS on the DDR bus with
correct timing. The internal delay settings are determined during calibration, and it varies
with system layout.
Following the memory system layout guidelines ensures that a spacing of eight DRAM
clocks is sufficient for correct operation. Write to Write timing to the same rank is limited
only by the DRAM specification and the command slot limitations for CAS commands
discussed earlier.

System Considerations for CAS Command Spacing

System layout and timing uncertainties should be considered in how your custom controller
sets minimum CAS command spacing. The controller must space the CAS commands so that
there are no DRAM timing violations and no DQ/DQS bus drive fights. When a DDR3/DDR4
SDRAM generated memory controller is instantiated, the layout guidelines are considered
and command spacing is adjusted accordingly for a worst case layout.
Consider Read to Write command spacing, the JEDEC DRAM specification [Ref 1] shows
the component requirement as: RL + BL/2 + 2 WL. This formula only spaces the Read DQS
post-amble and Write DQS preamble by one DRAM clock on an ideal bus with no timing
skews. Any DQS flight time, write leveling uncertainty, jitter, etc. reduces this margin. When
these timing errors add up to more than one DRAM clock, there is a drive fight at the FPGA
DQS pins which likely corrupts the Read transaction. A DDR3/DDR4 SDRAM generated
controller uses the following formula to delay Write CAS after a Read CAS to allow for a
worst case timing budget for a system following the layout guidelines: RL + BL/2 + 4 WL.
Read CAS to Read CAS commands to different ranks must also be spaced by your custom
controller to avoid drive fights, particularly when reading first from a "far" rank and then
from a "near" rank. A DDR3/DDR4 SDRAM generated controller spaces the Read CAS
commands to different ranks by at least six DRAM clock cycles.
Write CAS to Read CAS to the same rank is defined by the JEDEC DRAM specification
[Ref 1]. Your controller must follow this DRAM requirement, and it ensures that there is no
possibility of drive fights for Write to Read to the same rank. Write CAS to Read CAS spacing
to different ranks, however, must also be limited by your controller. This spacing is not
defined by the JEDEC DRAM specification [Ref 1] directly.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

147

Chapter 4: Designing with the Core

Write to Read to different ranks can be spaced much closer together than Write to Read to
the same rank, but factors to consider include write leveling uncertainty, jitter, and tDQSCK.
A DDR3/DDR4 SDRAM generated controller spaces Write CAS to Read CAS to different
ranks by at least six DRAM clocks.

Additive Latency
The PHY supports DRAM additive latency. The only effect on the PHY interface due to
enabling Additive Latency in the MRS parameters is in the timing of the wrDataEn signal
after mcWrCAS assertion. The PHY takes the AL setting into account when scheduling
wrDataEn. You can also find the rdDataEn asserts much later after mcRdCAS because the
DRAM returns data much later. The AL setting also has an impact on whether or not the
EXTRA_CMD_DELAY parameter needs to be set to a non-zero value.

VT Tracking
The PHY requires read commands to be issued at a minimum rate to keep the read DQS
gate signal aligned to the read DQS preamble after calDone is asserted. In addition, the
gt_data_ready signal needs to be pulsed at regular intervals to instruct the PHY to
update its read DQS training values in the RIU. Finally, the PHY requires periodic gaps in
read traffic to allow the XIPHY to update its gate alignment circuits with the values the PHY
programs into the RIU. Specifically, the PHY requires the following after calDone asserts:
1. At least one read command every 1 s. For a multi-rank system any rank is acceptable.
2. The gt_data_ready signal is asserted for one system clock cycle after the rdDataEn
signal asserts at least once within each 1 s interval.
3. There is a three contiguous system clock cycle period with no read CAS commands
asserted at the PHY interface every 1 s.
The PHY cannot interrupt traffic to meet these requirements. It is therefore your custom
Memory Controller's responsibility to issue DRAM commands and assert the
gt_data_ready input signal in a way that meets the above requirements.
Figure 4-14 shows two examples where the custom controller must interrupt normal traffic
to meet the VT tracking requirements. The first example is a High read bandwidth workload
with mcRdCAS asserted continuously for almost 1 s. The controller must stop issuing read
commands for three contiguous system clocks once each 1 s period, and assert
gt_data_ready once per period.
The second example is a High write bandwidth workload with mcWrCAS asserted
continuously for almost 1 s. The controller must stop issuing writes, issue at least one read
command, and then assert gt_data_ready once per 1 s period.
IMPORTANT: The controller must not violate DRAM protocol or timing requirements during this

process.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

148

Chapter 4: Designing with the Core

Note: The VT tracking diagrams are not drawn to scale.
X-Ref Target - Figure 4-14

wV

PF5G&$6

wV

V\VWHPFORFNV

PF:U&$6
V\VWHPFORFN

JWBGDWDBUHDG\

wV

wV

V\VWHPFORFN

PF5G&$6
PF:U&$6

V\VWHPFORFN

JWBGDWDBUHDG\

Figure 4-14:

VT Tracking Diagrams

A workload that has a mix of read and write traffic in every 1 s interval might naturally
meet the first and third VT tracking requirements listed above. In this case, the only extra
step required is to assert the gt_data_ready signal every 1 s and regular traffic would
not be interrupted at all. The custom controller, however, is responsible for ensuring all
three requirements are met for all workloads. DDR3/DDR4 SDRAM generated controllers
monitor the mcRdCAS and mcWrCAS signals and decide each 1 s period what actions, if
any, need to be taken to meet the VT tracking requirements. Your custom controller can
implement any scheme that meets the requirements described here.

Refresh and ZQ
After calDone is asserted by the PHY, periodic DRAM refresh and ZQ calibration are the
responsibility of your custom Memory Controller. Your controller must issue refresh and ZQ
commands, meet DRAM refresh and ZQ interval requirements, while meeting all other
DRAM protocol and timing requirements. For example, if a refresh is due and you have open
pages in the DRAM, you must precharge the pages, wait tRP, and then issue a refresh
command, etc. The PHY does not perform the precharge or any other part of this process
for you.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

149

Chapter 4: Designing with the Core

Performance
The efficiency of a memory system is affected by many factors including limitations due to
the memory, such as cycle time (tRC) within a single bank, or Activate to Activate spacing to
the same DDR4 bank group (tRRD_L). When given multiple transactions to work on, the
Memory Controller schedules commands to the DRAM in a way that attempts to minimize
the impact of these DRAM timing requirements. But there are also limitations due to the
Memory Controller architecture itself. This section explains the key controller limitations
and options for obtaining the best performance out of the controller.

Address Map
The app_addr to the DRAM address map is described in the User Interface. Three mapping
options are included:

ROW_COLUMN_BANK

ROW_BANK_COLUMN

BANK_ROW_COLUMN

For a purely random address stream at the user interface, all three options would result in
a similar efficiency. For a sequential app_addr address stream, or any workload that tends
to have a small stride through the app_addr memory space, the ROW_COLUMN_BANK
mapping generally provides a better overall efficiency. This is due to the Memory Controller
architecture and the interleaving of transactions across the Group FSMs. The Group FSMs
are described in the Memory Controller, page 18. This controller architecture impact on
efficiency should be considered even for situations where DRAM timing is not limiting
efficiency. Table 4-60 shows two mapping options for the 4 Gb (x8) DRAM components.
Table 4-60:
DRAM
Address

DDR3/DDR4 4 Gb (x8) DRAM Address Mapping Options

DDR3 4 Gb (x8)

DDR4 4 Gb (x8)

ROW_BANK_COLUMN ROW_COLUMN_BANK ROW_BANK_COLUMN ROW_COLUMN_BANK

Row 15

28

28

Row 14

27

27

28

28

Row 13

26

26

27

27

Row 12

25

25

26

26

Row 11

24

24

25

25

Row 10

23

23

24

24

Row 9

22

22

23

23

Row 8

21

21

22

22

Row 7

20

20

21

21

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

150

Chapter 4: Designing with the Core

Table 4-60:

DDR3/DDR4 4 Gb (x8) DRAM Address Mapping Options (Contd)

DRAM
Address

DDR3 4 Gb (x8)

DDR4 4 Gb (x8)

ROW_BANK_COLUMN ROW_COLUMN_BANK ROW_BANK_COLUMN ROW_COLUMN_BANK

Row 6

19

19

20

20

Row 5

18

18

19

19

Row 4

17

17

18

18

Row 3

16

16

17

17

Row 2

15

15

16

16

Row 1

14

14

15

15

Row 0

13

13

14

14

Column 9

12

13

Column 8

11

12

Column 7

10

11

Column 6

10

Column 5

Column 4

Column 3

Column 2

Column 1

Column 0

Bank 2

12

Bank 1

11

11

Bank 0

10

10

Bank Group 1

13

Bank Group 0

12

Note: Highlighted bits are used to map addresses to Group FSMs in the controller.
From the DDR3 map, you might expect reasonable efficiency with the
ROW_BANK_COLUMN option with a simple address increment pattern. The increment
pattern would generate page hits to a single bank, which DDR3 could handle as a stream of
back-to-back CAS commands resulting in high efficiency. But looking at the italic bank bits
in Table 4-60 show that the address increment pattern also maps the long stream of page
hits to the same controller Group FSM.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

151

Chapter 4: Designing with the Core

For example, Table 4-61 shows how the first 12 app_addr addresses decode to the DRAM
addresses and map to the Group FSMs for both mapping options. The
ROW_BANK_COLUMN option only maps to the Group FSM 0 over this address range.
Table 4-61:
app_addr

DDR3/DDR4 4 Gb (x8) app_addr Mapping Options

DDR3 4 Gb (x8) ROW_BANK_COLUMN

DDR3 4 Gb (x8) ROW_COLUMN_BANK

Row

Column

Bank

Group_FSM

Row

Column

Bank

Group_FSM

0x58

0x0

0x58

0x0

0x0

0x8

0x6

0x50

0x0

0x50

0x0

0x0

0x8

0x4

0x48

0x0

0x48

0x0

0x0

0x8

0x2

0x40

0x0

0x40

0x0

0x0

0x8

0x0

0x38

0x0

0x38

0x0

0x0

0x0

0x7

0x30

0x0

0x30

0x0

0x0

0x0

0x5

0x28

0x0

0x28

0x0

0x0

0x0

0x3

0x20

0x0

0x20

0x0

0x0

0x0

0x1

0x18

0x0

0x18

0x0

0x0

0x0

0x6

0x10

0x0

0x10

0x0

0x0

0x0

0x4

0x8

0x0

0x8

0x0

0x0

0x0

0x2

0x0

0x0

0x0

0x0

0x0

0x0

0x0

As mentioned in the Memory Controller, page 18, a Group FSM can issue one CAS
command every three system clock cycles, or every 12 DRAM clock cycles, even for page
hits. Therefore with only a single Group FSM issuing page hit commands to the DRAM for
long periods, the maximum efficiency is 33%.
Table 4-61 shows that the ROW_COLUMN_BANK option maps these same 12 addresses
evenly across all eight DRAM banks and all four controller Group FSMs. This generates eight
page empty transactions which open up all eight DRAM banks, followed by page hits to
the open banks.
With all four Group FSMs issuing page hits, the efficiency can hit 100%, for as long as the
address increment pattern continues, or until a refresh interrupts the pattern, or there is bus
dead time for a DQ bus turnaround, etc. Figure 4-15 shows the Group FSM issue over a
larger address range for the ROW_BANK_COLUMN option. Note that the first 2k addresses
map to two DRAM banks, but only one Group FSM.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

152

Chapter 4: Designing with the Core

X-Ref Target - Figure 4-15

Figure 4-15:

DDR3 4 Gb (x8) Address Map ROW_BANK_COLUMN Graph

The address map graph for the ROW_COLUMN_BANK option is shown in Figure 4-16. Note
that the address range in this graph is only 64 bytes, not 8k bytes. This graph is showing the
same information as in the Address Decode in Table 4-61. With an address pattern that
tends to stride through memory in minimum sized steps, efficiency tends to be High with
the ROW_COLUMN_BANK option.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

153

Chapter 4: Designing with the Core

X-Ref Target - Figure 4-16

Figure 4-16:

DDR3 4 Gb (x8) Address Map ROW_COLUMN_BANK Graph

Note that the ROW_COLUMN_BANK option does not result in High bus efficiency for all
strides through memory. Consider the case of a stride of 16 bytes. This maps to only two
Group FSMs resulting in a maximum efficiency of 67%. A stride of 32 bytes maps to only one
Group FSM and the maximum efficiency is the same as the ROW_BANK_COLUMN option,
just 33%. For an address pattern with variable strides, but strides that tend to be < 1k in the
app_addr address space, the ROW_COLUMN_BANK option is much more likely to result in
good efficiency.
The same Group FSM issue exists for DDR4. With an address increment pattern and the
DDR4 ROW_BANK_COLUMN option, the first 4k transactions map to a single Group FSM, as
well as mapping to banks within a single DRAM bank group. The DRAM would limit the
address increment pattern efficiency due to the tCCD_L timing restriction. The controller
limitation in this case is even more restrictive, due to the single Group FSM. Again the
efficiency would be limited to 33%.
With the ROW_COLUMN_BANK option, the address increment pattern interleaves across all
the DRAM banks and bank groups and all of the Group FSMs over a small address range.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

154

Chapter 4: Designing with the Core

Figure 4-17 shows how the DDR4 4 Gb (x8) ROW_COLUMN_BANK address map for the first
128 bytes of app_addr. This graph shows how the addresses map evenly across all DRAM
banks and bank groups, and all four controller Group FSMs.
X-Ref Target - Figure 4-17

Figure 4-17:

DDR4 4 Gb (x8) Address Map ROW_COLUMN_BANK Graph

When considering whether an address pattern at the user interface results in good DRAM
efficiency, the mapping of the pattern to the controller Group FSMs is just as important as
the mapping to the DRAM address. The app_addr bits that map app_addr addresses to
the Group FSMs are shown in Table 4-62 for 4 Gb and 8 Gb components.
Table 4-62:

DDR3/DDR4 Map Options for 4 Gb and 8 Gb

Memory Type
Map Option

DDR3
ROW_BANK_COLUMN

DDR4
ROW_COLUMN
ROW_COLUMN
ROW_BANK_COLUMN
_BANK
_BANK

DRAM Component
Width

x4

x8

x16

x4, x8, x16

x4, x8

x16

x4, x8, x16

Component Density

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

155

Chapter 4: Designing with the Core

Table 4-62:

DDR3/DDR4 Map Options for 4 Gb and 8 Gb (Contd)

Memory Type
Map Option

DDR3
ROW_BANK_COLUMN

DDR4
ROW_COLUMN
ROW_COLUMN
ROW_BANK_COLUMN
_BANK
_BANK

4 Gb

13,12

12,11

12,11

4,3

13,12

12,10

4,3

8 Gb

14,13

13,12

12,11

4,3

13,12

12,10

4,3

Consider an example where you try to obtain good efficiency using only four DDR3 banks
at a time. Assume you are using a 4 Gb (x8) with the ROW_COLUMN_BANK option and you
decide to open a page in banks 0, 1, 2, and 3, and issue transactions to four column
addresses in each bank. Using the address map from Address Map, determine the
app_addr pattern that decodes to this DRAM sequence. Applying the Group FSM map
from Table 4-62, determine how this app_addr pattern maps to the FSMs. The result is
shown in Table 4-63.
Table 4-63:
app_addr

Four Banks Sequence on DDR3 4 Gb (x8)

Bank 0, 1, 2, 3 Sequence DDR3 4 Gb (x8)
ROW_COLUMN_BANK
Row

Column

Bank

Group_FSM

0xE8

0x0

0x18

0x3

0xC8

0x0

0x18

0x2

0xE0

0x0

0x18

0x1

0xC0

0x0

0x18

0x0

0xA8

0x0

0x10

0x3

0x88

0x0

0x10

0x2

0xA0

0x0

0x10

0x1

0x80

0x0

0x10

0x0

0x68

0x0

0x8

0x3

0x48

0x0

0x8

0x2

0x60

0x0

0x8

0x1

0x40

0x0

0x8

0x0

0x28

0x0

0x0

0x3

0x08

0x0

0x0

0x2

0x20

0x0

0x0

0x1

0x00

0x0

0x0

0x0

The four bank pattern in Table 4-63 works well from a DRAM point of view, but the
controller only uses two of its four Group FSMs and the maximum efficiency is 67%. In
practice it is even lower due to other timing restrictions like tRCD. A better bank pattern
would be to open all the even banks and send four transactions to each as shown in
Table 4-64.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

156

Chapter 4: Designing with the Core

Table 4-64:

Four Even Banks Sequence on DDR3 4 Gb (x8)

app_addr

Bank 0, 2, 4, 6 Sequence DDR3 4 Gb (x8)

ROW_COLUMN_BANK
Row

Column

Bank

Group_FSM

0xD8

0x0

0x18

0x6

0xD0

0x0

0x18

0x4

0xC8

0x0

0x18

0x2

0xC0

0x0

0x18

0x0

0x98

0x0

0x10

0x6

0x90

0x0

0x10

0x4

0x88

0x0

0x10

0x2

0x80

0x0

0x10

0x0

0x58

0x0

0x8

0x6

0x50

0x0

0x8

0x4

0x48

0x0

0x8

0x2

0x40

0x0

0x8

0x0

0x18

0x0

0x0

0x6

0x10

0x0

0x0

0x4

0x08

0x0

0x0

0x2

0x00

0x0

0x0

0x0

The even bank pattern uses all of the Group FSMs and therefore has better efficiency than
the previous pattern.

Controller Head of Line Blocking and Look Ahead

As described in the Memory Controller, page 18, each Group FSM has an associated
transaction FIFO that is intended to improve efficiency by reducing head of line blocking.
Head of line blocking occurs when one or more Group FSMs are fully occupied and cannot
accept any new transactions for the moment, but the transaction presented to the user
interface command port maps to one of the unavailable Group FSMs. This not only causes
a delay in issuing new transactions to those busy FSMs, but to all the other FSMs as well,
even if they are idle.
For good efficiency, you want to keep as many Group FSMs busy in parallel as you can. You
could try changing the transaction presented to the user interface to one that maps to a
different FSM, but you do not have visibility at the user interface as to which FSMs have
space to take new transactions. The transaction FIFOs prevent this type of head of line
blocking until a UI command maps to an FSM with a full FIFO.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

157

Chapter 4: Designing with the Core

A Group FSM FIFO structure can hold up to six transactions, depending on the page status
of the target rank and bank. The FIFO structure is made up of two stages that also
implement a Look Ahead function. New transactions are placed in the first FIFO stage and
are operated on when they reach the head of the FIFO. Then depending on the transaction
page status, the Group FSM either arbitrates to open the transaction page, or if the page is
already open, the FSM pushes the page hit into the second FIFO stage. This scheme allows
multiple page hits to be queued up while the FSM looks ahead into the logical FIFO
structure for pages that need to be opened. Looking ahead into the queue allows an FSM to
interleave DRAM commands for multiple transactions on the DDR bus. This helps to hide
DRAM tRCD and tRP timing associated with opening and closing pages.
The following conceptual timing diagram shows the transaction flow from the UI to the
DDR command bus, through the Group FSMs, for a series of transactions. The diagram is
conceptual in that the latency from the UI to the DDR bus is not considered and not all
DRAM timing requirements are met. Although not completely timing accurate, the diagram
does follow DRAM protocol well enough to help explain the controller features under
discussion.
Four transactions are presented at the UI, the first three mapping to the Group FSM0 and
the fourth to FSM1. On system clock cycle 1, FSM0 accepts transaction 1 to Row 0, Column
0, and Bank 0 into its stage 1 FIFO and issues an Activate command.
On clock 2, transaction 1 is moved into the FSM0 stage 2 FIFO and transaction 2 is accepted
into FSM0 stage 1 FIFO. On clock cycles 2 through 4, FSM0 is arbitrating to issue a CAS
command for transaction 1, and an Activate command for transaction 2. FSM0 is looking
ahead to schedule commands for transaction 2 even though transaction 1 is not complete.
Note that the time when these DRAM commands win arbitration is determined by DRAM
timing such as tRCD and controller pipeline delays, which explains why the commands are
spaced on the DDR command bus as shown.
On cycle 3, transaction 3 is accepted into FSM0 stage 1 FIFO, but it is not processed until
clock cycle 5 when it comes to the head of the stage 1 FIFO. Cycle 5 is where FSM0 begins
looking ahead at transaction 3 while also arbitrating to issue the CAS command for
transaction 2. Finally on cycle 4, transaction 4 is accepted into FSM1 stage 1 FIFO. If FSM0
did not have at least a three deep FIFO, transaction 4 would have been blocked until cycle 6.
Transaction Flow
System
Clock Cycle

10

11

12

13

UI
Transaction
Number

UI
Transaction

R0,
C0,
B0

R0,
C0,
B1

R1,
C0,
B0

R0,
C0,
B2

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

158

Chapter 4: Designing with the Core

Transaction Flow
FSM0 FIFO
Stage 2

R0,
C0,
B0

R0,
C0,
B0

R0,
C0,
B0

R0,
C0,
B1

R0,
C0,
B1

R0,
B0,
B1

R1,
C0,
B0

R1,
C0,
B0

R1,
C0,
B0

R0,
C0,
B1
R1,
C0,
B0

R1,
C0,
B0

R1,
C0,
B0

R1,
C0,
B0

R1,
C0,
B0

R1,
C0,
B0

FSM0 FIFO
Stage 1

R0,
C0,
B0

R0,
C0,
B1

R0,
C0,
B1
R1,
C0,
B0

FSM1 FIFO
Stage 2

R0,
C0,
B2

R0,
C0,
B2

R0,
C0,
B2

FSM1 FIFO
Stage 1

R0,
C0,
B2

R0,
C0,
B2

Act
R0,
B1

ACT
R0,
B2
CAS
C0,
B0

CAS
C0,
B1

Act
R1,
B0
CAS
C0,
B2

CAS
C0,
B0

DDR
Command
Bus

Act
R0,
B0

Pre
B0

This diagram does not show a high efficiency transaction pattern. There are no page hits
and only two Group FSMs are involved. But the example does show how a single Group FSM
interleaves DRAM commands for multiple transactions on the DDR bus and minimizes
blocking of the UI, thereby improving efficiency.

Autoprecharge
The Memory Controller defaults to a page open policy. It leaves banks open, even when
there are no transactions pending. It only closes banks when a refresh is due, a page miss
transaction is being processed, or when explicitly instructed to issue a transaction with a
RDA or WRA CAS command. The app_autoprecharge port on the UI allows you to
explicitly instruct the controller to issue a RDA or WRA command in the CAS command
phase of processing a transaction, on a per transaction basis. You can use this signal to
improve efficiency when you have knowledge of what transactions will be sent to the UI in
the future.
The following diagram is a modified version of the look ahead example from the previous
section. The page miss transaction that was previously presented to the UI in cycle 3 is now
moved out to cycle 9. The controller can no longer look ahead and issues the Precharge to
Bank 0 in cycle 6 because it does not know about the page miss until cycle 9. But if you
know that transaction 1 in cycle 1 is the only transaction to Row 0 in Bank0, assert the
app_autoprecharge port in cycle 1. Then, the CAS command for transaction 1 in cycle 5
is a RDA or WRA, and the transaction to Row 1, Bank 0 in cycle 9 is no longer a page miss.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

159

Chapter 4: Designing with the Core

The transaction in cycle 9 is only needed as an Activate command instead of a Precharge
followed by an Activate tRP later.
Transaction Flow
System
Clock Cycle

10

11

12

13

UI
Transaction
Number

UI
Transaction

R0, C0, B0
AutoPrecharge

R0,
C0,
B1

R0,
C0,
B2

R1,
C0,
B0

FSM0 FIFO
Stage 2

R0, R0,
C0, C0,
B0 B0

R0,
C0,
B0

R0,
C0,
B1

R0,
C0,
B1

R0,
B0,
B1

R1,
C0,
B0

R1,
C0,
B0

R1,
C0,
B0

FSM0 FIFO
Stage 1

R0, C0, B0

R0, R0,
C0, C0,
B1 B1

R0,
C0,
B1

R1,
C0,
B0

FSM1 FIFO
Stage 2

R0,
C0,
B2

R0,
C0,
B2

R0,
C0,
B2

FSM1 FIFO
Stage 1

R0,
C0,
B2

R0,
C0,
B2

Act
R0,
B1

Act
R0,
B2
CASA
C0,
B0

CAS
C0,
B1

Act
R1,
B0
CAS
C0,
B2

CAS
C0,
B0

DDR
Command
Bus

Act R0, B0

A general rule for improving efficiency is to assert app_autoprecharge on the last

transaction to a page. An extreme example is an address pattern that never generates page
hits. In this situation, it is best to assert app_autoprecharge on every transactions issued
to the UI.

User Refresh and ZQCS

The Memory Controller can be configured to automatically generate DRAM refresh and
ZQCS maintenance commands to meet DRAM timing requirements. In this mode, the
controller blocks the UI transactions on a regular basis to issue the maintenance
commands, reducing efficiency.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

160

Chapter 4: Designing with the Core

If you have knowledge of the UI traffic pattern, you might be able to schedule DRAM
maintenance commands with less impact on system efficiency. You can use the app_ref
and app_zq ports at the UI to schedule these commands when the controller is configured
for User Refresh and ZQCS. In this mode, the controller does not schedule the DRAM
maintenance commands and only issues them based on the app_ref and app_zq ports.
You are responsible for meeting all DRAM timing requirements for refresh and ZQCS.
Consider a case where the system needs to move a large amount of data into or out of the
DRAM with the highest possible efficiency over a 50 s period. If the controller schedules
the maintenance commands, this 50 s data burst would be interrupted multiple times for
refresh, reducing efficiency roughly 4%. In User Refresh mode, however, you can decide to
postpone refreshes during the 50 s burst and make them up later. The DRAM specification
allows up to eight refreshes to be postponed, giving you flexibility to schedule refreshes
over a 9 tREFI period, more than enough to cover the 50 s in this example.
While User Refresh and ZQCS enable you to optimize efficiency, their incorrect use can lead
to DRAM timing violations and data loss in the DRAM. Use this mode only if you thoroughly
understand DRAM refresh and ZQCS requirements as well as the operation of the app_ref
and app_zq UI ports. The UI port operation is described in the User Interface.

Periodic Reads
The FPGA DDR PHY requires at least one DRAM RD or RDA command to be issued every
1 s. This requirement is described in the User Interface. If this requirement is not met by
the transaction pattern at the UI, the controller detects the lack of reads and injects a read
transaction into Group FSM0. This injected read is issued to the DRAM following the normal
mechanisms of the controller issuing transactions. The key difference is that no read data is
returned to the UI. This is wasted DRAM bandwidth.
User interface patterns with long strings of write transactions are affected the most by the
PHY periodic read requirement. Consider a pattern with a 50/50 read/write transaction
ratio, but organized such that the pattern alternates between 2 s bursts of 100% page hit
reads and 2 s bursts of 100% page hit writes. There is at least one injected read in the 2 s
write burst, resulting in a loss of efficiency due to the read command and the turnaround
time to switch the DRAM and DDR bus from writes to reads back to writes. This 2 s
alternating burst pattern is slightly more efficient than alternating between reads and
writes every 1 s. A 1 s or shorter alternating pattern would eliminate the need for the
controller to inject reads, but there would still be more read-write turnarounds.
Bus turnarounds are expensive in terms of efficiency and should be avoided if possible.
Long bursts of page hit writes, > 2 s in duration, are still the most efficient way to write to
the DRAM, but the impact of one write-read-write turnaround each 1 s must be taken into
account when calculating the maximum write efficiency.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

161

Chapter 4: Designing with the Core

DIMM Configurations
DDR3/DDR4 SDRAM memory interface supports UDIMM, RDIMM, and SODIMM in multiple
slot configurations.
IMPORTANT: Note that the chip select order generated by Vivado is dependant to your board design.

In the following configurations, the empty slot is not used and it is optional to be
implemented on the board.

DDR3/DDR4 UDIMM/SODIMM
Table 4-65 and Figure 4-18 show the four configurations supported for DDR3/DDR4
UDIMM and SODIMM.
For a Dual Rank DIMM, Dual Slot configuration, follow the chip select order shown in
Figure 4-18, where CS0 and CS1 are connected to Slot0 and CS2 and CS3 are connected to
Slot1.
Table 4-65:

DDR3/DDR4 UDIMM Configuration

Slot0

Slot1

Single rank

Empty

Dual rank

Empty

Dual rank

Dual rank

Single rank

Single rank

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

162

Chapter 4: Designing with the Core

X-Ref Target - Figure 4-18

''5''58',00
6ORW

6ORW

5DQN 

&6

6ORW

6ORW

5DQN 

&6
&6

6ORW

6ORW
5DQN 

&6

5DQN 

6ORW

6ORW
5DQN 

&6
&6

&6

&6

5DQN 

&6

;

Figure 4-18:

DDR3/DDR4 UDIMM Configuration

DDR3 RDIMM
Table 4-66 and Figure 4-19 show the five configurations supported for DDR3 RDIMM.
DDR3 RDIMM requires two chip selects for a single rank RDIMM to program the register
chip.
For a Single Rank DIMM, Dual slot configuration, you must follow the chip select order
shown in Figure 4-19, where CS0 and CS2 are connected to Slot0 and CS1 and CS3 are
connected to Slot1.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

163

Chapter 4: Designing with the Core

For a Dual Rank DIMM, Dual Slot configuration, follow the chip select order shown in
Figure 4-19, where CS0 and CS1 are connected to Slot0 and CS2 and CS3 are connected to
Slot1.
Table 4-66:

DDR3 RDIMM Configuration

Slot0

Slot1

Single rank

Empty

Single rank

Single rank

Dual rank

Empty

Dual rank

Dual rank

Quad rank

Empty

X-Ref Target - Figure 4-19

''55',00
6ORW

6ORW

5DQN 

&6

5DQN 

&6

5DQN 

&6

&6
&6

6ORW

6ORW

6ORW

&6

6ORW

6ORW

5DQN 

&6

6ORW

6ORW
5DQN 

&6

&6

5DQN 

&6

6ORW
5DQN 

&6
&6

&6
&6
&6
&6

;

Figure 4-19:

DDR3 RDIMM Configuration

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

164

Chapter 4: Designing with the Core

DDR4 RDIMM
Table 4-67 and Figure 4-20 show the four configurations supported for DDR4 RDIMM.
For Dual Rank DIMM, Dual Slot configuration, follow the chip select order shown in
Figure 4-20, where CS0 and CS1 are connected to Slot0 and CS2 and CS3 are connected to
Slot1.
Table 4-67:

DDR4 RDIMM Configuration

Slot0

Slot1

Single rank

Empty

Single rank

Single rank

Dual rank

Empty

Dual rank

Dual rank

X-Ref Target - Figure 4-20

''55',00
6ORW

6ORW

5DQN 

6ORW

6ORW
5DQN 

&6

5DQN 

&6

6ORW

6ORW

5DQN 

&6
&6

6ORW

6ORW
5DQN 

&6

&6

5DQN 

&6

&6
&6

;

Figure 4-20:

DDR4 RDIMM Configuration

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

165

Chapter 4: Designing with the Core

SLOT0_CONFIG
In a given DIMM configuration, the logic chip select is mapped to physical slot using an
8-bit number per SLOT. Each bit corresponds to a logic chip select connectivity in a SLOT.
Example 1: Dual Rank DIMM, Dual Slot system (total of four ranks):
SLOT0_CONFIG = 8'b0000_0011 // describes CS0 and CS1 are connected to SLOT0.
SLOT1_CONFIG = 8'b0000_1100 // describes CS2 and CS3 are connected to SLOT1.
SLOT0_FUNC_CS = 8'b0000_0011 // describes CS0 and CS1 in SLOT0 are functional chip
select.
SLOT1_FUNC_CS = 8'b0000_1100 // describes CS2 and CS3 in SLOT1 are functional chip
select.

Example 2: Single Rank DIMM, Dual Slot system (total of two ranks):
SLOT0_CONFIG = 8'b0000_0001 // describes CS0 is connected to SLOT0.
SLOT1_CONFIG = 8'b0000_0010 // describes CS2 and CS3 are connected to SLOT1.
SLOT0_FUNC_CS = 8'b0000_0001 // describes CS0 and CS1 in SLOT0 are functional chip
select.
SLOT1_FUNC_CS = 8'b0000_0001 // describes CS2 and CS3 in SLOT1 are functional chip
select.

SLOT0_FUNC_CS
A DDR3 single rank RDIMM and two chip selects are needed to access the register chip.
However, only the lower rank chip select is used as functional chip select. SLOT0_FUNC_CS
describes the functional chip select per SLOT. For any DIMM other than a DDR3 single rank
RDIMM, SLOT0_CONFIG is the same as SLOT0_FUNC_CS and SLOT1_CONFIG is the same as
SLOT1_FUNC_CS.
Example 1: DDR3 RDIMM, Single Rank DIMM, Single Slot system:
SLOT0_CONFIG = 8'b0000_0011 // describes CS0 and CS1 are connected to SLOT0.
SLOT1_CONFIG = 8'b0000_0000 // describes no DIMM is connected to SLOT1.
SLOT0_FUNC_CS = 8'b0000_0001 // describes CS0 is functional chip select. CS1 is not
functional chip select and is only used for register chip access.
SLOT1_FUNC_CS = 8'b0000_0000 // describes there is no functional chip select in
SLOT1.

Example 2: DDR3 RDIMM, Single Rank DIMM, Dual Slot system:

SLOT0_CONFIG = 8'b0000_0011 // describes CS0 and CS1 are connected to SLOT0.
SLOT1_CONFIG = 8'b0000_1100 // describes CS2 and CS3 are connected to SLOT1.
SLOT0_FUNC_CS = 8'b0000_0001 // describes CS0 is functional chip select. CS1 is not
functional chip select and is only used for Register Chip access.
SLOT1_FUNC_CS = 8'b0000_0100 // describes CS2 is functional chip select. CS3 is not
functional chip select and is only used for register chip access.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

166

Chapter 5

Design Flow Steps

This chapter describes customizing and generating the core, constraining the core, and the
simulation, synthesis and implementation steps that are specific to this IP core. More
detailed information about the standard Vivado design flows and the Vivado IP integrator
can be found in the following Vivado Design Suite user guides:

Vivado Design Suite User Guide: Designing IP Subsystems using IP Integrator (UG994)
[Ref 8]

Vivado Design Suite User Guide: Designing with IP (UG896) [Ref 9]

Vivado Design Suite User Guide: Getting Started (UG910) [Ref 10]

Vivado Design Suite User Guide: Logic Simulation (UG900) [Ref 11]

Customizing and Generating the Core

CAUTION! The Windows operating system has a 260-character limit for path lengths, which can affect
the Vivado tools. To avoid this issue, use the shortest possible names and directory locations when
creating projects, defining IP or managed IP projects, and creating block designs.

This section includes information about using Xilinx tools to customize and generate the
core in the Vivado Design Suite.
If you are customizing and generating the core in the IP integrator, see the Vivado Design
Suite User Guide: Designing IP Subsystems using IP Integrator (UG994) [Ref 8] for detailed
information. IP integrator might auto-compute certain configuration values when
validating or generating the design. To check whether the values change, see the
description of the parameter in this chapter. To view the parameter value, run the
validate_bd_design command in the Tcl Console.
You can customize the IP for use in your design by specifying values for the various
parameters associated with the IP core using the following steps:
1. Select the IP from the Vivado IP catalog.
2. Double-click the selected IP or select the Customize IP command from the toolbar or
right-click menu.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

167

Chapter 5: Design Flow Steps

For more information about generating the core in Vivado, see the Vivado Design Suite User
Guide: Designing with IP (UG896) [Ref 9] and the Vivado Design Suite User Guide: Getting
Started (UG910) [Ref 10].
Note: Figures in this chapter are illustrations of the Vivado Integrated Design Environment (IDE).
This layout might vary from the current version.

Basic Tab
Figure 5-1 and Figure 5-2 show the Basic tab when you start up the DDR3/DDR4 SDRAM.
X-Ref Target - Figure 5-1

Figure 5-1:

Vivado Customize IP Dialog Box for DDR3 Basic Tab

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

168

Chapter 5: Design Flow Steps

X-Ref Target - Figure 5-2

Figure 5-2:

Vivado Customize IP Dialog Box for DDR4 Basic Tab

IMPORTANT: All parameters shown in the controller options dialog box are limited selection options in

this release.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

169

Chapter 5: Design Flow Steps

For the Vivado IDE, all controllers (DDR3, DDR4, QDR II+, and RLDRAM 3) can be created
and available for instantiation.
In IP integrator, only one controller instance can be created and only two kinds of
controllers are available for instantiation:

DDR3

DDR4

1. After a controller is added in the pull-down menu, select the Mode and Interface for
the controller. Select the AXI4 Interface or have the option to select the Generate the
PHY component only.
2. Select the settings in the Clocking, Controller Options, Memory Options, and
Advanced User Request Controller Options.
In Clocking, the Memory Device Interface Speed sets the speed of the interface. The
speed entered drives the available Reference Input Clock Speeds. For more
information on the clocking structure, see the Clocking, page 73.
3. To use memory parts which are not available by default through the DDR3/DDR4
SDRAM Vivado IDE, you can create a custom parts CSV file, as specified in the AR:
63462. This CSV file has to be provided after enabling the Custom Parts Data File
option. After selecting this option. you are able to see the custom memory parts along
with the default memory parts. Note that, simulations are not supported for the custom
part.
IMPORTANT: Data Mask (DM) option is always selected for AXI designs and is grayed out (you cannot

select it). For AXI interfaces, Read Modify Write (RMW) is supported and for RMW to mask certain bytes
of Data Mask bits should be present. Therefore, the DM is always enabled for AXI interface designs. This
is the case for all data widths except 72-bit.
For 72-bit interfaces, ECC is enabled and DM is deselected and grayed out for 72-bit designs. If DM is
enabled for 72-bit designs, computing ECC does is not compatible, so DM is disabled for 72-bit designs.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

170

Chapter 5: Design Flow Steps

Advanced Tab
Figure 5-3 and Figure 5-4 show the next tab called Advanced. This displays the settings for
FPGA Options, Debug Signals for Controller, Simulation Options, and Clock Options for
the specific controller.
X-Ref Target - Figure 5-3

Figure 5-3:

Vivado Customize IP Dialog Box for DDR3 Advanced

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

171

Chapter 5: Design Flow Steps

X-Ref Target - Figure 5-4

Figure 5-4:

Vivado Customize IP Dialog Box for DDR4 Advanced

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

172

Chapter 5: Design Flow Steps

DDR3/DDR4 SDRAM Design Checklist Tab

Figure 5-5 and Figure 5-6 show the DDR3/DDR4 SDRAM Design Checklist usage
information.
X-Ref Target - Figure 5-5

Figure 5-5:

Vivado Customize IP Dialog Box DDR3 SDRAM Design Checklist Tab

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

173

Chapter 5: Design Flow Steps

X-Ref Target - Figure 5-6

Figure 5-6:

Vivado Customize IP Dialog Box DDR4 SDRAM Design Checklist Tab

User Parameters
Table 5-1 shows the relationship between the fields in the Vivado IDE and the User
Parameters (which can be viewed in the Tcl Console).
Table 5-1:

Vivado IDE Parameter to User Parameter Relationship

Vivado IDE Parameter/Value(1)

User Parameter/Value(1)

Default Value

System Clock Configuration

System_Clock

Differential

Internal V REF

Internal_Vref

TRUE

DCI Cascade

DCI_Cascade

FALSE

Debug Signal for Controller

Debug_Signal

Disable

Clock 1 (MHz)

ADDN_UI_CLKOUT1_FREQ_HZ

None

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

174

Chapter 5: Design Flow Steps

Table 5-1:

Vivado IDE Parameter to User Parameter Relationship (Contd)

Vivado IDE Parameter/Value(1)

User Parameter/Value(1)

Default Value

Clock 2 (MHz)

ADDN_UI_CLKOUT2_FREQ_HZ

None

Clock 3 (MHz)

ADDN_UI_CLKOUT3_FREQ_HZ

None

Clock 4 (MHz)

ADDN_UI_CLKOUT4_FREQ_HZ

None

I/O Power Reduction

IOPowerReduction

OFF

Enable System Ports

Enable_SysPorts

TRUE

I/O Power Reduction

IO_Power_Reduction

FALSE

Default Bank Selections

Default_Bank_Selections

FALSE

Reference Clock

Reference_Clock

FALSE

Enable System Ports

Enable_SysPorts

TRUE

DDR3
AXI4 Interface

C0.DDR3_AxiSelection

FALSE

Clock Period (ps)

C0.DDR3_TimePeriod

1,071

Input Clock Period (ps)

C0.DDR3_InputClockPeriod

13,947

General Interconnect to Memory Clock

Ratio

C0.DDR3_PhyClockRatio

4:1

Data Width

C0.DDR3_AxiDataWidth

64

Arbitration Scheme

C0.DDR3_AxiArbitrationScheme

RD_PRI_REG

Address Width

C0.DDR3_AxiAddressWidth

27

AXI4 Narrow Burst

C0.DDR3_AxiNarrowBurst

FALSE

Configuration

C0.DDR3_MemoryType

Components

Memory Part

C0.DDR3_MemoryPart

MT41J128M16JT-093

Data Width

C0.DDR3_DataWidth

Data Mask

C0.DDR3_DataMask

TRUE

Burst Length

C0.DDR3_BurstLength

RTT (nominal)-ODT

C0.DDR3_OnDieTermination

RZQ/4

CAS Latency

C0.DDR3_CasLatency

11

CAS Write Latency

C0.DDR3_CasWriteLatency

Chip Select

C0.DDR3_ChipSelect

TRUE

Memory Address Map

C0.DDR3_Mem_Add_Map

ROW_COLUMN_BANK

Memory Voltage

C0.DDR3_MemoryVoltage

1.5

ECC

C0.DDR3_Ecc

FALSE

Ordering

C0.DDR3_Ordering

Normal

Burst Type

C0.DDR3_BurstType

Sequential

Output Driver Impedance Control

C0.DDR3_OutputDriverImpedanceControl

RZQ/7

AXI ID Width

C0.DDR3_AxiIDWidth

Capacity

C0.DDR3_Capacity

512

DDR4
AXI4 Interface

C0.DDR4_AxiSelection

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

FALSE

Send Feedback

175

Chapter 5: Design Flow Steps

Table 5-1:

Vivado IDE Parameter to User Parameter Relationship (Contd)

Vivado IDE Parameter/Value(1)

User Parameter/Value(1)

Default Value

Clock Period (ps)

C0.DDR4_TimePeriod

938

Input Clock Period (ps)

C0.DDR4_InputClockPeriod

104,045

General Interconnect to Memory Clock

Ratio

C0.DDR4_PhyClockRatio

4:1

Data Width

C0.DDR4_AxiDataWidth

64

Arbitration Scheme

C0.DDR4_AxiArbitrationScheme

RD_PRI_REG

Address Width

C0.DDR4_AxiAddressWidth

27

AXI4 Narrow Burst

C0.DDR4_AxiNarrowBurst

FALSE

Configuration

C0.DDR4_MemoryType

Components

Memory Part

C0.DDR4_MemoryPart

MT40A256M16HA-083

Data Width

C0.DDR4_DataWidth

Data Mask

C0.DDR4_DataMask

TRUE

Burst Length

C0.DDR4_BurstLength

RTT (nominal)-ODT

C0.DDR4_OnDieTermination

RZQ/6

CAS Latency

C0.DDR4_CasLatency

14

CAS Write Latency

C0.DDR4_CasWriteLatency

11

Chip Select

C0.DDR4_ChipSelect

TRUE

Memory Address Map

C0.DDR4_Mem_Add_Map

ROW_COLUMN_BANK

Memory Voltage

C0.DDR4_MemoryVoltage

1.2

ECC

C0.DDR4_Ecc

FALSE

Ordering

C0.DDR4_Ordering

Normal

Burst Type

C0.DDR4_BurstType

Sequential

Output Driver Impedance Control

C0.DDR4_OutputDriverImpedenceControl

RZQ/7

AXI ID Width

C0.DDR4_AxiIDWidth

Capacity

C0.DDR4_Capacity

512

Notes:
1. Parameter values are listed in the table where the Vivado IDE parameter value differs from the user parameter value. Such
values are shown in this table as indented below the associated parameter.

Output Generation
For details, see the Vivado Design Suite User Guide: Designing with IP (UG896) [Ref 9].

I/O Planning
DDR3/DDR4 SDRAM I/O pin planning is completed with the full design pin planning using
the Vivado I/O Pin Planner. DDR3/DDR4 SDRAM I/O pins can be selected through several
Vivado I/O Pin Planner features including assignments using I/O Ports view, Package view,

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

176

Chapter 5: Design Flow Steps

or Memory Bank/Byte Planner. Pin assignments can additionally be made through
importing an XDC or modifying the existing XDC file.
These options are available for all DDR3/DDR4 SDRAM designs and multiple DDR3/DDR4
SDRAM IP instances can be completed in one setting. To learn more about the available
Memory IP pin planning options, see the Vivado Design Suite User Guide: I/O and Clock
Planning (UG899) [Ref 13].

Constraining the Core

This section contains information about constraining the core in the Vivado Design Suite.

Required Constraints
For DDR3/DDR4 SDRAM Vivado IDE, you specify the pin location constraints. For more
information on I/O standard and other constraints, see the Vivado Design Suite User Guide:
I/O and Clock Planning (UG899) [Ref 13]. The location is chosen by the Vivado IDE
according to the banks and byte lanes chosen for the design.
The I/O standard is chosen by the memory type selection and options in the Vivado IDE and
by the pin type. A sample for dq[0] is shown here.
set_property PACKAGE_PIN AF20 [get_ports "c0_ddr4_dq[0]"]
set_property IOSTANDARD POD12_DCI [get_ports "c0_ddr4_dq[0]"]

Internal VREF is always used for DDR4. Internal VREF is optional for DDR3. A sample for DDR4
is shown here.
set_property INTERNAL_VREF 0.600 [get_iobanks 45]

Note: Internal V REF is automatically generated by the tool and you do not need to specify it. The

V REF value listed in this constraint is not used with PODL12 I/Os. The initial value is set to 0.84V. The
calibration logic adjusts this voltage as needed for maximum interface performance.

The system clock must have the period set properly:

create_clock -name c0_sys_clk -period.938 [get_ports c0_sys_clk_p]

For HR banks, update the output_impedance of all the ports assigned to HR banks pins
using the reset_property command. For more information, see AR: 63852.
IMPORTANT: Do not alter these constraints. If the pin locations need to be altered, rerun the DDR3/

DDR4 SDRAM Vivado IDE to generate a new XDC file.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

177

Chapter 5: Design Flow Steps

Device, Package, and Speed Grade Selections

This section is not applicable for this IP core.

Clock Frequencies
This section is not applicable for this IP core.

Clock Management
For more information on clocking, see Clocking, page 73.

Clock Placement
This section is not applicable for this IP core.

Banking
This section is not applicable for this IP core.

Transceiver Placement
This section is not applicable for this IP core.

I/O Standard and Placement

The DDR3/DDR4 SDRAM tool generates the appropriate I/O standards and placement
based on the selections made in the Vivado IDE for the interface type and options.
IMPORTANT: The set_input_delay and set_output_delay constraints are not needed on the
external memory interface pins in this design due to the calibration process that automatically runs at
start-up. Warnings seen during implementation for the pins can be ignored.

Simulation
For comprehensive information about Vivado simulation components, as well as
information about using supported third-party tools, see the Vivado Design Suite User
Guide: Logic Simulation (UG900) [Ref 11]. For more information on simulation, see
Chapter 6, Example Design and Chapter 7, Test Bench.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

178

Chapter 5: Design Flow Steps

Synthesis and Implementation

For details about synthesis and implementation, see the Vivado Design Suite User Guide:
Designing with IP (UG896) [Ref 9].

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

179

Chapter 6

Example Design
This chapter contains information about the example design provided in the Vivado
Design Suite.
Vivado supports Open IP Example Design flow. To create the example design using this flow,
right-click the IP in the Source Window, as shown in Figure 6-1 and select Open IP
Example Design.
X-Ref Target - Figure 6-1

Figure 6-1:

Open IP Example Design

This option creates a new Vivado project. Upon selecting the menu, a dialog box to enter
the directory information for the new design project opens.
Select a directory, or use the defaults, and click OK. This launches a new Vivado with all of
the example design files and a copy of the IP.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

180

Chapter 6: Example Design

Figure 6-2 shows the example design with the PHY only option selected (controller module
does not get generated).
X-Ref Target - Figure 6-2

Figure 6-2:

Open IP Example Design with PHY Only Option Selected

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

181

Chapter 6: Example Design

Figure 6-3 shows the example design with the PHY only option not selected (controller
module is generated).
X-Ref Target - Figure 6-3

Figure 6-3:

Open IP Example Design with PHY Only Option Not Selected

Simulating the Example Design (Designs with

Standard User Interface)
The example design provides a synthesizable test bench to generate a fixed simple data
pattern. DDR3/DDR4 SDRAM generates the Simple Traffic Generator (STG) module as
example_tb for native interface and example_tb_phy for PHY only interface. The STG
native interface generates 100 writes and 100 reads. The STG PHY only interface generates
10 writes and 10 reads.
The example design can be simulated using one of the methods in the following sections.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

182

Chapter 6: Example Design

Project-Based Simulation
This method can be used to simulate the example design using the Vivado Integrated
Design Environment (IDE). Memory IP delivers memory models for DDR3 and IEEE
encrypted memory models for DDR4.
The Vivado simulator, QuestaSim, IES, and VCS tools are used for DDR3/DDR4 IP verification
at each software release. The Vivado simulation tool is used for DDR3/DDR4 IP verification
from 2015.1 Vivado software release. The following subsections describe steps to run a
project-based simulation using each supported simulator tool.

Project-Based Simulation Flow Using Vivado Simulator

1. In the Open IP Example Design Vivado project, under Flow Navigator, select
Simulation Settings.
2. Select Target simulator as Vivado Simulator.
a. Under the Simulation tab, set the xsim.simulate.runtime to 1 ms (there are
simulation RTL directives which stop the simulation after certain period of time,
which is less than 1 ms) as shown in Figure 6-4. For DDR3 simulation, set the
xsim.simulate.xsim.more_options to -testplusarg model_data+./.
The Generate Scripts Only option generates simulation scripts only. To run
behavioral simulation, Generate Scripts Only option must be de-selected.
3. Apply the settings and select OK.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

183

Chapter 6: Example Design

X-Ref Target - Figure 6-4

Figure 6-4:

Simulation with Vivado Simulator

4. In the Flow Navigator window, select Run Simulation and select Run Behavioral
Simulation option as shown in Figure 6-5.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

184

Chapter 6: Example Design

X-Ref Target - Figure 6-5

Figure 6-5:

Run Behavioral Simulation

5. Vivado invokes Vivado simulator and simulations are run in the Vivado simulator tool.
For more information, see the Vivado Design Suite User Guide: Logic Simulation (UG900)
[Ref 11].

Project-Based Simulation Flow Using QuestaSim

1. Open a DDR3/DDR4 SDRAM example Vivado project (Open IP Example Design...), then
under Flow Navigator, select Simulation Settings.
2. Select Target simulator as QuestaSim/ModelSim Simulator.
a. Browse to the compiled libraries location and set the path on Compiled libraries
location option.
b. Under the Simulation tab, set the modelsim.simulate.runtime to 1 ms (there
are simulation RTL directives which stop the simulation after certain period of time,
which is less than 1 ms) as shown in Figure 6-6. The Generate Scripts Only option
generates simulation scripts only. To run behavioral simulation, Generate Scripts
Only option must be de-selected. For DDR3 simulation, set the
modelsim.simulate.vsim.more_options to +model_data+./.
3. Apply the settings and select OK.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

185

Chapter 6: Example Design

X-Ref Target - Figure 6-6

Figure 6-6:

Simulation with QuestaSim

4. In the Flow Navigator window, select Run Simulation and select Run
BehavioralSimulation option as shown in Figure 6-7.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

186

Chapter 6: Example Design

X-Ref Target - Figure 6-7

Figure 6-7:

Run Behavioral Simulation

5. Vivado invokes QuestaSim and simulations are run in the QuestaSim tool. For more
information, see the Vivado Design Suite User Guide: Logic Simulation (UG900) [Ref 11].

Project-Based Simulation Flow Using IES

1. Open a DDR3/DDR4 SDRAM example Vivado project (Open IP Example Design...), then
under Flow Navigator, select Simulation Settings.
2. Select Target simulator as Incisive Enterprise Simulator (IES).
a. Browse to the compiled libraries location and set the path on Compiled libraries
location option.
b. Under the Simulation tab, set the ies.simulate.runtime to 1 ms (there are
simulation RTL directives which stop the simulation after certain period of time,
which is less than 1 ms) as shown in Figure 6-8. The Generate Scripts Only option
generates simulation scripts only. To run behavioral simulation, Generate Scripts
Only option must be de-selected. For DDR3 simulation, set the
modelsim.simulate.vsim.more_options to +model_data+./.
3. Apply the settings and select OK.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

187

Chapter 6: Example Design

X-Ref Target - Figure 6-8

Figure 6-8:

Simulation with IES Simulator

4. In the Flow Navigator window, select Run Simulation and select Run
BehavioralSimulation option as shown in Figure 6-7.
5. Vivado invokes IES and simulations are run in the IES tool. For more information, see the
Vivado Design Suite User Guide: Logic Simulation (UG900) [Ref 11].

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

188

Chapter 6: Example Design

Project-Based Simulation Flow Using VCS

1. Open a DDR3/DDR4 SDRAM example Vivado project (Open IP Example Design...), then
under Flow Navigator, select Simulation Settings.
2. Select Target simulator as Verilog Compiler Simulator (VCS).
a. Browse to the compiled libraries location and set the path on Compiled libraries
location option.
b. Under the Simulation tab, set the vcs.simulate.runtime to 1 ms (there are
simulation RTL directives which stop the simulation after certain period of time,
which is less than 1 ms) as shown in Figure 6-9. The Generate Scripts Only option
generates simulation scripts only. To run behavioral simulation, Generate Scripts
Only option must be de-selected. For DDR3 simulation, set the
modelsim.simulate.vsim.more_options to +model_data+./.
3. Apply the settings and select OK.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

189

Chapter 6: Example Design

X-Ref Target - Figure 6-9

Figure 6-9:

Simulation with VCS Simulator

4. In the Flow Navigator window, select Run Simulation and select Run
BehavioralSimulation option as shown in Figure 6-7.
5. Vivado invokes VCS and simulations are run in the VCS tool. For more information, see
the Vivado Design Suite User Guide: Logic Simulation (UG900) [Ref 11].

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

190

Chapter 6: Example Design

Simulation Speed
DDR3/DDR4 SDRAM provides a Vivado IDE option to reduce the simulation speed by
selecting behavioral XIPHY model instead of UNISIM XIPHY model. Behavioral XIPHY model
simulation is a default option for DDR3/DDR4 SDRAM designs. To select the simulation
mode, click the Advanced tab and find the Simulation Options as shown in Figure 6-10.
X-Ref Target - Figure 6-10

Figure 6-10:

Advanced Tab Simulation Options

The SIM_MODE parameter in the RTL is given a different value based on the Vivado IDE
selection.

SIM_MODE = BFM If fast mode is selected in the Vivado IDE, the RTL parameter
reflects this value for the SIM_MODE parameter. This is the default option.

SIM_MODE = FULL If FULL mode is selected in the Vivado IDE, XIPHY UNISIMs are
selected and the parameter value in the RTL is FULL.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

191

Chapter 6: Example Design

Synplify Pro Black Box Testing

Using the Synopsys Synplify Pro black box testing for example_design, follow these
steps to run black box synthesis with synplify_pro and implementation with Vivado.
1. Generate the UltraScale architecture DDR3/DDR4 SDRAM IP core with OOC flow to
generate the .dcp file for implementation. The Target Language for the project can be
selected as verilog or VHDL.
2. Create the example design for the DDR3/DDR4 SDRAM IP core using the information
provided in the example design section and close the Vivado project.
3. Invoke the synplify_pro software which supports UltraScale FPGA and select the
same UltraScale FPGA part selected at the time of generating the IP core.
4. Add the following files into synplify_pro project based on the Target Language
selected at the time of invoking Vivado:
a. For Verilog:
<project_dir>/example_project/<Component_Name>example/
<Component_Name>_example.srcs/sources_1/ip/<Component_Name>/*stub.v
<project_dir>/example_project/<Component_Name>example/
<Component_Name>_example.srcs/sources_1/imports/<Component_Name>/rtl/ip_top/
example_top.sv
<project_dir>/example_project/<Component_Name>example/
<Component_Name>_example.srcs/sources_1/imports/<Component_Name>/tb/example_tb.sv

b. For VHDL:
<project_dir>/example_project/<Component_Name>example/
<Component_Name>_example.srcs/sources_1/ip/<Component_Name>/*stub.vhdl
<project_dir>/example_project/<Component_Name>example/
<Component_Name>_example.srcs/sources_1/imports/<Component_Name>/rtl/ip_top/
example_top.sv
<project_dir>/example_project/<Component_Name>example/
<Component_Name>_example.srcs/sources_1/imports/<Component_Name>/tb/example_tb.sv

5. Run synplify_pro synthesis to generate the .edf file. Then, close the
synplify_pro project.
6. Open new Vivado project with Project Type as Post-synthesis Project and select the
Target Language same as selected at the time of generating the IP core.
7. Add the synplify_pro generated .edf file to the Vivado project as Design Source.
8. Add the .dcp file generated in steps 1 and 2 to the Vivado project as Design Source.
For example:
<project_dir>/example_project/<Component_Name>example/
<Component_Name>_example.srcs/sources_1/ip/<Component_Name>/<Component_Name>.dcp

9. Add the .xdc file generated in step 2 to the Vivado project as constraint. For example:

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

192

Chapter 6: Example Design

<project_dir>/example_project/<Component_Name>example/
<Component_Name>_example.srcs/constrs_1/imports/par/example_design.xdc

10. Run implementation flow with the Vivado tool. For details about implementation, see
the Vivado Design Suite User Guide: Designing with IP (UG896) [Ref 9].
Note: Similar steps can be followed for the user design using appropriate .dcp and .xdc files.

CLOCK_DEDICATED_ROUTE Constraints and BUFG

Instantiation
If the GCIO pin and MMCM are not allocated in the same bank, the
CLOCK_DEDICATED_ROUTE constraint must be set to BACKBONE. To use the BACKBONE
route, BUFG/BUFGCE/BUFGCTRL/BUFGCE_DIV must be instantiated between GCIO and
MMCM input. DDR3/DDR4 SDRAM manages these constraints for designs generated with
the Reference Input Clock option selected as Differential (at Advanced > FPGA Options
> Reference Input). Also, DDR3/DDR4 SDRAM handles the IP and example design flows for
all scenarios.
If the design is generated with the Reference Input Clock option selected as No Buffer (at
Advanced > FPGA Options > Reference Input), the CLOCK_DEDICATED_ROUTE
constraints and BUFG/BUFGCE/BUFGCTRL/BUFGCE_DIV instantiation based on GCIO and
MMCM allocation needs to be handled manually for the IP flow. DDR3/DDR4 SDRAM does
not generate clock constraints in the XDC file for No Buffer configurations and you must
take care of the clock constraints for No Buffer configurations for the IP flow.
For an example design flow with No Buffer configurations, DDR3/DDR4 SDRAM generates
the example design with differential buffer instantiation for system clock pins. DDR3/DDR4
SDRAM generates clock constraints in the example_design.xdc. It also generates a
CLOCK_DEDICATED_ROUTE constraint as the BACKBONE and instantiates BUFG/BUFGCE/
BUFGCTRL/BUFGCE_DIV between GCIO and MMCM input if the GCIO and MMCM are not in
same bank to provide a complete solution. This is done for the example design flow as a
reference when it is generated for the first time.
If in the example design, the I/O pins of the system clock pins are changed to some other
pins with the I/O pin planner, the CLOCK_DEDICATED_ROUTE constraints and BUFG/
BUFGCE/BUFGCTRL/BUFGCE_DIV instantiation need to be managed manually. A DRC error
is reported for the same.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

193

Chapter 7

Test Bench
This chapter contains information about the test bench provided in the Vivado Design
Suite.
The intent of the performance test bench is for you to obtain an estimate on the efficiency
for a given traffic pattern with the DDR3/DDR4 SDRAM controller. The test bench passes
your supplied commands and address to the Memory Controller and measures the
efficiency for the given pattern. The efficiency is measured by the occupancy of the dq bus.
The primary use of the test bench is for efficiency measurements so no data integrity checks
are performed. Static data is written into the memory during write transactions and the
same data is always read back.
The stimulus to the Traffic Generator is provided through a
mig_v1_0_ddr4_stimulus.txt file. The stimulus consists of command, address, and
command repetition count. Each line in the stimulus file represents one stimulus (command
repetition, address, and command). Multiple stimuli can be provided in a stimulus file and
each stimulus is separated by the new line.
Table 7-1:

Modules for Performance Traffic Generator

File Name

Description

mig_v1_0_ddr4_traffic_generator.sv

This file has the Traffic Generator code for sending out the traffic
for DDR4 and also for the calculation of bus utilized.

mig_v1_0_ddr4_stimulus.txt

These files have the stimulus with Writes, Reads, and NOPs for
DDR4 for the calculation of bus utilization.

mig_v1_0_ddr3_traffic_generator.sv

This file has the Traffic Generator code for sending out the traffic
for DDR3 and also for the calculation of bus utilized.

mig_v1_0_ddr3_stimulus.txt

These files have the stimulus with Writes, Reads, and NOPs for
DDR3 for the calculation of bus utilization.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

194

Chapter 7: Test Bench

Stimulus Pattern
Each stimulus pattern is 48 bits and the format is described in Table 7-2 and Table 7-3.
Table 7-2:

Stimulus Command Pattern

Command Repeat[47:40]

Table 7-3:

Address [39:4]

Command[3:0]

Stimulus Pattern Description

Signal

Description

Command[3:0]

This corresponds to the WRITE/READ/NOP command that is sent to the

user interface.

Address[35:0]

This corresponds to the address to the user interface.

Command Repeat[7:0]

This corresponds to the repetition count of the command. Up to 128

repetitions can be made for a command. In the burst length of eight
mode, 128 transactions fill up the page in the memory.

Command Encoding (Command[3:0])

Table 7-4:

Command Description

Command

Code

Description

WRITE

This corresponds to the Write operation that needs to be performed.

READ

This corresponds to the Read operation that needs to be performed.

NOP

This corresponds to the idle situation for the bus.

Address Encoding (Address[35:0])

Address is encoded in the stimulus as per Figure 7-1 to Figure 7-6. All the address fields
need to be entered in the hexadecimal format. All the address fields are the width that is
divisible by four to enter in the hexadecimal format. The test bench only sends the required
bits of an address field to the Memory Controller.
For example, an eight bank configuration only bank Bits[2:0] is sent to the Memory
Controller and the remaining bits are ignored. The extra bits for an address field are
provided for you to enter the address in a hexadecimal format. You must confirm the value
entered corresponds to the width of a given configuration.
Table 7-5:
Rank[3:0]

Address Encoded
Bank[3:0]

Row[15:0]

Column[11:0]

Column Address (Column[11:0]) Column Address in the stimulus is provided

maximum of 12 bits, but you need to address this based on the column width
parameter set in your design.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

195

Chapter 7: Test Bench

Row Address (Row[15:0]) Row address in the stimulus is provided maximum of 16

bits, but you need to address this based on the row width parameter set in your design.

Bank Address (Bank[3:0]) Bank address in the stimulus is provided maximum of four
bits, but you need to address this based on the bank width parameter set in your
design.
Note: For DDR4, use the 2-bit LSB for Bank Address and two bits of MSB for Bank Groups.

Rank Address (Rank[3:0]) Rank address in the stimulus is provided maximum of four
bits, but you need to address this based on the rank width parameter set in your
design.

The address is assembled based on the top-level MEM_ADDR_ORDER parameter and sent to
the user interface.

Command Repeat (Command Repeat[7:0])

The command repetition count is the number of time the respective command is repeated
at the User Interface. The address for each repetition is incremented by 8. The maximum
repetition count is 128. The test bench does not check for the column boundary and it
wraps around if the maximum column limit is reached during the increments. The 128
commands fill up the page. For any column address other than 0, the repetition count of
128 ends up crossing the column boundary and wrapping around to the start of the column
address.

Bus Utilization
The bus utilization is calculated at the User Interface taking total number of Reads and
Writes into consideration and the following equation is used:
((rd_command_cnt + wr_command_cnt) (BURST_LEN / 2) 100)

Equation 7-1

bw_cumulative = -------------------------------------------------------------------------------((end_of_stimulus calib_done) / tCK);

BL8 takes four memory clock cycles.

end_of_stimulus is the time when all the commands are done.

calib_doneis the time when the calibration is done.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

196

Chapter 7: Test Bench

Example Patterns
These examples are based on the MEM_ADDR_ORDER set to BANK_ROW_COLUMN.

Single Read Pattern

00_0_2_000F_00A_1 This pattern is a single read from 10th column, 15th row, and second bank.
X-Ref Target - Figure 7-1

Figure 7-1:

Single Read Pattern

Single Write Pattern

00_0_1_0040_010_0 This pattern is a single write to the 32 nd column, 128 th row, and first bank.
X-Ref Target - Figure 7-2

Figure 7-2:

UltraScale Architecture FPGAs Memory IP v1.0

PG150 September 30, 2015

Single Write Pattern

www.xilinx.com

197

Chapter 7: Test Bench

Single Write and Read to Same Address

00_0_2_000F_00A_0 This pattern is a single write to 10th column, 15th row, and second bank.
00_0_2_000F_00A_1 This pattern is a single read from 10th column, 15th row, and second bank.
X-Ref Target - Figure 7-3

Figure 7-3:

Single Write and Read to Same Address

Multiple Writes and Reads with Same Address

0A_0_0_0010_000_0 This corresponds to 11 writes with address starting from 0 to 80 which can be seen in the column.
X-Ref Target - Figure 7-4

Figure 7-4:

UltraScale Architecture FPGAs Memory IP v1.0

PG150 September 30, 2015

Multiple Writes with Same Address

www.xilinx.com

198

Chapter 7: Test Bench

0A_0_0_0010_000_1 This corresponds to 11 reads with address starting from 0 to 80 which can be seen in the column.
X-Ref Target - Figure 7-5

Figure 7-5:

Multiple Reads with Same Address

Page Wrap During Writes

0A_0_2_000F_3F8_0 This corresponds to 11 writes with column address wrapped to the starting of the page after one write.
X-Ref Target - Figure 7-6

Figure 7-6:

UltraScale Architecture FPGAs Memory IP v1.0

PG150 September 30, 2015

Page Wrap During Writes

www.xilinx.com

199

Chapter 7: Test Bench

Simulating the Performance Traffic Generator

After opening the example_design project, follow the steps to run the performance
traffic generator.
1. In the Vivado Integrated Design Environment (IDE), open the Simulation Sources
section and double-click the sim_tb_top.sv file to open it in Edit mode. Or open the
file from the following location, <project_dir>/example_project/
<component_name>_example/<component_name>_example.srcs/sim_1/
imports/tb/sim_tb_top.sv.
2. Add a `define BEHV line in the file[sim_tb_to.sv] and save it.
3. Go to the Simulation Settings in the Vivado IDE.
a. Select Target Simulator as Mentor Graphics Questa Simulator (QuestaSim/
ModelSim). Browse to the compiled libraries location and set the path on the
Compiled Libraries Location option.
b. Under the Simulation tab, set the modelsim.simulate.runtime to 1 ms (there
are simulation RTL directives which stop the simulation after a certain period of time,
which is less than 1 ms). The Generate Scripts Only option generates simulation
scripts only. To run behavioral simulation, the Generate Scripts Only option must be
de-selected. For DDR3 simulation, set the
modelsim.simulate.vsim.more_options to +model_data+./.
c. Click Apply to save these settings.
4. Click Run Simulations.
5. Check the transcript for the results.
Note:
a. Simulations with Performance Traffic Generator are supported with QuestaSim only.
b. Vivado invokes QuestaSim and simulations are run in the QuestaSim tool. For more
information, see the Vivado Design Suite User Guide: Logic Simulation (UG900)
[Ref 11].

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

200

SECTION III: QDR II+ SRAM

Overview
Product Specification
Core Architecture
Designing with the Core
Design Flow Steps
Example Design
Test Bench

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

201

Chapter 8

Overview
The Xilinx UltraScale architecture includes the QDR II+ SRAM core. This core provides
solutions for interfacing with the QDR II+ SRAM memory type.
The QDR II+ SRAM core is a physical layer for interfacing Xilinx UltraScale FPGA user
designs to the QDR II+ SRAM devices. QDR II+ SRAMs offer high-speed data transfers on
separate read and write buses on the rising and falling edges of the clock. These memory
devices are used in high-performance systems as temporary data storage, such as:

Look-up tables in networking systems

Packet buffers in network switches

Cache memory in high-speed computing

Data buffers in high-performance testers

The QDR II+ SRAM solutions core is a PHY that takes simple user commands, converts them
to the QDR II+ protocol, and provides the converted commands to the memory. The design
enables you to provide one read and one write request per cycle eliminating the need for a
Memory Controller and the associated overhead, thereby reducing the latency through the
core.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

202

Chapter 8: Overview
Figure 8-1 shows a high-level block diagram of the QDR II+ SRAM interface solution.
X-Ref Target - Figure 8-1

&OLHQW,QWHUIDFH

3K\VLFDO
,QWHUIDFH

8OWUD6FDOH$UFKLWHFWXUH)3*$V

FON

TGUBNBS

V\VBUVW

TGUBNBQ

UVWBGN

TGUBZBQ

TGUBUBQ

TGUBVD
TGUBG

6$

4'5,,65$0

'

TGUBEZBQ

%:

DSSBZUBFPG

TGUBFTBS

&4

DSSBZUBDGGU

TGUBFTBQ

&4

DSSBZUBGDWD

TGUBT

DSSBZUBEZBQ
DSSBUGBFPG
DSSBUGBDGGU
DSSBUGBYDOLG
DSSBUGBGDWD
LQLWBFDOLEBFRPSOHWH

Figure 8-1:

High-Level Block Diagram of QDR II+ Interface Solution

The physical layer includes the hard blocks inside the FPGA and the soft calibration logic
necessary to ensure optimal timing of the hard blocks interfacing to the memory part.
These hard blocks include:

Data serialization and transmission

Data capture and deserialization

High-speed clock generation and synchronization

Coarse and fine delay elements per pin with voltage and temperature tracking

The soft blocks include:

Memory Initialization The calibration modules provide an initialization routine for

the particular memory type. The delays in the initialization process can be bypassed to
speed up simulation time if desired.
The QDR II+ memories do not require an elaborate initialization procedure. However,
you must ensure that the Doff_n signal is provided to the memory as required by the
vendor. The QDR II+ SRAM interface design provided by the memory wizard drives the

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

203

Chapter 8: Overview
Doff_n signal from the FPGA. After the internal MMCM has locked, the Doff_n signal
is asserted High for 100 s without issuing any commands to the memory device.
For memory devices that require the Doff_n signal to be terminated at the memory
and not be driven from the FPGA, you must perform the required initialization
procedure.

Calibration The calibration modules provide a complete method to set all delays in
the hard blocks and soft IP to work with the memory interface. Each bit is individually
trained and then combined to ensure optimal interface performance. Results of the
calibration process is available through the Xilinx debug tools. After completion of
calibration, the PHY layer presents raw interface to the memory part.

Feature Summary

Component support for interface widths up to 36 bits

x18 and x36 memory device support

4-word and 2-word burst support

Only HSTL_I I/O standard support

Cascaded data width support is available only for BL-4 designs

Data rates up to 1,266 Mb/s for BL-4 designs

Data rates up to 900 Mb/s for BL-2 designs

Memory device support with 72 Mb density

Support for 2.0 and 2.5 cycles of Read Latency

Source code delivery in Verilog

2:1 memory to FPGA logic interface clock ratio

Interface calibration and training information available through the Vivado hardware
manager

Licensing and Ordering Information

This Xilinx LogiCORE IP module is provided at no additional cost with the Xilinx Vivado
Design Suite under the terms of the Xilinx End User License. Information about this and
other Xilinx LogiCORE IP modules is available at the Xilinx Intellectual Property page. For
information about pricing and availability of other Xilinx LogiCORE IP modules and tools,
contact your local Xilinx sales representative.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

204

Chapter 8: Overview

License Checkers
If the IP requires a license key, the key must be verified. The Vivado design tools have
several license checkpoints for gating licensed IP through the flow. If the license check
succeeds, the IP can continue generation. Otherwise, generation halts with error. License
checkpoints are enforced by the following tools:

Vivado synthesis

Vivado implementation

write_bitstream (Tcl command)

IMPORTANT: IP license level is ignored at checkpoints. The test confirms a valid license exists. It does

not check IP license level.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

205

Chapter 9

Product Specification
Standards
This core complies with the QDR II+ SRAM standard defined by the QDR Consortium. For
more information on UltraScale architecture documents, see References, page 516.

Performance
Maximum Frequencies
For more information on the maximum frequencies, see Kintex UltraScale FPGAs Data Sheet,
DC and AC Switching Characteristics (DS892) [Ref 2].

Resource Utilization
Kintex UltraScale Devices
Table 9-1 provides approximate resource counts on Kintex UltraScale devices.
Table 9-1:

Device Utilization Kintex UltraScale FPGAs

Parameter
Values

Device Resources
Memory LUTs RAMB36E2/
RAMB18E2

Interface Width

FFs

LUTs

BUFGs

PLLE3_ADV MMCME3_ADV

36

6,741

4,456

106

16

18

4,271

3,083

106

16

Resources required for the UltraScale architecture FPGAs QDR II+ SRAM core have been
estimated for the Kintex UltraScale devices. These values were generated using Vivado IP
catalog. They are derived from post-synthesis reports, and might change during
implementation.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

206

Chapter 9: Product Specification

Port Descriptions
There are three port categories at the top-level of the memory interface core called the
user design.

The first category is the memory interface signals that directly interfaces with the
memory part. These are defined by the QDR II+ SRAM specification.

The second category is the application interface signals which is referred to as the
user interface. This is described in the Protocol Description, page 224.

The third category includes other signals necessary for proper operation of the core.
These include the clocks, reset, and status signals from the core. The clocking and reset
signals are described in their respective sections.
The active-High init_calib_complete signal indicates that the initialization and
calibration are complete and that the interface is now ready to accept commands for the
interface.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

207

Chapter 10

Core Architecture
This chapter describes the UltraScale device FPGAs Memory Interface Solutions core with
an overview of the modules and interfaces.

Overview
The UltraScale architecture FPGAs Memory Interface Solutions is shown in Figure 10-1.
X-Ref Target - Figure 10-1

8OWUD6FDOH$UFKLWHFWXUH)3*$V
8OWUD6FDOH$UFKLWHFWXUH)3*$V0HPRU\,QWHUIDFH6ROXWLRQ

4'5,,
65$0
0HPRU\


8VHU)3*$
/RJLF

8VHU
LQWHUIDFH

3K\VLFDO
/D\HU

,QLWLDOL]DWLRQ
&DOLEUDWLRQ
&DO'RQH

5HDG'DWD

Figure 10-1:

UltraScale Architecture FPGAs Memory Interface Solution Core

The user interface uses a simple protocol based entirely on SDR signals to make read and
write requests. For more details describing this protocol, see User Interface in Chapter 11.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

208

Chapter 10: Core Architecture

There is no requirement for the controller in QDR II+ SRAM protocol and thus, the Memory
Controller contains only the physical interface. It takes commands from the user interface
and adheres to the protocol requirements of the QDR II+ SRAM device. It is responsible to
generate proper timing relationships and DDR signaling to communicate with the external
memory device. For more details, see Memory Interface in Chapter 11.

PHY
PHY is considered the low-level physical interface to an external QDR II+ SRAM device. It
contains the entire calibration logic for ensuring reliable operation of the physical interface
itself. PHY generates the signal timing and sequencing required to interface to the memory
device.
PHY contains the following features:

Clock/address/control-generation logics

Write and read datapaths

Logic for initializing the SDRAM after power-up

In addition, PHY contains calibration logic to perform timing training of the read and write
datapaths to account for system static and dynamic delays.

Overall PHY Architecture

The UltraScale architecture PHY is composed of dedicated blocks and soft calibration logic.
The dedicated blocks are structured adjacent to one another with back-to-back
interconnects to minimize the clock and datapath routing necessary to build high
performance physical layers.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

209

Chapter 10: Core Architecture

The user interface and calibration logic communicate with this dedicated PHY in the slow
frequency clock domain, which is divided by 2. A more detailed block diagram of the PHY
design is shown in Figure 10-2.
X-Ref Target - Figure 10-2

8OWUD6FDOH$UFKLWHFWXUH)3*$V0HPRU\,QWHUIDFH6ROXWLRQ
SOOFONV
SOOVY

UHIFON

$GGUHVV&RQWURO:ULWH'DWDDQG0DVN
&0':ULWH'DWD
SOO*DWH
TGULLSBSK\VY


TGULLSBFDOVY

8VHU
,QWHUIDFH

TGULLSBFDOBDGGUB
GHFRGHVY
0LFUR%OD]H
3URFHVVRU

TGULLSB
[LSK\VY

TGULLSB
,REVY

&DO'RQH

FRQILJBURPVY

5HDG'DWD
5HDG'DWD

6WDWXV
&DO'RQH

Figure 10-2:
Table 10-1:

PHY Block Diagram

PHY Modules

Module Name

Description

qdriip_phy.sv

PHY top of QDR II+ design

qdriip_phycal.sv

Contains the instances of XIPHY top and calibration top modules

qdriip_cal.sv

Calibration top module

qdriip_cal_addr_decode.sv

FPGA logic interface for the MicroBlaze processor

config_rom.sv

Configuration storage for calibration options

debug_microblaze.sv

MicroBlaze processor

qdriip_xiphy.sv

Contains the XIPHY instance

qdriip_iob.sv

Instantiates all byte IOB modules

qdriip_iob_byte.sv

Generates the I/O buffers for all the signals in a given byte lane

qdriip_rd_bit_slip.sv

Read bit slip

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

210

Chapter 10: Core Architecture

The PHY architecture encompasses all of the logic contained in qdriip_xiphy.sv. The
PHY contains wrappers around dedicated hard blocks to build up the memory interface
from smaller components. A byte lane contains all of the clocks, resets, and datapaths for a
given subset of I/O. Multiple byte lanes are grouped together, along with dedicated
clocking resources, to make up a single bank memory interface. For more information on
the hard silicon physical layer architecture, see the UltraScale Architecture FPGAs
SelectIO Resources User Guide (UG571) [Ref 3].
The memory initialization and calibration are implemented in C programming on a small
soft core processor. The MicroBlaze Controller System (MCS) is configured with an I/O
Module and block RAM. The module qdriip_cal_adr_decode.sv module provides the
interface for the processor to the rest of the system and implements helper logic. The
config_rom.sv module stores settings that control the operation of initialization and
calibration, providing run time options that can be adjusted without having to recompile
the source code.
The address unit connects the MCS to the local register set and the PHY by performing
address decode and control translation on the I/O module bus from spaces in the memory
map and MUXing return data (qdriip_cal_adr_decode.sv). In addition, it provides
address translation (also known as mapping) from a logical conceptualization of the
DRAM interface to the appropriate pinout-dependent location of the delay control in the
PHY address space.
Although the calibration architecture presents a simple and organized address map for
manipulating the delay elements for individual data, control and command bits, there is
flexibility in how those I/O pins are placed. For a given I/O placement, the path to the FPGA
logic is locked to a given pin. To enable a single binary software file to work with any
memory interface pinout, a translation block converts the simplified Register Interface Unit
(RIU) addressing into the pinout-specific RIU address for the target design. The specific
address translation is written by QDR II+ SRAM after a pinout is selected. The code shows
an example of the RTL structure that supports this.
Casez(io_address)// MicroBlaze I/O module address
// static address decoding skipped
//========================================//
//===========DQ ODELAYS===================//
//========================================//
//Byte0
28h0004100: begin //dq2
riu_addr_cal = /* QDR II+ SRAM Generated */ 6hd;
riu_nibble =
/* QDR II+ SRAM Generated */ h0;
end
// additional dynamic addressing follows

In this example, DQ0 is pinned out on Bit[0] of nibble 0 (nibble 0 according to instantiation
order). The RIU address for the ODELAY for Bit[0] is 0x0D. When DQ0 is addressed
indicated by address 0x000_4100), this snippet of code is active. It enables nibble 0
(decoded to one-hot downstream) and forwards the address 0x0D to the RIU address bus.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

211

Chapter 10: Core Architecture

The MicroBlaze I/O interface operates at much slower frequency, which is not fast enough
for implementing all the functions required in calibration. A helper circuit implemented in
qdriip_cal_adr_decode.sv is required to obtain commands from the registers and
translate at least a portion into single-cycle accuracy for submission to the PHY. In addition,
it supports command repetition to enable back-to-back read transactions and read data
comparison.

Memory Initialization and Calibration Sequence

After deassertion of the system reset, PHY performs some required internal calibration
steps first.
1. The built-in self-check (BISC) of the PHY is run. It is used to compensate the internal
skews among the data bits and the strobe on the read path.
2. After BISC completion, the required steps for the power-on initialization of the memory
part starts.
3. It requires several stages of calibration for tuning the write and read datapath skews as
mentioned in Figure 10-3.
4. After calibration is completed, PHY calculates internal offsets for the voltage and
temperature tracking purpose by considering the taps used until the end of step 3.
5. When PHY indicates the calibration completion, the user interface command execution
begins.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

212

Chapter 10: Core Architecture

Figure 10-3 shows the overall flow of memory initialization and the different stages of
calibration.
X-Ref Target - Figure 10-3

&DOLEUDWLRQ6WDUW

%,6&&DOLEUDWLRQ

4'5,,,QLWLDOL]DWLRQ

5HDG&ORFN*DWH&DOLEUDWLRQ

,QLWLDO5HDG'DWD'HVNHZ

$GGUHVV&DOLEUDWLRQIRU%/'HVLJQV

..&HQWHULQJDQG%LWVOLSIRU:ULWH'DWD%LWV

..&HQWHULQJDQG%LWVOLSIRU%\WH:ULWH%LWV

5HDG%LWVOLS&DOLEUDWLRQ

&RPSOH[5HDG&DOLEUDWLRQ

5HDG9DOLG&DOLEUDWLRQ

&DOLEUDWLRQ&RPSOHWH

Figure 10-3:

PHY Overall Initialization and Calibration Sequence

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

213

Chapter 11

Designing with the Core

This chapter includes guidelines and additional information to facilitate designing with the
core.

Clocking
The memory interface requires one MMCM, one TXPLL per I/O bank used by the memory
interface, and two BUFGs. These clocking components are used to create the proper clock
frequencies and phase shifts necessary for the proper operation of the memory interface.
There are two TXPLLs per bank. If a bank is shared by two memory interfaces, both TXPLLs
in that bank are used.
Note: QDR II+ SRAM generates the appropriate clocking structure and no modifications to the RTL
are supported.

The QDR II+ SRAM tool generates the appropriate clocking structure for the desired
interface. This structure must not be modified. The allowed clock configuration is as
follows:

Differential reference clock source connected to GCIO

GCIO to MMCM (located in center bank of memory interface)

MMCM to BUFG (located at center bank of memory interface) driving FPGA logic and
all TXPLLs

MMCM to BUFG (located at center bank of memory interface) divide by two mode
driving 1/2 rate FPGA logic

Clocking pair of the interface must be in the same SLR of memory interface for the SSI
technology devices

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

214

Chapter 11: Designing with the Core

Requirements
GCIO

Must use a differential I/O standard

Must be in the same I/O column as the memory interface

Must be in the same SLR of memory interface for the SSI technology devices

MMCM

MMCM is used to generate the FPGA logic system clock (1/2 of the memory clock)

Must be located in the center bank of memory interface

Must use internal feedback

Input clock frequency divided by input divider must be 70 MHz (CLKINx / D

70 MHz)

Must use integer multiply and output divide values

BUFGs and Clock Roots

One BUFG is used to generate the system clock to FPGA logic and another BUFG is used
to divide the system clock by two.

BUFGs and clock roots must be located in center most bank of the memory interface.

For two bank systems, banks with more number of bytes selected is chosen as the
center bank. If the same number of bytes is selected in two banks, then the top
bank is chosen as the center bank.

For four bank systems, either of the center banks can be chosen. QDR II+ SRAM
refers to the second bank from the top-most selected bank as the center bank.

Both the BUFGs must be in the same bank.

TXPLL

CLKOUTPHY from TXPLL drives XIPHY within its bank

TXPLL must be set to use a CLKFBOUT phase shift of 90

TXPLL must be held in reset until the MMCM lock output goes High

Must use internal feedback

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

215

Chapter 11: Designing with the Core

Figure 11-1 shows an example of the clocking structure for a three bank memory interface.
The GCIO drives the MMCM located at the center bank of the memory interface. MMCM
drives both the BUFGs located in the same bank. The BUFG (which is used to generate
system clock to FPGA logic) output drives the TXPLLs used in each bank of the interface.
X-Ref Target - Figure 11-1

7;3//

,2%DQN

6\VWHP&ORFNWR)3*$/RJLF

0HPRU\,QWHUIDFH

%8)*
7;3//
00&0

,2%DQN

&/.287
&/.287
%8)*

6\VWHP&ORFN'LYLGHG
E\WR)3*$/RJLF

7;3//

,2%DQN

'LIIHUHQWLDO
*&,2,QSXW

%8)*
,2%DQN

Figure 11-1:

Clocking Structure for Three Bank Memory Interface

The MMCM is placed in the center bank of the memory interface.

For two bank systems, MMCM is placed in a bank with the most number of bytes
selected. If they both have the same number of bytes selected in two banks, then
MMCM is placed in the top bank.

For four bank systems, MMCM is placed in a second bank from the top.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

216

Chapter 11: Designing with the Core

For designs generated with System Clock configuration of No Buffer, MMCM must not be
driven by another MMCM/PLL. Cascading clocking structures MMCM BUFG MMCM
and PLL BUFG MMCM are not allowed.
If the MMCM is driven by the GCIO pin of the other bank, then the
CLOCK_DEDICATED_ROUTE constraint with value "BACKBONE" must be set on the net that
is driving MMCM or on the MMCM input. Setting up the CLOCK_DEDICATED_ROUTE
constraint on the net is preferred. But when the same net is driving two MMCMs, the
CLOCK_DEDICATED_ROUTE constraint must be managed by considering which MMCM
needs the BACKBONE route.
In such cases, the CLOCK_DEDICATED_ROUTE constraint can be set on the MMCM input. To
use the "BACKBONE" route, any clock buffer that exists in the same CMT tile as the GCIO
must exist between the GCIO and MMCM input. The clock buffers that exists in the I/O CMT
are BUFG, BUFGCE, BUFGCTRL, and BUFGCE_DIV. So QDR II+ SRAM instantiates BUFG
between the GCIO and MMCM when the GCIO pins and MMCM are not in the same bank
(see Figure 11-1).
If the GCIO pin and MMCM are allocated in different banks, QDR II+ SRAM generates
CLOCK_DEDICATED_ROUTE constraints with value as "BACKBONE." If the GCIO pin and
MMCM are allocated in the same bank, there is no need to set any constraints on the
MMCM input.
Similarly when designs are generated with System Clock Configuration as a No Buffer
option, you must take care of the "BACKBONE" constraint and the BUFG/BUFGCE/
BUFGCTRL/BUFGCE_DIV between GCIO and MMCM if GCIO pin and MMCM are allocated in
different banks. QDR II+ SRAM does not generate clock constraints in the XDC file for No
Buffer configurations and you must take care of the clock constraints for No Buffer
configurations. For more information on clocking, see the UltraScale Architecture Clocking
Resources User Guide (UG572) [Ref 4].
XDC syntax for CLOCK_DEDICATED_ROUTE constraint is given here:
set_property CLOCK_DEDICATED_ROUTE BACKBONE [get_nets net_name]

For more information on the CLOCK_DEDICATED_ROUTE constraints, see the Vivado Design
Suite Properties Reference Guide (UG912) [Ref 5].
Note: If two different GCIO pins are used for two QDR II+ SRAM IP cores in the same bank, center
bank of the memory interface is different for each IP. QDR II+ SRAM generates MMCM LOC and
CLOCK_DEDICATED_ROUTE constraints accordingly.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

217

Chapter 11: Designing with the Core

Sharing of Input Clock Source (sys_clk_p)

If the same GCIO pin must be used for two IP cores, generate the two IP cores with the same
frequency value selected for option Reference Input Clock Period (ps) and System Clock
Configuration option as No Buffer. Perform the following changes in the wrapper file in
which both IPs are instantiated:
1. QDR II+ SRAM generates a single-ended input for system clock pins, such as
sys_clk_i. Connect the differential buffer output to the single-ended system clock
inputs (sys_clk_i) of both the IP cores.
2. System clock pins must be allocated within the same I/O column of the memory
interface pins allocated. Add the pin LOC constraints for system clock pins and clock
constraints in your top-level XDC.
3. You must add a "BACKBONE" constraint on the net that is driving the MMCM or on the
MMCM input if GCIO pin and MMCM are not allocated in the same bank. Apart from
this, BUFG/BUFGCE/BUFGCTRL/BUFGCE_DIV must be instantiated between GCIO and
MMCM to use the "BACKBONE" route.
Note:

The Ultrascale architecture includes an independent XIPHY power supply and TXPLL
for each XIPHY. This results in clean, low jitter clocks for the memory system.

Skew spanning across multiple BUFGs is not a concern because single point of
contact exists between BUFG TXPLL and the same BUFG System Clock Logic.

System input clock cannot span I/O columns because the longer the clock lines
span, the more jitter is picked up.

TXPLL Usage
There are two TXPLLs per bank. If a bank is shared by two memory interfaces, both TXPLLs
in that bank are used. One PLL per bank is used if a bank is used by a single memory
interface. You can use a second PLL for other usage. To use a second PLL, you can perform
the following steps:
1. Generate the design for the System Clock Configuration option as No Buffer.
2. QDR II+ SRAM generates a single-ended input for system clock pins, such as
sys_clk_i. Connect the differential buffer output to the single-ended system clock
inputs (sys_clk_i) and also to the input of PLL (PLL instance that you have in your
design).
3. You can use the PLL output clocks.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

218

Chapter 11: Designing with the Core

Additional Clocks
You can produce up to four additional clocks which are created from the same MMCM that
generates ui_clk. Additional clocks can be selected from the Clock Options section in the
Advanced tab. The GUI lists the possible clock frequencies from MMCM and the
frequencies for additional clocks vary based on selected memory frequency (Memory
Device Interface Speed (ps) value in the Basic tab), selected FPGA, and FPGA speed grade.

Resets
An asynchronous reset (sys_rst) input is provided. This is an active-High reset and the
sys_rst must assert for a minimum pulse width of 5 ns. The sys_rst can be an internal
or external pin.

PCB Guidelines for QDR II+ SRAM

Strict adherence to all documented QDR II+ SRAM PCB guidelines is required for successful
operation. For more information on PCB guidelines, see the UltraScale Architecture PCB
Design and Pin Planning User Guide (UG583) [Ref 6].

Pin and Bank Rules

QDR II+ Pin Rules
This section describes the pin out rules for QDR II+ SRAM interface.

Both HR and HP Banks are supported.

All signal groups that are write data, read data, address/control, and system clock
interfaces must be selected in a single column.

All banks used must be adjacent. No skip banks allowed.

1. Write Data (D) and Byte Write (BW) Pins Allocation:

a. The entire write data bus must be placed in a single bank regardless of the number
of memory components.
b. Only one write data byte is allowed per byte lane.
c. All byte lanes that are used for the write data of a single component must be
adjacent, no skip byte lanes are allowed.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

219

Chapter 11: Designing with the Core

d. One of the write data bytes of a memory component should be allocated in the
center byte lanes (byte lanes 1 and 2).
e. Each byte write pin (BW) must be allocated in the corresponding write data byte
lane.
2. Memory Clock (K/K#) Allocation:
a. Memory Clock pair must be allocated in one of the byte lanes that are used for the
write data of the corresponding memory component.
b. Memory clock should come from one of the center byte lanes (byte lanes 1 and 2).
c. K/K# can be allocated to any PN pair.
3. Read Data (Q) Allocation:
a. The entire read data bus must be placed in a single bank irrespective of the number
of memory components.
b. All byte lanes that are used for the read data of a single component must be
adjacent, no skip byte lanes are allowed.
c. One of the read data bytes of a memory component should be allocated in the
center byte lanes (byte lanes 1 and 2).
d. If a byte lane is used for read data, Bit[0] and Bit[6] must be used. Read clock (CQ or
CQ#) gets the first priority and data (Q) is the next.
e. Read data buses of two components should not share a byte lane.
4. Read Clock (CQ/CQ#) Allocation:
a. Read Clock pair must be allocated in one of the byte lanes that are used for the read
data of the corresponding memory component.
b. CQ/CQ# pair must be allocated in a single byte lane.
c. CQ/CQ# must be allocated only in the center byte lanes (byte lanes 1 and 2) because
other byte lanes cannot forward the clock out for read data capture.
d. CQ and CQ# must be allocated to either pin 0 or pin 6 of a byte lane. For example, if
CQ is allocated to pin 0, CQ# should be allocated to pin 6 and vice versa.
5. For x36 and x18 component designs:
a. All Read Data pins of a single component must not span more than three
consecutive byte lanes and CQ/CQ# must always be allocated in center byte lane.
6. Address/Control (A/C) Pins Allocation:
a. All address/control (A/C) bits must be allocated in a single bank.
b. All A/C byte lanes should be contiguous and no skip byte lanes is allowed.
c. The address/control bank should be the same or adjacent to that of the write data
bank.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

220

Chapter 11: Designing with the Core

d. There should not be any empty byte lane or read byte lane between A/C and write
data byte lanes. This rule applies when A/C and write data share the same bank or
allocated in adjacent banks.
e. Address/control pins should not share a byte lane with the write data as well as read
data.
f.

System clock pins (sys_clk_p/sys_clk_n) must be placed on any GCIO pin pair in
the same column as that of the memory interface. For more information, see
Clocking, page 214.

7. All I/O banks used by the memory interface must be in the same SLR of the column for
the SSI technology devices.
8. One vrp pin per bank is used and a DCI is required for the interfaces. A vrp pin is
required in I/O banks containing inputs as well as output only banks. It is required in
output only banks because address/control signals use HSTL_I_DCI to enable usage of
controlled output impedance. A DCI cascade is not permitted. All rules for the DCI in the
UltraScale Device FPGAs SelectIO Resources User Guide (UG571) [Ref 3] must be
followed.
9. There are dedicated V REF pins (not included in the rules above). Either internal or
external VREF is permitted. If an external VREF is not used, the V REF pins must be pulled
to ground by a resistor value specified in the UltraScale Device FPGAs SelectIO
Resources User Guide (UG571) [Ref 3]. These pins must be connected appropriately for
the standard in use.

QDR II+ Pinout Examples

IMPORTANT: Due to the calibration stage, there is no need for set_input_delay/

set_output_delay on the QDR II+ SRAM. Ignore the unconstrained inputs and outputs for QDR II+
SRAM and the signals which are calibrated.

Table 11-1 shows an example of an 18-bit QDR II+ SRAM interface contained within two
banks.
Table 11-1:
Bank

18-Bit QDR II+ Interface Contained in Two Banks

Signal Name

Byte Group

I/O Type

T1U_12

sys_clk_p

T1U_11

sys_clk_n

T1U_10

T1U_9

q17

T1U_8

q16

T1U_7

cq_p

T1U_6

q15

T1L_5

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

221

Chapter 11: Designing with the Core

Table 11-1:
Bank

18-Bit QDR II+ Interface Contained in Two Banks (Contd)

Signal Name

Byte Group

I/O Type

q14

T1L_4

q13

T1L_3

q12

T1L_2

q11

T1L_1

cq_n

T1L_0

vrp

T0U_12

T0U_11

q10

T0U_10

q9

T0U_9

q8

T0U_8

q7

T0U_7

q6

T0U_6

q5

T0L_5

q4

T0L_4

q3

T0L_3

q2

T0L_2

q1

T0L_1

q0

T0L_0

T3U_12

T3U_11

T3U_10

d17

T3U_9

d16

T3U_8

d15

T3U_7

d14

T3U_6

d13

T3L_5

d12

T3L_4

d11

T3L_3

d10

T3L_2

bwsn1

T3L_1

d9

T3L_0

T2U_12

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

222

Chapter 11: Designing with the Core

Table 11-1:
Bank

18-Bit QDR II+ Interface Contained in Two Banks (Contd)

Signal Name

Byte Group

I/O Type

d8

T2U_11

d7

T2U_10

d6

T2U_9

d5

T2U_8

k_n

T2U_7

k_p

T2U_6

d4

T2L_5

d3

T2L_4

d2

T2L_3

d1

T2L_2

bwsn0

T2L_1

d0

T2L_0

doff

T1U_12

a21

T1U_11

a20

T1U_10

a19

T1U_9

a18

T1U_8

a17

T1U_7

a16

T1U_6

a15

T1L_5

a14

T1L_4

a13

T1L_3

a12

T1L_2

rpsn

T1L_1

a11

T1L_0

vrp

T0U_12

a10

T0U_11

a9

T0U_10

a8

T0U_9

a7

T0U_8

a6

T0U_7

a5

T0U_6

a4

T0L_5

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

223

Chapter 11: Designing with the Core

Table 11-1:
Bank

18-Bit QDR II+ Interface Contained in Two Banks (Contd)

Signal Name

Byte Group

I/O Type

a3

T0L_4

a2

T0L_3

a1

T0L_2

wpsn

T0L_1

a0

T0L_0

Protocol Description
This core has the following interfaces:

User Interface

Memory Interface

User Interface
The user interface connects an FPGA user design to the QDR II+ SRAM solutions core to
simplify interactions between you and the external memory device. The user interface
provides a set of signals used to issue a read or write command to the memory device.
These signals are summarized in Table 11-2.
Table 11-2:

User Interface Signals

Signal

Direction Description

app_rd_addr0[ADDR_WIDTH 1:0]

Input

Read Address. This bus provides the address to use

for a read request. It is valid when app_rd_cmd0 is
asserted.

app_rd_cmd0

Input

Read Command. This signal is used to issue a read

request and indicates that the address on port0 is
valid.

app_rd_data0[DBITS BURST_LEN 1:0]

Output

Read Data. This bus carries the data read back from
the read command issued on app_rd_cmd0

app_rd_valid0

Output

Read Valid. This signal indicates that data read back

from memory is now available on app_rd_data0 and
should be sampled.

app_wr_addr0[ADDR_WIDTH 1:0]

Input

Write Address. This bus provides the address for a

write request. It is valid when app_wr_cmd0 is
asserted.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

224

Chapter 11: Designing with the Core

Table 11-2:

User Interface Signals (Contd)

Signal

Direction Description

app_wr_bw_n0[(DBITS/9) BURST_LEN 1:0]

Input

Byte Writes. This bus provides the byte writes for a

write request and indicates which bytes need to be
written into the SRAM. It is valid when app_wr_cmd0
is asserted and is active-Low.

app_wr_cmd0

Input

Write Command. This signal is used to issue a write

request and indicates that the corresponding
sideband signals on write port0 are valid.

app_wr_data0[DBITS BURST_LEN 1:0]

Input

Write Data. This bus provides the data to use for a

write request. It is valid when app_wr_cmd0 is
asserted.

app_rd_addr1[ADDR_WIDTH 1:0] (1)

Input

Read Address. This bus provides the address to use

for a read request. It is valid when app_rd_cmd1 is
asserted.

app_rd_cmd1 (1)

Input

Read Command. This signal is used to issue a read

request and indicates that the address on port1 is
valid.

app_rd_data1[DBITS BURST_LEN 1:0] (1)

Output

Read Data. This bus carries the data read back from
the read command issued on app_rd_cmd1.

app_rd_valid1 (1)

Output

Read Valid. This signal indicates that data read back

from memory is now available on app_rd_data1 and
should be sampled.

app_wr_addr1[ADDR_WIDTH 1:0](1)

Input

Write Address. This bus provides the address for a

write request. It is valid when app_wr_cmd1 is
asserted.

Input

Byte Writes. This bus provides the byte writes for a

write request and indicates which bytes need to be
written into the SRAM. It is valid when app_wr_cmd1
is asserted and is active-Low.

app_wr_cmd1 (1)

Input

Write Command. This signal is used to issue a write

request and indicates that the corresponding
sideband signals on write port1 are valid.

app_wr_data1[DBITS BURST_LEN 1:0] (1)

Input

Write Data. This bus provides the data to use for a

write request. It is valid when app_wr_cmd1 is
asserted.

clk

Output

User Interface clock.

rst_clk

Output

Reset signal synchronized by the User Interface

clock.

Init_calib_complete

Output

Calibration Done. This signal indicates to the user

design that read calibration is complete and the
user can now initiate read and write requests from
the client interface.

sys_rst

Input

Asynchronous system reset input.

sys_clk_p/n

Input

System clock to the Memory Controller.

app_wr_bw_n1[(DBITS/9) BURST_LEN 1:0]

(1)

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

225

Chapter 11: Designing with the Core

Table 11-2:

User Interface Signals (Contd)

Signal

Direction Description

dbg_clk

Output

Debug Clock. Do not connect any signals to dbg_clk

and keep the port open during instantiation.

dbg_bus

Output

Reserved. Do not connect any signals to dbg_bus

and keep the port open during instantiation.

Notes:
1. These ports are available and valid only in BL2 configuration. For BL4 configuration, these ports are not available or if
available, no need to be driven.

Interfacing with the Core through the User Interface

Figure 11-2 shows the user interface protocol.
X-Ref Target - Figure 11-2

FON
LQLWBFDOLEBFRPSOHWH
DSSBZUBFPG
DSSBZUBDGGU

:5B$''5

:5B$''5

DSSBZUBGDWD

:5B'$7$

:5B'$7$

DSSBZUBEZBQ

:5B%:B1

:5B%:B1

DSSBUGBFPG
DSSBUGBDGGU

5'B$''5

5'B$''5

DSSBUGBYDOLG
DSSBUGBGDWD

5'B'$7$

Figure 11-2:

User Interface Write/Read Timing Diagram

Before any requests can be made, the init_calib_complete signal must be asserted
High, as shown in Figure 11-2, no read or write requests can take place, and the assertion of
app_wr_cmd0 or app_rd_cmd0 on the client interface is ignored. A write request is issued
by asserting app_wr_cmd0 as a single cycle pulse. At this time, the app_wr_addr0,
app_wr_data0, and app_wr_bw_n0 signals must be valid.
On the following cycle, a read request is issued by asserting app_rd_cmd0 for a single
cycle pulse. At this time, app_rd_addr0 must be valid. After one cycle of idle time, a read
and write request are both asserted on the same clock cycle. In this case, the read to the
memory occurs first, followed by the write. The write and read commands can be applied in
any order at the user interface, two examples are shown in the Figure 11-2.
Also, Figure 11-2 shows data returning from the memory device to the user design. The
app_rd_valid0 signal is asserted, indicating that app_rd_data0 is now valid. This
should be sampled on the same cycle when app_rd_valid0 is asserted because the core
does not buffer returning data.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

226

Chapter 11: Designing with the Core

In case of BL2, the same protocol should be followed on two independent ports: port-0 and
port-1. Figure 11-2 shows the user interface signals on port-0 only.

Memory Interface
Memory interface is a connection from the FPGA memory solution to an external QDR II+
SRAM device. The I/O signals for this interface are defined in Table 11-3. These signals can
be directly connected to the corresponding signals on the memory device.
Table 11-3:

Memory Interface Signals

Signal

Direction

Description

qdriip_cq_n

Input

QDR CQ#. This is the echo clock returned from the memory derived from
qdr_k_n.

qdriip_cq_p

Input

QDR CQ. This is the echo clock returned from the memory derived from qdr_k_p.

qdriip_d

Output

QDR Data. This is the write data from the PHY to the QDR II+ memory device.

qdriip_dll_off_n

Output

QDR DLL Off. This signal turns off the DLL in the memory device.

qdriip_bw_n

Output

QDR Byte Write. This is the byte write signal from the PHY to the QDR II+ SRAM
device.

qdriip_k_n

Output

QDR Clock K#. This is the inverted input clock to the memory device.

qdriip_k_p

Output

QDR Clock K. This is the input clock to the memory device.

qdriip_q

Input

QDR Data Q. This is the data returned from reads to memory.

qdriip_qvld

Input

QDR Q Valid. This signal indicates that the data on qdriip_q is valid. It is only
present in QDR II+ SRAM devices.

qdriip_sa

Output

QDR Address. This is the address supplied for memory operations.

qdriip_w_n

Output

QDR Write. This is the write command to memory.

qdriip_r_n

Output

QDR Read. This is the read command to memory.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

227

Chapter 11: Designing with the Core

Figure 11-3 shows the timing diagram for the sample write and read operations at the
memory interface of a BL4 QDR II+ SRAM device and Figure 11-4 is that of a BL2 device.
X-Ref Target - Figure 11-3

TGULLSBNBS
TGULLSBNBQ
TGULLSBZBQ
TGULLSBUBQ
TGULLSBVD

:5

5'

TGULLSBG

'

'

'

'

TGULLSBEZBQ

%:

%:

%:

%:

4

4

4

TGULLSBFTBS
TGULLSBFTBQ
TGULLSBT

Figure 11-3:

4

Interfacing with a Four-Word Burst Length Memory Device

X-Ref Target - Figure 11-4

TGULLSBNBS
TGULLSBNBQ
TGULLSBZBQ
TGULLSBUBQ
TGULLSBVD

5'

:5

5'

:5

TGULLSBG

'

'

'

'

TGULLSBEZBQ

%: %:

%: %:

TGULLSBFTBS
TGULLSBFTBQ
TGULLSBT

Figure 11-4:

4

4

4

4

Interfacing with a Two-Word Burst Length Memory Device

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

228

Chapter 12

Design Flow Steps

This chapter describes customizing and generating the core, constraining the core, and the
simulation, synthesis and implementation steps that are specific to this IP core. More
detailed information about the standard Vivado design flows and the Vivado IP integrator
can be found in the following Vivado Design Suite user guides:

Vivado Design Suite User Guide: Designing IP Subsystems using IP Integrator (UG994)
[Ref 8]

Vivado Design Suite User Guide: Designing with IP (UG896) [Ref 9]

Vivado Design Suite User Guide: Getting Started (UG910) [Ref 10]

Vivado Design Suite User Guide: Logic Simulation (UG900) [Ref 11]

Customizing and Generating the Core

CAUTION! The Windows operating system has a 260-character limit for path lengths, which can affect
the Vivado tools. To avoid this issue, use the shortest possible names and directory locations when
creating projects, defining IP or managed IP projects, and creating block designs.

This section includes information about using Xilinx tools to customize and generate the
core in the Vivado Design Suite.
If you are customizing and generating the core in the IP integrator, see the Vivado Design
Suite User Guide: Designing IP Subsystems using IP Integrator (UG994) [Ref 8] for detailed
information. IP integrator might auto-compute certain configuration values when
validating or generating the design. To check whether the values change, see the
description of the parameter in this chapter. To view the parameter value, run the
validate_bd_design command in the Tcl Console.
You can customize the IP for use in your design by specifying values for the various
parameters associated with the IP core using the following steps:
1. Select the IP from the Vivado IP catalog.
2. Double-click the selected IP or select the Customize IP command from the toolbar or
right-click menu.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

229

Chapter 12: Design Flow Steps

For more information about generating the core in Vivado, see the Vivado Design Suite User
Guide: Designing with IP (UG896) [Ref 9] and the Vivado Design Suite User Guide: Getting
Started (UG910) [Ref 10].
Note: Figures in this chapter are illustrations of the Vivado Integrated Design Environment (IDE).
This layout might vary from the current version.

Basic Tab
Figure 12-1 shows the Basic tab when you start up the QDR II+ SRAM.
X-Ref Target - Figure 12-1

Figure 12-1:

Vivado Customize IP Dialog Box Basic Tab

IMPORTANT: All parameters shown in the controller options dialog box are limited selection options in

this release.

For the Vivado IDE, all controllers (DDR3, DDR4, QDR II+, and RLDRAM 3) can be created
and available for instantiation.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

230

Chapter 12: Design Flow Steps

1. Select the settings in the Clocking and Controller Options.
In Clocking, the Memory Device Interface Speed sets the speed of the interface. The
speed entered drives the available Reference Input Clock Speeds. For more
information on the clocking structure, see the Clocking, page 214.
2. To use memory parts which are not available by default through the QDR II+ SRAM
Vivado IDE, you can create a custom parts CSV file, as specified in the AR: 63462. This
CSV file has to be provided after enabling the Custom Parts Data File option. After
selecting this option. you are able to see the custom memory parts along with the
default memory parts. Note that, simulations are not supported for the custom part.
IMPORTANT: Data Mask (DM) option is always selected for AXI designs and is grayed out (you cannot
select it). For AXI interfaces, Read Modify Write (RMW) is supported and for RMW to mask certain bytes
of Data Mask bits should be present. Therefore, the DM is always enabled for AXI interface designs. This
is the case for all data widths except 72-bit.
For 72-bit interfaces, ECC is enabled and DM is deselected and grayed out for 72-bit designs. If DM is
enabled for 72-bit designs, computing ECC does is not compatible, so DM is disabled for 72-bit designs.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

231

Chapter 12: Design Flow Steps

Advanced Tab
Figure 12-2 shows the next tab called Advanced. This displays the settings for FPGA
Options, Debug Signals for Controller, Simulation Options, and Clock Options for the
specific controller.
X-Ref Target - Figure 12-2

Figure 12-2:

Vivado Customize IP Dialog Box Advanced

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

232

Chapter 12: Design Flow Steps

QDR II+ SRAM Design Checklist Tab

Figure 12-3 shows the QDR II+ SRAM Design Checklist usage information.
X-Ref Target - Figure 12-3

Figure 12-3:

Vivado Customize IP Dialog Box Design Checklist Tab

User Parameters
Table 12-1 shows the relationship between the fields in the Vivado IDE and the User
Parameters (which can be viewed in the Tcl Console).
Table 12-1:

Vivado IDE Parameter to User Parameter Relationship

Vivado IDE Parameter/Value(1)

User Parameter/Value(1)

Default Value

System Clock Configuration

System_Clock

Differential

Internal V REF

Internal_Vref

TRUE

DCI Cascade

DCI_Cascade

FALSE

Debug Signal for Controller

Debug_Signal

Disable

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

233

Chapter 12: Design Flow Steps

Table 12-1:

Vivado IDE Parameter to User Parameter Relationship (Contd)

Vivado IDE Parameter/Value(1)

User Parameter/Value(1)

Default Value

Clock 1 (MHz)

ADDN_UI_CLKOUT1_FREQ_HZ

None

Clock 2 (MHz)

ADDN_UI_CLKOUT2_FREQ_HZ

None

Clock 3 (MHz)

ADDN_UI_CLKOUT3_FREQ_HZ

None

Clock 4 (MHz)

ADDN_UI_CLKOUT4_FREQ_HZ

None

I/O Power Reduction

IOPowerReduction

OFF

Enable System Ports

Enable_SysPorts

TRUE

Default Bank Selections

Default_Bank_Selections

FALSE

Reference Clock

Reference_Clock

FALSE

Clock Period (ps)

C0.QDRIIP_TimePeriod

1,819

Input Clock Period (ps)

C0.QDRIIP_InputClockPeriod

13,637

Configuration

C0.QDRIIP_MemoryType

Components

Memory Part

C0.QDRIIP_MemoryPart

CY7C2565XV18-633BZXC

Data Width

C0.QDRIIP_DataWidth

36

Burst Length

C0.QDRIIP_BurstLen

Memory Name

C0.QDRIIP_MemoryName

Main Memory

Notes:
1. Parameter values are listed in the table where the Vivado IDE parameter value differs from the user parameter value. Such
values are shown in this table as indented below the associated parameter.

Output Generation
For details, see the Vivado Design Suite User Guide: Designing with IP (UG896) [Ref 9].

I/O Planning
For details on I/O planning, see I/O Planning, page 176.

Constraining the Core

This section contains information about constraining the core in the Vivado Design Suite.

Required Constraints
The QDR II+ SRAM Vivado IDE generates the required constraints. A location constraint and
an I/O standard constraint are added for each external pin in the design. The location is
chosen by the Vivado IDE according to the banks and byte lanes chosen for the design.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

234

Chapter 12: Design Flow Steps

The I/O standard is chosen by the memory type selection and options in the Vivado IDE and
by the pin type. A sample for qdriip_d[0] is shown here.
set_property LOC AP25 [get_ports {c0_qdriip_d[0]}]
set_property IOSTANDARD HSTL_I [get_ports {c0_qdriip_d[0]}]

The system clock must have the period set properly:

create_clock -name c0_sys_clk period 1.818 [get_ports c0_sys_clk_p]

Device, Package, and Speed Grade Selections

This section is not applicable for this IP core.

Clock Frequencies
This section is not applicable for this IP core.

Clock Management
For more information on clocking, see Clocking, page 214.

Clock Placement
This section is not applicable for this IP core.

Banking
This section is not applicable for this IP core.

Transceiver Placement
This section is not applicable for this IP core.

I/O Standard and Placement

The QDR II+ SRAM tool generates the appropriate I/O standards and placement based on
the selections made in the Vivado IDE for the interface type and options.
IMPORTANT: The set_input_delay and set_output_delay constraints are not needed on the
external memory interface pins in this design due to the calibration process that automatically runs at
start-up. Warnings seen during implementation for the pins can be ignored.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

235

Chapter 12: Design Flow Steps

Simulation
This section contains information about simulating the QDR II+ SRAM generated IP. Vivado
simulator, QuestaSim, IES, and VCS simulation tools are used for verification of the QDR II+
SRAM IP at each software release. Vivado simulator is not supported yet. For more
information on simulation, see Chapter 13, Example Design and Chapter 14, Test Bench.

Synthesis and Implementation

For details about synthesis and implementation, see the Vivado Design Suite User Guide:
Designing with IP (UG896) [Ref 9].

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

236

Chapter 13

Example Design
This chapter contains information about the example design provided in the Vivado
Design Suite.
Vivado supports Open IP Example Design flow. To create the example design using this flow,
right-click the IP in the Source Window, as shown in Figure 13-1 and select Open IP
Example Design.
X-Ref Target - Figure 13-1

Figure 13-1:

Open IP Example Design

This option creates a new Vivado project. Upon selecting the menu, a dialog box to enter
the directory information for the new design project opens.
Select a directory, or use the defaults, and click OK. This launches a new Vivado with all of
the example design files and a copy of the IP.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

237

Chapter 13: Example Design

Figure 13-2 shows the example design with the PHY only option selected (controller
module does not get generated).
X-Ref Target - Figure 13-2

Figure 13-2:

Open IP Example Design with PHY Only Option Selected

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

238

Chapter 13: Example Design

Figure 13-3 shows the example design with the PHY only option not selected (controller
module is generated).
X-Ref Target - Figure 13-3

Figure 13-3:

Open IP Example Design with PHY Only Option Not Selected

Simulating the Example Design (Designs with

Standard User Interface)
The example design provides a synthesizable test bench to generate a fixed simple data
pattern to the Memory Controller. This test bench consists of an IP wrapper and an
example_tb that generates 10 writes and 10 reads. QDR II+ SRAM does not deliver the
QDR II+ memory models. The memory model required for the simulation must be
downloaded from the memory vendor website.
The example design can be simulated using one of the methods in the following sections.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

239

Chapter 13: Example Design

Project-Based Simulation
This method can be used to simulate the example design using the Vivado Integrated
Design Environment (IDE). Memory IP does not deliver the QDR II+ memory models. The
memory model required for the simulation must be downloaded from the memory vendor
website. The memory model file must be added in the example design using Add Sources
option to run simulation.
The Vivado simulator, QuestaSim, IES, and VCS tools are used for QDR II+ IP verification at
each software release. The Vivado simulation tool is used for QDR II+ IP verification from
2015.1 Vivado software release. The following subsections describe steps to run a
project-based simulation using each supported simulator tool.

Project-Based Simulation Flow Using Vivado Simulator

1. In the Open IP Example Design Vivado project, under Add sources option, select the
Add or create simulation sources option, and click Next as shown in Figure 13-4.
X-Ref Target - Figure 13-4

Figure 13-4:

Add Source Option in Vivado

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

240

Chapter 13: Example Design

2. Add the memory model in the Add or create simulation sources page and click Finish
as shown in Figure 13-5.
X-Ref Target - Figure 13-5

Figure 13-5:

Add or Create Simulation Sources in Vivado

3. In the Open IP Example Design Vivado project, under Flow Navigator, select
Simulation Settings.
4. Select Target simulator as Vivado Simulator.
a. Under the Simulation tab, set the xsim.simulate.runtime to 1 ms (there are
simulation RTL directives which stop the simulation after certain period of time,
which is less than 1 ms) as shown in Figure 13-6. The Generate Scripts Only option
generates simulation scripts only. To run behavioral simulation, Generate Scripts
Only option must be de-selected.
5. Apply the settings and select OK.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

241

Chapter 13: Example Design

X-Ref Target - Figure 13-6

Figure 13-6:

Simulation with Vivado Simulator

6. In the Flow Navigator window, select Run Simulation and select Run Behavioral
Simulation option as shown in Figure 13-7.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

242

Chapter 13: Example Design

X-Ref Target - Figure 13-7

Figure 13-7:

Run Behavioral Simulation

7. Vivado invokes Vivado simulator and simulations are run in the Vivado simulator tool.
For more information, see the Vivado Design Suite User Guide: Logic Simulation (UG900)
[Ref 11].

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

243

Chapter 13: Example Design

Project-Based Simulation Flow Using QuestaSim

1. Open a QDR II+ SRAM example Vivado project (Open IP Example Design...), then under
Add sources option, select the Add or create simulation sources option, and click
Next as shown in Figure 13-8.
X-Ref Target - Figure 13-8

Figure 13-8:

Add Source Option in Vivado

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

244

Chapter 13: Example Design

2. Add the memory model in the Add or create simulation sources page and click Finish
as shown in Figure 13-9.
X-Ref Target - Figure 13-9

Figure 13-9:

Add or Create Simulation Sources in Vivado

3. In the Open IP Example Design Vivado project, under Flow Navigator, select
Simulation Settings.
4. Select Target simulator as QuestaSim/ModelSim Simulator.
a. Browse to the compiled libraries location and set the path on Compiled libraries
location option.
b. Under the Simulation tab, set the modelsim.simulate.runtime to 1 ms (there
are simulation RTL directives which stop the simulation after certain period of time,
which is less than 1 ms) as shown in Figure 13-10. The Generate Scripts Only option
generates simulation scripts only. To run behavioral simulation, Generate Scripts
Only option must be de-selected.
5. Apply the settings and select OK.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

245

Chapter 13: Example Design

X-Ref Target - Figure 13-10

Figure 13-10:

Simulation with QuestaSim

6. In the Flow Navigator window, select Run Simulation and select Run
BehavioralSimulation option as shown in Figure 13-11.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

246

Chapter 13: Example Design

X-Ref Target - Figure 13-11

Figure 13-11:

Run Behavioral Simulation

7. Vivado invokes QuestaSim and simulations are run in the QuestaSim tool. For more
information, see the Vivado Design Suite User Guide: Logic Simulation (UG900) [Ref 11].

Project-Based Simulation Flow Using IES

1. Open a QDR II+ SRAM example Vivado project (Open IP Example Design...), then under
Add sources option, select the Add or create simulation sources option and click
Next as shown in Figure 13-8.
2. Add the memory model in the Add or create simulation sources page and click Finish
as shown in Figure 13-9.
3. In the Open IP Example Design Vivado project, under Flow Navigator, select
Simulation Settings.
4. Select Target simulator as Incisive Enterprise Simulator (IES).
a. Browse to the compiled libraries location and set the path on Compiled libraries
location option.
b. Under the Simulation tab, set the ies.simulate.runtime to 1 ms (there are
simulation RTL directives which stop the simulation after certain period of time,
which is less than 1 ms) as shown in Figure 13-12. The Generate Scripts Only option
generates simulation scripts only. To run behavioral simulation, Generate Scripts
Only option must be de-selected.
5. Apply the settings and select OK.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

247

Chapter 13: Example Design

X-Ref Target - Figure 13-12

Figure 13-12:

Simulation with IES Simulator

6. In the Flow Navigator window, select Run Simulation and select Run
BehavioralSimulation option as shown in Figure 13-11.
7. Vivado invokes IES and simulations are run in the IES tool. For more information, see the
Vivado Design Suite User Guide: Logic Simulation (UG900) [Ref 11].

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

248

Chapter 13: Example Design

Project-Based Simulation Flow Using VCS

1. Open a QDR II+ SRAM example Vivado project (Open IP Example Design...), then under
Add sources option, select the Add or create simulation sources option and click
Next as shown in Figure 13-8.
2. Add the memory model in the Add or create simulation sources page and click Finish
as shown in Figure 13-9.
3. In the Open IP Example Design Vivado project, under Flow Navigator, select
Simulation Settings.
4. Select Target simulator as Verilog Compiler Simulator (VCS).
a. Browse to the compiled libraries location and set the path on Compiled libraries
location option.
b. Under the Simulation tab, set the vcs.simulate.runtime to 1 ms (there are
simulation RTL directives which stop the simulation after certain period of time,
which is less than 1 ms) as shown in Figure 13-13. The Generate Scripts Only option
generates simulation scripts only. To run behavioral simulation, Generate Scripts
Only option must be de-selected.
5. Apply the settings and select OK.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

249

Chapter 13: Example Design

X-Ref Target - Figure 13-13

Figure 13-13:

Simulation with VCS Simulator

6. In the Flow Navigator window, select Run Simulation and select Run
BehavioralSimulation option as shown in Figure 13-11.
7. Vivado invokes VCS and simulations are run in the VCS tool. For more information, see
the Vivado Design Suite User Guide: Logic Simulation (UG900) [Ref 11].

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

250

Chapter 13: Example Design

Simulation Speed
QDR II+ SRAM provides a Vivado IDE option to reduce the simulation speed by selecting
behavioral XIPHY model instead of UNISIM XIPHY model. Behavioral XIPHY model
simulation is a default option for QDR II+ SRAM designs. To select the simulation mode,
click the Advanced tab and find the Simulation Options as shown in Figure 13-14.
X-Ref Target - Figure 13-14

Figure 13-14:

Advanced Tab Simulation Options

The SIM_MODE parameter in the RTL is given a different value based on the Vivado IDE
selection.

SIM_MODE = BFM If fast mode is selected in the Vivado IDE, the RTL parameter
reflects this value for the SIM_MODE parameter. This is the default option.

SIM_MODE = FULL If FULL mode is selected in the Vivado IDE, XIPHY UNISIMs are
selected and the parameter value in the RTL is FULL.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

251

Chapter 13: Example Design

IMPORTANT: QDR II+ memory models from Cypress Semiconductor need to be modified with the

following two timing parameter values to run the simulations successfully:

`define tcqd #0
`define tcqdoh #0.15

Synplify Pro Black Box Testing

Using the Synopsys Synplify Pro black box testing for example_design, follow these
steps to run black box synthesis with synplify_pro and implementation with Vivado.
1. Generate the UltraScale architecture QDR II+ SRAM IP core with OOC flow to generate
the .dcp file for implementation. The Target Language for the project can be selected
as verilog or VHDL.
2. Create the example design for the QDR II+ SRAM IP core using the information provided
in the example design section and close the Vivado project.
3. Invoke the synplify_pro software which supports UltraScale FPGA and select the
same UltraScale FPGA part selected at the time of generating the IP core.
4. Add the following files into synplify_pro project based on the Target Language
selected at the time of invoking Vivado:
a. For Verilog:
<project_dir>/example_project/<Component_Name>example/
<Component_Name>_example.srcs/sources_1/ip/<Component_Name>/*stub.v
<project_dir>/example_project/<Component_Name>example/
<Component_Name>_example.srcs/sources_1/imports/<Component_Name>/rtl/ip_top/
example_top.sv
<project_dir>/example_project/<Component_Name>example/
<Component_Name>_example.srcs/sources_1/imports/<Component_Name>/tb/example_tb.sv

b. For VHDL:
<project_dir>/example_project/<Component_Name>example/
<Component_Name>_example.srcs/sources_1/ip/<Component_Name>/*stub.vhdl
<project_dir>/example_project/<Component_Name>example/
<Component_Name>_example.srcs/sources_1/imports/<Component_Name>/rtl/ip_top/
example_top.sv
<project_dir>/example_project/<Component_Name>example/
<Component_Name>_example.srcs/sources_1/imports/<Component_Name>/tb/example_tb.sv

5. Run synplify_pro synthesis to generate the .edf file. Then, close the
synplify_pro project.
6. Open new Vivado project with Project Type as Post-synthesis Project and select the
Target Language same as selected at the time of generating the IP core.
7. Add the synplify_pro generated .edf file to the Vivado project as Design Source.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

252

Chapter 13: Example Design

8. Add the .dcp file generated in steps 1 and 2 to the Vivado project as Design Source.
For example:
<project_dir>/example_project/<Component_Name>example/
<Component_Name>_example.srcs/sources_1/ip/<Component_Name>/<Component_Name>.dcp

9. Add the .xdc file generated in step 2 to the Vivado project as constraint. For example:
<project_dir>/example_project/<Component_Name>example/
<Component_Name>_example.srcs/constrs_1/imports/par/example_design.xdc

10. Run implementation flow with the Vivado tool. For details about implementation, see
the Vivado Design Suite User Guide: Designing with IP (UG896) [Ref 9].
Note: Similar steps can be followed for the user design using appropriate .dcp and .xdc files.

CLOCK_DEDICATED_ROUTE Constraints and BUFG

Instantiation
If the GCIO pin and MMCM are not allocated in the same bank, the
CLOCK_DEDICATED_ROUTE constraint must be set to BACKBONE. To use the BACKBONE
route, BUFG/BUFGCE/BUFGCTRL/BUFGCE_DIV must be instantiated between GCIO and
MMCM input. QDR II+ SRAM manages these constraints for designs generated with the
Reference Input Clock option selected as Differential (at Advanced > FPGA Options >
Reference Input). Also, QDR II+ SRAM handles the IP and example design flows for all
scenarios.
If the design is generated with the Reference Input Clock option selected as No Buffer (at
Advanced > FPGA Options > Reference Input), the CLOCK_DEDICATED_ROUTE
constraints and BUFG/BUFGCE/BUFGCTRL/BUFGCE_DIV instantiation based on GCIO and
MMCM allocation needs to be handled manually for the IP flow. QDR II+ SRAM does not
generate clock constraints in the XDC file for No Buffer configurations and you must take
care of the clock constraints for No Buffer configurations for the IP flow.
For an example design flow with No Buffer configurations, QDR II+ SRAM generates the
example design with differential buffer instantiation for system clock pins. QDR II+ SRAM
generates clock constraints in the example_design.xdc. It also generates a
CLOCK_DEDICATED_ROUTE constraint as the BACKBONE and instantiates BUFG/BUFGCE/
BUFGCTRL/BUFGCE_DIV between GCIO and MMCM input if the GCIO and MMCM are not in
same bank to provide a complete solution. This is done for the example design flow as a
reference when it is generated for the first time.
If in the example design, the I/O pins of the system clock pins are changed to some other
pins with the I/O pin planner, the CLOCK_DEDICATED_ROUTE constraints and BUFG/
BUFGCE/BUFGCTRL/BUFGCE_DIV instantiation need to be managed manually. A DRC error
is reported for the same.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

253

Chapter 14

Test Bench
This chapter contains information about the test bench provided in the Vivado Design
Suite.
The Memory Controller is generated along with a simple test bench to verify the basic read
and write operations. The stimulus contains 10 consecutive writes followed by 10
consecutive reads for data integrity check.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

254

SECTION IV: RLDRAM 3

Overview
Product Specification
Core Architecture
Designing with the Core
Design Flow Steps
Example Design
Test Bench

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

255

Chapter 15

Overview
The Xilinx UltraScale architecture includes the RLDRAM 3 core. This core provides
solutions for interfacing with these DRAM memory types. Both a complete Memory
Controller and a physical (PHY) layer only solution are supported. The UltraScale
architecture for the RLDRAM 3 cores is organized in the following high-level blocks.

Controller The controller accepts burst transactions from the User Interface and
generates transactions to and from the RLDRAM 3. The controller takes care of the
DRAM timing parameters and refresh.

Physical Layer The physical layer provides a high-speed interface to the DRAM. This
layer includes the hard blocks inside the FPGA and the soft blocks calibration logic
necessary to ensure optimal timing of the hard blocks interfacing to the DRAM.

The new hard blocks in the UltraScale architecture allow interface rates of up to
2,133 Mb/s to be achieved.

These hard blocks include:

-

Data serialization and transmission

Data capture and deserialization

High-speed clock generation and synchronization

Fine delay elements per pin with voltage and temperature tracking

The soft blocks include:

-

Memory Initialization The calibration modules provide an initialization

routine for RLDRAM 3. The delays in the initialization process are bypassed to
speed up simulation time.

Calibration The calibration modules provide a complete method to set all

delays in the hard blocks and soft IP to work with the memory interface. Each bit
is individually trained and then combined to ensure optimal interface
performance. Results of the calibration process are available through the Xilinx
debug tools. After completion of calibration, the PHY layer presents raw
interface to the DRAM.

Application Interface The "User Interface" layer provides a simple FIFO interface to
the application. Data is buffered and read data is presented in request order.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

256

Chapter 15: Overview

X-Ref Target - Figure 15-1

8OWUD6FDOH$UFKLWHFWXUH)3*$V
8VHU,QWHUIDFH
UVW

3K\VLFDO,QWHUIDFH
8OWUD6FDOH$UFKLWHFWXUH)3*$V0HPRU\
,QWHUIDFH6ROXWLRQ

UOGBFNBS
UOGBFNBQ

FON
XVHUBDGGU

UOGBD

XVHUBFPG

UOGBED

XVHUBFPGBHQ

0HPRU\
&RQWUROOHU

XVHUBED

UOGBUHIBQ

3K\VLFDO
/D\HU

UOGZHQ

XVHUBZUBGDWD

UOGBFVBQ

XVHUBZUBHQ

UOGBUHVHWBQ

XVHUBZUBGP

UOGBGNBS
8VHU
)3*$
/RJLF

0&3+<,QWHUIDFH

XVHUBUGBYDOLG

,2%

XVHUBUGBGDWD

5/'5$0

UOGBGNBQ
UOGBGP

XVHUBDILIRBHPSW\

UOGBGT

XVHUBDILIRBIXOO
XVHUBDILIRBDHPSW\

UOGBTYOG

XVHUBDILIRBDIXOO

UOGBTNBS

XVHUBZGILIRBHPSW\

UOGBTNBQ

XVHUBZGILIRBIXOO
XVHUBZGILIRBDHPSW\
XVHUBZGILIRBDIXOO

Figure 15-1:

UltraScale Architecture FPGAs Memory Interface Solution

Feature Summary

Component support for interface widths of 18 and 36 bits

Table 15-1:

Supported Configurations

Interface Width

Burst Length

Number of Device

36

BL2, BL4

1, 2

18

BL2, BL4, BL8

1, 2

36 with address
multiplexing

BL4

1, 2

18 with address
multiplexing

BL4, BL8

1, 2

ODT support

RLDRAM 3 initialization support

Source code delivery in Verilog

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

257

Chapter 15: Overview

4:1 memory to FPGA logic interface clock ratio

Interface calibration and training information available through the Vivado hardware
manager

Licensing and Ordering Information

This Xilinx LogiCORE IP module is provided at no additional cost with the Xilinx Vivado
Design Suite under the terms of the Xilinx End User License. Information about this and
other Xilinx LogiCORE IP modules is available at the Xilinx Intellectual Property page. For
information about pricing and availability of other Xilinx LogiCORE IP modules and tools,
contact your local Xilinx sales representative.

License Checkers
If the IP requires a license key, the key must be verified. The Vivado design tools have
several license checkpoints for gating licensed IP through the flow. If the license check
succeeds, the IP can continue generation. Otherwise, generation halts with error. License
checkpoints are enforced by the following tools:

Vivado synthesis

Vivado implementation

write_bitstream (Tcl command)

IMPORTANT: IP license level is ignored at checkpoints. The test confirms a valid license exists. It does

not check IP license level.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

258

Chapter 16

Product Specification
Standards
For more information on UltraScale architecture documents, see References, page 516.

Performance
Maximum Frequencies
For more information on the maximum frequencies, see Kintex UltraScale FPGAs Data Sheet,
DC and AC Switching Characteristics (DS892) [Ref 2].

Resource Utilization
Kintex UltraScale Devices
Table 16-1 provides approximate resource counts on Kintex UltraScale devices.
Table 16-1:

Device Utilization Kintex UltraScale FPGAs

Parameter
Values

Device Resources

Interface Width

FFs

LUTs

Memory LUTs

RAMB36E2/
RAMB18E2

BUFGs

36

5,311

4,799

463

29

PLLE3_ADV MMCME3_ADV
2

Resources required for the UltraScale architecture FPGAs RLDRAM 3 core have been
estimated for the Kintex UltraScale devices. These values were generated using Vivado IP
catalog. They are derived from post-synthesis reports, and might change during
implementation.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

259

Chapter 16: Product Specification

Port Descriptions
There are three port categories at the top-level of the memory interface core called the
user design.

The first category is the memory interface signals that directly interfaces with the
RLDRAM. These are defined by the Micron RLDRAM 3 specification.

The second category is the application interface signals which is the user interface.
These are described in the Protocol Description, page 276.

The third category includes other signals necessary for proper operation of the core.
These include the clocks, reset, and status signals from the core. The clocking and reset
signals are described in their respective sections.
The active-High init_calib_complete signal indicates that the initialization and
calibration are complete and that the interface is now ready to accept commands for the
interface.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

260

Chapter 17

Core Architecture
This chapter describes the UltraScale device FPGAs Memory Interface Solutions core with
an overview of the modules and interfaces.

Overview
Figure 17-1 shows a high-level block diagram of the RLDRAM 3 core. This figure shows both
the internal FPGA connections to the user interface for initiating read and write commands,
and the external interface to the memory device.
X-Ref Target - Figure 17-1

8VHU,QWHUIDFH

3K\VLFDO
,QWHUIDFH

8OWUD6FDOH$UFKLWHFWXUH)3*$V

FON
V\VBUVW
UVWBFON
UVW
PHPBUHIFON
IUHTBUHIFON
FONBUHI
SOOBORFN
V\QFBSXOVH
XVHUBFPGBHQ
XVHUBFPG
XVHUBDGGU
XVHUBED
XVHUBZUBHQ
XVHUBZUBGDWD
XVHUBZUBGP
XVHUBDILIRBHPSW\
XVHUBDILIRBIXOO
XVHUBDILIRBDHPSW\
XVHUBDILIRBDIXOO
XVHUBZGILIRBHPSW\
XVHUBZGILIRBIXOO
XVHUBZGILIRBDHPSW\
XVHUBZGILIRBDIXOO
XVHUBUGBYDOLG
XVHUBUGBGDWD
LQLWBFDOLEBFRPSOHWH

Figure 17-1:

UOGBFNBS
UOGBFNBQ
UOGBGNBS
UOGBGNBQ
UOGBFVBQ
UOGBZHBQ
UOGBUHIBQ
UOGBD
UOGBED
UOGBGT
UOGBGP
UOGBTNBS
UOGBTNBQ
UOGBTYOG
UOGBUHVHWBQ

FN
FNBQ
GN
GNBQ
FVBQ
ZHBQ
UHIBQ
D
ED
GT
GP
TN
TNBQ
TYOG
UHVHWBQ

5/'5$0

High-Level Block Diagram of RLDRAM 3 Interface Solution

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

261

Chapter 17: Core Architecture

Figure 17-2 shows the UltraScale architecture FPGAs Memory Interface Solutions diagram.
X-Ref Target - Figure 17-2

8OWUD6FDOH$UFKLWHFWXUH)3*$V
8OWUD6FDOH$UFKLWHFWXUH)3*$V0HPRU\,QWHUIDFH6ROXWLRQ

0HPRU\
&RQWUROOHU



8VHUV)3*$
/RJLF

8VHU
LQWHUIDFH

3K\VLFDO
/D\HU

,QLWLDOL]DWLRQ
&DOLEUDWLRQ

5/'5$0

&DO'RQH

5HDG'DWD

Figure 17-2:

UltraScale Architecture FPGAs Memory Interface Solution Core

The user interface uses a simple protocol based entirely on SDR signals to make read and
write requests. See User Interface in Chapter 18 for more details describing this protocol.
The Memory Controller takes commands from the user interface and adheres to the
protocol requirements of the RLDRAM 3 device. See Memory Controller for more details.
The physical interface generates the proper timing relationships and DDR signaling to
communicate with the external memory device, while conforming to the RLDRAM 3
protocol and timing requirements. See Physical Interface in Chapter 18 for more details.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

262

Chapter 17: Core Architecture

Memory Controller
The Memory Controller (MC) enforces the RLDRAM 3 access requirements and interfaces
with the PHY. The controller processes commands in order, so the commands presented to
the controller is the order in which they are presented to the memory device.
The MC first receives commands from the user interface and determines if the command
can be processed immediately or needs to wait. When all requirements are met, the
command is placed on the PHY interface. For a write command, the controller generates a
signal for the user interface to provide the write data to the PHY. This signal is generated
based on the memory configuration to ensure the proper command-to-data relationship.
Auto-refresh commands are inserted into the command flow by the controller to meet the
memory device refresh requirements.
The data bus is shared for read and write data in RLDRAM 3. Switching from read commands
to write commands and vice versa introduces gaps in the command stream due to switching
the bus. For better throughput, changes in the command bus should be minimized when
possible.
CMD_PER_CLK is a top-level parameter used to determine how many memory commands
are provided to the controller per FPGA logic clock cycle. It depends on nCK_PER_CLK and
the burst length. For example if nCK_PER_CLK = 4, the CMD_PER_CLK is set to 1 for burst
length = 8 and CMD_PER_CLK is set to 2 for burst length = 4 and CMD_PER_CLK is set to 4
for burst length = 2.

User Interface Allocation

The address bits on c0_rld3_user_addr bus needs to be assigned as below.

PHY
PHY is considered the low-level physical interface to an external RLDRAM 3 device as well as
all calibration logic for ensuring reliable operation of the physical interface itself. PHY
generates the signal timing and sequencing required to interface to the memory device.
PHY contains the following features:

Clock/address/control-generation logics

Write and read datapaths

Logic for initializing the SDRAM after power-up

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

263

Chapter 17: Core Architecture

In addition, PHY contains calibration logic to perform timing training of the read and write
datapaths to account for system static and dynamic delays.

Overall PHY Architecture

The UltraScale architecture PHY is composed of dedicated blocks and soft calibration logic.
The dedicated blocks are structured adjacent to one another with back-to-back
interconnects to minimize the clock and datapath routing necessary to build high
performance physical layers.
The Memory Controller and calibration logic communicate with this dedicated PHY in the
slow frequency clock domain, which is divided by 4. A more detailed block diagram of the
PHY design is shown in Figure 17-3.
X-Ref Target - Figure 17-3

8OWUD6FDOH)3*$

8OWUD6FDOH)3*$V0HPRU\,QWHUIDFH6ROXWLRQ

0HPRU\&RQWUROOHU

8VHULQWHUIDFH

8VHU)3*$/RJLF

3K\VLFDO/D\HU

5/'5$0

,QLWLDOL]DWLRQ&DOLEUDWLRQ

&DO'RQH

5HDG'DWD

Figure 17-3:

PHY Block Diagram

The MC is designed to separate out the command processing from the low-level PHY
requirements to ensure a clean separation between the controller and physical layer. The
command processing can be replaced with custom logic if desired, while the logic for
interacting with the PHY stays the same and can still be used by the calibration logic.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

264

Chapter 17: Core Architecture

Table 17-1:

PHY Modules

Module Name

Description

rld3_phy.sv

Contains infrastructure (infrastructure.sv), rld_cal.sv, rld_xiphy.sv, and MUXes between the

calibration and the Memory Controller.

rld_cal.sv

Contains the MicroBlaze processing system and associated logic.

rld_cal_adr_decode.sv

FPGA logic interface for the MicroBlaze processor.

config_rom.sv

Configuration storage for calibration options.

debug_microblaze.sv

MicroBlaze processor

rld_iob.sv

Instantiates all byte IOB modules

rld_iob_byte.sv

Generates the I/O buffers for all the signals in a given byte lane.

rld_addr_mux.sv

Address MUX

rld_rd_bit_slip.sv

Read bit slip

rld_wr_lat.sv

Write latency

rld_xiphy.sv

Top-level XIPHY module

The PHY architecture encompasses all of the logic contained in rld_xiphy.sv. The PHY
contains wrappers around dedicated hard blocks to build up the memory interface from
smaller components. A byte lane contains all of the clocks, resets, and datapaths for a given
subset of I/O. Multiple byte lanes are grouped together, along with dedicated clocking
resources, to make up a single bank memory interface. For more information on the hard
silicon physical layer architecture, see the UltraScale Architecture FPGAs SelectIO
Resources User Guide (UG571) [Ref 3].
The memory initialization and calibration are implemented in C programming on a small
soft core processor. The MicroBlaze Controller System (MCS) is configured with an I/O
Module and block RAM. The rld_cal_adr_decode.sv module provides the interface for
the processor to the rest of the system and implements helper logic. The config_rom.sv
module stores settings that control the operation of initialization and calibration, providing
run time options that can be adjusted without having to recompile the source code.
The MicroBlaze I/O module interface updates at a maximum rate of once every three clock
cycles, which is not always fast enough for implementing all of the functions required in
calibration. A helper circuit implemented in rld_cal_adr_decode.sv is required to
obtain commands from the registers and translate at least a portion into single-cycle
accuracy for submission to the PHY. In addition, it supports command repetition to enable
back-to-back read transactions and read data comparison.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

265

Chapter 17: Core Architecture

Memory Initialization and Calibration Sequence

After deassertion of the system reset, calibration logic performs power-on initialization
sequence for the memory. This is followed by several stages of timing calibration for the
write and read datapaths. PHY indicates calibration is finished and controller begins issuing
commands to the memory.
Figure 17-4 shows the overall flow of memory initialization and the different stages of
calibration.
X-Ref Target - Figure 17-4

6\VWHP5HVHW

5/'5$0,QLWLDOL]DWLRQ

5HDG&ORFN$OLJQPHQW

5HDG'4'HVNHZ

5HDG'47UDLQLQJZLWK6LPSOH3DWWHUQ

49$/,'7UDLQLQJ

:ULWH'4'0'HVNHZ7UDLQLQJ

:ULWH5HDG6DQLW\&KHFN

%\WH6OLS7UDLQLQJ

49$/,'6OLS7UDLQLQJ

:ULWH5HDG6DQLW\&KHFN

49$/,'$OLJQ7UDLQLQJ

%\WH$OLJQ7UDLQLQJ

:ULWH5HDG6DQLW\&KHFN

5HDG'47UDLQLQJZLWK&RPSOH[3DWWHUQ

:ULWH5HDG6DQLW\&KHFN

&DOLEUDWLRQ&RPSOHWH

Figure 17-4:

PHY Overall Initialization and Calibration Sequence

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

266

Chapter 18

Designing with the Core

This chapter includes guidelines and additional information to facilitate designing with the
core.

Clocking
The memory interface requires one MMCM, one TXPLL per I/O bank used by the memory
interface, and two BUFGs. These clocking components are used to create the proper clock
frequencies and phase shifts necessary for the proper operation of the memory interface.
There are two TXPLLs per bank. If a bank is shared by two memory interfaces, both TXPLLs
in that bank are used.
Note: RLDRAM 3 generates the appropriate clocking structure and no modifications to the RTL are
supported.

The RLDRAM 3 tool generates the appropriate clocking structure for the desired interface.
This structure must not be modified. The allowed clock configuration is as follows:

Differential reference clock source connected to GCIO

GCIO to MMCM (located in center bank of memory interface)

MMCM to BUFG (located at center bank of memory interface) driving FPGA logic and
all TXPLLs

MMCM to BUFG (located at center bank of memory interface) divide by two mode
driving 1/2 rate FPGA logic

Clocking pair of the interface must be in the same SLR of memory interface for the SSI
technology devices

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

267

Chapter 18: Designing with the Core

Requirements
GCIO

Must use a differential I/O standard

Must be in the same I/O column as the memory interface

Must be in the same SLR of memory interface for the SSI technology devices

MMCM

MMCM is used to generate the FPGA logic system clock (1/4 of the memory clock)

Must be located in the center bank of memory interface

Must use internal feedback

Input clock frequency divided by input divider must be 70 MHz (CLKINx / D

70 MHz)

Must use integer multiply and output divide values

BUFGs and Clock Roots

One BUFG is used to generate the system clock to FPGA logic and another BUFG is used
to divide the system clock by two.

BUFGs and clock roots must be located in center most bank of the memory interface.

For two bank systems, banks with more number of bytes selected is chosen as the
center bank. If the same number of bytes is selected in two banks, then the top
bank is chosen as the center bank.

For four bank systems, either of the center banks can be chosen. RLDRAM 3 refers
to the second bank from the top-most selected bank as the center bank.

Both the BUFGs must be in the same bank.

TXPLL

CLKOUTPHY from TXPLL drives XIPHY within its bank

TXPLL must be set to use a CLKFBOUT phase shift of 90

TXPLL must be held in reset until the MMCM lock output goes High

Must use internal feedback

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

268

Chapter 18: Designing with the Core

Figure 18-1 shows an example of the clocking structure for a three bank memory interface.
The GCIO drives the MMCM located at the center bank of the memory interface. MMCM
drives both the BUFGs located in the same bank. The BUFG (which is used to generate
system clock to FPGA logic) output drives the TXPLLs used in each bank of the interface.
X-Ref Target - Figure 18-1

7;3//

,2%DQN

6\VWHP&ORFNWR)3*$/RJLF

0HPRU\,QWHUIDFH

%8)*
7;3//
00&0

,2%DQN

&/.287
&/.287
%8)*

6\VWHP&ORFN'LYLGHG
E\WR)3*$/RJLF

7;3//

,2%DQN

'LIIHUHQWLDO
*&,2,QSXW

%8)*
,2%DQN

Figure 18-1:

Clocking Structure for Three Bank Memory Interface

The MMCM is placed in the center bank of the memory interface.

For two bank systems, MMCM is placed in a bank with the most number of bytes
selected. If they both have the same number of bytes selected in two banks, then
MMCM is placed in the top bank.

For four bank systems, MMCM is placed in a second bank from the top.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

269

Chapter 18: Designing with the Core

For designs generated with System Clock configuration of No Buffer, MMCM must not be
driven by another MMCM/PLL. Cascading clocking structures MMCM BUFG MMCM
and PLL BUFG MMCM are not allowed.
If the MMCM is driven by the GCIO pin of the other bank, then the
CLOCK_DEDICATED_ROUTE constraint with value "BACKBONE" must be set on the net that
is driving MMCM or on the MMCM input. Setting up the CLOCK_DEDICATED_ROUTE
constraint on the net is preferred. But when the same net is driving two MMCMs, the
CLOCK_DEDICATED_ROUTE constraint must be managed by considering which MMCM
needs the BACKBONE route.
In such cases, the CLOCK_DEDICATED_ROUTE constraint can be set on the MMCM input. To
use the "BACKBONE" route, any clock buffer that exists in the same CMT tile as the GCIO
must exist between the GCIO and MMCM input. The clock buffers that exists in the I/O CMT
are BUFG, BUFGCE, BUFGCTRL, and BUFGCE_DIV. So RLDRAM 3 instantiates BUFG between
the GCIO and MMCM when the GCIO pins and MMCM are not in the same bank (see
Figure 18-1).
If the GCIO pin and MMCM are allocated in different banks, RLDRAM 3 generates
CLOCK_DEDICATED_ROUTE constraints with value as "BACKBONE." If the GCIO pin and
MMCM are allocated in the same bank, there is no need to set any constraints on the
MMCM input.
Similarly when designs are generated with System Clock Configuration as a No Buffer
option, you must take care of the "BACKBONE" constraint and the BUFG/BUFGCE/
BUFGCTRL/BUFGCE_DIV between GCIO and MMCM if GCIO pin and MMCM are allocated in
different banks. RLDRAM 3 does not generate clock constraints in the XDC file for No
Buffer configurations and you must take care of the clock constraints for No Buffer
configurations. For more information on clocking, see the UltraScale Architecture Clocking
Resources User Guide (UG572) [Ref 4].
XDC syntax for CLOCK_DEDICATED_ROUTE constraint is given here:
set_property CLOCK_DEDICATED_ROUTE BACKBONE [get_nets net_name]

For more information on the CLOCK_DEDICATED_ROUTE constraints, see the Vivado Design
Suite Properties Reference Guide (UG912) [Ref 5].
Note: If two different GCIO pins are used for two RLDRAM 3 IP cores in the same bank, center bank
of the memory interface is different for each IP. RLDRAM 3 generates MMCM LOC and
CLOCK_DEDICATED_ROUTE constraints accordingly.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

270

Chapter 18: Designing with the Core

Sharing of Input Clock Source (sys_clk_p)

If the same GCIO pin must be used for two IP cores, generate the two IP cores with the same
frequency value selected for option Reference Input Clock Period (ps) and System Clock
Configuration option as No Buffer. Perform the following changes in the wrapper file in
which both IPs are instantiated:
1. RLDRAM 3 generates a single-ended input for system clock pins, such as sys_clk_i.
Connect the differential buffer output to the single-ended system clock inputs
(sys_clk_i) of both the IP cores.
2. System clock pins must be allocated within the same I/O column of the memory
interface pins allocated. Add the pin LOC constraints for system clock pins and clock
constraints in your top-level XDC.
3. You must add a "BACKBONE" constraint on the net that is driving the MMCM or on the
MMCM input if GCIO pin and MMCM are not allocated in the same bank. Apart from
this, BUFG/BUFGCE/BUFGCTRL/BUFGCE_DIV must be instantiated between GCIO and
MMCM to use the "BACKBONE" route.
Note:

The Ultrascale architecture includes an independent XIPHY power supply and TXPLL
for each XIPHY. This results in clean, low jitter clocks for the memory system.

Skew spanning across multiple BUFGs is not a concern because single point of
contact exists between BUFG TXPLL and the same BUFG System Clock Logic.

System input clock cannot span I/O columns because the longer the clock lines
span, the more jitter is picked up.

TXPLL Usage
There are two TXPLLs per bank. If a bank is shared by two memory interfaces, both TXPLLs
in that bank are used. One PLL per bank is used if a bank is used by a single memory
interface. You can use a second PLL for other usage. To use a second PLL, you can perform
the following steps:
1. Generate the design for the System Clock Configuration option as No Buffer.
2. RLDRAM 3 generates a single-ended input for system clock pins, such as sys_clk_i.
Connect the differential buffer output to the single-ended system clock inputs
(sys_clk_i) and also to the input of PLL (PLL instance that you have in your design).
3. You can use the PLL output clocks.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

271

Chapter 18: Designing with the Core

Additional Clocks
You can produce up to four additional clocks which are created from the same MMCM that
generates ui_clk. Additional clocks can be selected from the Clock Options section in the
Advanced tab. The GUI lists the possible clock frequencies from MMCM and the
frequencies for additional clocks vary based on selected memory frequency (Memory
Device Interface Speed (ps) value in the Basic tab), selected FPGA, and FPGA speed grade.

Resets
An asynchronous reset (sys_rst) input is provided. This is an active-High reset and the
sys_rst must assert for a minimum pulse width of 5 ns. The sys_rst can be an internal
or external pin.

PCB Guidelines for RLDRAM 3

Strict adherence to all documented RLDRAM 3 PCB guidelines is required for successful
operation. For more information on PCB guidelines, see the UltraScale Architecture PCB
Design and Pin Planning User Guide (UG583) [Ref 6].

Pin and Bank Rules

RLDRAM 3 Pin Rules
The rules are for single rank memory interfaces.

Address/control means cs_n, ref_n, we_n, ba, ck, reset_n, and a.

All groups such as, Data, Address/Control, and System clock interfaces must be
selected in a single column.

Pins in a byte lane are numbered N0 to N12.

Byte lanes in a bank are designed by T0, T1, T2, or T3. Nibbles within a byte lane are
distinguished by a U or L designator added to the byte lane designator (T0, T1, T2,
or T3). Thus they are T0L, T0U, T1L, T1U, T2L, T2U, T3L, and T3U.

Note: There are two PLLs per bank and a controller uses one PLL in every bank that is being used by
the interface.

1. Read Clock (qk/qk_n), Write Clock (dk/dk_n), dq, qvld, and dm.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

272

Chapter 18: Designing with the Core

a. Read Clock pairs (qkx_p/n) must be placed on N0 and N1 pins. dq associated with
a qk/qk_n pair must be in same byte lane on pins N2 to N11.
b. For the data mask off configurations, ensure that dm pin on the RLDRAM 3 device is
grounded. When data mask is enabled, one dm pin is associated with nine bits in x18
devices or with 18 bits in x36 devices. It must be placed in its associated dq byte
lanes as listed:
-

For x18 part, dm[0] must be allocated in dq[8:0] allocated byte group and
dm[1] must be allocated in dq[17:9].

For x36 part, dm[0] must be allocated in dq[8:0] or dq[26:18] allocated

byte lane. Similarly dm[1] must be allocated in dq[17:9] or dq[35:27]
allocated byte group. dq must be placed on one of the pins from N2 to N11 in
the byte lane.

c. dk/dk_n must be allocated to any P-N pair in the same byte lane as ck/ck_n in the
address/control bank.
Note: Pin 12 is not part of a pin pair and must not be used for differential clocks.
d. qvld (x18 device) or qvld0 (x36 device) must be placed on one of the pins from N2
to N12 in the qk0 or qk1 data byte lane. qvld1 (x36 device) must be placed on one
of the pins from N2 to N12 in of the qk2 or qk3 data byte lane.
2. Byte lanes are configured as either data or address/control.
a. Pin N12 can be used for address/control in a data byte lane.
b. No data signals (qvalid, dq, dm) can be placed in an address/control byte lane.
3. Address/control can be on any of the 13 pins in the address/control byte lanes. Address/
control must be contained within the same bank.
4. One vrp pin per bank is used and a DCI is required for the interfaces. A vrp pin is
required in I/O banks containing inputs as well as output only banks. It is required in
output only banks because address/control signals use SSTL12_DCI to enable usage of
controlled output impedance. A DCI cascade is not permitted. All rules for the DCI in the
UltraScale Architecture FPGAs SelectIO Resources User Guide (UG571) [Ref 3] must be
followed.
5. ck must be on the PN pair in the Address/Control byte lane.
6. reset_n can be on any pin as long as FPGA logic timing is met and I/O standard can be
accommodated for the chosen bank (SSTL12).
7. Banks can be shared between two controllers.
a. Each byte lane is dedicated to a specific controller (except for reset_n).
b. Byte lanes from one controller cannot be placed inside the other. For example, with
controllers A and B, AABB is allowed, while ABAB is not.
8. All I/O banks used by the memory interface must be in the same column.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

273

Chapter 18: Designing with the Core

9. All I/O banks used by the memory interface must be in the same SLR of the column for
the SSI technology devices.
10. Maximum height of interface is three contiguous banks for 72-bit wide interface.
11. Bank skipping is not allowed.
12. The input clock for the MMCM in the interface must come from the a GCIO pair in the
I/O column used for the memory interface. For more information, see Clocking,
page 267.
13. There are dedicated V REF pins (not included in the rules above). If an external V REF is not
used, the V REF pins must be pulled to ground by a resistor value specified in the
UltraScale Architecture FPGAs SelectIO Resources User Guide (UG571) [Ref 3]. These
pins must be connected appropriately for the standard in use.
14. The interface must be contained within the same I/O bank type (High Range or High
Performance). Mixing bank types is not permitted with the exceptions of the reset_n
in step 6 and the input clock mentioned in step 11.

RLDRAM 3 Pinout Examples

IMPORTANT: Due to the calibration stage, there is no need for set_input_delay/
set_output_delay on the RLDRAM 3. Ignore the unconstrained inputs and outputs for RLDRAM 3
and the signals which are calibrated.

Table 18-1 shows an example of an 18-bit RLDRAM 3 interface contained within one bank.
This example is for a component interface using one x18 RLDRAM3 component with
Address Multiplexing.
Table 18-1:
Bank

18-Bit RLDRAM 3 Interface Contained in One Bank

Signal Name

Byte Group

I/O Type

Special Designation

qvld0

T3U_12

dq8

T3U_11

dq7

T3U_10

dq6

T3U_9

dq5

T3U_8

dq4

T3U_7

DBC-N

dq3

T3U_6

DBC-P

dq2

T3L_5

dq1

T3L_4

dq0

T3L_3

dm0

T3L_2

qk0_n

T3L_1

DBC-N

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

274

Chapter 18: Designing with the Core

Table 18-1:
Bank

18-Bit RLDRAM 3 Interface Contained in One Bank (Contd)

Signal Name

Byte Group

I/O Type

Special Designation

qk0_p

T3L_0

DBC-P

reset_n

T2U_12

we#

T2U_11

a18

T2U_10

a17

T2U_9

a14

T2U_8

a13

T2U_7

QBC-N

a10

T2U_6

QBC-P

a9

T2L_5

a8

T2L_4

a5

T2L_3

a4

T2L_2

a3

T2L_1

QBC-N

a0

T2L_0

QBC-P

T1U_12

ba3

T1U_11

ba2

T1U_10

ba1

T1U_9

ba0

T1U_8

dk1_n

T1U_7

QBC-N

dk1_p

T1U_6

QBC-P

dk0_n

T1L_5

dk0_p

T1L_4

ck_n

T1L_3

ck_p

T1L_2

ref_n

T1L_1

QBC-N

cs_n

T1L_0

QBC-P

vrp

T0U_12

dq17

T0U_11

dq16

T0U_10

dq15

T0U_9

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

275

Chapter 18: Designing with the Core

Table 18-1:
Bank

18-Bit RLDRAM 3 Interface Contained in One Bank (Contd)

Signal Name

Byte Group

I/O Type

Special Designation

dq14

T0U_8

dq13

T0U_7

DBC-N

dq12

T0U_6

DBC-P

dq11

T0L_5

dq10

T0L_4

dq9

T0L_3

dm1

T0L_2

qk1_n

T0L_1

DBC-N

qk1_p

T0L_0

DBC-P

Protocol Description
This core has the following interfaces:

Memory Interface

User Interface

Physical Interface

Memory Interface
The RLDRAM 3 core is customizable to support several configurations. The specific
configuration is defined by Verilog parameters in the top-level of the core.

User Interface
The user interface connects to an FPGA user design to the RLDRAM 3 core to simplify
interactions between the user design and the external memory device.

Command Request Signals

The user interface provides a set of signals used to issue a read or write command to the
memory device. These signals are summarized in Table 18-2.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

276

Chapter 18: Designing with the Core

Table 18-2:

User Interface Request Signals

Signal

Direction Description

user_cmd_en

Input

Command Enable. This signal issues a read or

write request and indicates that the
corresponding command signals are valid.

user_cmd[2 CMD_PER_CLK 1:0]

Input

Command. This signal issues a read, write, or

NOP request. When user_cmd_en is asserted:
2b00 = Write Command
2b01 = Read Command
2b10 = NOP
2b11 = NOP
The NOP command is useful when more than
one command per clock cycle must be
provided to the Memory Controller yet not all
command slots are required in a given clock
cycle. The Memory Controller acts on the
other commands provided and ignore the
NOP command. NOP is not supported when
CMD_PER_CLK == 1. CMD_PER_CLK is a
top-level parameter used to determine how
many memory commands are provided to the
controller per FPGA logic clock cycle, it
depends on nCK_PER_CLK and the burst
length (see Figure 18-2)

user_addr[CMD_PER_CLK ADDR_WIDTH 1:0]

Input

Command Address. This is the address to use

for a command request. It is valid when
user_cmd_en is asserted.

user_ba[CMD_PER_CLK BANK_WIDTH 1:0]

Input

Command Bank Address. This is the address

to use for a write request. It is valid when
user_cmd_en is asserted.

user_wr_en

Input

Write Data Enable. This signal issues the write

data and data mask. It indicates that the
corresponding user_wr_* signals are valid.

Input

Write Data. This is the data to use for a write

request and is composed of the rise and fall
data concatenated together. It is valid when
user_wr_en is asserted.

user_wr_dm[2 nCK_PER_CLK DM_WIDTH 1:0]

Input

Write Data Mask. When active-High, the write

data for a given selected device is masked
and not written to the memory. It is valid
when user_wr_en is asserted.

user_afifo_empty

Output

Address FIFO empty. If asserted, the

command buffer is empty.

user_wdfifo_empty

Output

Write Data FIFO empty. If asserted, the write

data buffer is empty.

user_afifo_full

Output

Address FIFO full. If asserted, the command

buffer is full, and any writes to the FIFO are
ignored until deasserted.

user_wr_data[2 nCK_PER_CLK DATA_WIDTH 1:0]

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

277

Chapter 18: Designing with the Core

Table 18-2:

User Interface Request Signals (Contd)

Signal

Direction Description

user_wdfifo_full

Output

Write Data FIFO full. If asserted, the write data

buffer is full, and any writes to the FIFO are
ignored until deasserted.

user_afifo_aempty

Output

Address FIFO almost empty. If asserted, the

command buffer is almost empty.

user_afifo_afull

Output

Address FIFO almost full. If asserted, the

command buffer is almost full.

user_wdfifo_aempty

Output

Write Data FIFO almost empty. If asserted, the

write data buffer is almost empty.

user_wdfifo_afull

Output

Write Data FIFO almost full. If asserted, the

Write Data buffer is almost full.

user_rd_valid[CMD_PER_CLK 1:0]

Output

Read Valid. This signal indicates that data

read back from memory is available on
user_rd_data and should be sampled.

user_rd_data[2 nCK_PER_CLK DATA_WIDTH 1:0]

Output

Read Data. This is the data read back from the

read command.

init_calib_complete

Output

Calibration Done. This signal indicates back to

the user design that read calibration is
complete and requests can now take place.

cx_rld3_ui_clk

Output

This User Interface clock should be one

quarter of the RLDRAM3 clock.

cx_rld3_ui_clk_sync_rst

Output

This is the active-High user interface reset.

cx_calib_error

Output

When asserted indicates error during

calibration.

addn_ui_clkout1

Output

Additional clock outputs provided based on

user requirement.

addn_ui_clkout2

Output

Additional clock outputs provided based on

user requirement.

addn_ui_clkout3

Output

Additional clock outputs provided based on

user requirement.

addn_ui_clkout4

Output

Additional clock outputs provided based on

user requirement.

dbg_clk

Output

Debug Clock. Do not connect any signals to

dbg_clk and keep the port open during
instantiation.

Interfacing with the Core through the User Interface

The width of certain user interface signals is dependent on the system clock frequency and
the burst length. This allows the client to send multiple commands per FPGA logic clock
cycle as might be required for certain configurations.
Note: Both write and read commands in the same user_cmd cycle is not allowed.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

278

Chapter 18: Designing with the Core

Figure 18-2 shows the user_cmd signal and how it is made up of multiple commands
depending on the configuration.
X-Ref Target - Figure 18-2

)3*$/RJLF&ORFN

VW

QG

5/'5$0%/ XVHUBFPG

^`

^`

5/'5$0%/ XVHUBFPG

^`

^`

5/'5$0%/ XVHUBFPG

Figure 18-2:

Multiple Commands for user_cmd Signal

As shown in Figure 18-2, four command slots are present in a single user interface clock
cycle for BL2. Similarly, two command slots are present in a single user interface clock cycle
for BL4. These command slots are serviced sequentially and the return data for read
commands are presented at the user interface in the same sequence. Note that the read
data might not be available in the same slot as that of its read command. The slot of a read
data is determined by the timing requirements of the controller and its command slot. One
such example is mentioned in the following BL2 design configuration.
Assume that the following set of commands is presented at the user interface for a given
user interface cycle.
Table 18-3:

Command Set in User Interface Cycle

Slots

Commands

RD0

NOP

RD1

NOP

It is not guaranteed that the read data appears in {DATA0, NOP, DATA1, NOP} order. It might
also appear in {NOP, DATA0, NOP, DATA1} or {NOP, NOP, DATA0, DATA1} etc. orders. In any
case, the sequence of the commands are maintained.

User Address Bit Allocation Based on RLDRAM 3 Configuration

The width of the address bus (not including bank address bits) at the user interface is always
set in the multiple of 20 bits, which accounts for the maximum possible address width for
RLDRAM 3 device. Depending on the RLDRAM 3 device configuration, the actual address
width can be < 20 bits. Table 18-4 summarizes the address width for the various RLDRAM 3
configurations.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

279

Chapter 18: Designing with the Core

The address bits at the user interface are concatenated based on the burst length as shown
in Figure 18-2. If the address width is < 20 bits, pad the unused bits with zero. An example
for x36 burst length 4 configuration is shown here:
{00, (18-bit address), 00, (18-bit address)}
Table 18-4:

RLDRAM 3 Address Width

Burst Length RLDRAM 3 Device

Data Width

Address Width at
RLDRAM 3 Interface

Address Width at User

Interface

18

20

{20, 20, 20, 20}

36

19

({0, 19}, {0, 19}, {0, 19}, {0, 19})

18

19

({00, 19}, {00, 19})

36

18

({00, 18}, {00, 18})

18

18

({00, 18})

36

Not supported by
RLDRAM 3

N/A

Notes:
1. Two device configurations (2x18, 2x36) follow the same address mapping as one device configuration
mentioned.
2. For multiplexed address configurations, the address width at the User interface is identical to the
non-multiplex mode.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

280

Chapter 18: Designing with the Core

The user interface protocol for the RLDRAM 3 four-word burst architecture is shown in
Figure 18-3.
X-Ref Target - Figure 18-3

#,+

USER?CMD?EN
USER?CMD

[WRITE
WRITE]

[READ
READ]

[./0
READ]

[READ
./0]

[WRITE
./0]

[./0
WRITE]

USER?ADDR

[!!]

[!!]

[./0
!]

[!
./0]

[!
./0]

[./0
!]

["!
"!]

["!
"!]

[./0
"!]

["!
./0]

["!
./0]

[./0
!]

USER?BA

USER?WR?EN

USER?WR?DATA

USER?WR?DM

[FALL
RISE
FALL
RISE

FALL
RISE

FALL
RISE]

[FALL
RISE
FALL
RISE
./0
./0
./0
./0]

[FALL
RISE
FALL
RISE
FALL
RISE
FALL
RISE]

[FALL
RISE
FALL
RISE
./0
./0
./0
./0]

[./0
./0
./0
./0
FALL
RISE
FALL
RISE]

[./0
./0
./0
./0
FALL
RISE
FALL
RISE]

[./0
./0
./0
./0
FALL
RISE
FALL
RISE]

[./0
./0
./0
./0
FALL
RISE
FALL
RISE]

USER?AFIFO?FULL

USER?WDFIFO?FULL
8

Figure 18-3:

RLDRAM 3 User Interface Protocol (Four-Word Burst Architecture)

Before any requests can be accepted, the ui_clk_sync_rst signal must be deasserted
Low. After the ui_clk_sync_rst signal is deasserted, the user interface FIFOs can accept
commands and data for storage. The init_calib_complete signal is asserted after the
memory initialization procedure and PHY calibration are complete, and the core can begin
to service client requests.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

281

Chapter 18: Designing with the Core

A command request is issued by asserting user_cmd_en as a single cycle pulse. At this
time, the user_cmd, user_addr, and user_ba signals must be valid. To issue a read
request, user_cmd is set to 2b01, while for a write request, user_cmd is set to 2'b00. For
a write request, the data is to be issued in the same cycle as the command by asserting the
user_wr_en signal High and presenting valid data on user_wr_data and user_wr_dm.
The user interface protocol for the RLDRAM 3 eight-word burst architecture is shown in
Figure 18-4.
X-Ref Target - Figure 18-4

#,+

USER?CMD?EN

USER?CMD

WRITE

WRITE

READ

WRITE

READ

READ

USER?ADDR

!

!

!

!

!

!

"!

"!

"!

"!

"!

"!

[FALL
RISE
FALL
RISE
FALL
RISE
FALL
RISE]

[FALL
RISE
FALL
RISE
FALL
RISE
FALL
RISE]

[FALL
RISE
FALL
RISE
FALL
RISE
FALL
RISE]

[FALL
RISE
FALL
RISE
FALL
RISE
FALL
RISE]

[FALL
RISE
FALL
RISE
FALL
RISE
FALL
RISE]

[FALL
RISE
FALL
RISE
FALL
RISE
FALL
RISE]

USER?BA

USER?WR?EN

USER?WR?DATA

USER?WR?DM

USER?AFIFO?FULL

USER?WDFIFO?FULL

8

Figure 18-4:

RLDRAM 3 User Interface Protocol (Eight-Word Burst Architecture)

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

282

Chapter 18: Designing with the Core

When a read command is issued some time later (based on the configuration and latency of
the system), the user_rd_valid[0] signal is asserted, indicating that user_rd_data is
now valid, while user_rd_valid[1] is asserted indicating that user_rd_data is valid,
as shown in Figure 18-5. The read data should be sampled on the same cycle that
user_rd_valid[0] and user_rd_valid[1] are asserted because the core does not
buffer returning data. This functionality can be added in, if desired.
The Memory Controller only puts commands on certain slots to the PHY such that the
user_rd_valid signals are all asserted together and return the full width of data, but the
extra user_rd_valid signals are provided in case of controller modifications.
X-Ref Target - Figure 18-5

#,+
USER?RD?VALID;=
USER?RD?VALID;=
USER?RD?DATA

[FALLRISEFALLRISE]

[FALLRISEFALLRISE]

[FALLRISEFALLRISE]

[$.#$.#FALLRISE]

[FALLRISE$.#$.#]

5'?C??

Figure 18-5:

User Interface Protocol Read Data

Physical Interface
The physical interface is the connection from the FPGA core to an external RLDRAM 3
device. The I/O signals for this interface are defined in Table 18-5. These signals can be
directly connected to the corresponding signals on the RLDRAM 3 device.
Table 18-5:

Physical Interface Signals

Signal

Direction

Description

rld_ck_p

Output

System Clock CK. This is the address/command clock to the memory device.

rld_ck_n

Output

System Clock CK#. This is the inverted system clock to the memory device.

rld_dk_p

Output

Write Clock DK. This is the write clock to the memory device.

rld_dk_n

Output

Write Clock DK#. This is the inverted write clock to the memory device.

rld_a

Output

Address. This is the address supplied for memory operations.

rld_ba

Output

Bank Address. This is the bank address supplied for memory operations.

rld_cs_n

Output

Chip Select CS#. This is the active-Low chip select control signal for the
memory.

rld_we_n

Output

Write Enable WE#. This is the active-Low write enable control signal for the
memory.

rld_ref_n

Output

Refresh REF#. This is the active-Low refresh control signal for the memory.

rld_dm

Output

Data Mask DM. This is the active-High mask signal, driven by the FPGA to
mask data that a user does not want written to the memory during a write
command.

rld_dq

Input/Output

Data DQ. This is a bidirectional data port, driven by the FPGA for writes and
by the memory for reads.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

283

Chapter 18: Designing with the Core

Table 18-5:

Physical Interface Signals (Contd)

Signal

Direction

Description

rld_qk_p

Input

Read Clock QK. This is the read clock returned from the memory edge aligned
with read data on rld_dq. This clock (in conjunction with QK#) is used by the
PHY to sample the read data on rld_dq.

rld_qk_n

Input

Read Clock QK#. This is the inverted read clock returned from the memory.
This clock (in conjunction with QK) is used by the PHY to sample the read
data on rld_dq.

rld_reset_n

Output

RLDRAM 3 reset pin. This is the active-Low reset to the RLDRAM 3 device.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

284

Chapter 19

Design Flow Steps

This chapter describes customizing and generating the core, constraining the core, and the
simulation, synthesis and implementation steps that are specific to this IP core. More
detailed information about the standard Vivado design flows and the Vivado IP integrator
can be found in the following Vivado Design Suite user guides:

Vivado Design Suite User Guide: Designing IP Subsystems using IP Integrator (UG994)
[Ref 8]

Vivado Design Suite User Guide: Designing with IP (UG896) [Ref 9]

Vivado Design Suite User Guide: Getting Started (UG910) [Ref 10]

Vivado Design Suite User Guide: Logic Simulation (UG900) [Ref 11]

Customizing and Generating the Core

CAUTION! The Windows operating system has a 260-character limit for path lengths, which can affect
the Vivado tools. To avoid this issue, use the shortest possible names and directory locations when
creating projects, defining IP or managed IP projects, and creating block designs.

This section includes information about using Xilinx tools to customize and generate the
core in the Vivado Design Suite.
If you are customizing and generating the core in the IP integrator, see the Vivado Design
Suite User Guide: Designing IP Subsystems using IP Integrator (UG994) [Ref 8] for detailed
information. IP integrator might auto-compute certain configuration values when
validating or generating the design. To check whether the values change, see the
description of the parameter in this chapter. To view the parameter value, run the
validate_bd_design command in the Tcl Console.
You can customize the IP for use in your design by specifying values for the various
parameters associated with the IP core using the following steps:
1. Select the IP from the Vivado IP catalog.
2. Double-click the selected IP or select the Customize IP command from the toolbar or
right-click menu.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

285

Chapter 19: Design Flow Steps

For more information about generating the core in Vivado, see the Vivado Design Suite User
Guide: Designing with IP (UG896) [Ref 9] and the Vivado Design Suite User Guide: Getting
Started (UG910) [Ref 10].
Note: Figures in this chapter are illustrations of the Vivado Integrated Design Environment (IDE).
This layout might vary from the current version.

Basic Tab
Figure 19-1 shows the Basic tab when you start up the QDR II+ SRAM.
X-Ref Target - Figure 19-1

Figure 19-1:

Vivado Customize IP Dialog Box Basic Tab

IMPORTANT: All parameters shown in the controller options dialog box are limited selection options in

this release.

For the Vivado IDE, all controllers (DDR3, DDR4, QDR II+, and RLDRAM 3) can be created
and available for instantiation.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

286

Chapter 19: Design Flow Steps

1. Select the settings in the Clocking, Controller Options, and Memory Options.
In Clocking, the Memory Device Interface Speed sets the speed of the interface. The
speed entered drives the available Reference Input Clock Speeds. For more
information on the clocking structure, see the Clocking, page 267.
2. To use memory parts which are not available by default through the RLDRAM 3 SDRAM
Vivado IDE, you can create a custom parts CSV file, as specified in the AR: 63462. This
CSV file has to be provided after enabling the Custom Parts Data File option. After
selecting this option. you are able to see the custom memory parts along with the
default memory parts. Note that, simulations are not supported for the custom part.
IMPORTANT: Data Mask (DM) option is always selected for AXI designs and is grayed out (you cannot
select it). For AXI interfaces, Read Modify Write (RMW) is supported and for RMW to mask certain bytes
of Data Mask bits should be present. Therefore, the DM is always enabled for AXI interface designs. This
is the case for all data widths except 72-bit.
For 72-bit interfaces, ECC is enabled and DM is deselected and grayed out for 72-bit designs. If DM is
enabled for 72-bit designs, computing ECC does is not compatible, so DM is disabled for 72-bit designs.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

287

Chapter 19: Design Flow Steps

Advanced Tab
Figure 19-2 shows the next tab called Advanced. This displays the settings for FPGA
Options, Debug Signals for Controller, Simulation Options, and Clock Options for the
specific controller.
X-Ref Target - Figure 19-2

Figure 19-2:

Vivado Customize IP Dialog Box Advanced

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

288

Chapter 19: Design Flow Steps

RLDRAM 3 SDRAM Design Checklist Tab

Figure 19-3 shows the RLDRAM 3 SDRAM Design Checklist usage information.
X-Ref Target - Figure 19-3

Figure 19-3:

Vivado Customize IP Dialog Box Design Checklist Tab

User Parameters
Table 19-1 shows the relationship between the fields in the Vivado IDE and the User
Parameters (which can be viewed in the Tcl Console).
Table 19-1:

Vivado IDE Parameter to User Parameter Relationship

Vivado IDE Parameter/Value(1)

User Parameter/Value(1)

Default Value

System Clock Configuration

System_Clock

Differential

Internal V REF

Internal_Vref

TRUE

DCI Cascade

DCI_Cascade

FALSE

Debug Signal for Controller

Debug_Signal

Disable

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

289

Chapter 19: Design Flow Steps

Table 19-1:

Vivado IDE Parameter to User Parameter Relationship (Contd)

Vivado IDE Parameter/Value(1)

User Parameter/Value(1)

Default Value

Clock 1 (MHz)

ADDN_UI_CLKOUT1_FREQ_HZ

None

Clock 2 (MHz)

ADDN_UI_CLKOUT2_FREQ_HZ

None

Clock 3 (MHz)

ADDN_UI_CLKOUT3_FREQ_HZ

None

Clock 4 (MHz)

ADDN_UI_CLKOUT4_FREQ_HZ

None

I/O Power Reduction

IOPowerReduction

OFF

Enable System Ports

Enable_SysPorts

TRUE

I/O Power Reduction

IO_Power_Reduction

FALSE

Default Bank Selections

Default_Bank_Selections

FALSE

Reference Clock

Reference_Clock

FALSE

Enable System Ports

Enable_SysPorts

TRUE

Clock Period (ps)

C0.RLD3_TimePeriod

1,071

Input Clock Period (ps)

C0.RLD3_InputClockPeriod

13,947

General Interconnect to Memory

Clock Ratio

C0.RLD3_PhyClockRatio

4:1

Configuration

C0.RLD3_MemoryType

Components

Memory Part

C0.RLD3_MemoryPart

MT44K16M36RB-093

Data Width

C0.RLD3_DataWidth

36

Data Mask

C0.RLD3_DataMask

TRUE

Burst Length

C0.RLD3_BurstLength

C0.RLD3_MemoryVoltage

1.2

Notes:
1. Parameter values are listed in the table where the Vivado IDE parameter value differs from the user parameter value. Such
values are shown in this table as indented below the associated parameter.

Output Generation
For details, see the Vivado Design Suite User Guide: Designing with IP (UG896) [Ref 9].

I/O Planning
For details on I/O planning, see I/O Planning, page 176.

Constraining the Core

This section contains information about constraining the core in the Vivado Design Suite, if
applicable.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

290

Chapter 19: Design Flow Steps

Required Constraints
Internal VREF is optional for RLDRAM 3. A sample constraint for RLDRAM 3 is shown here:
set_property INTERNAL_VREF 0.600 [get_iobanks 45]

Device, Package, and Speed Grade Selections

This section is not applicable for this IP core.

Clock Frequencies
This section is not applicable for this IP core.

Clock Management
For information on clocking, see Clocking, page 267.

Clock Placement
This section is not applicable for this IP core.

Banking
This section is not applicable for this IP core.

Transceiver Placement
This section is not applicable for this IP core.

I/O Standard and Placement

The RLDRAM 3 tool generates the appropriate I/O standards and placement based on the
selections made in the Vivado IDE for the interface type and options.
IMPORTANT: The set_input_delay and set_output_delay constraints are not needed on the
external memory interface pins in this design due to the calibration process that automatically runs at
start-up. Warnings seen during implementation for the pins can be ignored.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

291

Chapter 19: Design Flow Steps

Simulation
For comprehensive information about Vivado simulation components, as well as
information about using supported third-party tools, see the Vivado Design Suite User
Guide: Logic Simulation (UG900) [Ref 11].

Synthesis and Implementation

For details about synthesis and implementation, see the Vivado Design Suite User Guide:
Designing with IP (UG896) [Ref 9].

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

292

Chapter 20

Example Design
This chapter contains information about the example design provided in the Vivado
Design Suite.
Vivado supports Open IP Example Design flow. To create the example design using this flow,
right-click the IP in the Source Window, as shown in Figure 20-1 and select Open IP
Example Design.
X-Ref Target - Figure 20-1

Figure 20-1:

Open IP Example Design

This option creates a new Vivado project. Upon selecting the menu, a dialog box to enter
the directory information for the new design project opens.
Select a directory, or use the defaults, and click OK. This launches a new Vivado with all of
the example design files and a copy of the IP.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

293

Chapter 20: Example Design

Figure 20-2 shows the example design with the PHY only option selected (controller
module does not get generated).
X-Ref Target - Figure 20-2

Figure 20-2:

Open IP Example Design with PHY Only Option Selected

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

294

Chapter 20: Example Design

Figure 20-3 shows the example design with the PHY only option not selected (controller
module is generated).
X-Ref Target - Figure 20-3

Figure 20-3:

Open IP Example Design with PHY Only Option Not Selected

Simulating the Example Design (Designs with

Standard User Interface)
The example design provides a synthesizable test bench to generate a fixed simple data
pattern to the Memory Controller. This test bench consists of an IP wrapper and an
example_tb that generates 10 writes and 10 reads.
The example design can be simulated using one of the methods in the following sections.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

295

Chapter 20: Example Design

Project-Based Simulation
This method can be used to simulate the example design using the Vivado Integrated
Design Environment (IDE). Memory IP delivers memory models for RLDRAM 3.
The Vivado simulator, QuestaSim, IES, and VCS tools are used for RLDRAM 3. IP verification
at each software release. The Vivado simulation tool is used for RLDRAM 3. IP verification
from 2015.1 Vivado software release. The following subsections describe steps to run a
project-based simulation using each supported simulator tool.

Project-Based Simulation Flow Using Vivado Simulator

1. In the Open IP Example Design Vivado project, under Flow Navigator, select
Simulation Settings.
2. Select Target simulator as Vivado Simulator.
a. Under the Simulation tab, set the xsim.simulate.runtime to 1 ms (there are
simulation RTL directives which stop the simulation after certain period of time,
which is less than 1 ms) as shown in Figure 20-4. The Generate Scripts Only option
generates simulation scripts only. To run behavioral simulation, Generate Scripts
Only option must be de-selected.
3. Apply the settings and select OK.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

296

Chapter 20: Example Design

X-Ref Target - Figure 20-4

Figure 20-4:

Simulation with Vivado Simulator

4. In the Flow Navigator window, select Run Simulation and select Run Behavioral
Simulation option as shown in Figure 20-5.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

297

Chapter 20: Example Design

X-Ref Target - Figure 20-5

Figure 20-5:

Run Behavioral Simulation

5. Vivado invokes Vivado simulator and simulations are run in the Vivado simulator tool.
For more information, see the Vivado Design Suite User Guide: Logic Simulation (UG900)
[Ref 11].

Project-Based Simulation Flow Using QuestaSim

1. Open a RLDRAM 3 example Vivado project (Open IP Example Design...), then under
Flow Navigator, select Simulation Settings.
2. Select Target simulator as QuestaSim/ModelSim Simulator.
a. Browse to the compiled libraries location and set the path on Compiled libraries
location option.
b. Under the Simulation tab, set the modelsim.simulate.runtime to 1 ms (there
are simulation RTL directives which stop the simulation after certain period of time,
which is less than 1 ms) as shown in Figure 20-6. The Generate Scripts Only option
generates simulation scripts only. To run behavioral simulation, Generate Scripts
Only option must be de-selected.
3. Apply the settings and select OK.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

298

Chapter 20: Example Design

X-Ref Target - Figure 20-6

Figure 20-6:

Simulation with QuestaSim

4. In the Flow Navigator window, select Run Simulation and select Run
BehavioralSimulation option as shown in Figure 20-7.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

299

Chapter 20: Example Design

X-Ref Target - Figure 20-7

Figure 20-7:

Run Behavioral Simulation

5. Vivado invokes QuestaSim and simulations are run in the QuestaSim tool. For more
information, see the Vivado Design Suite User Guide: Logic Simulation (UG900) [Ref 11].

Project-Based Simulation Flow Using IES

1. Open a RLDRAM 3 example Vivado project (Open IP Example Design...), then under
Flow Navigator, select Simulation Settings.
2. Select Target simulator as Incisive Enterprise Simulator (IES).
a. Browse to the compiled libraries location and set the path on Compiled libraries
location option.
b. Under the Simulation tab, set the ies.simulate.runtime to 1 ms (there are
simulation RTL directives which stop the simulation after certain period of time,
which is less than 1 ms) as shown in Figure 20-8. The Generate Scripts Only option
generates simulation scripts only. To run behavioral simulation, Generate Scripts
Only option must be de-selected.
3. Apply the settings and select OK.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

300

Chapter 20: Example Design

X-Ref Target - Figure 20-8

Figure 20-8:

Simulation with IES Simulator

4. In the Flow Navigator window, select Run Simulation and select Run
BehavioralSimulation option as shown in Figure 20-7.
5. Vivado invokes IES and simulations are run in the IES tool. For more information, see the
Vivado Design Suite User Guide: Logic Simulation (UG900) [Ref 11].

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

301

Chapter 20: Example Design

Project-Based Simulation Flow Using VCS

1. Open a RLDRAM 3 example Vivado project (Open IP Example Design...), then under
Flow Navigator, select Simulation Settings.
2. Select Target simulator as Verilog Compiler Simulator (VCS).
a. Browse to the compiled libraries location and set the path on Compiled libraries
location option.
b. Under the Simulation tab, set the vcs.simulate.runtime to 1 ms (there are
simulation RTL directives which stop the simulation after certain period of time,
which is less than 1 ms) as shown in Figure 20-9. The Generate Scripts Only option
generates simulation scripts only. To run behavioral simulation, Generate Scripts
Only option must be de-selected.
3. Apply the settings and select OK.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

302

Chapter 20: Example Design

X-Ref Target - Figure 20-9

Figure 20-9:

Simulation with VCS Simulator

4. In the Flow Navigator window, select Run Simulation and select Run
BehavioralSimulation option as shown in Figure 20-7.
5. Vivado invokes VCS and simulations are run in the VCS tool. For more information, see
the Vivado Design Suite User Guide: Logic Simulation (UG900) [Ref 11].

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

303

Chapter 20: Example Design

Simulation Speed
RLDRAM 3 provides a Vivado IDE option to reduce the simulation speed by selecting
behavioral XIPHY model instead of UNISIM XIPHY model. Behavioral XIPHY model
simulation is a default option for RLDRAM 3 designs. To select the simulation mode, click
the Advanced tab and find the Simulation Options as shown in Figure 20-10.
X-Ref Target - Figure 20-10

Figure 20-10:

Advanced Tab Simulation Options

The SIM_MODE parameter in the RTL is given a different value based on the Vivado IDE
selection.

SIM_MODE = BFM If fast mode is selected in the Vivado IDE, the RTL parameter
reflects this value for the SIM_MODE parameter. This is the default option.

SIM_MODE = FULL If FULL mode is selected in the Vivado IDE, XIPHY UNISIMs are
selected and the parameter value in the RTL is FULL.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

304

Chapter 20: Example Design

CLOCK_DEDICATED_ROUTE Constraints and BUFG

Instantiation
If the GCIO pin and MMCM are not allocated in the same bank, the
CLOCK_DEDICATED_ROUTE constraint must be set to BACKBONE. To use the BACKBONE
route, BUFG/BUFGCE/BUFGCTRL/BUFGCE_DIV must be instantiated between GCIO and
MMCM input. RLDRAM 3 manages these constraints for designs generated with the
Reference Input Clock option selected as Differential (at Advanced > FPGA Options >
Reference Input). Also, RLDRAM 3 handles the IP and example design flows for all
scenarios.
If the design is generated with the Reference Input Clock option selected as No Buffer (at
Advanced > FPGA Options > Reference Input), the CLOCK_DEDICATED_ROUTE
constraints and BUFG/BUFGCE/BUFGCTRL/BUFGCE_DIV instantiation based on GCIO and
MMCM allocation needs to be handled manually for the IP flow. RLDRAM 3 does not
generate clock constraints in the XDC file for No Buffer configurations and you must take
care of the clock constraints for No Buffer configurations for the IP flow.
For an example design flow with No Buffer configurations, RLDRAM 3 generates the
example design with differential buffer instantiation for system clock pins. RLDRAM 3
generates clock constraints in the example_design.xdc. It also generates a
CLOCK_DEDICATED_ROUTE constraint as the BACKBONE and instantiates BUFG/BUFGCE/
BUFGCTRL/BUFGCE_DIV between GCIO and MMCM input if the GCIO and MMCM are not in
same bank to provide a complete solution. This is done for the example design flow as a
reference when it is generated for the first time.
If in the example design, the I/O pins of the system clock pins are changed to some other
pins with the I/O pin planner, the CLOCK_DEDICATED_ROUTE constraints and BUFG/
BUFGCE/BUFGCTRL/BUFGCE_DIV instantiation need to be managed manually. A DRC error
is reported for the same.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

305

Chapter 21

Test Bench
This chapter contains information about the test bench provided in the Vivado Design
Suite.
The Memory Controller is generated along with a simple test bench to verify the basic read
and write operations. The stimulus contains 10 consecutive writes followed by 10
consecutive reads for data integrity check.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

306

SECTION V: TRAFFIC GENERATOR

Traffic Generator

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

307

Chapter 22

Traffic Generator
Overview
This section describes the setup and behavior of the Traffic Generator. In the UltraScale
architecture, Traffic Generator is instantiated in the example design (example_top.sv) to
drive the memory design through the application interface (Figure 22-1).
X-Ref Target - Figure 22-1

$SSOLFDWLRQ
,QWHUIDFH
DSSBHQDSSBFPG
DSSBDGGUDSSBZGIBGDWD
DSSBZGIBZUHQ

0HPRU\,3

7UDIILF*HQHUDWRU

DSSBUG\DSSBZGIBUG\
DSSBUGBGDWDBYDOLG
DSSBUGBGDWD


Figure 22-1:

Traffic Generator and Application Interface

Two Traffic Generators are available to drive the memory design and they include:

Simple Traffic Generator

Advanced Traffic Generator

By default, Vivado connects the memory design to the Simple Traffic Generator. You can
choose to use the Advanced Traffic Generator by defining a switch HW_TG_EN in the
example_top.sv. The Simple Traffic Generator is referred to as STG and the Advanced
Traffic Generator is referred to as ATG for the remainder of this section.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

308

Chapter 22: Traffic Generator

Simple Traffic Generator

Memory IP generates the STG modules as example_tb for native interface and
example_tb_phy for PHY only interface. The STG native interface generates 100 writes
and 100 reads. The STG PHY only interface generates 10 writes and 10 reads. Both address
and data increase linearly. Data check is performed during reads. Data error is reported
using the compare_error signal.

Advanced Traffic Generator

The ATG is only supported for the user interface. When HW_TG_EN is defined, ATG is set
to the default setting. To enable ATG (for both simulations and implementation), add
`define HW_TG_EN in the example_top module. The ATG could be programmed
differently to test memory interface with different traffic patterns. In the example design
created by Vivado, the ATG is set to default setting which is described in the next section.
The default setting is recommended for most to get started. For further information on ATG
programming, see the Traffic Generator Description section.
After memory initialization and calibration are done, the ATG starts sending write
commands and read commands. If the memory read data does not match with the expected
read data, the ATG flags compare errors through the status interface. For VIO or ILA debug,
you have the option to connect status interface signals.

Traffic Generator Default Behavior

The ATG default control connectivity in the example design created by Vivado is listed in
Table 22-1.
Note: Application interface signals are not shown in this table. See the corresponding memory
section for application interface address/data width.

Table 22-1:

Default Traffic Generator Control Connection

Signal

I/O

Width

Description

clk

Traffic Generator Clock

Traffic Generator
Clock

rst

Traffic Generator Reset

Traffic Generator
Reset

init_calib_complete

Calibration Complete

Calibration
Complete

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Default Value

Send Feedback

309

Chapter 22: Traffic Generator

Table 22-1:

Default Traffic Generator Control Connection (Contd)

Signal

I/O

Width

Description

Default Value

Enable traffic generator to proceed from

"START" state to "LOAD" state after calibration
completes.
If you do not plan to program instruction table
or PRBS data seed, tie this signal to 1'b1.
If you plan to program instruction table or PRBS
data seed, set this bit to 0 during reset. After
reset deassertion and done with instruction/
seed programming, set this bit to 1 to start
traffic generator.

Reserved signal.
Tie to 1'b1.

Reset traffic generator (synchronous reset, level

sensitive).
If there is outstanding traffic in memory
pipeline, assert signal long enough until all
outstanding transactions have completed.

Reserved signal.
Tie to 0.

Reserved signal.
Tie to 0.

General Control

vio_tg_start

vio_tg_rst

vio_tg_restart

Restart traffic generator after generator is done

with traffic, paused or stopped with error (level
sensitive).
If there is outstanding traffic in memory
pipeline, assert signal long enough until all
outstanding transactions have completed.

vio_tg_pause

Pause traffic generator (level sensitive).

Reserved signal.
Tie to 0.

If enabled, stop after first error detected. Read

test is performed to determine whether "READ"
or "WRITE" error occurred. If not enabled,
continue traffic without stop.

Reserved signal.
Tie to 0.

Clear all error excluding sticky error bit (positive

edge sensitive).
Only use this signal when vio_tg_status_state is
either TG_INSTR_ERRDONE or TG_INSTR_PAUSE.

Reserved signal.
Tie to 0.

Reserved signal.
Tie to 0.

Reserved signal.
Tie to 0.

vio_tg_err_chk_en

vio_tg_err_clear

vio_tg_err_clear_all

Clear all error including sticky error bit (positive

edge sensitive).
Only use this signal when vio_tg_status_state is
either TG_INSTR_ERRDONE or TG_INSTR_PAUSE.

vio_tg_err_continue

Continue traffic after error(s) at

TG_INSTR_ERRDONE state (positive edge
sensitive).

Instruction Table Programming

vio_tg_direct_instr_
en

0 = Traffic Table Mode Traffic Generator uses

traffic patterns programmed in 32-entry Traffic
table
1 = Direct Instruction Mode Traffic Generator
uses current traffic pattern presented at VIO
interface

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Reserved signal.
Tie to 0.

Send Feedback

310

Chapter 22: Traffic Generator

Table 22-1:

Default Traffic Generator Control Connection (Contd)

Signal

I/O

Width

vio_tg_instr_
program_en

Enable instruction table programming (level

sensitive).

Reserved signal.
Tie to 0.

vio_tg_instr_num

Instruction number to be programmed.

Reserved signal.
Tie to 0.

vio_tg_instr_addr_
mode

vio_tg_instr_data_
mode

vio_tg_instr_rw_
mode

vio_tg_instr_rw_
submode

Description

Default Value

Address mode to be programmed.

0 = LINEAR; (with user-defined start address)
1 = PRBS; (PRBS supported range from 8 to 34
based on address width)
2= WALKING1
3 = WALKING0
4-15 = Reserved

Reserved signal.
Tie to 0.

Data mode to be programmed.

0 = LINEAR
1 = PRBS (PRBS supported 8, 10, 23)
2 = WALKING1
3 = WALKING0
4 = HAMMER1
5 = HAMMER0
6 = Block RAM
7 = CAL_CPLX (Must be programmed along with
victim mode CAL_CPLX)
8-15 = Reserved

Reserved signal.
Tie to 0.

0 = Read Only (No data check)

1 = Write Only (No data check)
2 = Write/Read (Read performs after Write and
data value is checked against expected write
data. For QDR II+ SRAM, one port is used for
write and another port is used for read.)
3 = Write once and Read forever (Data check on
Read data)
4-15 = Reserved

Reserved signal.
Tie to 0.

Read/Write submode to be programmed.

This is a submode option when
vio_tg_instr_rw_mode is set to "WRITE_READ"
mode.
This mode is only valid for DDR3/DDR4 and
RLDRAM 3. For QDR II+ SRAM interface, this
mode should be set to 0.
WRITE_READ = 0; // Send all Write commands
follow by Read commands defined in the
instruction.
WRITE_READ_SIMULTANEOUSLY = 1; // Send
Write and Read commands pseudo-randomly.
Note that Write is always ahead of Read.

Reserved signal.
Tie to 0.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

311

Chapter 22: Traffic Generator

Table 22-1:

Default Traffic Generator Control Connection (Contd)

Signal

vio_tg_instr_victim_
mode

vio_tg_instr_victim_
aggr_delay

I/O

Width

Description

Default Value

Victim mode to be programmed.

One victim bit could be programmed using
global register vio_tg_victim_bit. The rest of the
bits on signal bus are considered to be
aggressors.
The following program options define aggressor
behavior:
NO_VICTIM = 0;
HELD1 = 1; // All aggressor signals held at 1
HELD0 = 2; // All aggressor signals held at 0
NONINV_AGGR = 3; // All aggressor signals
are same as victim
INV_AGGR = 4; // All aggressor signals are
inversion of victim
DELAYED_AGGR = 5; // All aggressor signals
are delayed version of victim (num of cycle of
delay is programmed at
vio_tg_victim_aggr_delay)
DELAYED_VICTIM = 6; // Victim signal is
delayed version of all aggressors
CAL_CPLX = 7; Complex Calibration pattern
(Must be programed along with Data Mode
CAL_CPLX)

Reserved signal.
Tie to 0.

Define aggressor/victim pattern to be N-delay

cycle of victim/aggressor, where 0 N 24.
It is used when victim mode "DELAY_AGGR" or
"DELAY VICTIM" mode is used in traffic pattern.

Reserved signal.
Tie to 0.

Reserved signal.
Tie to 0.

vio_tg_instr_victim_
select

Victim bit behavior programmed.

VICTIM_EXTERNAL = 0; // Use Victim bit
provided in vio_tg_glb_victim_bit
VICTIM_ROTATE4 = 1; // Victim bit rotates from
Bits[3:0] for every Nibble
VICTIM_ROTATE8 = 2; // Victim bit rotates from
Bits[7:0] for every Byte
VICTIM_ROTATE_ALL = 3; // Victim bit rotates
through all bits

vio_tg_instr_num_of
_iter

32

Number of Read/Write commands to issue

(number of issue must be > 0 for each
instruction programmed).

Reserved signal.
Tie to 0.

10

M = Number of NOP cycles in between Read/

Write commands at user interface at general
interconnect clock
N = Number of Read/Write commands before
NOP cycle insertion at user interface at general
interconnect clock

Reserved signal.
Tie to 0.

vio_tg_instr_m_nops
_btw_n_burst_m

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

312

Chapter 22: Traffic Generator

Table 22-1:

Default Traffic Generator Control Connection (Contd)

Signal

vio_tg_instr_m_nops
_btw_n_burst_n

vio_tg_instr_nxt_
instr

I/O

Width

Description

Default Value

32

M = Number of NOP cycles in between Read/

Write commands at user interface at general
interconnect clock
N = Number of Read/Write commands before
NOP cycle insertion at user interface at general
interconnect clock

Reserved signal.
Tie to 0.

Next instruction to run.

To end traffic, next instruction should point at
EXIT instruction.
6b000000-6b011111 valid instruction
6b1????? EXIT instruction

Reserved signal.
Tie to 0.

PRBS Data Seed Programming

vio_tg_seed_
program_en

0 = Traffic Table Mode Traffic Generator uses

traffic patterns programmed in 32-entry Traffic
table
1 = Direct Instruction Mode Traffic Generator
uses current traffic pattern presented at VIO
interface

vio_tg_seed_num

Seed number to be programmed.

Reserved signal.
Tie to 0.

PRBS seed to be programmed for a selected

seed number (vio_tg_seed_num).
PRBS_DATA_WIDTH is by default 23.
PRBS_DATA_WIDTH can support 8, 10, and 23.

Reserved signal.
Tie to 0.

vio_tg_seed_data

PRBS DATA WIDTH

Reserved signal.
Tie to 0.

Global Registers
vio_tg_glb_victim_
bit

vio_tg_glb_start_ad
dr

APP_ADDR_WIDTH

Global register to define which bit in data bus is

victim. It is used when victim mode is used in traffic
pattern.

Reserved signal.
Tie to 0.

Global register to define Start address seed for

Linear Address Mode.

Reserved signal.
Tie to 0.

Error Status Registers

vio_tg_status_state

Traffic Generator state machine state.

vio_tg_status_err_
bit_valid

Error detected. It is used as trigger to detect read

error.

vio_tg_status_err_
bit

APP_DATA_WIDTH

Error bit mismatch. Bitwise mismatch pattern.

A '1' indicates error detected in that bit location.
Saturated counter that counts the number of
assertion of the signal vio_tg_status_err_bit_valid.
The counter is reset by vio_tg_err_clear and
vio_tg_err_clear_all.

vio_tg_status_err_
cnt

32

vio_tg_status_err_
addr

APP_ADDR_WIDTH

vio_tg_status_exp_
bit_valid

Error Address
Address location of failed read.
Expected read data valid.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

313

Chapter 22: Traffic Generator

Table 22-1:

Default Traffic Generator Control Connection (Contd)

Signal

I/O

Width

vio_tg_status_exp_
bit

APP_DATA_WIDTH

vio_tg_status_read_
bit_valid

vio_tg_status_read_
bit

APP_DATA_WIDTH

Description

Default Value

Expected read data.

Memory read data valid.
Memory read data.

vio_tg_status_first_
err_bit_valid

If vio_tg_err_chk_en is set to 1,
vio_tg_status_first_err_bit_valid is set to 1 when
first mismatch error is encountered.
This register is not overwritten until
vio_tg_err_clear, vio_tg_err_continue, and
vio_tg_restart is triggered.

vio_tg_status_first_
err_bit

APP_DATA_WIDTH

If vio_tg_status_first_err_bit_valid is set to 1, only

the first error mismatch bit pattern is stored in this
register.

vio_tg_status_first_
err_addr

APP_ADDR_WIDTH

If vio_tg_status_first_err_bit_valid is set to 1, only

the first error address is stored in this register.

vio_tg_status_first_
exp_bit_valid

If vio_tg_err_chk_en is set to 1, this represents

expected read data valid when first mismatch error
is encountered.

vio_tg_status_first_
exp_bit

APP_DATA_WIDTH

vio_tg_status_first_
read_bit_valid

If vio_tg_err_chk_en is set to 1, this represents read

data valid when first mismatch error is
encountered.

vio_tg_status_first_
read_bit

APP_DATA_WIDTH

If vio_tg_status_first_read_bit_valid is set to 1, read

data from memory for the first error is stored in
this register.

vio_tg_status_err_
bit_sticky_valid

Accumulated error mismatch valid over time. This

register will be reset by vio_tg_err_clear,
vio_tg_err_continue, vio_tg_restart.

vio_tg_status_err_
bit_sticky

APP_DATA_WIDTH

If vio_tg_status_err_bit_sticky_valid is set to 1, this

represents accumulated error bit.

vio_tg_status_err_
cnt_sticky

vio_tg_status_err_
type_valid

If vio_tg_status_first_exp_bit_valid is set to 1,
expected read data for the first error is stored in
this register.

32

Saturated counter that counts the number of

assertion of the signal
vio_tg_status_err_bit_sticky_valid. The counter is
reset by vio_tg_err_clear_all.

If vio_tg_err_chk_en is set to 1, read test is

performed after the first mismatch error. Read test
returns error type of either "READ" or "WRITE"
error.
This register stores valid status of read test error
type.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

314

Chapter 22: Traffic Generator

Table 22-1:

Default Traffic Generator Control Connection (Contd)

Signal

I/O

Width

vio_tg_status_err_
type

vio_tg_status_done

Description

Default Value

If vio_tg_status_err_type_valid is set to 1, this

represents error type result from read test.
0 = Write Error,
1 = Read Error
All traffic programmed completed.

Note: If infinite loop is programmed,

vio_tg_status_done does not assert.

vio_tg_status_wr_
done

This signal pulses after a WRITE-READ mode

instruction completes.

vio_tg_status_watch
_dog_hang

Watchdog hang. This register is set to 1 if there

is no Read/Write command sent or no Read data
return for a period of time (defined in
tg_param.vh).

compare_error

Accumulated error mismatch valid over time.

This register is reset by vio_tg_err_clear,
vio_tg_err_continue, and vio_tg_restart.

In the default settings (parameter DEFAULT_MODE = 2015.3), the ATG performs memory
writes followed by memory reads and data checks. Three types of patterns are generated
sequentially:
1. PRBS23 data pattern
a. PRBS23 data pattern is used per data bit. Each data bit has a different default
starting seed value.
b. Linear address pattern is used. Memory address space is walked through to cover full
PRBS23 data pattern.
2. Hammer Zero pattern
a. Hammer Zero pattern is used for all data bits.
b. Linear address pattern is used. 1,024 Traffic Generator commands are issued.
3. PRBS address pattern
a. PRBS23 data pattern is used per data bit. Each data bit has a different default
starting seed value.
b. PRBS address pattern is used. 1,024 Traffic Generator commands are issued.
The ATG repeats memory writes and reads on each of the two patterns infinitely. For
simulations, ATG performs 1,000 PRBS23 pattern followed by 1,000 Hammer Zero pattern
and 1,000 PRBS address pattern.
Check if there is a memory error in the Status register
(vio_tg_status_err_sticky_valid) or if memory traffic stops
(vio_tg_status_watch_dog_hang).

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

315

Chapter 22: Traffic Generator

After the first memory error is seen, the ATG logs the error address
(vio_tg_status_first_err_addr) and bit mismatch
(vio_tg_status_first_err_bit).
Table 22-2 shows the common Traffic Generator Status register output which can be used
for debug.
Table 22-2:

Common Traffic Generator Status Register for Debug

Signal

I/O

Width

Description

Error Status Registers

Intermediate error detected. It is used as trigger
to detect read error.

vio_tg_status_err_bit_valid

vio_tg_status_err_bit

APP_DATA_WIDTH

Intermediate error bit mismatch. Bitwise

mismatch pattern.

vio_tg_status_err_addr

APP_ADDR_WIDTH

Intermediate error address. Address location of

failed read.

vio_tg_status_first_err_bit_valid

If vio_tg_err_chk_en is set to 1, first_err_bit_valid

is set to 1 when first mismatch error is
encountered.
This register is not overwritten until
vio_tg_err_clear, vio_tg_err_continue, and
vio_tg_restart is triggered.

vio_tg_status_first_err_bit

APP_DATA_WIDTH

If vio_tg_status_first_err_bit_valid is set to 1, error

mismatch bit pattern is stored in this register.

vio_tg_status_first_err_addr

APP_ADDR_WIDTH

If vio_tg_status_first_err_bit_valid is set to 1, error

address is stored in this register.

vio_tg_status_first_exp_bit_valid

If vio_tg_err_chk_en is set to 1, this represents

expected read data valid when first mismatch
error is encountered.

vio_tg_status_first_exp_bit

APP_DATA_WIDTH

If vio_tg_status_first_exp_bit_valid is set to 1,
expected read data is stored in this register.

vio_tg_status_first_read_bit_valid

If vio_tg_err_chk_en is set to 1, this represents

read data valid when first mismatch error is
encountered.

vio_tg_status_first_read_bit

APP_DATA_WIDTH

If vio_tg_status_first_read_bit_valid is set to 1,
read data from memory is stored in this register.

vio_tg_status_err_bit_sticky_valid

Accumulated error mismatch valid over time. This

register is reset by vio_tg_err_clear,
vio_tg_err_continue, and vio_tg_restart.

vio_tg_status_err_bit_sticky

APP_DATA_WIDTH

If vio_tg_status_err_bit_sticky_valid is set to 1, this

represents accumulated error bit.

vio_tg_status_done

All traffic programmed completes.

Note: If infinite loop is programmed,
vio_tg_status_done does not assert.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

316

Chapter 22: Traffic Generator

Table 22-2:

Common Traffic Generator Status Register for Debug (Contd)

Signal

vio_tg_status_wr_done

vio_tg_status_watch_dog_hang

I/O

Width

This signal pulses after a Write-Read mode

instruction completes.

Watchdog hang. This register is set to 1 if there is

no Read/Write command sent or no Read data
return for a period of time (defined in
tg_param.vh).

Description

Traffic Generator Description

This section provides detailed information on using the ATG beyond the default settings.

Feature Support
In this section, the ATG basic feature support and mode of operation is described. The ATG
allows you to program different traffic patterns, a read-write mode, and the duration of
traffic burst based on their application.
Provide one traffic pattern for a simple traffic test in the direct instruction mode or program
up to 32 traffic patterns into the traffic pattern table for a regression test in the traffic table
mode.
Each traffic pattern can be programmed with the following options:

Address Mode Linear, PRBS, walking1/0.

Data Mode Linear, PRBS 8/10/23, walking1/0, and hammer1/0.

Read/Write Mode Write-read, write-only, read-only, write-once-read-forever.

Read/Write Submode When read/write mode is set to write-read, you can

choose to send write and read commands. The first choice sends all write
commands follow by read commands.
The second choice sends write and read command pseudo-randomly. This submode
is valid for DDR3/DDR4 and RLDRAM 3 only.

Victim Mode No Victim, held1, held0, Non-inverted aggressor, inverted aggressor,

delayed aggressor, delayed victim.

Victim Aggressor Delay Aggressor or victim delay when the Victim mode of
"delayed aggressor" or "delayed victim" modes is used.

Victim Select Victim selected from the ATG VIO input or victim rotates per nibble/per
byte/per interface width.

Number of Command Per Traffic Pattern

Number of NOPs After Bursts

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

317

Chapter 22: Traffic Generator

Number of Bursts Before NOP

Next Instruction Pointer

Create one traffic pattern for simple traffic test using the direct instruction mode
(vio_tg_direct_instr_en).
Also, create a sequence of traffic patterns by programming a "next instruction" pointer
pointing to one of the 32 traffic pattern entries for regression test in traffic table mode. The
example in Table 22-3 shows four traffic patterns programmed in the table mode.
The first pattern has PRBS data traffic written in Linear address space. The 1,000 write
commands are issued followed by 1,000 read commands. Twenty cycles of NOPs are
inserted between every 100 cycle of commands. After completion of instruction0, the next
instruction points at instruction1.
Similarly, instruction1, instruction2, and instruction3 is executed and then looped back to
instruction0.
Table 22-3:
Instruction
Number

Example of Instruction Program

Addr
Mode

Data
Mode

Read/Write
Mode

Victim
Mode

Number of
Instruction
Iteration

Insert M Insert M
NOPs
NOPs
Next
Between Between
Instruction
N-Burst N-Burst
(M)
(N)

Linear

PRBS

Write-Read

No Victim

1,000

20

100

Linear

PRBS

Write-Read

No Victim

1,000

500

Linear

Linear

Write-Only

No Victim

10,000

10

100

Linear

Walking1

Write-Read

No Victim

1,000

10

100

.
31

The ATG waits for calibration to complete (init_calib_complete and tg_start

assertion). After the calibration complete and assertion of tg_start, the ATG starts
sending the default traffic sequence according to traffic pattern table or direct instruction
programmed. Memory Read/Write requests are then sent through the application interface,
Memory Controller, and PHY. Either program the instruction table before asserting
tg_start or pause the traffic generator (by asserting vio_tg_pause), reprogram the
instruction table, and restart the test traffic for custom traffic pattern. For more
information, see the Usage section.
The ATG performs error check when a traffic pattern is programmed to read/write modes
that have write requests followed by read request (that is, Write-read-mode or
Write-once-Read-forever-mode). The ATG first sends all write requests to the memory. After
all write requests are sent, the ATG sends read requests to the same addresses as the write
requests. Then the read data returning from memory is compared with the expected read
data.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

318

Chapter 22: Traffic Generator

If there is no mismatch error and the ATG is not programmed into an infinite loop,
vio_tg_status_done asserts to indicate run completion.
The ATG has watchdog logic. The watchdog logic checks if the ATG has any request sent to
the application interface or the application interface has any read data return within N
(parameter TG_WATCH_DOG_MAX_CNT) number of cycles. This provides information on
whether memory traffic is running or stalled (because of reasons other than data
mismatch).

Usage
In this section, basic usage and programming of the ATG is covered.
The ATG is programmed and controlled using the VIO interface. Table 22-4 shows
instruction table programming options.
Table 22-4:

Traffic Generator Instruction Options

Name

Bit
Width

Instruction Number

Addr Mode

Data Mode

Read/Write Mode

Description
Instruction select. From 0 to 31.
Address mode to be programmed.
0 = LINEAR; (with user-defined start address)
1 = PRBS; (PRBS supported range from 8 to 34 based on address width)
2= WALKING1
3 = WALKING0
4-15 = Reserved

Data mode to be programmed.

0 = LINEAR
1 = PRBS (PRBS supported 8, 10, 23)
2 = WALKING1
3 = WALKING0
4 = HAMMER1
5 = HAMMER0
6 = Block RAM
7 = CAL_CPLX
8-15 = Reserved

0 = Read Only (No data check)

1 = Write Only (No data check)
2 = Write/Read (Read performs after Write and data value is checked against
expected write data. For QDR II+ SRAM, one port is used for write and another
port is used for read.)
3 = Write once and Read forever (Data check on Read data)
4-15 = Reserved

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

319

Chapter 22: Traffic Generator

Table 22-4:

Traffic Generator Instruction Options (Contd)

Name

Bit
Width

Description

Read/Write submode to be programmed.

This is a submode option when vio_tg_instr_rw_mode is set to "WRITE_READ"
mode.
This mode is only valid for DDR3/DDR4 and RLDRAM 3. For QDR II+ SRAM
interface, this mode should be set to 0.
WRITE_READ = 00; // Send all Write commands follow by Read commands
defined in the instruction.
WRITE_READ_SIMULTANEOUSLY = 01; // Send Write and Read commands
pseudo-randomly. Note that Write is always ahead of Read.
2 and 3 = Reserved

Victim mode to be programmed.

One victim bit could be programmed using global register vio_tg_victim_bit. The
rest of the bits on signal bus are considered to be aggressors.
The following program options define aggressor behavior:
NO_VICTIM = 0;
HELD1 = 1; // All aggressor signals held at 1
HELD0 = 2; // All aggressor signals held at 0
NONINV_AGGR = 3; // All aggressor signals are same as victim
INV_AGGR = 4; // All aggressor signals are inversion of victim
DELAYED_AGGR = 5; // All aggressor signals are delayed version of victim (num
of cycle of delay is programmed at vio_tg_victim_aggr_delay)
DELAYED_VICTIM = 6; // Victim signal is delayed version of all aggressors
CAL_CPLX = 7; Complex Calibration pattern

Define aggressor/victim pattern to be N-delay cycle of victim/aggressor, where 0

N 24.
It is used when victim mode "DELAY_AGGR" or "DELAY VICTIM" mode is used in
traffic pattern.

Victim Select

Victim bit behavior programmed.

VICTIM_EXTERNAL = 0; // Use Victim bit provided in vio_tg_glb_victim_bit
VICTIM_ROTATE4 = 1; // Victim bit rotates from Bits[3:0] for every Nibble
VICTIM_ROTATE8 = 2; // Victim bit rotates from Bits[7:0] for every Byte
VICTIM_ROTATE_ALL = 3; // Victim bit rotates through all bits
RESERVED = 4-7

Number of
instruction iteration

32

Number of Read and/or Write commands to be sent.

Insert M NOPs
between N-burst (M)

10

M = Number of NOP cycles in between Read/Write commands at user interface

at general interconnect clock.

Insert M NOPs
between N-burst (N)

32

N = Number of Read/Write commands before NOP cycle insertion at user

interface at general interconnect clock.

Next instruction to run.

To end traffic, next instruction should point at EXIT instruction.
6b000000-6b011111 valid instruction
6b1????? EXIT instruction

Read/Write
Submode

Victim Mode

Victim Aggressor
Delay

Next Instruction

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

320

Chapter 22: Traffic Generator

How to Program Traffic Generator Instruction

After calibration is completed, the ATG starts sending current traffic pattern presented at
the VIO interface if direct instruction mode is on; or default traffic sequence according to
the traffic pattern table if the direct instruction mode is OFF.
If it is desired to run a custom traffic pattern, either program the instruction table before
the ATG starts or pause the ATG. Program the instruction table and restart the test traffic
through the VIO.
Steps to program the instruction table (wait for at least one general interconnect cycle
between each step) are listed here.
Programming instruction table after reset:
1. Set the vio_tg_start to 0 to stop the ATG before reset deassertion.
2. Check if the vio_tg_status_state is TG_INSTR_START (hex0). Then go to step 4.
Programming instruction table after traffic started:
1. Set the vio_tg_start to 0 and set vio_tg_pause to 1 to pause the ATG.
2. Check and wait until the vio_tg_status_state is TG_INSTR_DONE (hexC),
TG_INSTR_PAUSE (hex8), or TG_INSTR_ERRDONE (hex7).
3. Send a pulse to the vio_tg_restart. Then, go to step 4.
Common steps:
4. Set the vio_tg_instr_num_instr to the instruction number to be programmed.
5. Set all of the vio_tg_instr_* registers (instruction register) with desired traffic
pattern.
6. Wait for four general interconnect cycles (optional for relaxing VIO write timing).
7. Set the vio_tg_instr_program_en to 1. This enables instruction table
programming.
8. Wait for four general interconnect cycles (optional for relaxing VIO write timing).
9. Set the vio_tg_instr_program_en to 0. This disables instruction table
programming.
10. Wait for four general interconnect cycles (optional for relaxing VIO write timing).
11. Repeat steps 3 to 9 if more than one instruction is programmed.
12. Optionally set the vio_tg_glb* registers (global register) if related features are
programmed.
13. Optionally set the vio_tg_err_chk_en if you want the ATG to stop and perform read
test in case of mismatch error.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

321

Chapter 22: Traffic Generator

14. Set the vio_tg_pause to 0 and set vio_tg_start to 1. This starts the ATG with new
the programming.
In Figure 22-2, after c0_init_calib_complete signal is set, the ATG starts executing
default instructions preloaded in the instruction table. Then, the vio_tg_pause is set to
pause the ATG, and then pulse vio_tg_restart. Three ATG instructions are being
re-programmed and the ATG is started again by deasserting vio_tg_pause and asserting
tg_start.
X-Ref Target - Figure 22-2

Figure 22-2:

Basic ATG Simulation

Figure 22-3 zooms into the VIO instruction programming in Figure 22-2. After pausing the
traffic pattern, vio_tg_restart is pulsed. Then vio_tg_instr_num and
vio_tg_instr* are set, followed by vio_tg_program_en pulse (note that
vio_tg_instr_num and vio_tg_instr* are stable for four general interconnect cycles
before and after vio_tg_program_en pulse). After programming instructions are
finished, the vio_tg_pause is deasserted and vio_tg_start is asserted.
X-Ref Target - Figure 22-3

Figure 22-3:

ATG Re-Program Simulation

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

322

Chapter 22: Traffic Generator

Important Note:
1. For Write-read mode or Write-once-Read-forever modes, this ATG issues all write traffic,
followed by all read traffic. During read data check, expected read traffic is generated
on-the-fly and compared with read data.
If a memory address is written more than once with different data pattern, the ATG
creates a false error check. Xilinx recommends for a given traffic pattern programmed,
the number of command must be less than available address space programmed.
2. The ATG performs error check when read/write mode of a traffic pattern is programmed
to be "Write-read mode" or "Write-once-Read-forever modes." For "Write-only" or
"Read-only" modes error check is not performed.
To overwrite default ATG instruction table, update the mig_v1_0_tg_instr_bram.sv.

Traffic Error Detection

The ATG could be programmed to have two different behaviors (using
vio_tg_err_chk_en) when traffic error is detected.
1. Stop traffic after first error is seen.
The ATG stops traffic after first error. The ATG then performs a read-check to detect if
the mismatch seen is a "WRITE" error or "READ" error. When vio_tg_status_state
reaches ERRDone state, the read-check is completed. The vio_tg_restart can be
pulsed to clear and restart ATG or the vio_tg_err_continue can be pulsed to
continue traffic.
2. Continue traffic with error.
The ATG continues sending traffic. The traffic can be restarted by asserting pause
(vio_tg_pause), followed by pulse restart (vio_tg_restart), then deasserting
pause.
In both cases, bitwise sticky bit mismatch is available in VIO for accumulated mismatch.
When a mismatch error is encountered, use the vio_tg_status_err_bit_valid to
trigger the Vivado Logic Analyzer. All error status are presented in the vio_tg_status_*
registers.
Depending on the goal, different vio_tg_status_* signals can be connected to ILA or
VIO for observation. For example, if regression is run on a stable design, compare_error
and vio_tg_status_watch_dog_hang can be used to detect error or hang conditions.
For a design debug, vio_tg_status_err* signals track errors seen on current read data
return. vio_tg_status_first* signals store the first error seen.
vio_tg_status_err_bit_sticky* signals accumulate all error bits seen.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

323

Chapter 22: Traffic Generator

Error bit buses could be very wide. It is recommended to add a MUX stage and a flop stage
before connect the bus to ILA or VIO.
Error status can be cleared when the ATG is in either ERRDone or Pause states. Send a pulse
to the vio_tg_clear to clear all error status except sticky bit. Send a pulse to the
vio_tg_clear_all to clear all error status including sticky bit.

Traffic Generator Supported Interface and Configuration

The ATG supports DDR3/DDR4, RLDRAM II/RLDRAM 3, and QDR II+ SRAM interface with
various configurations. For each interface and configuration, the CMD_PER_CK needs to be
programmed with a different value.
Table 22-5:

CMD_PER_CK Setting for 4:1 General Interconnect Cycle to Memory Clock Cycle
UltraScale

7 Series

Burst Length/
Mem Type

DDR3/DDR4

RLDRAM 3

DDR3/DDR4

Table 22-6:

RLDRAM II RLDRAM 3

CMD_PER_CK Setting for 2:1 General Interconnect Cycle to Memory Clock Cycle

Burst Length/
Mem Type

UltraScale

7 Series

QDR II+

DDR3/DDR4

0.5

0.5

0.5

RLDRAM II RLDRAM 3

QDR II+

Note: For design with 2:1 general interconnect cycle to memory clock cycle ratio and burst length 8

(BL = 8), ATG error status interface vio_tg_status_* presents data in full burst (that is, double the
APP_DATA_WIDTH).

How to Program Victim Mode/Victim Select/Victim Aggressor Delay

Basic cross-coupling patterns are supported in the victim mode. In a given Victim mode, the
victim and aggressor behaviors are controlled by the Victim Select and the Victim
Aggressor Delay.
First, program Victim mode to choose victim/aggressor relationship.

Held1 All aggressors held at 1

Held0 All aggressors held at 0

NONINV_AGGR All aggressors are same as victim pattern

INV_AGGR All aggressors are presented as inversion of victim pattern

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

324

Chapter 22: Traffic Generator

DELAYED_AGGR All aggressors are presented as delayed version of victim pattern.

Delay is programmable (vio_tg_victim_aggr_delay).

DELAYED_VICTIM Victim is presented as delayed version of aggressor pattern. Delay

is programmable (vio_tg_victim_aggr_delay).

CAL_CPLX Both victim and aggressor are defined as calibration complex pattern.
Both Data Mode and Victim Mode have to be programmed to CAL_CPLX.

After a Victim mode is selected, program the victim/aggressor select.

Use the external VIO signal to choose victim bit (vio_tg_glb_victim_bit).

Rotate victim per nibble (from Bits[3:0]) for every nibble.

Rotate victim per byte (from Bits[7:0]) for every byte.

Rotate victim in the whole memory interface.

If you selected Victim mode DELAYED_AGGR or DELAYED_VICTIM, the number of UI cycle

shifted is programmed in vio_tg_victim_aggr_delay (where 0 N 24).
Note: CAL_CPLX is a Xilinx internal mode that is used for the Calibration Complex Pattern.

How to Program PRBS Data Seed

One of the programmable traffic pattern data modes is PRBS data mode. In PRBS data
mode, the PRBS Data Seed can be programmed per data bit using the VIO interface.
The following are steps to program PRBS Data Seed (wait for at least one general
interconnect cycle between each step):
1. Set the vio _tg_s tart to 0 to stop traffic generator before reset deassertion.
2. Check the v io_tg _stat us_st ate to be TG_INSTR_START (hex0).
3. Set the vio _tg_s eed_n um and vio_t g_see d_dat a with the desired seed
address number and seed.
4. Wait for four general interconnect cycles (optional for relaxing VIO write timing).
5. Set the vio _tg_s eed_p rogra m_en to 1. This enables seed programming.
6. Wait for four general interconnect cycles (optional for relaxing VIO write timing).
7. Set the vio _tg_s eed_p rogra m_en to 0. This disables seed programming.
8. Wait for four general interconnect cycles (optional for relaxing VIO write timing).
9. Repeat steps 3 to 8 if more than one seed (data bit) is programmed.
10. Set the v io_tg _star t to 1. This starts traffic generator with new seed programming.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

325

Chapter 22: Traffic Generator

How to Program Linear Data Seed

One of the programmable traffic pattern data modes is Linear data mode. In Linear data
mode, Linear data seed can be programmed by the parameter
TG_PATTERN_MODE_LINEAR_DATA_SEED. The seed has a width of APP_DATA_WIDTH. For 4:1
general interconnect cycle to memory clock cycle ratio (nCK_PER_CLK), the seed format
consists of eight data bursts of linear seed.
For 2:1 general interconnect cycle to memory clock cycle ratio, the seed format consists of
four data bursts of linear seed. Each linear seed has a width of DQ_WIDTH.
For example, a 72-bit wide memory design with 4:1 general interconnect cycle to memory
clock cycle ratio, linear seed starting with base of decimal 1024 is presented by {72'd1031,
72'd1030, 72'd1029, 72'd1028, 72'd1027, 72'd1026, 72'd1025, and 72'd1024}.
A second example, a 16-bit wide memory design with 2:1 general interconnect cycle to
memory clock cycle ratio, linear seed starting with base of zero is presented by {16'd3,
16'd2, 16'd1, and 16'd0}.

How to Program Linear Address Seed

One of the programmable traffic pattern address modes is Linear address mode. In Linear
address mode, the Linear Address Seed can be programmed using the VIO input
(vio_tg_glb_start_addr).
The seed has a width of APP_ADDR_WIDTH and it is formed by a concatenation of N number
of consecutive linear address seeds, where the number N is listed in Table 22-7 and
Table 22-8.
Table 22-7: Linear Address Seed Look Up Table for 4:1 General Interconnect Cycle to Memory
Clock Cycle
UltraScale

7 Series

Burst Length/
Mem Type

DDR3/DDR4

RLDRAM 3

DDR3/DDR4

RLDRAM II RLDRAM 3

Table 22-8: Linear Address Seed Look Up Table for 2:1 General Interconnect Cycle to Memory
Clock Cycle
Burst Length/
Mem Type

UltraScale

7 Series

QDR II+

DDR3/DDR4

RLDRAM II RLDRAM 3

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

QDR II+

Send Feedback

326

Chapter 22: Traffic Generator

Least significant bit(s) of Linear address seed is padded with zero. For DDR3/DDR4, the
3-bit of zero is padded because the burst length of eight is always used.
For RLDRAM 3, the 4-bit of zero is padded because the ATG cycles through 16 RLDRAM 3
banks automatically. For QDR II+ SRAM interface, zero padding is not required.

Read/Write Submode
When Read/Write mode is programmed to Write/Read mode in an instruction, there are two
options to perform the data write and read.

ATG writes all data, then reads all data

ATG switches between write and read pseudo-randomly. In this mode, data write is
always ahead of data read.

IMPORTANT: This mode is not supported in QDR II+ SRAM interface.

Traffic Generator Structure

In this section, the ATG logical structure and data flow is discussed.
The ATG data flow is summarized in Figure 22-4. The ATG is controlled and programmed
through the VIO interface. Based on current instruction pointer value, an instruction is
issued by the ATG state machine shown in Figure 22-5.
Based on the traffic pattern programmed in Read/Write mode, Read and/Write requests are
sent to the application interface. Write patterns are generated by the Write Data
Generation, Write Victim Pattern, and Write Address Generation engines (gray). Similarly,
Read patterns are generated by Read Address Generation engine (dark gray).
When Write-Read-mode or Write-Once-Read-forever mode are programmed, Read data
check is performed. Read data is compared against Expected Read pattern generated by the
Expected Data Generation, Expected Victim Pattern, and Expected Address Generation
engines (gray and white). Data compare is done in the Error Checker block. Error status is
presented to the VIO interface.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

327

Chapter 22: Traffic Generator

X-Ref Target - Figure 22-4

7UDIILF*HQHUDWRU
:ULWH9LFWLP3DWWHUQ
1R9LFWLP
+HOG
+HOG
$JJUHVVRULQY
$JJUHVVRUGHOD\

:ULWH'DWD*HQHUDWLRQ
/LQHDU
35%6
:DONLQJ
+DPPHU

,QVWUXFWLRQ7DEOH
7UDIILF3DWWHUQ
7UDIILF3DWWHUQ
7UDIILF3DWWHUQ

:ULWH
5HTXHVW

YLRBWJBLQVWU
:ULWH$GGUHVV*HQHUDWLRQ
/LQHDU
35%6
:DONLQJ

7R$SSLQWHUIDFH
DSSBHQ
DSSBFPG
DSSBDGGU
DSSBZGIBGDWD
DSSBZGIBZUHQ
DSSBZGIBHQG

7UDIILF3DWWHUQ
5HDG$GGUHVV*HQHUDWLRQ
/LQHDU
35%6
:DONLQJ

YLRBWJBUVW
YLRBWJBUHVWDUW
YLRBWJBSDXVH
YLRBWJBHUUBFKNBHQ

5HDG5HTXHVW

)URP$SS
LQWHUIDFHDSSBUG\
DSSBZGIBUG\

7UDIILF*HQHUDWRU6WDWH
0DFKLQH:DWFKGRJ

(UURU&KHFNHU
5HDG$GGUHVVUHDGWHVW

5HDG'DWD(LWKHUIURPUHJXODUUHDGRUUHDGWHVW

YLRBWJBVWDWXVB

%LWVWUHDP&RPSDUH/RJLF

([SHFWHG
5HDG
'DWD

([SHFWHG9LFWLP3DWWHUQ
1R9LFWLP
+HOG
+HOG
$JJUHVVRULQY
$JJUHVVRUGHOD\

([SHFWHG'DWD*HQHUDWLRQ
/LQHDU
35%6
:DONLQJ
+DPPHU

)URP$SSLQWHUIDFH
DSSBUHDGBGDWDBYDOLG
DSSBUHDGBGDWD

([SHFWHG$GGUHVV
*HQHUDWLRQ
/LQHDU
35%6
:DONLQJ

;

Figure 22-4:

Traffic Generator Data Flow

Figure 22-5 and Table 22-9 show the ATG state machine and its states. The ATG resets at the
"Start" state. After calibration completion (init_calib_complete) and the tg_start is
asserted, the ATG state moves to instruction load called the "Load" state. The "Load" state
performs next instruction load. When the instruction load is completed, the ATG state
moves to Data initialization called the "Dinit" state. The "Dinit" state initializes all Data/
Address generation engines. After completion of data initialization, the ATG state moves to
execution called the "exe" state. The "Exe" state issues Read and/or Write requests to the
APP interface.
At the "Exe" state, you can pause the ATG and the ATG state moves to the "Pause" state. At
the "Pause" state, the ATG can be restarted by issuing tg_restart through the VIO, or
un-pause the ATG back to the "Exe" state.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

328

Chapter 22: Traffic Generator

At the "Exe" state, the ATG state goes through RWWait RWload Dinit states if
Write-Read mode or Write-once-Read-forever modes are used. At the RWWait, the ATG
waits for all Read requests to have data returned (for QDR II+ SRAM).
At the RWload state, the ATG transitions from Write mode to Read mode for DDR3/DDR4,
RLDRAM II/RLDRAM 3, or from Write/Read mode to Read only mode for QDR II+ SRAM
Write-once-Read-forever mode.
At the "Exe" state, the ATG state goes through LDWait Load if the current instruction is
completed. At the LDWait, the ATG waits for all Read requests to have data returned.
At the "Exe" state, the ATG state goes through DNWait Done if the last instruction is
completed. At the DNWait, the ATG waits for all Read requests to have data returned.
At the "Exe" state, the ATG state goes through ERRWait ERRChk if an error is detected. At
the ERRWait, the ATG waits for all Read requests to have data returned. The "ERRChk" state
performs read test by issuing read requests to the application interface and determining
whether "Read" or "Write" error occurred. After read test completion, the ATG state moves
to "ERRDone."
At "Done," "Pause," and "ErrDone" states, the ATG can be restarted ATG by issuing
tg_restart.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

329

Chapter 22: Traffic Generator

X-Ref Target - Figure 22-5

6WDUW
GHIDXOW

WJBUHVWDUW

,QLWBFDOLEBFRPSOHWH

WJBVWDUW
'RQH

WJBUHVWDUW

/RDG

WJBUHVWDUW
5:ORDG

'LQLW
3DXVH

'1:DLW

/':DLW

/RDG1H[WLQVWUXFWLRQ

5::DLW

aWJBSDXVH

:ULWH!5HDG5HTXHVW
WUDQVLWLRQ

(55'RQH

3DXVH:DLW
WJBHUUBFRQWLQXH

'RQHZLWKDOO,QVWUXFWLRQV
([H

(UURU'HWHFWHG

WJBSDXVH

(55:DLW

(55&KN

;

Figure 22-5:
Table 22-9:

Traffic Generator State Machine

Traffic Generator State Machine States

State

Enum

Description

Start (default)

Default state after reset. Proceed to "Load" state when init_calib_complete and
vio_tg_start are TRUE.

Load

Load instruction into instruction pointer. Determine "Read" and/or "Write" requests to
be made in "EXE" state based on read/write mode.

Dinit

Data initialization of all Data and Address Pattern generators.

Exe

Execute state. Sends "Read" and/or "Write" requests to APP interface until
programmed request count is met.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

330

Chapter 22: Traffic Generator

Table 22-9:
State

Traffic Generator State Machine States (Contd)

Enum

Description

RWLoad

Update "Read" and/or "Write" requests to be made in "EXE" state based on read/write
mode.

ERRWait

Waiting until all outstanding "Read" traffic has returned and checked.

ERRChk

Perform read test to determine if error type is "Read" or "Write" error.

ERRDone

Stopped after an error. You could continue or restart TG.

Pause

Pause traffic

PauseWait

13

Waiting until all outstanding "Read" traffic has returned and checked. Go to Pause state
after all outstanding Read traffic are completed.

LDWait

Waiting until all outstanding "Read" traffic has returned and checked. Go to Load state
after all outstanding Read traffic are completed.

RWWait

10

Waiting until all outstanding "Read" traffic has returned and checked. Go to RWLoad
state after all outstanding Read traffic are completed.

DNWait

11

Waiting until all outstanding "Read" traffic has returned and checked. Go to Done state
after all outstanding Read traffic are completed.

Done

12

All instruction completed. You can program or restart TG.

QDR II+ SRAM ATG Support

This section covers special supports for QDR II+ SRAM interface.
For QDR II+ SRAM, the ATG supports separate Write and Read command signals in an
application interface. When Write-Read mode is selected, the ATG issues Write and Read
command simultaneously.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

331

SECTION VI: MULTIPLE IP CORES

Multiple IP Cores

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

332

Chapter 23

Multiple IP Cores
This chapter describes the specifications and pin rules for generating multiple IP cores.

Creating a Design with Multiple IP Cores

The following steps must be followed to create a design with multiple IP cores:
1. Generate the target memory IP. If the design includes multiple instances of the same
memory IP configuration, the IP only needs to be generated once. The same IP can be
instantiated multiple times within the design.

If the IP shares the input sys_clk, select the No Buffer clocking option during IP
generation with the same frequency value selected for option Reference Input
Clock Period (ps). Memory IP that share sys_clk must be allocated in the same I/
O column. For more information on Sharing of Input Clock Source, see the Sharing
of Input Clock Source for a link of each controller section.

2. Create a wrapper file to instantiate the target memory IP cores.

3. Assign the pin locations for the Memory IP I/O signals. For more information on pin
rules of the respective interface, see the Sharing of a Bank for a link of each controller
section. Also, to learn more about the available Memory IP pin planning options, see the
Vivado Design Suite User Guide: I/O and Clock Planning (UG899) [Ref 13].
4. Ensure the following specifications are followed.

Sharing of a Bank
Pin rules of each controller must be followed during IP generation. For more information on
pin rules of each interface, see the respective IP sections:

DDR3 Pin Rules in Chapter 4 and DDR4 Pin Rules in Chapter 4

QDR II+ Pin Rules in Chapter 11

RLDRAM 3 Pin Rules in Chapter 18

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

333

Chapter 23: Multiple IP Cores

The same bank can be shared across multiple IP cores, but Memory IP allows sharing of
banks across multiple IP cores if the rules for combining I/O standards in the same bank are
followed.
For more information on the rules for combining I/O standards in the same bank, see the
section "Rules for Combining I/O Standards in the Same Bank, in UltraScale Architecture
SelectIO Resources User Guide (UG571) [Ref 3]. The DCI I/O banking rules are also captured
in UG571.

Sharing of Input Clock Source

One GCIO pin can be shared across multiple IP cores. There are certain rules that must be
followed to share input clock source and you must perform a few manual changes in the
wrapper files. For more information on Sharing of Input Clock Source, see the respective
interfaces:

Sharing of Input Clock Source (sys_clk_p) in Chapter 4 (DDR3/DDR4)

Sharing of Input Clock Source (sys_clk_p) in Chapter 11 (QDR II+ SRAM)

Sharing of Input Clock Source (sys_clk_p) in Chapter 18 (RLDRAM 3)

XSDB and dbg_clk Changes

The dbg_clk port is an output from the Memory IP and it automatically connects to the
dbg_hub logic by Vivado during implementation. If multiple IP cores are instantiated in
the same project, Vivado automatically connects the first IP dbg_clk to dbg_bug.
In the wrapper file in which multiple Memory IP cores are instantiated, do not connect any
signal to dbg_clk and keep the port open during instantiation. Vivado takes care of the
dbg_clk connection to the dbg_hub.

MMCM Constraints
MMCM must be allocated in the center bank of the memory I/Os selected banks. Memory
IP generates the LOC constraints for MMCM such that there is no conflict if the same bank
is shared across multiple IP cores.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

334

SECTION VII: DEBUGGING

Debugging

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

335

Chapter 24

Debugging
This appendix includes details about resources available on the Xilinx Support website and
debugging tools.
TIP: If the IP generation halts with an error, there might be a license issue. See License Checkers in

Chapter 1 for more details.

Finding Help on Xilinx.com

To help in the design and debug process when using the Memory IP, the Xilinx Support web
page contains key resources such as product documentation, release notes, answer records,
information about known issues, and links for opening a Technical Support WebCase.

Documentation
This product guide is the main document associated with the Memory IP. This guide, along
with documentation related to all products that aid in the design process, can be found on
the Xilinx Support web page or by using the Xilinx Documentation Navigator.
Download the Xilinx Documentation Navigator from the Downloads page. For more
information about this tool and the features available, open the online help after
installation.

Solution Centers
See the Xilinx Solution Centers for support on devices, software tools, and intellectual
property at all stages of the design cycle. Topics include design assistance, advisories, and
troubleshooting tips.
The Solution Center specific to the Memory IP core is located at Xilinx Memory IP Solution
Center.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

336

Chapter 24: Debugging

Answer Records
Answer Records include information about commonly encountered problems, helpful
information on how to resolve these problems, and any known issues with a Xilinx product.
Answer Records are created and maintained daily ensuring that users have access to the
most accurate information available.
Answer Records for this core can be located by using the Search Support box on the main
Xilinx support web page. To maximize your search results, use proper keywords such as:

Product name

Tool message(s)

Summary of the issue encountered

A filter search is available after results are returned to further target the results.
Master Answer Record for the Memory IP
AR: 58435

Technical Support
Xilinx provides technical support at Xilinx support web page for this LogiCORE IP product
when used as described in the product documentation. Xilinx cannot guarantee timing,
functionality, or support if you do any of the following:

Implement the solution in devices that are not defined in the documentation.

Customize the solution beyond that allowed in the product documentation.

Change any section of the design labeled DO NOT MODIFY.

To contact Xilinx Technical Support, navigate to the Xilinx Support web page.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

337

Chapter 24: Debugging

Debug Tools
There are many tools available to address Memory IP design issues. It is important to know
which tools are useful for debugging various situations.

XSDB Debug
Memory IP includes XSDB debug support. The Memory IP stores useful core configuration,
calibration, and data window information within internal block RAM. The Memory IP debug
XSDB interface can be used at any point to read out this information and get valuable
statistics and feedback from the Memory IP. The information can be viewed through a
Memory IP Debug GUI or through available Memory IP Debug Tcl commands.

Memory IP Debug GUI Usage

After configuring the device the Memory IP debug core and contents are visible in the
Hardware Manager (Figure 24-1).

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

338

Chapter 24: Debugging

X-Ref Target - Figure 24-1

Figure 24-1:

Memory IP Debug Core Unit, Properties, and Configuration Windows

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

339

Chapter 24: Debugging

X-Ref Target - Figure 24-2

Figure 24-2:

Example Display of Memory IP Debug Core

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

340

Chapter 24: Debugging

X-Ref Target - Figure 24-3

Figure 24-3:

Example of Refresh Device

Memory IP Debug Tcl Usage

The following Tcl commands are available from the Vivado Tcl Console when connected to
the hardware.
This outputs all XSDB Memory IP content that is displayed in the GUIs.

get_hw_migs Displays what Memory IP cores exist in the design

refresh_hw_device Refreshes the whole device including all cores

refresh_hw_mig [lindex [get_hw_migs] 0] Refreshes only the Memory IP

core denoted by index (index begins with 0).

report_propery [lindex [get_hw_migs] 0] Reports all of the parameters

available for the Memory IP core. Where 0 is the index of the Memory IP core to be
reported (index begins with 0).

report_debug_core Reports all debug core peripherals connected to the Debug

Hub dbg_hub. Associates the debug core "Index" with the "Instance Name." Useful
when multiple instances of Memory IP are instantiated within the design to associate
the debug core index with the each IP instantiation.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

341

Chapter 24: Debugging

report_debug_core example:
Peripherals Connected to Debug Hub dbg_hub (2 Peripherals):
+-------+------------------------------+----------------------------------+
| Index | Type
| Instance Name
|
+-------+------------------------------+----------------------------------+
| 0
| vio_v3_0
| gtwizard_ultrascale_0_vio_0_inst |
+-------+------------------------------+----------------------------------+
| 1
| labtools_xsdb_slave_lib_v2_1 | your_instance_name
|
+-------+------------------------------+----------------------------------+
| 2
| labtools_xsdb_slave_lib_v2_1 | your_instance_name
|
+-------+------------------------------+----------------------------------+
| 3
| labtools_xsdb_slave_lib_v2_1 | your_instance_name
|
+-------+------------------------------+----------------------------------+
| 4
| labtools_xsdb_slave_lib_v2_1 | your_instance_name
|
+-------+------------------------------+----------------------------------+

Example Design
Generation of a DDR3/DDR4 design through the Memory IP tool allows an example design
to be generated using the Vivado Generate IP Example Design feature. The example
design includes a synthesizable test bench with a traffic generator that is fully verified in
simulation and hardware. This example design can be used to observe the behavior of the
Memory IP design and can also aid in identifying board-related problems.
For complete details on the example design, see Chapter 6, Example Design. The following
sections describe using the example design to perform hardware validation.

Debug Signals
The Memory IP UltraScale designs include an XSDB debug interface that can be used to very
quickly identify calibration status and read and write window margin. This debug interface
is always included in the generated Memory IP UltraScale designs.
Additional debug signals for use in the Vivado Design Suite debug feature can be enabled
using the Debug Signals option on the FPGA Options Memory IP GUI screen. Enabling this
feature allows example design signals to be monitored using the Vivado Design Suite debug
feature. Selecting this option brings the debug signals to the top-level and creates a sample
ILA core that debug signals can be port mapped into.
Furthermore, a VIO core can be added as needed. For details on enabling this debug
feature, see the Customizing and Generating the Core, page 167. The debug port is disabled
for functional simulation and can only be enabled if the signals are actively driven by the
user design.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

342

Chapter 24: Debugging

Vivado Design Suite Debug Feature

The Vivado Design Suite debug feature inserts logic analyzer and virtual I/O cores directly
into your design. The debug feature also allows you to set trigger conditions to capture
application and integrated block port signals in hardware. Captured signals can then be
analyzed. This feature in the Vivado IDE is used for logic debugging and validation of a
design running in Xilinx devices.
The Vivado logic analyzer is used with the logic debug IP cores, including:

ILA 2.0 (and later versions)

VIO 2.0 (and later versions)

See the Vivado Design Suite User Guide: Programming and Debugging (UG908) [Ref 15].

Reference Boards
The KCU105 evaluation kit is a Xilinx development board that includes FPGA interfaces to a
64-bit (4 x16 components) DDR4 interface. This board can be used to test user designs and
analyze board layout.

Hardware Debug
Hardware issues can range from link bring-up to problems seen after hours of testing. This
section provides debug steps for common issues. The Vivado Design Suite debug feature is
a valuable resource to use in hardware debug. The signal names mentioned in the following
individual sections can be probed using the Vivado Design Suite debug feature for
debugging the specific problems.

Memory IP Usage
To focus the debug of calibration or data errors, use the provided Memory IP example
design on the targeted board with the Debug Feature enabled through the Memory IP
UltraScale GUI.
Note: Using the Memory IP example design and enabling the Debug Feature is not required to
capture calibration and window results using XSDB, but it is useful to focus the debug on a known
working solution.
However, the debug signals and example design are required to analyze the provided ILA
and VIO debug signals within the Vivado Design Suite debug feature. The latest Memory IP
release should be used to generate the example design.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

343

Chapter 24: Debugging

General Checks
Ensure that all the timing constraints for the core were properly incorporated from the
example design and that all constraints were met during implementation.
1. If using MMCMs in the design, ensure that all MMCMs have obtained lock by monitoring
the locked port.
2. If your outputs go to 0, check your licensing.
3. Ensure all guidelines referenced in Chapter 4, Designing with the Core and the UltraScale
Architecture PCB Design and Pin Planning User Guide (UG583) [Ref 6] have been
followed.
4. In Chapter 4, Designing with the Core, it includes information on clocking, pin/bank, and
reset requirements. In the UltraScale Architecture PCB Design and Pin Planning User
Guide (UG583) [Ref 6], it includes PCB guidelines such as trace matching, topology and
routing, noise, termination, and I/O standard requirements. Adherence to these
requirements, along with proper board design and signal integrity analysis is critical to
the success of high-speed memory interfaces.
5. Measure all voltages on the board during idle and non-idle times to ensure the voltages
are set appropriately and noise is within specifications.

Ensure the termination voltage regulator (V TT) is powered on to VCCO/2.

Ensure VREF is measured when External V REF is used and set to VCCO/2.

6. When applicable, check vrp resistors.

7. Look at the clock inputs to ensure that they are clean.
8. Information on the clock input specifications can be found in the AC and DC Switching
Characteristics data sheets (LVDS input requirements and PLL requirements should be
considered).
9. Check the reset to ensure the polarity is correct and the signal is clean.
10. Check terminations. The UltraScale Architecture PCB Design and Pin Planning User Guide
(UG583) [Ref 6] should be used as a guideline.
11. Perform general signal integrity analysis.

IBIS simulations should be run to ensure terminations, ODT, and output drive
strength settings are appropriate.
For DDR3/DDR4, observe dq/dqs on a scope at the memory. View the alignment of
the signals, VIL/VIH, and analyze the signal integrity during both writes and reads.
Observe the Address and Command signals on a scope at the memory. View the
alignment, VIL/VIH, and analyze the signal integrity.

12. Verify the memory parts on the board(s) in test are the correct part(s) set through the
Memory IP. The timing parameters and signals widths (that is, address, bank address)

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

344

Chapter 24: Debugging

must match between the RTL and physical parts. Read/write failures can occur due to a
mismatch.
13. If Data Mask (DM) is not being used for DDR3/DDR4, ensure DM is tied Low at the
memory with the appropriate termination as noted in the memory data sheet. The
typical pull-down resistor value is 1 k.
14. For DDR3/DDR4, driving Chip Select (cs_n) from the FPGA is not required in single rank
designs. It can instead be tied Low at the memory device according to the memory
vendor recommendations. Ensure the appropriate selection (cs_n enable or disable) is
made when configuring the IP. Calibration sends commands differently based on
whether cs_n is enabled or disabled. If the pin is tied Low at the memory, ensure cs_n
is disabled during IP configuration.
15. ODT is required for all DDR3/DDR4 interfaces and therefore must be driven from the
FPGA. Memory IP sets the most ideal ODT setting based on extensive simulation.
External to the memory device, terminate ODT as specified in the UltraScale Architecture
PCB Design and Pin Planning User Guide (UG583) [Ref 6].
16. Check for any floating pins.

The par input for command and address parity, alert_n input/output, and the
TEN input for Connectivity Test Mode are not supported by the DDR4 UltraScale
interface. Consult the memory vendor for information on the proper connection for
these pins when not used.
Note: The par is required for DDR3 RDIMM interfaces and is optional for DDR4 RDIMM
interfaces.

Floating reset_n/reset# or address pins can result in inconsistent failures across

multiple resets and/or power supplies. If inconsistent calibration failures are seen,
check the reset_n/reset# and address pins.

17. Measure the ck/ck_n, dqs/dqs_n, and system clocks for duty cycle distortion and
general signal integrity.
18. If Internal V REF is used (required for DDR4), ensure that the constraints are set
appropriately in the XDC constraints file.
An example of the Interval VREF constraint is as follows:
set_property INTERNAL_VREF 0.600 [get_iobanks 45]

19. Check the MMCM and PLL lock signals.

20. If no system clock is present after configuring the part, the following error is generated
in Vivado Hardware Manager:
mig_calibration_ddr3_0.csv does not exist

21. Verify trace matching requirements are met as documented in the UltraScale
Architecture PCB Design and Pin Planning User Guide (UG583) [Ref 6].

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

345

Chapter 24: Debugging

22. Bring the init_calib_complete out to a pin and check with a scope or view whether
calibration completed successfully in Hardware Manager in the Memory IP Debug GUI.
23. Verify the configuration of the Memory IP. The XSDB output can be used to verify the
Memory IP settings. For example, the clock frequencies, version of Memory IP, Mode
register settings, and the memory part configuration (see step 12) can be determined
using Table 24-1.
Table 24-1:

Memory IP Configuration XSDB Parameters

Variable Name

Description

CAL_MAP_VERSION

CAL_STATUS_SIZE

CAL_VERSION_C_MB

C code version 2015.1 is v1.0, 2015.2 is v2.0

CAL_VERSION_RTL

RTL code version 2015.1 is v1.0, 2015.2 is v2.0

CONFIG_INFORMATION_0

Reserved

CONFIG_INFORMATION_0

Reserved

CONFIG_INFORMATION_1

Reserved

CONFIG_INFORMATION_2

Reserved

CONFIG_INFORMATION_3

Reserved

CONFIG_INFORMATION_4

Reserved

CONFIG_INFORMATION_5

Reserved

CONFIG_INFORMATION_6

Reserved

CONFIG_INFORMATION_7

Reserved

CONFIG_INFORMATION_8

Reserved

CONFIG_INFORMATION_9

Reserved

CONFIG_INFORMATION_10

Reserved

CONFIG_INFORMATION_11

Reserved

CONFIG_INFORMATION_12

Reserved

CONFIG_INFORMATION_13

Reserved

CONFIG_INFORMATION_14

Reserved

CONFIG_INFORMATION_15

Reserved

CONFIG_INFORMATION_16

Reserved

CONFIG_INFORMATION_17

Reserved

CONFIG_INFORMATION_18

Reserved

CONFIG_INFORMATION_19

Reserved

CONFIG_INFORMATION_20

Reserved

CONFIG_INFORMATION_21

Reserved

CONFIG_INFORMATION_22

Reserved

CONFIG_INFORMATION_23

Reserved

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

346

Chapter 24: Debugging

Table 24-1:

Memory IP Configuration XSDB Parameters (Contd)

Variable Name

Description

CONFIG_INFORMATION_24

Reserved

CONFIG_INFORMATION_25

Reserved

CONFIG_INFORMATION_26

Reserved

CONFIG_INFORMATION_27

Reserved

CONFIG_INFORMATION_28

Reserved

CONFIG_INFORMATION_29

Reserved

CONFIG_INFORMATION_30

Reserved

CONFIG_INFORMATION_31

Reserved

CONFIG_INFORMATION_32

Reserved

MR0_0

MR0[8:0] Setting

MR0_1

MR0[15:9] Setting

MR1_0

MR1[8:0] Setting

MR1_1

MR1[15:9] Setting

MR2_0

MR2[8:0] Setting

MR2_1

MR2[15:9] Setting

MR3_0

MR3[8:0] Setting

MR3_1

MR3[15:9] Setting

MR4_0

MR4[8:0] Setting

MR4_1

MR4[15:9] Setting

MR5_0

MR5[8:0] Setting

MR5_1

MR5[15:9] Setting

MR6_0

MR6[8:0] Setting

MR6_1

MR6[15:9] Setting

Memory_Code_Name

Reserved

Memory_Frequency_0

Memory tCK [8:0]

Memory_Frequency_1

Memory tCK [16:9]

Memory_Module_Type

Module Type
Component = 01
UDIMM = 02
SODIMM = 03
RDIMM = 04

Memory_Voltage

Memory Voltage
1.2V = 01
1.35V = 02
1.5V = 03

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

347

Chapter 24: Debugging

Table 24-1:

Memory IP Configuration XSDB Parameters (Contd)

Variable Name

Description

Mem_Type

Memory Type
DDR3 = 01
DDR4 = 02
RLDRAM 3 = 03
QDR II+ SRAM = 04

PLL_M

CLKFBOUT_MULT_F value used in the core TXPLLs.

PLL_D

DIVCLK_DIVIDE value using in the core TXPLLs.

MMCM_M

CLKFBOUT_MULT_F value used in the core MMCM.

MMCM_D

DIVCLK_DIVIDE value using in the core MMCM.

Controller_Info

Reserved

24. Copy all of the data reported and submit it as part of a WebCase. For more information
on opening a WebCase, see the Technical Support, page 337.

Debugging DDR3/DDR4 Designs

Calibration Stages
Figure 24-4 shows the overall flow of memory initialization and the different stages of
calibration.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

348

Chapter 24: Debugging

X-Ref Target - Figure 24-4

6\VWHP5HVHW

;,3+<%,6&

;6'%6HWXS

''5''56'5$0,QLWLDOL]DWLRQ

'46*DWH&DOLEUDWLRQ
'46*DWH
6DQLW\&KHFN
:ULWH/HYHOLQJ
<HV

5DQN
"
1R

5HDG7UDLQLQJ3HUELWGHVNHZ

5HDG'46&HQWHULQJ6LPSOH
5HDG
6DQLW\&KHFN

<HV

5DQN
"

:ULWH'46WR'4'HVNHZ

:ULWH'46WR'0'%,'HVNHZ
1R

:ULWH'46WR'46LPSOH

:ULWH'46WR'0'%,6LPSOH

,WHUDWLYHORRSWR
FDOLEUDWHPRUHUDQNV

:ULWH/DWHQF\&DOLEUDWLRQ

:ULWH5HDG
6DQLW\&KHFN

5HDG'46&HQWHULQJ&RPSOH[
:ULWH5HDG
6DQLW\&KHFN
5HDG95()7UDLQLQJ''52QO\
:ULWH5HDG
6DQLW\&KHFN

<HV

5DQN
"
1R

:ULWH'46WR'4&RPSOH[
:ULWH5HDG
6DQLW\&KHFN

:ULWH95()7UDLQLQJ''52QO\
:ULWH5HDG
6DQLW\&KHFN
5HDG'46&HQWHULQJ0XOWL5DQN$GMXVWPHQW
:ULWH5HDG
6DQLW\&KHFN

1R

$OO
'RQH"

5DQNFRXQW

<HV

0XOWL5DQN&KHFNVDQG$GMXVWPHQWV0XOWL5DQN2QO\
:ULWH5HDG
6DQLW\&KHFN
(QDEOH977UDFNLQJ
6DQLW\&KHFNUXQVIRUPXOWLUDQNDQGIRUDUDQNRWKHUWKDQWKH
ILUVWUDQN)RUH[DPSOHLIWKHUHZHUHWZRUDQNVLWZRXOGUXQRQ
WKHVHFRQGRQO\
6DQLW\&KHFNUXQVIRUPXOWLUDQNDQGJRHVWKURXJKDOORIWKH
UDQNV

Figure 24-4:

&DOLEUDWLRQ'RQH

PHY Overall Initialization and Calibration Sequence

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

349

Chapter 24: Debugging

Memory Initialization
The PHY executes a JEDEC-compliant DDR3/DDR4 initialization sequence following the
deassertion of system reset. Each DDR3/DDR4 SDRAM has a series of Mode registers
accessed through Mode register set (MRS) commands. These Mode registers determine
various SDRAM behaviors, such as burst length, read and write CAS latency, and additive
latency. Memory IP designs never issue a calibration failure during Memory Initialization.
All other initialization/calibration stages are reviewed in the following Debugging
Calibration Stages section.

Debug Signals
There are two types of debug signals used in Memory IP UltraScale debug. The first set is a
part of a debug interface that is always included in generated Memory IP UltraScale designs.
These signals include calibration status and tap settings that can be read at any time
throughout operation when the Hardware Manager is open using either Tcl commands or
the Memory IP Debug GUI.
The second type of debug signals are fully integrated in the IP when the Debug Signals
option in the Memory IP tool is enabled and when using the Memory IP Example Design.
However, these signals are currently only brought up in the RTL and not connected to the
debug VIO/ILA cores. Manual connection into either custom ILA/VIOs or the ILA generated
when the Debug Signals option is enabled is currently required. These signals are
documented in Table 24-2.
Table 24-2:

DDR3/DDR4 Debug Signals Used in Vivado Design Suite Debug Feature

Signal

Signal Width

Signal Description

init_calib_complete

[0:0]

Signifies the status of calibration.

1b0 = Calibration not complete
1b1 = Calibration completed successfully

cal_pre_status

[8:0]

Signifies the status of the memory core before calibration

has started. See Table 24-3 for decoding information.

cal_r*_status

[53:0]

Signifies the status of each stage of calibration. See

Table 24-4 for decoding information. See the following
relevant debug sections for usage information.
Note: The * indicates the rank value. Each rank has a separate
cal_r*_status bus.

cal_post_status

[8:0]

Signifies the status of the memory core after calibration has

finished. See Table 24-5 for decoding information.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

350

Chapter 24: Debugging

Table 24-2:

DDR3/DDR4 Debug Signals Used in Vivado Design Suite Debug Feature (Contd)
Signal

Signal Width

Signal Description

[2:0]

Calibration sequence indicator, when RTL is issuing

commands to the DRAM.
[0] = 1b0 -> Single Command Mode, one DRAM command
only. 1b1 -> Back-to-Back Command Mode. RTL is issuing
back-to-back commands.
[1] = Write Leveling Mode.
[2] = Extended write mode enabled, where extra data and
DQS pulses are sent to the DRAM before and after the
regular write burst.

dbg_cal_seq_cnt

[31:0]

Calibration command sequence count used when RTL is

issuing commands to the DRAM. Indicates how many
DRAM commands are requested (counts down to 0 when all
commands are sent out).

dbg_cal_seq_rd_cnt

[7:0]

Calibration read data burst count (counts down to 0 when

all expected bursts return), used when RTL is issuing read
commands to the DRAM.

dbg_rd_valid

[0:0]

Read Data Valid

dbg_cal_seq

Calibration byte selection (used to determine which byte is

currently selected and displayed in dbg_rd_data).

dbg_cmp_byte DQS Byte

dbg_cmp_byte

dbg_rd_data

[5:0]

[63:0]

000000

000001

000010

000011

000100

000101

000110

000111

001000

001001

001010

10

001011

11

001100

12

001101

13

001110

14

001111

15

010000

16

010001

17

Read Data from Input FIFOs

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

351

Chapter 24: Debugging

Table 24-2:

DDR3/DDR4 Debug Signals Used in Vivado Design Suite Debug Feature (Contd)
Signal

dbg_rd_data_cmp

Signal Width

Signal Description

[63:0]

Comparison of dbg_rd_data and dbg_expected_data

[63:0]

Displays the expected data during calibration stages that

use general interconnect-based data pattern comparison
such as Read per-bit deskew or read DQS centering
(complex).

dbg_cplx_config

[15:0]

Complex Calibration Configuration

[0] = Start
[1] = 1b0 selects the read pattern. 1b1 selects the write
pattern.
[3:2] = Rank selection
[8:4] = Byte selection
[15:9] = Number of loops through data pattern

dbg_cplx_status

[1:0]

Complex Calibration Status

[0] = Busy
[1] = Done

dbg_cplx_err_log

[63:0]

Complex calibration bitwise comparison result for all bits in

the selected byte. Comparison is stored for each bit (1b1
indicates compare mismatch):
{fall3, rise3, fall2, rise2, fall1, rise1, fall0, rise0}
[7:0] = Bit[0] of the byte
[15:8] = Bit[1] of the byte
[23:16] = Bit[2] of the byte
[31:24] = Bit[3] of the byte
[39:32] = Bit[4] of the byte
[47:40] = Bit[5] of the byte
[55:48] = Bit[6] of the byte
[63:56] = Bit[7] of the byte

dbg_io_address

[27:0]

MicroBlaze I/O Address Bus

dbg_pllGate

[0:0]

PLL Lock Indicator

dbg_phy2clb_fixdly_rdy_low

[BYTES 1 1:0]

XIPHY fixed delay ready signal (lower nibble)

dbg_phy2clb_fixdly_rdy_upp

[BYTES 1 1:0]

XIPHY fixed delay ready signal (upper nibble)

dbg_phy2clb_phy_rdy_low

[BYTES 1 1:0]

XIPHY PHY ready signal (lower nibble)

dbg_phy2clb_phy_rdy_upp

[BYTES 1 1:0]

XIPHY PHY ready signal (upper nibble)

Traffic_error

[BYTES 8 8 1:0]

Reserved

Traffic_clr_error

[0:0]

Reserved

Win_start

[3:0]

Reserved

dbg_expected_data

Determine the Failing Calibration Stage

XSDB can be used to very quickly determine which stage of calibration is failing, which byte/
nibble/bit is causing the failure, and how the algorithm is failing.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

352

Chapter 24: Debugging

Configure the device and, while the Hardware Manager is open, perform one of the
following:
1. Use the available XSDB Memory IP GUI to identify which stages have completed, which,
if any, has failed, and review the Memory IP properties window for a message on the
failure. Here is a sample of the GUI for a passing and failing case:
X-Ref Target - Figure 24-5

Figure 24-5:

Memory IP XSDB Debug GUI Example Calibration Pass

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

353

Chapter 24: Debugging

X-Ref Target - Figure 24-6

Figure 24-6:

Memory IP XSDB Debug GUI Example Calibration Failure

2. Manually analyze the XSDB output by running the following commands in the Tcl
prompt:
refresh_hw_device [lindex [get_hw_devices] 0]
report_property [lindex [get_hw_migs] 0]

Manually Analyzing the XSDB Output

The value of DDR_CAL_STATUS_RANK*_* can be used to determine which stages of
calibration have passed on a per rank basis.

RANK* within DDR_CAL_STATUS_RANK*_* denotes the physical DRAM RANK being

calibrated.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

354

Chapter 24: Debugging

The _* at the end of DDR_CAL_STATUS_RANK*_* can be decoded in the "XSDB Status

Reg" column in Table 24-4.

XSDB Bit represents the nine bits assigned to each XSDB Status register.

cal_r*_status represents the full port value used in simulation or when brought to
an ILA core.

Note: A 1 in each bit position signifies the corresponding stage of calibration completed.
Table 24-3:

DDR3/DDR4 Pre-Cal Status

XSDB Status Name

Bit

DDR_PRE_CAL_STATUS

Table 24-4:

Description

Pre-Calibration Step

Done

MicroBlaze has started up

Done

Reserved

Done

Reserved

Done

Reserved

Done

XSDB Setup Complete

Reserved

Reserved

Reserved

Reserved

DDR3/DDR4 DDR_CAL_STATUS_RANK*_* Decoding

XSDB
XSDB Bit Status Bus Bits (Sim) Description
Status Reg
0

Start

Done

Start

Done

Start

Done

Start

Done

Start

Done

10

Start

11

Done

12

Start

13

Done

14

Start

15

Done

Calibration Step
DQS Gate
Check for DQS gate
Write leveling
Read Per-bit Deskew
Reserved
Read DQS Centering (Simple)
Read Sanity Check
Write DQS-to-DQ Deskew

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

355

Chapter 24: Debugging

Table 24-4:

DDR3/DDR4 DDR_CAL_STATUS_RANK*_* Decoding (Contd)

XSDB
XSDB Bit Status Bus Bits (Sim) Description
Status Reg

16

Start

17

Done

18

Start

19

Done

20

Start

21

Done

22

Start

23

Done

24

Start

25

Done

26

Start

27

Done

28

Start

29

Done

30

Start

31

Done

32

Start

33

Done

34

Start

35

Done

36

Start

37

Done

38

Start

39

Done

40

Start

41

Done

42

Start

43

Done

44

Start

45

Done

46

Start

47

Done

48

Start

49

Done

Calibration Step
Write DQS-to-DM Deskew
Write DQS-to-DQ (Simple)
Write DQS-to-DM (Simple)
Reserved
Write Latency Calibration
Write/Read Sanity Check 0
Read DQS Centering (Complex)
Write/Read Sanity Check 1
Reserved
Write/Read Sanity Check 2
Write DQS-to-DQ (Complex)
Write DQS-to-DM (Complex)
Write/Read Sanity Check 3
Reserved
Write/Read Sanity Check 4
Read level multi-rank adjustment
Write/Read Sanity Check 5 (for more than 1 rank)

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

356

Chapter 24: Debugging

Table 24-4:

DDR3/DDR4 DDR_CAL_STATUS_RANK*_* Decoding (Contd)

XSDB
XSDB Bit Status Bus Bits (Sim) Description
Status Reg
5

50

Start

51

Done

52

Start

53

Done

Table 24-5:

Calibration Step
Multi-rank adjustments & Checks
Write/Read Sanity Check 6 (all ranks)

DDR3/DDR4 Post-Calibration Status

XSDB Status Name

DDR_POST_CAL_STATUS

Bit

Description

Post-Calibration Step

Running

Idle

Fail

Running

Read Margin Check (Reserved)

Running

Write Margin Check (Reserved)

DQS Gate Tracking

Reserved

Reserved

Reserved

Reserved

When the rank and calibration stage causing the failure are known, the failing byte, nibble,
and/or bit position and error status for the failure can be identified using the signals listed
in Table 24-6.
Table 24-6:

DDR3/DDR4 DDR_CAL_ERROR_0/_1/_CODE Decoding

Variable Name

Description

DDR_CAL_ERROR_0

Bit position failing

DDR_CAL_ERROR_1

Nibble or byte position failing

DDR_CAL_ERROR_CODE

Error code specific to the failing stage of calibration. See the failing stage
section below for details.

With these error codes, the failing stage of calibration, failing bit, nibble, and/or byte
positions, and error code are known. The next step is to review the failing stage in the
following section for specific debugging steps.

Understanding Calibration Warnings (Cal_warning)

A warning flag indicates something unexpected occurred but calibration can continue.
Warnings can occur for multiple bits or bytes. Therefore, a limit on the number of warnings
stored is not set. Warnings are outputs from the PHY, where the cal_warning signal is
asserted for a single clock cycle to indicate a new warning.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

357

Chapter 24: Debugging

In XSDB, the warnings are stored as part of the leftover address space in the block RAM used
to store the XSDB data. The amount of space left over for warnings is dependent on the
memory configuration (bus width, ranks, etc.). The Vivado GUI does not currently support
reading out the warnings. The following steps show how to manually read out the warnings.
1. Check the XSDB warnings fields to see if any warnings have occurred as listed in
Table 24-7. If CAL_WARNINGS_END is non-zero then at least one warning has occurred.
Table 24-7:

DDR3/DDR4 DDR_CAL_ERROR_0/_1/_CODE Decoding

Variable Name

Description

CAL_WARNINGS_START

Number of block RAM address locations used to store a single

warning (set to 2).

CAL_WARNINGS_END

Total number of warnings stored in the block RAM.

2. Determine the end of the regular XSDB address range. END_ADDR0 and END_ADDR1
together form the end of the XSDB address range in the block RAM. The full address is
made up by concatenating the two addresses together in binary (each made up of nine
bits). For example, END_ADDR0 = 0x0AA and END_ADDR1 = 0x004 means the end
address is 0x8AA (18b 00_0000_100 0_1010_1010).
3. At the Hardware Manager Tcl Console, use the following command to read out a single
warning:
read_hw -hw_core [ lindex [get_hw_cores] 0] 0 0x8AB 0x02

This command reads out the XSDB block RAM location for the address provided up
through the number of address locations requested. In the example above, the XSDB
end address is 0x8AA. Add 1 to this value to get to the warning storage area. The next
field (0x02 in the above example command) is the number of addresses to read from the
starting location. Multiple addresses can be read out by changing 0x02 to whatever
value is required.
4. The hex value read out is the raw data from the block RAM with four digits representing
one register value. For example:
a. A value of 00140000 is broken down into 0014 as the second register field and
0000 as the first register field where:
-

First field indicates bit/byte/nibble flag (depending on the warning)

Second field indicates the actual warning code, as shown in Table 24-8

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

358

Chapter 24: Debugging

Table 24-8:

DDR3/DDR4 DDR Warning Code Decoding

Stage of Calibration

Code (Hex)
Second
Address

First Address

Description

0x000

Reserved

Reserved

0x001

Reserved

Reserved

0x002

N/A

RTL XSDB block RAM setting smaller than code

computes range required.

0x003 to 0x00F

Reserved

Reserved

0x010

Byte

(DDR4 only) Sampled 1XX or 01X with initial CAS

read latency setting when expected to find 000 or
001.

0x011

Byte

When searching with fine taps all samples

returned 0 on GT_STATUS, did not find 1.

0x012

Byte

Did not find a stable 1 on GT_STATUS when

searching with fine taps.

0x013

N/A

(DDR3 only) DQS gate ran without BISC enabled.

0x014

Byte

(DDR3 only) Data failure seen after DQS gate

calibration for a given byte. XSDB contains the
data seen in the BUS_DATA_BURST field.

0x015 to 0x01F

Reserved

Reserved

0x020

Byte

Odelay offset computation from BISC results is 0.

0x021

Byte

Step size speed up computation from BISC results

is 0.

0x022

Byte

Did not find a stable 1 when searching with

ODELAY taps.

0x023

Byte

Lowest ODELAY setting is maximum ODELAY taps

allowed.

0x024 to 0x02F

Reserved

Reserved

0x030

Nibble

Small window found for a given nibble.

0x031 to 0x03F

Reserved

Reserved

0x040

Byte

Small window found for a given byte.

0x041

Byte

DM Calibration wanted to underflow the DQS

ODELAY.

0x042

Byte

DM Calibration wanted to overflow the DQS

ODELAY.

0x043 to 0x04F

Reserved

Reserved

Write Latency Calibration

(0x050 to 0x05F)

0x050 to 0x05F

Reserved

Reserved

Read V REF Calibration

(0x060 to 0x06F)

0x060 to 0x06F

Reserved

Reserved

Pre-Cal
(0x000 to 0x00F)

DQS Gate
(0x010 to 0x01F)

(0x020 to 0x02F)

Read DQS Centering

(0x030 to 0x03F)

Write DQS-to-DQ
Write DQS-to-DM
(0x040 to 0x04F)

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

359

Chapter 24: Debugging

Table 24-8:

DDR3/DDR4 DDR Warning Code Decoding (Contd)

Stage of Calibration

Code (Hex)
Second
Address

First Address

Description

0x070

Nibble

Readback write VREF value from DRAM does not

match expected value.

0x071 to 0x07F

Reserved

Reserved

0x080

Nibble

Final XSDB PQTR value did not match what was left
in the RIU.

0x081

Nibble

Final XSDB NQTR value did not match what was

left in the RIU.

0x082 to 0x08F

Reserved

Reserved

Multi-Rank Adjustments
and Checks
(0x090 to 0x09F)

0x090 to 0x09F

Reserved

Reserved

Write/Read Sanity Check

(0x100 to 0x10F)

0x100 to 0x10F

Reserved

Reserved

DQS Gate Tracking

(0x110 to 0x11F)

0x110 to 0x11F

Reserved

Reserved

Margin Check
(0x120 to 0x12F)

0x120 to 0x12F

Reserved

Reserved

0x130 to 0x1FF

Reserved

Reserved

Write V REF Calibration

(0x070 to 0x07F)

Read DQS Centering

Multi-Rank Adjustment
(0x080 to 0x08F)

Debugging DQS Gate Calibration Failures

Calibration Overview
During this stage of calibration, the read DQS preamble is detected and the gate to enable
data capture within the FPGA is calibrated to be one clock cycle before the first valid data on
DQ. The coarse and fine DQS gate taps (RL_DLY_COARSE and RL_DLY_FINE) are adjusted
during this stage. Read commands are issued with gaps in between to continually search for
the DQS preamble position. The DDR4 preamble training mode is enabled during this stage
to increase the low preamble period and aid in detection. During this stage of calibration,
only the read DQS signals are monitored and not the read DQ signals. DQS Preamble
Detection is performed sequentially on a per byte basis.
During this stage of calibration, the coarse taps are first adjusted while searching for the low
preamble position and the first rising DQS edge, in other words, a DQS pattern of 00X1.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

360

Chapter 24: Debugging

X-Ref Target - Figure 24-7

''5
''5
3UHDPEOHWUDLQLQJPRGH
;

Figure 24-7:

DDR3 vs. DDR4 Preamble

If the preamble is not found, the read latency is increased by one. The coarse taps are reset
and then adjusted again while searching for the low preamble and first rising DQS edge.
After the preamble position is properly detected, the fine taps are then adjusted to fine tune
and edge align the position of the sample clock with the DQS.

Debug
To determine the status of DQS Gate Calibration, click the DQS_GATE stage under the
Status window and view the results within the Memory IP Properties window. The message
displayed in the Memory IP Properties identifies how the stage failed, or notes if it passed
successfully.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

361

Chapter 24: Debugging

X-Ref Target - Figure 24-8

Figure 24-8:

Memory IP XSDB Debug GUI Example DQS Gate

The status of DQS Gate can also be determined by decoding the DDR_CAL_ERROR_0 and
DDR_CAL_ERROR_1 results according to Table 24-9. Execute the Tcl commands noted in the
XSDB Debug section to generate the XSDB output containing the signal results.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

362

Chapter 24: Debugging

Table 24-9:

DDR_CAL_ERROR Decode for DQS Preamble Detection Calibration

DQS
Gate DDR_CAL_ DDR_CAL_
ERROR_1 ERROR_0
Code

0x1

0x2

0x3

0x4

0x5

0x6

Byte

Logical
Nibble

Description

Recommended Debug Steps

Based on the calculated latency from

the MR register, back off and start
sampling. If the sample occurs too late
in the DQS burst and it cannot decrease
the latency, then issue an error.

Check the PCB routing guidelines

against the routing on the PCB being
tested. Measure the Chip Select and
the returning DQS and check if the
time of the returning DQS matches
the expected CAS latency. Check the
levels on the DQS signal itself.

Byte

Logical
Nibble

Expected Pattern not found on

GT_STATUS.

Check the DQS_GATE_PATTERN_*

stored in XSDB. This stores what the
DQS pattern found around the
expected CAS latency. More generic
version of error 0x4/0x5 where not
all samples found matched. Probe
the DQS when a read command
occurs and look at the signal levels
of the P/N pair. Check the VRP
resistor value.

Byte

Logical
Nibble

CAS latency is too low. Calibration starts

at a CAS latency (CL) minus 3; For
allowable CAS latencies, see Table 4-58,
page 145

Check CAS latency parameter in the

XSDB MR fields against what is
allowed in Table 4-58, page 145.

Pattern not found on GT_STATUS, all

samples were 0. Expecting to sample
the preamble.

Check power and pinout on the PCB/

Design. This is the error found when
the DRAM does not respond to the
Read command. Probe if the read
DQS is generated when a read
command is sent out.

Pattern not found on GT_STATUS, all

samples were 1. Expecting to sample
the preamble.

Check power and pinout on the PCB/

Design. This is the error found when
the DRAM does not respond to the
Read command. Probe if the read
DQS is generated when a read
command is sent out.

Could not find the 0->1 transition with

fine taps in at least tck (estimated) of
fine taps.

Check the BISC values in XSDB (for

the nibbles associated with the DQS)
to determine the 90 offset value in
taps. Check if any warnings are
generated, look if any are 0x13 or
0x014.
For DDR3, BISC must be run and a
data check is used to confirm the
DQS gate settings, but if the data is
wrong the algorithm keeps
searching and could end up in this
failure. Check data connections, vrp
settings, V REF resistor in the PCB (or
if internal V REF set properly for all
bytes).

Byte

Byte

Byte

Logical
Nibble

Logical
Nibble

Logical
Nibble

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

363

Chapter 24: Debugging

Table 24-9:

DDR_CAL_ERROR Decode for DQS Preamble Detection Calibration (Contd)

DQS DDR_CAL_ DDR_CAL_

Gate
Code ERROR_1 ERROR_0

Description

Recommended Debug Steps

0x7

Byte

Logical
Nibble

Underflow of coarse taps when trying to

limit maximum coarse tap setting.

0x8

Byte

Logical
Nibble

Violation of maximum read latency

limit.

Table 24-10 shows the signals and values adjusted or used during the DQS Preamble
Detection stage of calibration. The values can be analyzed in both successful and failing
calibrations to determine the resultant values and the consistency in results across resets.
These values can be found within the Memory IP core properties in the Hardware Manager
or by executing the Tcl commands noted in the XSDB Debug section.
Table 24-10:

Additional XSDB Signals of Interest During DQS Preamble Detection

Signal

Usage

Signal Description

DQS_GATE_COARSE_RANK*_BYTE*

One value per rank and

DQS group

Final RL_DLY_COARSE tap value.

DQS_GATE_FINE_CENTER_RANK*_BYTE*

One value per rank and

DQS group.

Final RL_DLY_FINE tap value. This is

adjusted during alignment of sample
clock to DQS.

DQS_GATE_FINE_LEFT_RANK*_BYTE*

One value per rank and

DQS group.

RL_DLY_FINE tap value when left edge was

detected.

DQS_GATE_FINE_RIGHT_RANK*_BYTE*

One value per rank and

DQS group.

RL_DLY_FINE tap value when right edge

was detected.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

364

Chapter 24: Debugging

Table 24-10:

Additional XSDB Signals of Interest During DQS Preamble Detection (Contd)

Signal

Usage

Signal Description

One value per rank and

DQS group.

The DQS pattern detected during DQS

preamble detection. When a DQS
Preamble Detection error occurs where
the pattern is not found
(DDR_CAL_ERROR code 0x0, 0x2, 0x4, or
0x5), the pattern seen during CL+1 is
saved here.
The full pattern could be up to 13 bits.
The first nine bits are stored on _0.
Overflow bits are stored on _1. Currently,
_2 is reserved. For example,
9b0_1100_1100
9b1_1001_1000
9b1_0011_0000
9b0_0110_0000
Examples shown here are not
comprehensive, as the expected pattern
looks like:
10b0X1X0X1X00
Where X above can be a 0 or 1. The LSB
within this signals is the pattern detected
when Coarse = 0, the next bit is the
pattern detected when Coarse = 1, etc.
Additionally, there can be up to three
padded zeros before start of the pattern.
In some cases, extra information of
interest is stored in the overflow register.
The full pattern stored can be:
13b0_0110_1100_0000
So the pattern is broken up and stored in
two locations:
9b0_0110_0000 <- PATTERN_0
9b0_0001_0011 <- PATTERN_1

DQS_GATE_READ_LATENCY_RANK*_BYTE*

One value per rank and

DQS group

Read Latency value last used during DQS

Preamble Detection. The Read Latency
field is limited to CAS latency -3 to CAS
latency + 7. If the DQS is toggling yet was
not found check the latency of the DQS
signal coming back in relation to the chip
select.

BISC_ALIGN_PQTR_NIBBLE*

One per nibble

Initial 0 offset value provided by BISC at

power-up.

BISC_ALIGN_NQTR_NIBBLE*

One per nibble

Initial 0 offset value provided by BISC at

power-up.

DQS_GATE_PATTERN_0/1/2_RANK*_BYTE*

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

365

Chapter 24: Debugging

Table 24-10:

Additional XSDB Signals of Interest During DQS Preamble Detection (Contd)

Signal

BISC_PQTR_NIBBLE*

BISC_NQTR_NIBBLE*

Usage

Signal Description

One per nibble

Initial 90 offset value provided by BISC at

power-up. Compute 90 value in taps by
taking (BISC_PQTR BISC_ALIGN_PQTR).
To estimate tap resolution take ( of the
memory clock period)/ (BISC_PQTR
BISC_ALIGN_PQTR). Useful for error code
0x6.

One per nibble

Initial 90 offset value provided by BISC at

power-up. Compute 90 value in taps by
taking (BISC_NQTR BISC_ALIGN_NQTR).
To estimate tap resolution take ( of the
memory clock period)/ (BISC_NQTR
BISC_ALIGN_NQTR). Useful for error code
0x6.

This is a sample of the results for the DQS Preamble Detection XSDB debug signals:
DQS_GATE_COARSE_RANK0_BYTE0
DQS_GATE_COARSE_RANK0_BYTE1
DQS_GATE_COARSE_RANK0_BYTE2
DQS_GATE_COARSE_RANK0_BYTE3
DQS_GATE_COARSE_RANK0_BYTE4
DQS_GATE_COARSE_RANK0_BYTE5
DQS_GATE_COARSE_RANK0_BYTE6
DQS_GATE_COARSE_RANK0_BYTE7
DQS_GATE_COARSE_RANK0_BYTE8
DQS_GATE_FINE_CENTER_RANK0_BYTE0
DQS_GATE_FINE_CENTER_RANK0_BYTE1
DQS_GATE_FINE_CENTER_RANK0_BYTE2
DQS_GATE_FINE_CENTER_RANK0_BYTE3
DQS_GATE_FINE_CENTER_RANK0_BYTE4
DQS_GATE_FINE_CENTER_RANK0_BYTE5
DQS_GATE_FINE_CENTER_RANK0_BYTE6
DQS_GATE_FINE_CENTER_RANK0_BYTE7
DQS_GATE_FINE_CENTER_RANK0_BYTE8
DQS_GATE_FINE_LEFT_RANK0_BYTE0
DQS_GATE_FINE_LEFT_RANK0_BYTE1
DQS_GATE_FINE_LEFT_RANK0_BYTE2
DQS_GATE_FINE_LEFT_RANK0_BYTE3
DQS_GATE_FINE_LEFT_RANK0_BYTE4
DQS_GATE_FINE_LEFT_RANK0_BYTE5
DQS_GATE_FINE_LEFT_RANK0_BYTE6
DQS_GATE_FINE_LEFT_RANK0_BYTE7
DQS_GATE_FINE_LEFT_RANK0_BYTE8
DQS_GATE_FINE_RIGHT_RANK0_BYTE0
DQS_GATE_FINE_RIGHT_RANK0_BYTE1
DQS_GATE_FINE_RIGHT_RANK0_BYTE2
DQS_GATE_FINE_RIGHT_RANK0_BYTE3
DQS_GATE_FINE_RIGHT_RANK0_BYTE4
DQS_GATE_FINE_RIGHT_RANK0_BYTE5
DQS_GATE_FINE_RIGHT_RANK0_BYTE6
DQS_GATE_FINE_RIGHT_RANK0_BYTE7
DQS_GATE_FINE_RIGHT_RANK0_BYTE8

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

007
006
007
007
008
008
008
008
008
005
02b
024
019
022
021
011
008
000
002
028
021
015
020
01f
00f
006
000
008
02f
028
01e
025
024
014
00b
001

Send Feedback

366

Chapter 24: Debugging

DQS_GATE_PATTERN_0_RANK0_BYTE0
DQS_GATE_PATTERN_0_RANK0_BYTE1
DQS_GATE_PATTERN_0_RANK0_BYTE2
DQS_GATE_PATTERN_0_RANK0_BYTE3
DQS_GATE_PATTERN_0_RANK0_BYTE4
DQS_GATE_PATTERN_0_RANK0_BYTE5
DQS_GATE_PATTERN_0_RANK0_BYTE6
DQS_GATE_PATTERN_0_RANK0_BYTE7
DQS_GATE_PATTERN_0_RANK0_BYTE8
DQS_GATE_PATTERN_1_RANK0_BYTE0
DQS_GATE_PATTERN_1_RANK0_BYTE1
DQS_GATE_PATTERN_1_RANK0_BYTE2
DQS_GATE_PATTERN_1_RANK0_BYTE3
DQS_GATE_PATTERN_1_RANK0_BYTE4
DQS_GATE_PATTERN_1_RANK0_BYTE5
DQS_GATE_PATTERN_1_RANK0_BYTE6
DQS_GATE_PATTERN_1_RANK0_BYTE7
DQS_GATE_PATTERN_1_RANK0_BYTE8
DQS_GATE_PATTERN_2_RANK0_BYTE0
DQS_GATE_PATTERN_2_RANK0_BYTE1
DQS_GATE_PATTERN_2_RANK0_BYTE2
DQS_GATE_PATTERN_2_RANK0_BYTE3
DQS_GATE_PATTERN_2_RANK0_BYTE4
DQS_GATE_PATTERN_2_RANK0_BYTE5
DQS_GATE_PATTERN_2_RANK0_BYTE6
DQS_GATE_PATTERN_2_RANK0_BYTE7
DQS_GATE_PATTERN_2_RANK0_BYTE8
DQS_GATE_READ_LATENCY_RANK0_BYTE0
DQS_GATE_READ_LATENCY_RANK0_BYTE1
DQS_GATE_READ_LATENCY_RANK0_BYTE2
DQS_GATE_READ_LATENCY_RANK0_BYTE3
DQS_GATE_READ_LATENCY_RANK0_BYTE4
DQS_GATE_READ_LATENCY_RANK0_BYTE5
DQS_GATE_READ_LATENCY_RANK0_BYTE6
DQS_GATE_READ_LATENCY_RANK0_BYTE7
DQS_GATE_READ_LATENCY_RANK0_BYTE8
BISC_ALIGN_NQTR_NIBBLE0
BISC_ALIGN_NQTR_NIBBLE1
BISC_ALIGN_NQTR_NIBBLE2
BISC_ALIGN_NQTR_NIBBLE3
BISC_ALIGN_NQTR_NIBBLE4
BISC_ALIGN_NQTR_NIBBLE5
BISC_ALIGN_NQTR_NIBBLE6
BISC_ALIGN_NQTR_NIBBLE7
BISC_ALIGN_NQTR_NIBBLE8
BISC_ALIGN_NQTR_NIBBLE9
BISC_ALIGN_NQTR_NIBBLE10
BISC_ALIGN_NQTR_NIBBLE11
BISC_ALIGN_NQTR_NIBBLE12
BISC_ALIGN_NQTR_NIBBLE13
BISC_ALIGN_NQTR_NIBBLE14
BISC_ALIGN_NQTR_NIBBLE15
BISC_ALIGN_NQTR_NIBBLE16
BISC_ALIGN_NQTR_NIBBLE17
BISC_ALIGN_PQTR_NIBBLE0
BISC_ALIGN_PQTR_NIBBLE1
BISC_ALIGN_PQTR_NIBBLE2
BISC_ALIGN_PQTR_NIBBLE3
BISC_ALIGN_PQTR_NIBBLE4

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

130
198
130
130
060
060
060
060
060
001
001
001
001
003
003
003
003
003
000
000
000
000
000
000
000
000
000
010
010
010
010
010
010
010
010
010
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
004
006
005
005
004

Send Feedback

367

Chapter 24: Debugging

BISC_ALIGN_PQTR_NIBBLE5
BISC_ALIGN_PQTR_NIBBLE6
BISC_ALIGN_PQTR_NIBBLE7
BISC_ALIGN_PQTR_NIBBLE8
BISC_ALIGN_PQTR_NIBBLE9
BISC_ALIGN_PQTR_NIBBLE10
BISC_ALIGN_PQTR_NIBBLE11
BISC_ALIGN_PQTR_NIBBLE12
BISC_ALIGN_PQTR_NIBBLE13
BISC_ALIGN_PQTR_NIBBLE14
BISC_ALIGN_PQTR_NIBBLE15
BISC_ALIGN_PQTR_NIBBLE16
BISC_ALIGN_PQTR_NIBBLE17
BISC_NQTR_NIBBLE0
BISC_NQTR_NIBBLE1
BISC_NQTR_NIBBLE2
BISC_NQTR_NIBBLE3
BISC_NQTR_NIBBLE4
BISC_NQTR_NIBBLE5
BISC_NQTR_NIBBLE6
BISC_NQTR_NIBBLE7
BISC_NQTR_NIBBLE8
BISC_NQTR_NIBBLE9
BISC_NQTR_NIBBLE10
BISC_NQTR_NIBBLE11
BISC_NQTR_NIBBLE12
BISC_NQTR_NIBBLE13
BISC_NQTR_NIBBLE14
BISC_NQTR_NIBBLE15
BISC_NQTR_NIBBLE16
BISC_NQTR_NIBBLE17
BISC_PQTR_NIBBLE0
BISC_PQTR_NIBBLE1
BISC_PQTR_NIBBLE2
BISC_PQTR_NIBBLE3
BISC_PQTR_NIBBLE4
BISC_PQTR_NIBBLE5
BISC_PQTR_NIBBLE6
BISC_PQTR_NIBBLE7
BISC_PQTR_NIBBLE8
BISC_PQTR_NIBBLE9
BISC_PQTR_NIBBLE10
BISC_PQTR_NIBBLE11
BISC_PQTR_NIBBLE12
BISC_PQTR_NIBBLE13
BISC_PQTR_NIBBLE14
BISC_PQTR_NIBBLE15
BISC_PQTR_NIBBLE16
BISC_PQTR_NIBBLE17

string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

006
003
004
007
006
003
006
004
004
004
006
004
007
030
02f
031
031
02e
030
02f
031
030
031
02f
030
02f
032
031
031
031
031
030
032
031
032
030
030
02e
02f
033
033
030
034
030
030
030
031
031
033

Expected Results
Table 24-11 provides expected results for the coarse, fine, and read latency parameters
during DQS Preamble Detection. These values can be compared to the results found in
hardware testing.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

368

Chapter 24: Debugging

Table 24-11:

Expected Results for DQS Preamble Detection Coarse/Fine Tap and RL

Parameter

Description

DQS_GATE_COARSE_RANK*_BYTE*

Final RL_DLY_COARSE tap value. Expected values 3-6 only.

DQS_GATE_FINE_CENTER_RANK*_BYTE*

Final RL_DLY_FINE tap value. Expected value should be

less than 90 degrees (use BISC values to estimate the 90
value) and between DQS_GATE_FINE_LEFT and
DQS_GATE_FINE_RIGHT.

DQS_GATE_READ_LATENCY_RANK*_BYTE*

Read Latency value last used during DQS Preamble

Detection. Expected value is dependent on the PCB trace
length but should be in the range CL-2 to CL+4.

Hardware Measurements
This is the first stage of calibration. Therefore, any general setup issue can result in a failure
during DQS Preamble Detection Calibration. The first items to verify are proper clocking and
reset setup as well as usage of unmodified Memory IP RTL that is generated specifically for
the SDRAM(s) in hardware. The General Checks, page 344 section should be verified when a
failure occurs during DQS Preamble Detection.
After the General Checks, page 344 have been verified, hardware measurements on DQS,
and specifically the DQS byte that fails during DQS Preamble Detection, should be captured
and analyzed. DQS must be toggling during DQS Preamble Detection. If this stage fails, after
failure, probe the failing DQS at the FPGA using a high quality scope and probes. When a
failure occurs, the calibration goes into an error loop routine, continually issuing read
commands to the DRAM to allow for probing of the PCB. While probing DQS, validate:
1. Continuous DQS pulses exist with gaps between each BL8 read.
2. The signal integrity of DQS:

Ensure VIL and VIH are met for the specific I/O Standard in use. For more
information, see the Kintex UltraScale FPGAs Data Sheet: DC and AC Switching
Characteristics (DS892) [Ref 2].

Look for 50% duty cycle periods.

Ensure that the signals have low jitter/noise that can result from any power supply
or board noise.

If DQS pulses are not present and the General Checks, page 344 have been verified, probe
the read commands at the SDAM and verify:
1. The appropriate read commands exist CS# = 0, RAS# = 1, CAS# = 0, WE# = 1.
2. The signal integrity of each command signal is valid.

Ensure VIL and VIH are met. For more information, see the JESD79-3F, DDR3 SDRAM
Standard and JESD79-4, DDR4 SDRAM Standard, JEDEC Solid State Technology
Association [Ref 1].

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

369

Chapter 24: Debugging

3. CK to command timing.
4. RESET# voltage level.
5. Memory initialization routine.

Debugging Write Leveling Calibration Failures

Calibration Overview
DDR3/DDR4 write leveling allows the controller to adjust each write DQS phase
independently with respect to the CK forwarded to the DDR3/DDR4 SDRAM device. This
compensates for the skew between DQS and CK and meets the tDQSS specification.
During write leveling, DQS is driven by the FPGA memory interface and DQ is driven by the
DDR3/DDR4 SDRAM device to provide feedback. DQS is delayed until the 0to 1 edge
transition on DQ is detected. The DQS delay is achieved using both ODELAY and coarse tap
delays.
After the edge transition is detected, the write leveling algorithm centers on the noise
region around the transition to maximize margin. This second step is completed with only
the use of ODELAY taps. Any reference to FINE is the ODELAY search.

Debug
To determine the status of Write Leveling Calibration, click the Write Leveling stage under
the Status window and view the results within the Memory IP Properties window. The
message displayed in Memory IP Properties identifies how the stage failed or notes if it
passed successfully.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

370

Chapter 24: Debugging

X-Ref Target - Figure 24-9

Figure 24-9:

Memory IP XSDB Debug GUI Example Write Leveling

The status of Write Leveling can also be determined by decoding the DDR_CAL_ERROR_0
and DDR_CAL_ERROR_1 results according to Table 24-12. Execute the Tcl commands noted
in the XSDB Debug section to generate the XSDB output containing the signal results.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

371

Chapter 24: Debugging

Table 24-12:

DDR_CAL_ERROR Decode for Write Leveling Calibration

Write
Leveling DDR_CAL_ DDR_CAL_
ERROR_1 ERROR_0
Code

0x1

Byte

N/A

Description

Recommended Debug Steps

Cannot find stable 0 region

For failures on the second rank of a

multi-rank DIMM, check if the DIMM
uses mirroring and make sure the
design generated matches what the
DIMM expects. Check the pinout and
connections of the address/control
bus, specifically A7 which is used to
power on the write leveling mode in
the DRAM.

0x2

Byte

N/A

Cannot find stable 1 region

Check XSDB BUS_DATA_BURST fields

to see what the data looked like. Check
if a single BIT is stuck at a certain
value. If possible, add an ILA to look at
the dbg_rd_data to check multiple
bursts of data.

0x3

Byte

N/A

Cannot find the left edge of noise

region with fine taps

Check the BISC values in XSDB (for the

nibbles associated with the DQS) to
determine the 90 offset value in taps.

0x4

Byte

N/A

Could not find the 0->1 transition

with ODELAY taps in at least 1 tck
(estimated) of ODELAY taps.

Check the BISC values in XSDB (for the

nibbles associated with the DQS) to
determine the 90 offset value in taps.

Table 24-13 describes the signals and values adjusted or used during the Write Leveling
stage of calibration. The values can be analyzed in both successful and failing calibrations to
determine the resultant values and the consistency in results across resets. These values can
be found within the Memory IP Core Properties within Hardware Manager or by executing
the Tcl commands noted in the XSDB Debug.
Table 24-13:

Signals of Interest for Write Leveling Calibration

Signal

Usage

Signal Description

WRLVL_COARSE_STABLE0 _RANK*_BYTE*

One per rank

per Byte

WRLVL course tap setting to find Stable 0.

WRLVL_COARSE_STABLE1 _RANK*_BYTE*

One per rank

per Byte

WRLVL coarse tap setting to find Stable 1 or

noise.

WRLVL_ODELAY_INITIAL_OFFSET_BYTE*

One per Byte

ODELAY Offset used during Write Leveling.

Used to estimate number of ODELAY taps to
equal one coarse tap, for offsetting alignment
during algorithm.

WRLVL_ODELAY_STABLE0_RANK*_BYTE*

One per rank

per Byte

Left side of noise region when edge aligned (or

last stable 0 received) before getting noisy data
or stable 1.

WRLVL_ODLEAY_STABLE1_ RANK*_BYTE*

One per rank

per Byte

Right side of noise region when edge aligned

(or first stable 1 received) after getting noisy
data or stable 0.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

372

Chapter 24: Debugging

Table 24-13:

Signals of Interest for Write Leveling Calibration (Contd)

Signal

Usage

Signal Description

WRLVL_ODELAY_CENTER_ RANK*_BYTE*

One per rank

per Byte

Midpoint between WRLVL_ODELAY_STABLE0

and WRLVL_ODELAY_STABLE1. Final ODELAY
setting for the byte after WRLVL.

WRLVL_
ODELAY_LAST_OFFSET_RANK*_BYTE*

One per rank

per Byte

Final Offset setting used in the algorithm (may

be smaller than
WRLVL_ODELAY_INITIAL_OFFSET_BYTE*)

WRLVL_ODELAY_LOWEST_COMMON_Byte*

One per Byte

Final ODELAY setting programmed into the RIU.

BUS_DATA_BURST
(Available in 2014.2 and later)

General purpose area for storing read bursts of

data. This register is intended to store up to
four bursts of data for a x8 byte. During Write
Leveling, the bus is being used to store the DQ
data that may be useful when an error occurs
(such as a stuck-at-bit) without having to check
general interconnect data.
See Interpreting BUS_DATA_BURST Data Pattern
for additional details.
During the first part of the algorithm data is
sampled coming back at multiple coarse taps,
and the data is stored in these locations. Given
the number of samples taken and the limitation
of space to store all samples, what is stored is
the value found on the bus across multiple
samples, as well as the last value seen for a
given setting.
The data is returned per bit and stored in a
32-bit register such that single bit data is in the
format of {f3, r3, f2, r2, f1, r1, f0, r0} (8-bits for a
single bit of a burst). A single general
interconnect 32-bit register holds data for bits
{3, 2, 1, 0} while another holds data for bits {7,
6, 5, 4}. For a x8 device, all bits are read in and
ORd together to create a sample. This
sample is used to determine stable 0 or stable
1. When dealing with multiple samples, if any
sample does not match with the first sample,
the data is marked as unstable internally
(0x01010101).
The register is split up such that:
Bus_Data_Burst_0_Bit0,
Bus_Data_Burst_0_Bit1,
Bus_Data_Burst_0_Bit2,
Bus_Data_Burst_0_Bit3
will hold the aggregate value found across all
samples for a given tap setting. This might be
for coarse = 0.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

373

Chapter 24: Debugging

Table 24-13:

Signals of Interest for Write Leveling Calibration (Contd)

Signal

Usage

Signal Description
Then the following:
Bus_Data_Burst_0_Bit4,
Bus_Data_Burst_0_Bit5,
Bus_Data_Burst_0_Bit6,
Bus_Data_Burst_0_Bit7
would hold the last single sample when taking
multiple samples. For example, if it is set up to
take five samples, this would hold the fifth
sample, while the previous bit locations would
hold the aggregate of all samples which might
be UNSTABLE (0x01010101). Unstable can easily
happen if the edges are close to being aligned
already.
Given that there are only four burst locations
yet the algorithm could try up to six coarse taps,
there are not enough locations to store all data
(4 & 5 would overwrite locations 0 & 1). Some
of the data will be overwritten in that case. This
is mostly to aid in what is actually seen on the
DQ bus as the coarse taps are adjusted. It
provides a window into the data as the DQS is
adjusted in relation to the CK for a full clock
cycle.
If the coarse adjustment is found in the first
step, a single location is used in case of a failure
in the fine search.
When no stable 0 is found during the fine
adjustment, the value received is stored at:
Bus_Data_Burst_0_Bit0, Bus_Data_Burst_0_Bit1,
Bus_Data_Burst_0_Bit2,
Bus_Data_Burst_0_Bit3
Much in the same way as before, 0 to 3 stores
the aggregate, while 4 to 7 stores the final
reading of a set of samples.

BUS_DATA_BURST
(Available in 2014.2 and later)
Continued

BISC_ALIGN_PQTR_NIBBLE*

One per nibble

Initial 0 offset value provided by BISC at

power-up.

BISC_ALIGN_NQTR_NIBBLE*

One per nibble

Initial 0 offset value provided by BISC at

power-up.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

374

Chapter 24: Debugging

Table 24-13:

Signals of Interest for Write Leveling Calibration (Contd)

Signal

BISC_PQTR_NIBBLE*

BISC_NQTR_NIBBLE*

Usage

Signal Description

One per nibble

Initial 90 offset value provided by BISC at

power-up. Compute 90 value in taps by taking
(BISC_PQTR BISC_ALIGN_PQTR). To estimate
tap resolution take ( of the memory clock
period)/ (BISC_PQTR BISC_ALIGN_PQTR).
Useful for error code 0x6.

One per nibble

Initial 90 offset value provided by BISC at

power-up. Compute 90 value in taps by taking
(BISC_NQTR BISC_ALIGN_NQTR). To estimate
tap resolution take ( of the memory clock
period)/ (BISC_NQTR BISC_ALIGN_NQTR).
Useful for error code 0x6.

This is a sample of results for the Write Leveling XSDB debug signals:
WRLVL_COARSE_STABLE0_RANK0_BYTE0
WRLVL_COARSE_STABLE0_RANK0_BYTE1
WRLVL_COARSE_STABLE0_RANK0_BYTE2
WRLVL_COARSE_STABLE0_RANK0_BYTE3
WRLVL_COARSE_STABLE0_RANK0_BYTE4
WRLVL_COARSE_STABLE0_RANK0_BYTE5
WRLVL_COARSE_STABLE0_RANK0_BYTE6
WRLVL_COARSE_STABLE0_RANK0_BYTE7
WRLVL_COARSE_STABLE0_RANK0_BYTE8
WRLVL_COARSE_STABLE1_RANK0_BYTE0
WRLVL_COARSE_STABLE1_RANK0_BYTE1
WRLVL_COARSE_STABLE1_RANK0_BYTE2
WRLVL_COARSE_STABLE1_RANK0_BYTE3
WRLVL_COARSE_STABLE1_RANK0_BYTE4
WRLVL_COARSE_STABLE1_RANK0_BYTE5
WRLVL_COARSE_STABLE1_RANK0_BYTE6
WRLVL_COARSE_STABLE1_RANK0_BYTE7
WRLVL_COARSE_STABLE1_RANK0_BYTE8
WRLVL_ODELAY_CENTER_RANK0_BYTE0
WRLVL_ODELAY_CENTER_RANK0_BYTE1
WRLVL_ODELAY_CENTER_RANK0_BYTE2
WRLVL_ODELAY_CENTER_RANK0_BYTE3
WRLVL_ODELAY_CENTER_RANK0_BYTE4
WRLVL_ODELAY_CENTER_RANK0_BYTE5
WRLVL_ODELAY_CENTER_RANK0_BYTE6
WRLVL_ODELAY_CENTER_RANK0_BYTE7
WRLVL_ODELAY_CENTER_RANK0_BYTE8
WRLVL_ODELAY_INITIAL_OFFSET_BYTE0
WRLVL_ODELAY_INITIAL_OFFSET_BYTE1
WRLVL_ODELAY_INITIAL_OFFSET_BYTE2
WRLVL_ODELAY_INITIAL_OFFSET_BYTE3
WRLVL_ODELAY_INITIAL_OFFSET_BYTE4
WRLVL_ODELAY_INITIAL_OFFSET_BYTE5
WRLVL_ODELAY_INITIAL_OFFSET_BYTE6
WRLVL_ODELAY_INITIAL_OFFSET_BYTE7
WRLVL_ODELAY_INITIAL_OFFSET_BYTE8
WRLVL_ODELAY_LAST_OFFSET_RANK0_BYTE0
WRLVL_ODELAY_LAST_OFFSET_RANK0_BYTE1

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

003
000
000
000
002
001
001
001
001
004
001
001
001
003
002
002
002
002
02b
010
020
02b
008
02c
01b
02b
016
016
017
016
016
017
017
017
017
017
016
017

Send Feedback

375

Chapter 24: Debugging

WRLVL_ODELAY_LAST_OFFSET_RANK0_BYTE2
WRLVL_ODELAY_LAST_OFFSET_RANK0_BYTE3
WRLVL_ODELAY_LAST_OFFSET_RANK0_BYTE4
WRLVL_ODELAY_LAST_OFFSET_RANK0_BYTE5
WRLVL_ODELAY_LAST_OFFSET_RANK0_BYTE6
WRLVL_ODELAY_LAST_OFFSET_RANK0_BYTE7
WRLVL_ODELAY_LAST_OFFSET_RANK0_BYTE8
WRLVL_ODELAY_LOWEST_COMMON_BYTE0
WRLVL_ODELAY_LOWEST_COMMON_BYTE1
WRLVL_ODELAY_LOWEST_COMMON_BYTE2
WRLVL_ODELAY_LOWEST_COMMON_BYTE3
WRLVL_ODELAY_LOWEST_COMMON_BYTE4
WRLVL_ODELAY_LOWEST_COMMON_BYTE5
WRLVL_ODELAY_LOWEST_COMMON_BYTE6
WRLVL_ODELAY_LOWEST_COMMON_BYTE7
WRLVL_ODELAY_LOWEST_COMMON_BYTE8
WRLVL_ODELAY_STABLE0_RANK0_BYTE0
WRLVL_ODELAY_STABLE0_RANK0_BYTE1
WRLVL_ODELAY_STABLE0_RANK0_BYTE2
WRLVL_ODELAY_STABLE0_RANK0_BYTE3
WRLVL_ODELAY_STABLE0_RANK0_BYTE4
WRLVL_ODELAY_STABLE0_RANK0_BYTE5
WRLVL_ODELAY_STABLE0_RANK0_BYTE6
WRLVL_ODELAY_STABLE0_RANK0_BYTE7
WRLVL_ODELAY_STABLE0_RANK0_BYTE8
WRLVL_ODELAY_STABLE1_RANK0_BYTE0
WRLVL_ODELAY_STABLE1_RANK0_BYTE1
WRLVL_ODELAY_STABLE1_RANK0_BYTE2
WRLVL_ODELAY_STABLE1_RANK0_BYTE3
WRLVL_ODELAY_STABLE1_RANK0_BYTE4
WRLVL_ODELAY_STABLE1_RANK0_BYTE5
WRLVL_ODELAY_STABLE1_RANK0_BYTE6
WRLVL_ODELAY_STABLE1_RANK0_BYTE7
WRLVL_ODELAY_STABLE1_RANK0_BYTE8
BISC_ALIGN_NQTR_NIBBLE0
BISC_ALIGN_NQTR_NIBBLE1
BISC_ALIGN_NQTR_NIBBLE2
BISC_ALIGN_NQTR_NIBBLE3
BISC_ALIGN_NQTR_NIBBLE4
BISC_ALIGN_NQTR_NIBBLE5
BISC_ALIGN_NQTR_NIBBLE6
BISC_ALIGN_NQTR_NIBBLE7
BISC_ALIGN_NQTR_NIBBLE8
BISC_ALIGN_NQTR_NIBBLE9
BISC_ALIGN_NQTR_NIBBLE10
BISC_ALIGN_NQTR_NIBBLE11
BISC_ALIGN_NQTR_NIBBLE12
BISC_ALIGN_NQTR_NIBBLE13
BISC_ALIGN_NQTR_NIBBLE14
BISC_ALIGN_NQTR_NIBBLE15
BISC_ALIGN_NQTR_NIBBLE16
BISC_ALIGN_NQTR_NIBBLE17
BISC_ALIGN_PQTR_NIBBLE0
BISC_ALIGN_PQTR_NIBBLE1
BISC_ALIGN_PQTR_NIBBLE2
BISC_ALIGN_PQTR_NIBBLE3
BISC_ALIGN_PQTR_NIBBLE4
BISC_ALIGN_PQTR_NIBBLE5
BISC_ALIGN_PQTR_NIBBLE6

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

016
016
017
017
017
017
017
000
000
000
000
000
000
000
000
000
028
00d
01d
027
004
027
017
027
014
02e
014
023
02f
00c
031
020
030
018
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
004
006
005
005
004
006
003

Send Feedback

376

Chapter 24: Debugging

BISC_ALIGN_PQTR_NIBBLE7
BISC_ALIGN_PQTR_NIBBLE8
BISC_ALIGN_PQTR_NIBBLE9
BISC_ALIGN_PQTR_NIBBLE10
BISC_ALIGN_PQTR_NIBBLE11
BISC_ALIGN_PQTR_NIBBLE12
BISC_ALIGN_PQTR_NIBBLE13
BISC_ALIGN_PQTR_NIBBLE14
BISC_ALIGN_PQTR_NIBBLE15
BISC_ALIGN_PQTR_NIBBLE16
BISC_ALIGN_PQTR_NIBBLE17
BISC_NQTR_NIBBLE0
BISC_NQTR_NIBBLE1
BISC_NQTR_NIBBLE2
BISC_NQTR_NIBBLE3
BISC_NQTR_NIBBLE4
BISC_NQTR_NIBBLE5
BISC_NQTR_NIBBLE6
BISC_NQTR_NIBBLE7
BISC_NQTR_NIBBLE8
BISC_NQTR_NIBBLE9
BISC_NQTR_NIBBLE10
BISC_NQTR_NIBBLE11
BISC_NQTR_NIBBLE12
BISC_NQTR_NIBBLE13
BISC_NQTR_NIBBLE14
BISC_NQTR_NIBBLE15
BISC_NQTR_NIBBLE16
BISC_NQTR_NIBBLE17
BISC_PQTR_NIBBLE0
BISC_PQTR_NIBBLE1
BISC_PQTR_NIBBLE2
BISC_PQTR_NIBBLE3
BISC_PQTR_NIBBLE4
BISC_PQTR_NIBBLE5
BISC_PQTR_NIBBLE6
BISC_PQTR_NIBBLE7
BISC_PQTR_NIBBLE8
BISC_PQTR_NIBBLE9
BISC_PQTR_NIBBLE10
BISC_PQTR_NIBBLE11
BISC_PQTR_NIBBLE12
BISC_PQTR_NIBBLE13
BISC_PQTR_NIBBLE14
BISC_PQTR_NIBBLE15
BISC_PQTR_NIBBLE16
BISC_PQTR_NIBBLE17

string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

004
007
006
003
006
004
004
004
006
004
007
030
02f
031
031
02e
030
02f
031
030
031
02f
030
02f
032
031
031
031
031
030
032
031
032
030
030
02e
02f
033
033
030
034
030
030
030
031
031
033

Expected Results
The tap variance across DQS byte groups vary greatly due to the difference in trace lengths
with fly-by-routing. When an error occurs, an error loop is started that generates DQS
strobes to the DRAM while still in WRLVL mode. This error loop runs continuously until a
reset or power cycle to aid in debug. Table 24-14 provides expected results for the coarse
and fine parameters during Write Leveling.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

377

Chapter 24: Debugging

Table 24-14:

Expected Write Leveling Results

Parameter

Description

WRLVL_COARSE_STABLE0_RANK*_BYTE*

WRLVL Coarse tap setting after calibration. Expected values

0 to 4.

WRLVL_ODELAY_STABLE1_RANK*_BYTE*

WRLVL ODELAY tap setting to find Stable 1 or noise.

Expected values 1 to 5.

WRLVL_ODELAY_CENTER_ RANK*_BYTE*

Midpoint between WRLVL_ODELAY_STABLE0 and

WRLVL_ODELAY_STABLE1. Expected value should be less
than 90 (use BISC values to estimate the 90 value) and
between WRLVL_FINE_LEFT and WRLVL_FINE_RIGHT.

Hardware Measurements
The following measurements can be made during the error loop or when triggering on the
status bit that indicates the start of WRLVL (dbg_cal_seq[1] = 1b1).

Verify DQS and CK are toggling on the board. The FPGA sends DQS and CK during Write
Leveling. If they are not toggling, something is wrong with the setup and the General
Checks, page 344 section should be thoroughly reviewed.

Verify fly-by-routing is implemented correctly on the board.

Verify CK to DQS trace matching. The required matching is documented with the
UltraScale Architecture PCB Design and Pin Planning User Guide (UG583) [Ref 6]. Failure
to adhere to this spec can result in Write Leveling failures.

Trigger on the start of Write Leveling by bringing dbg_cal_seq[1] to an I/O and

using the rising edge (1b1) as the scope trigger.
Monitor the following:

MRS command at the memory to enable Write Leveling Mode. The Mode registers
must be properly set up to enable Write Leveling. Specifically, address bit A7 must
be correct. If the part chosen in the Memory IP is not accurate or there is an issue
with the connection of the address bits on the board, this could be an issue. If the
Mode registers are not set up to enable Write Leveling, the 0-to-1 transition is not
seen.
Note: For dual rank design when address mirroring is used, address bit A7 is not the same
between the two ranks.

Verify the ODT pin is connected and being asserted properly during the DQS
toggling.

Check the signal levels of all the DQ bits being returned. Any stuck-at-bits (Low/
High) or floating bits that are not being driven to a given rail can cause issues.

Verify the DQS to CK relationship changes as the algorithm makes adjustments to

the DQS. Check the DQ value being returned as this relationship changes.

For DDR3 check the V REF voltage, while for DDR4 check the V REF settings are correct
in the design.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

378

Chapter 24: Debugging

Using the Vivado Hardware Manager and while running the Memory IP Example Design
with Debug Signals enabled, set the trigger to dbg_cal_seq = 0R0 (R signifies rising
edge). The following simulation example shows how the debug signals should behave
during successful Write Leveling.

X-Ref Target - Figure 24-10

Figure 24-10:

RTL Debug Signals during Write Leveling

Read Leveling Calibration Overview

Calibration Overview
Read Leveling is performed over multiple stages to maximize the data eye and center the
internal read sampling clock in the read DQ window for robust sampling. To perform this,
Read Leveling performs the following sequential steps:
1. Maximizes the DQ eye by removing skew and OCV effects using per bit read DQ deskew.

See Debugging Per-Bit Deskew Failures for details.

2. Sweeps DQS across all DQ bits and finds the center of the data eye using both easy
(Multi-Purpose register data pattern) and complex data patterns. Centering of the data
eye is completed for both the DQS and DQS#.

See Debugging Read MPR DQS Centering Failures for details.

See Debugging Complex Pattern Calibration Failures section for details.

3. Post calibration, continuously maintains the relative delay of DQS versus DQ across the
VT range.

Debugging Read Per-Bit Deskew Failures

Calibration Overview
Per-bit deskew is performed on a per-bit basis whereas Read Leveling DQS centering is
performed on a per-nibble basis.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

379

Chapter 24: Debugging

During per-bit deskew, Read Leveling Calibration, a pattern of 0000000_11111111 is
written and read back while DQS adjustments (PQTR and NQTR individual fine taps on DQS)
and DQ adjustments (IDELAY) are made.
At the end of this stage, the DQ bits are internally deskewed to the left edge of the incoming
DQS.

Debug
To determine the status of Read Per-Bit Deskew Calibration, click the Read Per-Bit Deskew
stage under the Status window and view the results within the Memory IP Properties
window. The message displayed in Memory IP Properties identifies how the stage failed or
notes if it passed successfully.
X-Ref Target - Figure 24-11

Figure 24-11:

Memory IP XSDB Debug GUI Example Read Per-Bit Deskew

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

380

Chapter 24: Debugging

The status of Read Per-Bit Deskew can also be determined by decoding the
DDR_CAL_ERROR_0 and DDR_CAL_ERROR_1 results according to Table 24-15. Execute the Tcl
commands noted in the XSDB Debug section to generate the XSDB output containing the
signal results.
Table 24-15:

DDR_CAL_ERROR Decode for Read Deskew Calibration

Per-Bit
Deskew
DDR_CAL_ DDR_CAL_
DDR_CAL_
ERROR_1 ERROR_0
ERROR_CODE

Description

Recommended Debug Steps

0x1

Nibble

Bit

No valid data found for a given

bit in the nibble (deskew
pattern)

Check the BUS_DATA_BURST fields in

XSDB. Check the dbg_rd_data,
dbg_rd_data_cmp, and
dbg_expected_data signals in the ILA.
Check the pinout and look for any
STUCK-AT-BITs, check vrp resistor,
V REF resistor. Check BISC_PQTR,
BISC_NQTR for starting offset
between rising/falling clocks. Probe
the board and check for the returning
pattern to determine if the initial write
to the DRAM happened properly, or if
it is a read failure. Check ODT if it is a
write issue.

0xF

Nibble

Bit

Timeout error waiting for read

data to return.

Check the dbg_cal_seq_rd_cnt and

dbg_cal_seq_cnt.

Table 24-16 describes the signals and values adjusted or used during the Read Per-Bit
Deskew stage of calibration. The values can be analyzed in both successful and failing
calibrations to determine the resultant values and the consistency in results across resets.
These values can be found within the Memory IP Core Properties within Hardware
Manager or by executing the Tcl commands noted in the XSDB Debug section.
Table 24-16:

Signals of Interest for Read Deskew Calibration

Signal

Usage

Signal Description

RDLVL_DESKEW_PQTR_NIBBLE*

One per nibble

Read leveling PQTR when left edge of read data valid

window is detected during per bit read DQ deskew.

RDLVL_DESKEW_NQTR_NIBBLE*

One per nibble

Read leveling NQTR when left edge of read data valid

window is detected during per bit read DQ deskew.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

381

Chapter 24: Debugging

Table 24-16:

Signals of Interest for Read Deskew Calibration

Signal

Usage

RDLVL_DESKEW_IDELAY_BYTE_BIT*

One per Bit

Signal Description
Read leveling IDELAY delay value found during per bit
read DQ deskew.
When a failure occurs during deskew, some data is saved
to indicate what the data looks like for a byte across some
tap settings for a given byte the failure occurred for (DQ
IDELAY is left wherever the algorithm left it).
Deskew (Figure 24-12): BUS_DATA_BURST_0 holds first
part of two burst data (should be all 0) when PQTR/NQTR
set to 0 taps.
BUS_DATA_BURST_1 holds second part of two burst data
(should be all 1). when PQTR/NQTR set to 0 taps.
BUS_DATA_BURST_2 holds first part of two burst data
(should be all 0) when PQTR/NQTR set to 90.
BUS_DATA_BURST_3 holds second part of two burst data
(should be all 1) when PQTR/NQTR set to 90.
See Interpreting BUS_DATA_BURST Data Pattern for
additional details.

BUS_DATA_BURST (2014.3+)

Figure 24-12 shows an example of the behavior described in the BUS_DATA_BURST

description in Table 24-16.
X-Ref Target - Figure 24-12

%86B'$7$B%8567B

%86B'$7$B%8567B
3475
1475
WDSV

[

'4

GHJUHH
RIIVHW

[))

%86B'$7$B%8567B

%86B'$7$B%8567B

3475
1475
GHJUHH
RIIVHW

'4

[

[))

;

Figure 24-12:

Deskew Error (XSDB BUS_DATA_BURST)

Data swizzling (bit reordering) is completed within the UltraScale PHY. Therefore, the data
visible on BUS_DATA_BURST and a scope in hardware is ordered differently compared to
what would be seen in ChipScope. Figure 24-13 is an example of how the data is
converted.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

382

Chapter 24: Debugging

Note: For this stage of calibration which is using a data pattern of all 0s or all 1s, the conversion is
not visible.

X-Ref Target - Figure 24-13

Figure 24-13:

Expected Read Back 0000_0000 Data Pattern

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

383

Chapter 24: Debugging

X-Ref Target - Figure 24-14

Figure 24-14:

Expected Read Back 1111_1111 Data Pattern

This is a sample of results for the Read Per-Bit Deskew XSDB debug signals:
RDLVL_DESKEW_IDELAY_BYTE0_BIT0
RDLVL_DESKEW_IDELAY_BYTE0_BIT1
RDLVL_DESKEW_IDELAY_BYTE0_BIT2
RDLVL_DESKEW_IDELAY_BYTE0_BIT3
RDLVL_DESKEW_IDELAY_BYTE0_BIT4
RDLVL_DESKEW_IDELAY_BYTE0_BIT5
RDLVL_DESKEW_IDELAY_BYTE0_BIT6
RDLVL_DESKEW_IDELAY_BYTE0_BIT7
RDLVL_DESKEW_IDELAY_BYTE1_BIT0
RDLVL_DESKEW_IDELAY_BYTE1_BIT1
RDLVL_DESKEW_IDELAY_BYTE1_BIT2
RDLVL_DESKEW_IDELAY_BYTE1_BIT3
RDLVL_DESKEW_IDELAY_BYTE1_BIT4
RDLVL_DESKEW_IDELAY_BYTE1_BIT5
RDLVL_DESKEW_IDELAY_BYTE1_BIT6
RDLVL_DESKEW_IDELAY_BYTE1_BIT7
RDLVL_DESKEW_IDELAY_BYTE2_BIT0
RDLVL_DESKEW_IDELAY_BYTE2_BIT1
RDLVL_DESKEW_IDELAY_BYTE2_BIT2
RDLVL_DESKEW_IDELAY_BYTE2_BIT3

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

02e
02e
02f
030
02f
02f
033
030
02f
032
02e
032
030
032
030
031
033
030
02e
028

Send Feedback

384

Chapter 24: Debugging

RDLVL_DESKEW_IDELAY_BYTE2_BIT4
RDLVL_DESKEW_IDELAY_BYTE2_BIT5
RDLVL_DESKEW_IDELAY_BYTE2_BIT6
RDLVL_DESKEW_IDELAY_BYTE2_BIT7
RDLVL_DESKEW_IDELAY_BYTE3_BIT0
RDLVL_DESKEW_IDELAY_BYTE3_BIT1
RDLVL_DESKEW_IDELAY_BYTE3_BIT2
RDLVL_DESKEW_IDELAY_BYTE3_BIT3
RDLVL_DESKEW_IDELAY_BYTE3_BIT4
RDLVL_DESKEW_IDELAY_BYTE3_BIT5
RDLVL_DESKEW_IDELAY_BYTE3_BIT6
RDLVL_DESKEW_IDELAY_BYTE3_BIT7
RDLVL_DESKEW_IDELAY_BYTE4_BIT0
RDLVL_DESKEW_IDELAY_BYTE4_BIT1
RDLVL_DESKEW_IDELAY_BYTE4_BIT2
RDLVL_DESKEW_IDELAY_BYTE4_BIT3
RDLVL_DESKEW_IDELAY_BYTE4_BIT4
RDLVL_DESKEW_IDELAY_BYTE4_BIT5
RDLVL_DESKEW_IDELAY_BYTE4_BIT6
RDLVL_DESKEW_IDELAY_BYTE4_BIT7
RDLVL_DESKEW_IDELAY_BYTE5_BIT0
RDLVL_DESKEW_IDELAY_BYTE5_BIT1
RDLVL_DESKEW_IDELAY_BYTE5_BIT2
RDLVL_DESKEW_IDELAY_BYTE5_BIT3
RDLVL_DESKEW_IDELAY_BYTE5_BIT4
RDLVL_DESKEW_IDELAY_BYTE5_BIT5
RDLVL_DESKEW_IDELAY_BYTE5_BIT6
RDLVL_DESKEW_IDELAY_BYTE5_BIT7
RDLVL_DESKEW_IDELAY_BYTE6_BIT0
RDLVL_DESKEW_IDELAY_BYTE6_BIT1
RDLVL_DESKEW_IDELAY_BYTE6_BIT2
RDLVL_DESKEW_IDELAY_BYTE6_BIT3
RDLVL_DESKEW_IDELAY_BYTE6_BIT4
RDLVL_DESKEW_IDELAY_BYTE6_BIT5
RDLVL_DESKEW_IDELAY_BYTE6_BIT6
RDLVL_DESKEW_IDELAY_BYTE6_BIT7
RDLVL_DESKEW_IDELAY_BYTE7_BIT0
RDLVL_DESKEW_IDELAY_BYTE7_BIT1
RDLVL_DESKEW_IDELAY_BYTE7_BIT2
RDLVL_DESKEW_IDELAY_BYTE7_BIT3
RDLVL_DESKEW_IDELAY_BYTE7_BIT4
RDLVL_DESKEW_IDELAY_BYTE7_BIT5
RDLVL_DESKEW_IDELAY_BYTE7_BIT6
RDLVL_DESKEW_IDELAY_BYTE7_BIT7
RDLVL_DESKEW_IDELAY_BYTE8_BIT0
RDLVL_DESKEW_IDELAY_BYTE8_BIT1
RDLVL_DESKEW_IDELAY_BYTE8_BIT2
RDLVL_DESKEW_IDELAY_BYTE8_BIT3
RDLVL_DESKEW_IDELAY_BYTE8_BIT4
RDLVL_DESKEW_IDELAY_BYTE8_BIT5
RDLVL_DESKEW_IDELAY_BYTE8_BIT6
RDLVL_DESKEW_IDELAY_BYTE8_BIT7
RDLVL_DESKEW_NQTR_NIBBLE0
RDLVL_DESKEW_NQTR_NIBBLE1
RDLVL_DESKEW_NQTR_NIBBLE2
RDLVL_DESKEW_NQTR_NIBBLE3
RDLVL_DESKEW_NQTR_NIBBLE4
RDLVL_DESKEW_NQTR_NIBBLE5
RDLVL_DESKEW_NQTR_NIBBLE6

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

02d
02e
02e
02e
02f
030
02e
02e
02e
02c
028
02c
02d
031
02c
032
030
029
031
02e
029
02a
02b
02b
028
02c
02c
026
028
030
025
02d
02c
030
032
02d
029
02a
030
02d
02c
02a
02b
02b
029
02e
02b
02c
02e
02c
031
02f
000
000
000
000
000
000
001

Send Feedback

385

Chapter 24: Debugging

RDLVL_DESKEW_NQTR_NIBBLE7
RDLVL_DESKEW_NQTR_NIBBLE8
RDLVL_DESKEW_NQTR_NIBBLE9
RDLVL_DESKEW_NQTR_NIBBLE10
RDLVL_DESKEW_NQTR_NIBBLE11
RDLVL_DESKEW_NQTR_NIBBLE12
RDLVL_DESKEW_NQTR_NIBBLE13
RDLVL_DESKEW_NQTR_NIBBLE14
RDLVL_DESKEW_NQTR_NIBBLE15
RDLVL_DESKEW_NQTR_NIBBLE16
RDLVL_DESKEW_NQTR_NIBBLE17
RDLVL_DESKEW_PQTR_NIBBLE0
RDLVL_DESKEW_PQTR_NIBBLE1
RDLVL_DESKEW_PQTR_NIBBLE2
RDLVL_DESKEW_PQTR_NIBBLE3
RDLVL_DESKEW_PQTR_NIBBLE4
RDLVL_DESKEW_PQTR_NIBBLE5
RDLVL_DESKEW_PQTR_NIBBLE6
RDLVL_DESKEW_PQTR_NIBBLE7
RDLVL_DESKEW_PQTR_NIBBLE8
RDLVL_DESKEW_PQTR_NIBBLE9
RDLVL_DESKEW_PQTR_NIBBLE10
RDLVL_DESKEW_PQTR_NIBBLE11
RDLVL_DESKEW_PQTR_NIBBLE12
RDLVL_DESKEW_PQTR_NIBBLE13
RDLVL_DESKEW_PQTR_NIBBLE14
RDLVL_DESKEW_PQTR_NIBBLE15
RDLVL_DESKEW_PQTR_NIBBLE16
RDLVL_DESKEW_PQTR_NIBBLE17

string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

002
000
000
000
000
000
002
001
000
000
000
000
003
000
001
002
000
000
000
003
002
001
004
001
000
000
000
000
002

Expected Results

Look at the individual IDELAY taps for each bit. The IDELAY taps should only vary by 0 to
20 taps, and is dependent on PCB trace delays. For Deskew, the IDELAY taps are
typically in the 50 to 70 tap range, while PQTR and NQTR are usually in the 0 to 5 tap
range.

Determine if any bytes completed successfully. The per-bit algorithm sequentially steps
through each DQS byte.

Hardware Measurements
1. Probe the write commands and read commands at the memory:

Write = cs_n = 1; ras_n = 0; cas_n = 1; we_n = 1; act_n = 1 (DDR4 only)

Read = cs_n = 1; ras_n = 0; cas_n = 1; we_n = 0; act_n = 1 (DDR4 only)

2. Probe a data pin to check for data being returned from the DRAM.
3. Probe the writes checking the signal level of the write DQS and the write DQ.
4. Probe the V REF level at the DRAM (for DDR3).
5. Probe the DM pin which should be deasserted during the write burst (or tied off on the
board with an appropriate value resistor).

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

386

Chapter 24: Debugging

6. Probe the read burst after the write and check if the expected data pattern is being
returned.
7. Check for floating address pins if the expected data is not returned.
8. Check for any stuck-at level issues on DQ pins whose signal level does not change. If at
all possible probe at the receiver to check termination and signal integrity.
9. Check the DBG port signals and the full read data and comparison result to check the
data in general interconnect. The calibration algorithm has RTL logic issue the
commands and check the data.
Check if the dbg_rd_valid aligns with the data pattern or is off (which can indicate an
issue with DQS gate calibration). Set up a trigger when the error gets asserted to capture
signals in the hardware debugger for analysis.
10. Re-check results from DQS gate or other previous calibration stages. Compare passing
byte lanes against failing byte lanes for previous stages of calibration. If a failure occurs
during simple pattern calibration, check the values found during deskew for example.
11. All of the data comparison for read deskew occurs in the general interconnect, so it can
be useful to pull in the debug data in the hardware debugger and take a look at what the
data looks like coming back as taps are adjusted, see Figure 24-15. The screen captures
are from simulation, with a small burst of five reads. Look at dbg_rd_data,
dbg_rd_data_cmp, and dbg_rd_valid.
12. Using the Vivado Hardware Manager and while running the Memory IP Example Design
with Debug Signals enabled, set the Read Deskew trigger to cal_r*_status[6] = R
(rising edge). To view each byte, add an additional trigger on dbg_cmp_byte and set to
the byte of interest. The following simulation example shows how the debug signals
should behave during successful Read Deskew.
X-Ref Target - Figure 24-15

Figure 24-15:

RTL Debug Signals during Read Deskew (No Error)

13. After failure during this stage of calibration, the design goes into a continuous loop of
read commands to allow board probing.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

387

Chapter 24: Debugging

Debugging Read DQS Centering (Simple/MPR) Failures

Calibration Overview
During DQS read centering (simple), the toggling 01010101 MPR pattern is continuously
read back while DQS adjustments (PQTR and NQTR individual fine taps on DQS) and DQ
adjustments (IDELAY) are made. This is to establish an initial DQS center point using an easy
pattern that does not rely on writing a pattern to the DRAM.

Debug
To determine the status of Read MPR DQS Centering Calibration, click the Read DQS
Centering (Simple) stage under the Status window and view the results within the
Memory IP Properties window. The message displayed in Memory IP Properties identifies
how the stage failed or notes if it passed successfully.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

388

Chapter 24: Debugging

X-Ref Target - Figure 24-16

Figure 24-16:

Memory IP XSDB Debug GUI Example Read DQS Centering (Simple)

The status of Read MPR DQS Centering can also be determined by decoding the
DDR_CAL_ERROR_0 and DDR_CAL_ERROR_1 results according to Table 24-17. Execute the Tcl
commands noted in the XSDB Debug section to generate the XSDB output containing the
signal results.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

389

Chapter 24: Debugging

Table 24-17:

DDR_CAL_ERROR Decode for Read Leveling Calibration

Read DQS
Centering
DDR_CAL_ DDR_CAL_
DDR_CAL_ ERROR_1 ERROR_0
ERROR_
CODE

0x1

Nibble

Bit

Description

Recommended Debug Steps

No Valid data found for a

given bit in the nibble

Check the BUS_DATA_BURST fields in

XSDB. Check the dbg_rd_data,
dbg_rd_data_cmp, and
dbg_expected_data signals in the ILA.
Check the pinout and look for any
STUCK-AT-BITs, check VRP resistor, VREF
resistor. Check the RDLVL_DESKEW_*
fields of XSDB to check if any delays are
much larger/smaller than others.

0x2

Nibble

Bit

Could not find the left Edge

(error condition) to
determine window size.

Check for a mapping issue. This usually

implies a delay is not moving when it
should. Check the connections going to
the XIPHY and ensure the correct RIU is
selected based on the byte being
adjusted.

0xF

Nibble

Bit

Timeout error waiting for

read data to return

Check the dbg_cal_seq_rd_cnt and

dbg_cal_seq_cnt.

Table 24-18 shows the signals and values adjusted or used during the Read MPR DQS
Centering stage of calibration. The values can be analyzed in both successful and failing
calibrations to determine the resultant values and the consistency in results across resets.
These values can be found within the Memory IP Core Properties within Hardware
Manager or by executing the Tcl commands noted in the XSDB Debug section.
Table 24-18:

Signals of Interest for Read Leveling Calibration

Signal

Usage

Signal Description

RDLVL_PQTR_LEFT_RANK*_NIBBLE*

One per rank per nibble

Read leveling PQTR tap position when

left edge of read data valid window is
detected (simple pattern).

RDLVL_NQTR_LEFT_RANK*_NIBBLE*

One per rank per nibble

Read leveling NQTR tap position when

left edge of read data valid window is
detected (simple pattern).

RDLVL_PQTR_RIGHT_RANK*_NIBBLE*

One per rank per nibble

Read leveling PQTR tap position when

right edge of read data valid window is
detected (simple pattern).

RDLVL_NQTR_RIGHT_RANK*_NIBBLE*

One per rank per nibble

Read leveling NQTR tap position when

right edge of read data valid window is
detected (simple pattern).

RDLVL_PQTR_CENTER_RANK*_NIBBLE*

One per rank per nibble

Read leveling PQTR center tap position

found at the end of read DQS centering
(simple pattern).

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

390

Chapter 24: Debugging

Table 24-18:

Signals of Interest for Read Leveling Calibration (Contd)

Signal

Usage

Signal Description

RDLVL_NQTR_CENTER_RANK*_NIBBLE*

One per rank per nibble

Read leveling NQTR center tap position

found at the end of read DQS centering
(simple pattern).

RDLVL_IDELAY_VALUE_RANK*_BYTE*_BIT*

One per rank per Bit

Read leveling IDELAY delay value found

during per bit read DQS centering
(simple pattern).

RDLVL_IDELAY_DBI_RANK*_BYTE*

One per rank per Byte

Reserved

BISC_ALIGN_PQTR_NIBBLE*

One per nibble

Initial 0 offset value provided by BISC at

power-up.

BISC_ALIGN_NQTR_NIBBLE*

One per nibble

Initial 0 offset value provided by BISC at

power-up.

One per nibble

Initial 90 offset value provided by BISC

at power-up. Compute 90 value in taps
by taking (BISC_PQTR
BISC_ALIGN_PQTR). To estimate tap
resolution take ( of the memory clock
period)/ (BISC_PQTR
BISC_ALIGN_PQTR). Useful for error code
0x6.

BISC_NQTR_NIBBLE*

One per nibble

Initial 90 offset value provided by BISC

at power-up. Compute 90 value in taps
by taking (BISC_NQTR
BISC_ALIGN_NQTR). To estimate tap
resolution take ( of the memory clock
period)/ (BISC_NQTR
BISC_ALIGN_NQTR). Useful for error
code 0x6.

RDLVL_PQTR_FINAL_NIBBLE*

One per nibble

Final Read leveling PQTR tap position

from the XIPHY.

RDLVL_NQTR_FINAL_NIBBLE*

One per nibble

Final Read leveling NQTR tap position

from the XIPHY.

RDLVL_IDELAY_FINAL_BYTE*_BIT*

One per Bit

Final IDELAY tap position from the

XIPHY.

BISC_PQTR_NIBBLE*

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

391

Chapter 24: Debugging

Table 24-18:

Signals of Interest for Read Leveling Calibration (Contd)

Signal

RDLVL_IDELAY_DBI_FINAL_BYTE*

Usage
One per Byte

BUS_DATA_BURST (2014.3+)

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Signal Description
Reserved
When a failure occurs during simple
pattern read training, some data is saved
to indicate what the data looks like for a
byte across some tap settings for a given
byte the failure occurred for (DQ IDELAY
is left wherever the algorithm left it).
Read DQS centering (Figure 24-17):
BUS_DATA_BURST_0 holds a single burst
of data when PQTR/NQTR set to 0 taps.
BUS_DATA_BURST_1 holds a single burst
of data when PQTR/NQTR set to 90.
BUS_DATA_BURST_2 holds a single burst
of data when PQTR/NQTR set to 180.
BUS_DATA_BURST_3 holds a single burst
of data when PQTR/NQTR set to 270.
See Interpreting BUS_DATA_BURST Data
Pattern for additional details.

Send Feedback

392

Chapter 24: Debugging

X-Ref Target - Figure 24-17

%86B'$7$B%8567B

WDSV

3475

1475

'4

3475

1475

'4

%86B'$7$B%8567B

rRIIVHW

r
RIIVHW

%86B'$7$B%8567B

rRIIVHW

r
RIIVHW

3475

1475

'4

%86B'$7$B%8567B

rRIIVHW

r 3475
RIIVHW 1475
'4

;

Figure 24-17:

Read DQS Centering Error (XSDB BUS_DATA_BURST)

Data swizzling (bit reordering) is completed within the UltraScale PHY. Therefore, the data
visible on BUS_DATA_BURST and a scope in hardware is ordered differently compared to
what would be seen in ChipScope. Figure 24-18 and Figure 24-19 are examples of how the
data is converted.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

393

Chapter 24: Debugging

X-Ref Target - Figure 24-18

Figure 24-18:

Expected Read Pattern of Toggling 0101_0101

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

394

Chapter 24: Debugging

X-Ref Target - Figure 24-19

Figure 24-19:

Expected Read Pattern of Toggling 1010_1010

This is a sample of results for Read MPR DQS Centering using the Memory IP Debug GUI
within the Hardware Manager.
Note: Either the Table or Chart view can be used to look at the window.
Figure 24-20 and Figure 24-21 are screen captures from 2015.1 and might vary from the
current version.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

395

Chapter 24: Debugging

X-Ref Target - Figure 24-20

Figure 24-20:

Example Read Calibration Margin from Memory IP Debug GUI

This is a sample of results for the Read Per-Bit Deskew XSDB debug signals:
RDLVL_IDELAY_VALUE_RANK0_BYTE0_BIT0
RDLVL_IDELAY_VALUE_RANK0_BYTE0_BIT1
RDLVL_IDELAY_VALUE_RANK0_BYTE0_BIT2
RDLVL_IDELAY_VALUE_RANK0_BYTE0_BIT3
RDLVL_IDELAY_VALUE_RANK0_BYTE0_BIT4
RDLVL_IDELAY_VALUE_RANK0_BYTE0_BIT5
RDLVL_IDELAY_VALUE_RANK0_BYTE0_BIT6
RDLVL_IDELAY_VALUE_RANK0_BYTE0_BIT7
RDLVL_IDELAY_VALUE_RANK0_BYTE1_BIT0
RDLVL_IDELAY_VALUE_RANK0_BYTE1_BIT1
RDLVL_IDELAY_VALUE_RANK0_BYTE1_BIT2
RDLVL_IDELAY_VALUE_RANK0_BYTE1_BIT3
RDLVL_IDELAY_VALUE_RANK0_BYTE1_BIT4
RDLVL_IDELAY_VALUE_RANK0_BYTE1_BIT5
RDLVL_IDELAY_VALUE_RANK0_BYTE1_BIT6
RDLVL_IDELAY_VALUE_RANK0_BYTE1_BIT7
RDLVL_IDELAY_VALUE_RANK0_BYTE2_BIT0

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

042
042
042
045
03a
03e
040
03d
038
03d
03e
039
03a
034
03c
033
041

Send Feedback

396

Chapter 24: Debugging

RDLVL_IDELAY_VALUE_RANK0_BYTE2_BIT1
RDLVL_IDELAY_VALUE_RANK0_BYTE2_BIT2
RDLVL_IDELAY_VALUE_RANK0_BYTE2_BIT3
RDLVL_IDELAY_VALUE_RANK0_BYTE2_BIT4
RDLVL_IDELAY_VALUE_RANK0_BYTE2_BIT5
RDLVL_IDELAY_VALUE_RANK0_BYTE2_BIT6
RDLVL_IDELAY_VALUE_RANK0_BYTE2_BIT7
RDLVL_IDELAY_VALUE_RANK0_BYTE3_BIT0
RDLVL_IDELAY_VALUE_RANK0_BYTE3_BIT1
RDLVL_IDELAY_VALUE_RANK0_BYTE3_BIT2
RDLVL_IDELAY_VALUE_RANK0_BYTE3_BIT3
RDLVL_IDELAY_VALUE_RANK0_BYTE3_BIT4
RDLVL_IDELAY_VALUE_RANK0_BYTE3_BIT5
RDLVL_IDELAY_VALUE_RANK0_BYTE3_BIT6
RDLVL_IDELAY_VALUE_RANK0_BYTE3_BIT7
RDLVL_NQTR_CENTER_RANK0_NIBBLE0
RDLVL_NQTR_CENTER_RANK0_NIBBLE1
RDLVL_NQTR_CENTER_RANK0_NIBBLE2
RDLVL_NQTR_CENTER_RANK0_NIBBLE3
RDLVL_NQTR_CENTER_RANK0_NIBBLE4
RDLVL_NQTR_CENTER_RANK0_NIBBLE5
RDLVL_NQTR_CENTER_RANK0_NIBBLE6
RDLVL_NQTR_CENTER_RANK0_NIBBLE7
RDLVL_NQTR_LEFT_RANK0_NIBBLE0
RDLVL_NQTR_LEFT_RANK0_NIBBLE1
RDLVL_NQTR_LEFT_RANK0_NIBBLE2
RDLVL_NQTR_LEFT_RANK0_NIBBLE3
RDLVL_NQTR_LEFT_RANK0_NIBBLE4
RDLVL_NQTR_LEFT_RANK0_NIBBLE5
RDLVL_NQTR_LEFT_RANK0_NIBBLE6
RDLVL_NQTR_LEFT_RANK0_NIBBLE7
RDLVL_NQTR_RIGHT_RANK0_NIBBLE0
RDLVL_NQTR_RIGHT_RANK0_NIBBLE1
RDLVL_NQTR_RIGHT_RANK0_NIBBLE2
RDLVL_NQTR_RIGHT_RANK0_NIBBLE3
RDLVL_NQTR_RIGHT_RANK0_NIBBLE4
RDLVL_NQTR_RIGHT_RANK0_NIBBLE5
RDLVL_NQTR_RIGHT_RANK0_NIBBLE6
RDLVL_NQTR_RIGHT_RANK0_NIBBLE7
RDLVL_PQTR_CENTER_RANK0_NIBBLE0
RDLVL_PQTR_CENTER_RANK0_NIBBLE1
RDLVL_PQTR_CENTER_RANK0_NIBBLE2
RDLVL_PQTR_CENTER_RANK0_NIBBLE3
RDLVL_PQTR_CENTER_RANK0_NIBBLE4
RDLVL_PQTR_CENTER_RANK0_NIBBLE5
RDLVL_PQTR_CENTER_RANK0_NIBBLE6
RDLVL_PQTR_CENTER_RANK0_NIBBLE7
RDLVL_PQTR_LEFT_RANK0_NIBBLE0
RDLVL_PQTR_LEFT_RANK0_NIBBLE1
RDLVL_PQTR_LEFT_RANK0_NIBBLE2
RDLVL_PQTR_LEFT_RANK0_NIBBLE3
RDLVL_PQTR_LEFT_RANK0_NIBBLE4
RDLVL_PQTR_LEFT_RANK0_NIBBLE5
RDLVL_PQTR_LEFT_RANK0_NIBBLE6
RDLVL_PQTR_LEFT_RANK0_NIBBLE7
RDLVL_PQTR_RIGHT_RANK0_NIBBLE0
RDLVL_PQTR_RIGHT_RANK0_NIBBLE1
RDLVL_PQTR_RIGHT_RANK0_NIBBLE2
RDLVL_PQTR_RIGHT_RANK0_NIBBLE3

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

042
031
040
040
033
036
031
038
038
035
035
036
03c
038
037
03c
03a
03a
039
044
038
039
03b
009
006
00b
008
010
006
006
00a
06f
06e
06a
06a
078
06a
06c
06d
040
040
037
03a
043
037
03e
040
013
015
008
00b
018
008
00d
012
06e
06c
066
06a

Send Feedback

397

Chapter 24: Debugging

RDLVL_PQTR_RIGHT_RANK0_NIBBLE4
RDLVL_PQTR_RIGHT_RANK0_NIBBLE5
RDLVL_PQTR_RIGHT_RANK0_NIBBLE6
RDLVL_PQTR_RIGHT_RANK0_NIBBLE7
MULTI_RANK_RDLVL_IDELAY_BYTE0_BIT0
MULTI_RANK_RDLVL_IDELAY_BYTE0_BIT1
MULTI_RANK_RDLVL_IDELAY_BYTE0_BIT2
MULTI_RANK_RDLVL_IDELAY_BYTE0_BIT3
MULTI_RANK_RDLVL_IDELAY_BYTE0_BIT4
MULTI_RANK_RDLVL_IDELAY_BYTE0_BIT5
MULTI_RANK_RDLVL_IDELAY_BYTE0_BIT6
MULTI_RANK_RDLVL_IDELAY_BYTE0_BIT7
MULTI_RANK_RDLVL_IDELAY_BYTE1_BIT0
MULTI_RANK_RDLVL_IDELAY_BYTE1_BIT1
MULTI_RANK_RDLVL_IDELAY_BYTE1_BIT2
MULTI_RANK_RDLVL_IDELAY_BYTE1_BIT3
MULTI_RANK_RDLVL_IDELAY_BYTE1_BIT4
MULTI_RANK_RDLVL_IDELAY_BYTE1_BIT5
MULTI_RANK_RDLVL_IDELAY_BYTE1_BIT6
MULTI_RANK_RDLVL_IDELAY_BYTE1_BIT7
MULTI_RANK_RDLVL_IDELAY_BYTE2_BIT0
MULTI_RANK_RDLVL_IDELAY_BYTE2_BIT1
MULTI_RANK_RDLVL_IDELAY_BYTE2_BIT2
MULTI_RANK_RDLVL_IDELAY_BYTE2_BIT3
MULTI_RANK_RDLVL_IDELAY_BYTE2_BIT4
MULTI_RANK_RDLVL_IDELAY_BYTE2_BIT5
MULTI_RANK_RDLVL_IDELAY_BYTE2_BIT6
MULTI_RANK_RDLVL_IDELAY_BYTE2_BIT7
MULTI_RANK_RDLVL_IDELAY_BYTE3_BIT0
MULTI_RANK_RDLVL_IDELAY_BYTE3_BIT1
MULTI_RANK_RDLVL_IDELAY_BYTE3_BIT2
MULTI_RANK_RDLVL_IDELAY_BYTE3_BIT3
MULTI_RANK_RDLVL_IDELAY_BYTE3_BIT4
MULTI_RANK_RDLVL_IDELAY_BYTE3_BIT5
MULTI_RANK_RDLVL_IDELAY_BYTE3_BIT6
MULTI_RANK_RDLVL_IDELAY_BYTE3_BIT7
MULTI_RANK_RDLVL_NQTR_NIBBLE0
MULTI_RANK_RDLVL_NQTR_NIBBLE1
MULTI_RANK_RDLVL_NQTR_NIBBLE2
MULTI_RANK_RDLVL_NQTR_NIBBLE3
MULTI_RANK_RDLVL_NQTR_NIBBLE4
MULTI_RANK_RDLVL_NQTR_NIBBLE5
MULTI_RANK_RDLVL_NQTR_NIBBLE6
MULTI_RANK_RDLVL_NQTR_NIBBLE7
MULTI_RANK_RDLVL_PQTR_NIBBLE0
MULTI_RANK_RDLVL_PQTR_NIBBLE1
MULTI_RANK_RDLVL_PQTR_NIBBLE2
MULTI_RANK_RDLVL_PQTR_NIBBLE3
MULTI_RANK_RDLVL_PQTR_NIBBLE4
MULTI_RANK_RDLVL_PQTR_NIBBLE5
MULTI_RANK_RDLVL_PQTR_NIBBLE6
MULTI_RANK_RDLVL_PQTR_NIBBLE7
BISC_ALIGN_NQTR_NIBBLE0
BISC_ALIGN_NQTR_NIBBLE1
BISC_ALIGN_NQTR_NIBBLE2
BISC_ALIGN_NQTR_NIBBLE3
BISC_ALIGN_NQTR_NIBBLE4
BISC_ALIGN_NQTR_NIBBLE5
BISC_ALIGN_NQTR_NIBBLE6

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

06f
067
06f
06f
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000

Send Feedback

398

Chapter 24: Debugging

BISC_ALIGN_NQTR_NIBBLE7
BISC_ALIGN_PQTR_NIBBLE0
BISC_ALIGN_PQTR_NIBBLE1
BISC_ALIGN_PQTR_NIBBLE2
BISC_ALIGN_PQTR_NIBBLE3
BISC_ALIGN_PQTR_NIBBLE4
BISC_ALIGN_PQTR_NIBBLE5
BISC_ALIGN_PQTR_NIBBLE6
BISC_ALIGN_PQTR_NIBBLE7
BISC_NQTR_NIBBLE0
BISC_NQTR_NIBBLE1
BISC_NQTR_NIBBLE2
BISC_NQTR_NIBBLE3
BISC_NQTR_NIBBLE4
BISC_NQTR_NIBBLE5
BISC_NQTR_NIBBLE6
BISC_NQTR_NIBBLE7
BISC_PQTR_NIBBLE0
BISC_PQTR_NIBBLE1
BISC_PQTR_NIBBLE2
BISC_PQTR_NIBBLE3
BISC_PQTR_NIBBLE4
BISC_PQTR_NIBBLE5
BISC_PQTR_NIBBLE6
BISC_PQTR_NIBBLE7

string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

000
007
004
006
005
005
004
004
004
036
033
037
035
037
036
036
036
038
036
038
035
037
037
035
036

Expected Results

Look at the individual PQTR/NQTR tap settings for each nibble. The taps should only
vary by 0 to 20 taps. Use the BISC values to compute the estimated bit time in taps.

For example, Byte 7 Nibble 0 in Figure 24-21 is shifted and smaller compared to the
remaining nibbles. This type of result is not expected. For this specific example, the
FPGA was not properly loaded into the socket.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

399

Chapter 24: Debugging

X-Ref Target - Figure 24-21

Figure 24-21:

Example of Suspicious Calibration Read Margin

Determine if any bytes completed successfully. The read DQS Centering algorithm
sequentially steps through each DQS byte group detecting the capture edges.

To analyze the window size in ps, see the Determining Window Size in ps, page 513. In
some cases, simple pattern calibration might show a better than ideal rise or fall
window. Because a simple pattern (clock pattern) is used, it is possible for the rising
edge clock to always find the same value (for example, 1) and the falling edge to always
find the opposite (for example, 0). This can occur due to a non-ideal starting VREF value
which causes duty cycle distortion making the rise or fall larger than the other. If the
rise and fall window sizes are added together and compared against the expected clock
cycle time, the result should be more reasonable.
As a general rule of thumb, the window size for a healthy system should be 30% of the
expected UI size.

Hardware Measurements
1. Using high quality probes and scope, probe the address/command to ensure the load
register command to the DRAM that enables MPR was correct. To enable the MPR, a
Mode register set (MRS) command is issued to the MR3 register with bit A2 = 1. To make
this measurement, bring a scope trigger to an I/O based on the following conditions:

cal_r*_status[9]= R (rising edge) && dbg_rd_valid = 1b0 &&

cal_seq_cnt[2:0] = 3b0

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

400

Chapter 24: Debugging

To view each byte, add an additional trigger on dbg_cmp_byte and set to the byte
of interest.

Within this capture, A2 (must be 1) and we_n (must be 0).

2. Probe the read commands at the memory:

Read = cs_n = 1; ras_n = 0; cas_n = 1; we_n = 0; act_n = 1 (DDR4 only)

3. Probe a data pin to check for data being returned from the DRAM.
4. Probe the read burst and check if the expected data pattern is being returned.
5. Check for floating address pins if the expected data is not returned.
6. Check for any stuck-at level issues on DQ pins whose signal level does not change. If at
all possible probe at the receiver to check termination and signal integrity.
7. Check the DBG port signals and the full read data and comparison result to check the
data in general interconnect. The calibration algorithm has RTL logic issue the
commands and check the data. Check if the dbg_rd_valid aligns with the data pattern
or is OFF (which can indicate an issue with DQS gate calibration). Set up a trigger when
the error gets asserted to capture signals in the hardware debugger for analysis.
8. Re-check results from DQS gate or other previous calibration stages. Compare passing
byte lanes against failing byte lanes for previous stages of calibration. If a failure occurs
during simple pattern calibration, check the values found during deskew for example.
9. All of the data comparison for read DQS centering occurs in the general interconnect, so
it can be useful to pull in the debug data in the hardware debugger and take a look at
what the data looks like coming back as taps are adjusted, see Figure 24-22 and
Figure 24-23. Screenshots shown are from simulation, with a small burst of five reads.
Look at dbg_rd_data, dbg_rd_data_cmp, and dbg_rd_valid.
10. Using the Vivado Hardware Manager and while running the Memory IP Example Design
with Debug Signals enabled, set the Read Centering trigger to (cal_r*_status[10]
= R (rising edge) && dbg_rd_valid = 1b0 && cal_seq_cnt[2:0] = 3b0). To view
each byte, add an additional trigger on dbg_cmp_byte and set to the byte of interest.
The following simulation example shows how the debug signals should behave during
successful Read DQS Centering.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

401

Chapter 24: Debugging

X-Ref Target - Figure 24-22

Figure 24-22:

RTL Debug Signals during Read DQS Centering (No Error)

X-Ref Target - Figure 24-23

Figure 24-23:

RTL Debug Signals during Read DQS Centering (Error Case Shown)

11. After failure during this stage of calibration, the design goes into a continuous loop of
read commands to allow board probing.

Write Calibration Overview

Calibration Overview
This stage of calibration is required to center align the write DQS in the write DQ window
per bit. At the start of Write DQS Centering and Per-Bit Deskew, DQS is aligned to CK but no
adjustments on the write window have been made. Write window adjustments are made in
the following two sequential stages:

Write Per-Bit Deskew

Write DQS Centering

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

402

Chapter 24: Debugging

Debugging Write Per-Bit Deskew Failures

Calibration Overview
During write per-bit deskew, a toggling 10101010 pattern is continuously written and read
back while making 90o clock phase adjustments on the write DQ along with individual fine
ODELAY adjustments on DQS and DQ. At the end of per-bit write DQ deskew, the write DQ
bits are aligned as they are transmitted to the memory.

Debug
To determine the status of Write Per-Bit Deskew Calibration, click the Write DQS to DQ
Deskew stage under the Status window and view the results within the Memory IP
Properties window. The message displayed in Memory IP Properties identifies how the
stage failed or notes if it passed successfully.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

403

Chapter 24: Debugging

X-Ref Target - Figure 24-24

Figure 24-24:

Memory IP XSDB Debug GUI Example Write DQS to DQ Deskew

The status of Write Per-Bit Deskew can also be determined by decoding the
DDR_CAL_ERROR_0 and DDR_CAL_ERROR_1 results according to the Table 24-19. Execute
the Tcl commands noted in the XSDB Debug section to generate the XSDB output
containing the signal results.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

404

Chapter 24: Debugging

Table 24-19:

DDR_CAL_ERROR Decode for Write DQS Centering Calibration

Write
DQS-to-DQ
Deskew
DDR_CAL_ DDR_CAL_
DDR_CAL_ ERROR_1 ERROR_0
ERROR_
CODE

0x1

Byte

Description

Recommended Debug Steps

Bit

DQS Deskew Error. Ran out of

taps, no valid data found.

Check BUS_DATA_BURST XSDB field to

check what values were returned. Check
the alignment of DQS to DQ during a
write burst with a scope on the PCB.
Check the DQS-to-CK alignment. Check
the WRLVL fields in XSDB for a given
byte.
Check for a mapping issue. This usually
implies a delay is not moving when it
should. Check the connections going to
the XIPHY and ensure the correct RIU is
selected based on the byte being
adjusted.
Check the dbg_cal_seq_rd_cnt and
dbg_cal_seq_cnt.

0x2

Byte

Bit

DQ (or DM) Deskew Error.

Failure point not found (bit
only indicated when set to
CAL_FULL)

0xF

Byte

N/A

Timeout error waiting for read

data to return

Table 24-20 shows the signals and values adjusted or used during the Write Per-Bit Deskew
stage of calibration. The values can be analyzed in both successful and failing calibrations to
determine the resultant values and the consistency in results across resets. These values can
be found within the Memory IP Core Properties within the Hardware Manager or by
executing the Tcl commands noted in the XSDB Debug section.
Table 24-20:

Signals of Interest for Write Per-Bit Deskew

Signal

Usage

Signal Description

WRITE_DQS_TO_DQ_DESKEW_DELAY_BYTE*

One per byte

ODELAY value required to place DQS into the byte

write data valid window during write per-bit
deskew.

WRITE_DQS_ODELAY_FINAL_BYTE*

One per byte

Final DQS ODELAY value.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

405

Chapter 24: Debugging

Table 24-20:

Signals of Interest for Write Per-Bit Deskew (Contd)

Signal

Usage

WRITE_DQ_ODELAY_FINAL_BYTE*_BIT*

One per bit

Signal Description
Final DQ ODELAY value.
During calibration for a byte an example data
burst is saved for later analysis in case of failure.
BUS_DATA_BURST_0 holds an initial read data
burst pattern for a given byte with the starting
alignment prior to write deskew (TX_DATA_PHASE
set to 1 for DQS, 0 for DQ). The ODELAY values for
DQS and DQ are the initial WRLVL values.
After a byte calibrates, the example read data
saved in the BUS_DATA_BURST registers is cleared.
BUS_DATA_BURST_1, BUS_DATA_BURST_2, and
BUS_DATA_BURST_3 are not used.
See Interpreting BUS_DATA_BURST Data Pattern
for additional details.

BUS_DATA_BURST (2014.3+)

X-Ref Target - Figure 24-25

%86B'$7$B%8567B
7;B'$7$B3+$6( 

:ULWH'46
'4

7;B'$7$B3+$6( 

;

Figure 24-25:

Write DQS Centering (XSDB BUS_DATA_BURST_0)

Data swizzling (bit reordering) is completed within the UltraScale PHY. Therefore, the data
visible on BUS_DATA_BURST and a scope in hardware is ordered differently compared to
what would be seen in ChipScope. Figure 24-26 is an example of how the data is converted.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

406

Chapter 24: Debugging

X-Ref Target - Figure 24-26

Figure 24-26:

Write DQS-to-DQ Debug Data (XSDB BUS_DATA_BURST, Associated Read Data Saved)

This is a sample of results for the Write DQS Centering XSDB debug signals:
WRITE_DQS_ODELAY_FINAL_BYTE0
WRITE_DQS_ODELAY_FINAL_BYTE1
WRITE_DQS_ODELAY_FINAL_BYTE2
WRITE_DQS_ODELAY_FINAL_BYTE3
WRITE_DQS_ODELAY_FINAL_BYTE4
WRITE_DQS_ODELAY_FINAL_BYTE5
WRITE_DQS_ODELAY_FINAL_BYTE6
WRITE_DQS_ODELAY_FINAL_BYTE7
WRITE_DQS_ODELAY_FINAL_BYTE8
WRITE_DQS_TO_DQ_DESKEW_DELAY_BYTE0
WRITE_DQS_TO_DQ_DESKEW_DELAY_BYTE1
WRITE_DQS_TO_DQ_DESKEW_DELAY_BYTE2
WRITE_DQS_TO_DQ_DESKEW_DELAY_BYTE3
WRITE_DQS_TO_DQ_DESKEW_DELAY_BYTE4
WRITE_DQS_TO_DQ_DESKEW_DELAY_BYTE5
WRITE_DQS_TO_DQ_DESKEW_DELAY_BYTE6
WRITE_DQS_TO_DQ_DESKEW_DELAY_BYTE7
WRITE_DQS_TO_DQ_DESKEW_DELAY_BYTE8

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

02b
010
020
02b
00b
02c
01b
02b
016
035
01d
030
03a
019
039
028
039
028

Send Feedback

407

Chapter 24: Debugging

WRITE_DQ_ODELAY_FINAL_BYTE0_BIT0
WRITE_DQ_ODELAY_FINAL_BYTE0_BIT1
WRITE_DQ_ODELAY_FINAL_BYTE0_BIT2
WRITE_DQ_ODELAY_FINAL_BYTE0_BIT3
WRITE_DQ_ODELAY_FINAL_BYTE0_BIT4
WRITE_DQ_ODELAY_FINAL_BYTE0_BIT5
WRITE_DQ_ODELAY_FINAL_BYTE0_BIT6
WRITE_DQ_ODELAY_FINAL_BYTE0_BIT7
WRITE_DQ_ODELAY_FINAL_BYTE1_BIT0
WRITE_DQ_ODELAY_FINAL_BYTE1_BIT1
WRITE_DQ_ODELAY_FINAL_BYTE1_BIT2
WRITE_DQ_ODELAY_FINAL_BYTE1_BIT3
WRITE_DQ_ODELAY_FINAL_BYTE1_BIT4
WRITE_DQ_ODELAY_FINAL_BYTE1_BIT5
WRITE_DQ_ODELAY_FINAL_BYTE1_BIT6
WRITE_DQ_ODELAY_FINAL_BYTE1_BIT7
WRITE_DQ_ODELAY_FINAL_BYTE2_BIT0
WRITE_DQ_ODELAY_FINAL_BYTE2_BIT1
WRITE_DQ_ODELAY_FINAL_BYTE2_BIT2
WRITE_DQ_ODELAY_FINAL_BYTE2_BIT3
WRITE_DQ_ODELAY_FINAL_BYTE2_BIT4
WRITE_DQ_ODELAY_FINAL_BYTE2_BIT5
WRITE_DQ_ODELAY_FINAL_BYTE2_BIT6
WRITE_DQ_ODELAY_FINAL_BYTE2_BIT7
WRITE_DQ_ODELAY_FINAL_BYTE3_BIT0
WRITE_DQ_ODELAY_FINAL_BYTE3_BIT1
WRITE_DQ_ODELAY_FINAL_BYTE3_BIT2
WRITE_DQ_ODELAY_FINAL_BYTE3_BIT3
WRITE_DQ_ODELAY_FINAL_BYTE3_BIT4
WRITE_DQ_ODELAY_FINAL_BYTE3_BIT5
WRITE_DQ_ODELAY_FINAL_BYTE3_BIT6
WRITE_DQ_ODELAY_FINAL_BYTE3_BIT7
WRITE_DQ_ODELAY_FINAL_BYTE4_BIT0
WRITE_DQ_ODELAY_FINAL_BYTE4_BIT1
WRITE_DQ_ODELAY_FINAL_BYTE4_BIT2
WRITE_DQ_ODELAY_FINAL_BYTE4_BIT3
WRITE_DQ_ODELAY_FINAL_BYTE4_BIT4
WRITE_DQ_ODELAY_FINAL_BYTE4_BIT5
WRITE_DQ_ODELAY_FINAL_BYTE4_BIT6
WRITE_DQ_ODELAY_FINAL_BYTE4_BIT7
WRITE_DQ_ODELAY_FINAL_BYTE5_BIT0
WRITE_DQ_ODELAY_FINAL_BYTE5_BIT1
WRITE_DQ_ODELAY_FINAL_BYTE5_BIT2
WRITE_DQ_ODELAY_FINAL_BYTE5_BIT3
WRITE_DQ_ODELAY_FINAL_BYTE5_BIT4
WRITE_DQ_ODELAY_FINAL_BYTE5_BIT5
WRITE_DQ_ODELAY_FINAL_BYTE5_BIT6
WRITE_DQ_ODELAY_FINAL_BYTE5_BIT7
WRITE_DQ_ODELAY_FINAL_BYTE6_BIT0
WRITE_DQ_ODELAY_FINAL_BYTE6_BIT1
WRITE_DQ_ODELAY_FINAL_BYTE6_BIT2
WRITE_DQ_ODELAY_FINAL_BYTE6_BIT3
WRITE_DQ_ODELAY_FINAL_BYTE6_BIT4
WRITE_DQ_ODELAY_FINAL_BYTE6_BIT5
WRITE_DQ_ODELAY_FINAL_BYTE6_BIT6
WRITE_DQ_ODELAY_FINAL_BYTE6_BIT7
WRITE_DQ_ODELAY_FINAL_BYTE7_BIT0
WRITE_DQ_ODELAY_FINAL_BYTE7_BIT1
WRITE_DQ_ODELAY_FINAL_BYTE7_BIT2

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

033
034
033
030
02b
02b
033
02c
011
00e
00d
00c
00e
00e
010
009
023
01b
01d
019
019
01a
01d
014
02b
02a
025
025
028
029
021
02b
008
005
00b
008
004
000
009
007
031
02f
02e
02d
030
030
030
02a
020
023
01f
01f
01f
01d
01d
01b
033
031
028

Send Feedback

408

Chapter 24: Debugging

WRITE_DQ_ODELAY_FINAL_BYTE7_BIT3
WRITE_DQ_ODELAY_FINAL_BYTE7_BIT4
WRITE_DQ_ODELAY_FINAL_BYTE7_BIT5
WRITE_DQ_ODELAY_FINAL_BYTE7_BIT6
WRITE_DQ_ODELAY_FINAL_BYTE7_BIT7
WRITE_DQ_ODELAY_FINAL_BYTE8_BIT0
WRITE_DQ_ODELAY_FINAL_BYTE8_BIT1
WRITE_DQ_ODELAY_FINAL_BYTE8_BIT2
WRITE_DQ_ODELAY_FINAL_BYTE8_BIT3
WRITE_DQ_ODELAY_FINAL_BYTE8_BIT4
WRITE_DQ_ODELAY_FINAL_BYTE8_BIT5
WRITE_DQ_ODELAY_FINAL_BYTE8_BIT6
WRITE_DQ_ODELAY_FINAL_BYTE8_BIT7

string
string
string
string
string
string
string
string
string
string
string
string
string

true
true
true
true
true
true
true
true
true
true
true
true
true

true
true
true
true
true
true
true
true
true
true
true
true
true

02a
02d
02b
031
02e
01f
020
017
01c
018
013
01f
012

Hardware Measurements
Probe the DQ bit alignment at the memory during writes. Trigger at the start
(cal_r*_status[14] = R for Rising Edge) and again at the end of per bit deskew
(cal_r*_status[15] = R for Rising Edge) to view the starting and ending alignments. To
look at each byte, add a trigger on the byte using dbg_cmp_byte.

Expected Results
Hardware measurements should show the write DQ bits are deskewed at the end of these
calibration stages.

Determine if any bytes completed successfully. The write calibration algorithm

sequentially steps through each DQS byte group detecting the capture edges.

If the incorrect data pattern is detected, determine if the error is due to the write access
or the read access. See the Determining If a Data Error is Due to the Write or Read,
page 510.

Using the Vivado Hardware Manager and while running the Memory IP Example Design with
Debug Signals enabled, set the trigger (cal_r*_status[14] =R for Rising Edge). The
following simulation examples show how the debug signals should behave during
successful Write Per-Bit Deskew:

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

409

Chapter 24: Debugging

X-Ref Target - Figure 24-27

Figure 24-27:

RTL Debug Signals during Write Per-Bit Deskew #1

Figure 24-28:

RTL Debug Signals during Write Per-Bit Deskew #2

X-Ref Target - Figure 24-28

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

410

Chapter 24: Debugging

X-Ref Target - Figure 24-29

Figure 24-29:

RTL Debug Signals during Write Per-Bit Deskew #3

Debugging Write DQS Centering Failures

Calibration Overview
During Write DQS Centering, the same toggling 10101010 pattern is continuously written
and read back. ODELAY adjustments on DQS and DQ are also made but all of the DQ
ODELAY adjustments for a given byte are made in step to maintain the previously deskewed
alignment.

Debug
To determine the status of Write DQS Centering Calibration, click the Write DQS to DQ
(Simple) stage under the Status window and view the results within the Memory IP
Properties window. The message displayed in Memory IP Properties identifies how the
stage failed or notes if it passed successfully.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

411

Chapter 24: Debugging

X-Ref Target - Figure 24-30

Figure 24-30:

Memory IP XSDB Debug GUI Example Write DQS to DQ (Simple)

The status of Write DQS Centering can also be determined by decoding the
DDR_CAL_ERROR_0 and DDR_CAL_ERROR_1 results according to Table 24-21. Execute the Tcl
commands noted in the XSDB Debug section to generate the XSDB output containing the
signal results.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

412

Chapter 24: Debugging

Table 24-21:

DDR_CAL_ERROR Decode for Write DQS Centering Calibration

Write DQS
to DQ
DDR_CAL DDR_CAL
DDR_CAL_ _ERROR_ _ERROR_
ERROR_
1
0
CODE

Description

Recommended Debug Steps

0x1

Byte

N/A

No Valid Data found

Check BUS_DATA_BURST XSDB field to

check what values were returned. Check
the alignment of DQS to DQ during a write
burst with a scope on the PCB. Check the
DQS-to-CK alignment. Check the WRLVL
fields in XSDB for a given byte. Check the
Write_dqs_to_dq_deskew values.

0xF

Byte

N/A

Timeout error waiting for read

data to return

Check the dbg_cal_seq_rd_cnt and

dbg_cal_seq_cnt.

Table 24-22 shows the signals and values adjusted or used during the Write DQS Centering
stage of calibration. The values can be analyzed in both successful and failing calibrations to
determine the resultant values and the consistency in results across resets. These values can
be found within the Memory IP Core Properties within the Hardware Manager or by
executing the Tcl commands noted in the XSDB Debug section.
Table 24-22:

Signals of Interest for Write DQS Centering

Signal

Usage

Signal Description

One per byte

Left side of the write DQS-to-DQ

window measured during
calibration before adjustments
made.

WRITE_DQS_TO_DQ_PRE_ADJUST_MARGIN_RIGHT _BYTE*

One per byte

Right side of the write DQS-to-DQ

window measured during
calibration before adjustments
made.

WRITE_DQS_TO_DQ_MARGIN_LEFT_BYTE*

One per byte

Left side of the write DQS-to-DQ

window.

WRITE_DQS_TO_DQ_MARGIN_RIGHT _BYTE*

One per byte

Right side of the write DQS-to-DQ

window.

WRITE_DQS_TO_DQ_DQS_ODELAY_BYTE*

One per byte

Final DQS ODELAY value after Write

DQS-to-DQ (simple).

WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE*_BIT*

One per bit

Final DQ ODELAY value after Write

DQS-to-DQ (simple).

WRITE_DQS_ODELAY_FINAL_BYTE*_BIT*

One per byte

Final DQS ODELAY value.

WRITE_DQ_ODELAY_FINAL_BYTE*_BIT*

One per bit

Final DQ ODELAY value.

WRITE_DQS_TO_DQ_PRE_ADJUST_MARGIN_LEFT_BYTE*

Data swizzling (bit reordering) is completed within the UltraScale PHY. Therefore, the data
visible on BUS_DATA_BURST and a scope in hardware is ordered differently compared to
what would be seen in ChipScope. Figure 24-31 is an example of how the data is converted.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

413

Chapter 24: Debugging

X-Ref Target - Figure 24-31

Figure 24-31:

Expected Read Pattern of Toggling 1010_1010

This is a sample of results for the Write DQS Centering XSDB debug signals:
WRITE_DQS_TO_DQ_PRE_ADJUST_MARGIN_LEFT_BYTE0
WRITE_DQS_TO_DQ_PRE_ADJUST_MARGIN_LEFT_BYTE1
WRITE_DQS_TO_DQ_PRE_ADJUST_MARGIN_LEFT_BYTE2
WRITE_DQS_TO_DQ_PRE_ADJUST_MARGIN_LEFT_BYTE3
WRITE_DQS_TO_DQ_PRE_ADJUST_MARGIN_LEFT_BYTE4
WRITE_DQS_TO_DQ_PRE_ADJUST_MARGIN_LEFT_BYTE5
WRITE_DQS_TO_DQ_PRE_ADJUST_MARGIN_LEFT_BYTE6
WRITE_DQS_TO_DQ_PRE_ADJUST_MARGIN_LEFT_BYTE7
WRITE_DQS_TO_DQ_PRE_ADJUST_MARGIN_LEFT_BYTE8
WRITE_DQS_TO_DQ_PRE_ADJUST_MARGIN_RIGHT_BYTE0
WRITE_DQS_TO_DQ_PRE_ADJUST_MARGIN_RIGHT_BYTE1
WRITE_DQS_TO_DQ_PRE_ADJUST_MARGIN_RIGHT_BYTE2
WRITE_DQS_TO_DQ_PRE_ADJUST_MARGIN_RIGHT_BYTE3
WRITE_DQS_TO_DQ_PRE_ADJUST_MARGIN_RIGHT_BYTE4
WRITE_DQS_TO_DQ_PRE_ADJUST_MARGIN_RIGHT_BYTE5
WRITE_DQS_TO_DQ_PRE_ADJUST_MARGIN_RIGHT_BYTE6
WRITE_DQS_TO_DQ_PRE_ADJUST_MARGIN_RIGHT_BYTE7
WRITE_DQS_TO_DQ_PRE_ADJUST_MARGIN_RIGHT_BYTE8
WRITE_DQ_ODELAY_FINAL_BYTE0_BIT0
WRITE_DQ_ODELAY_FINAL_BYTE0_BIT1

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

063
044
058
065
042
066
057
068
057
056
042
05a
063
042
05c
048
05f
048
033
034

Send Feedback

414

Chapter 24: Debugging

WRITE_DQ_ODELAY_FINAL_BYTE0_BIT2
WRITE_DQ_ODELAY_FINAL_BYTE0_BIT3
WRITE_DQ_ODELAY_FINAL_BYTE0_BIT4
WRITE_DQ_ODELAY_FINAL_BYTE0_BIT5
WRITE_DQ_ODELAY_FINAL_BYTE0_BIT6
WRITE_DQ_ODELAY_FINAL_BYTE0_BIT7
WRITE_DQ_ODELAY_FINAL_BYTE1_BIT0
WRITE_DQ_ODELAY_FINAL_BYTE1_BIT1
WRITE_DQ_ODELAY_FINAL_BYTE1_BIT2
WRITE_DQ_ODELAY_FINAL_BYTE1_BIT3
WRITE_DQ_ODELAY_FINAL_BYTE1_BIT4
WRITE_DQ_ODELAY_FINAL_BYTE1_BIT5
WRITE_DQ_ODELAY_FINAL_BYTE1_BIT6
WRITE_DQ_ODELAY_FINAL_BYTE1_BIT7
WRITE_DQ_ODELAY_FINAL_BYTE2_BIT0
WRITE_DQ_ODELAY_FINAL_BYTE2_BIT1
WRITE_DQ_ODELAY_FINAL_BYTE2_BIT2
WRITE_DQ_ODELAY_FINAL_BYTE2_BIT3
WRITE_DQ_ODELAY_FINAL_BYTE2_BIT4
WRITE_DQ_ODELAY_FINAL_BYTE2_BIT5
WRITE_DQ_ODELAY_FINAL_BYTE2_BIT6
WRITE_DQ_ODELAY_FINAL_BYTE2_BIT7
WRITE_DQ_ODELAY_FINAL_BYTE3_BIT0
WRITE_DQ_ODELAY_FINAL_BYTE3_BIT1
WRITE_DQ_ODELAY_FINAL_BYTE3_BIT2
WRITE_DQ_ODELAY_FINAL_BYTE3_BIT3
WRITE_DQ_ODELAY_FINAL_BYTE3_BIT4
WRITE_DQ_ODELAY_FINAL_BYTE3_BIT5
WRITE_DQ_ODELAY_FINAL_BYTE3_BIT6
WRITE_DQ_ODELAY_FINAL_BYTE3_BIT7
WRITE_DQ_ODELAY_FINAL_BYTE4_BIT0
WRITE_DQ_ODELAY_FINAL_BYTE4_BIT1
WRITE_DQ_ODELAY_FINAL_BYTE4_BIT2
WRITE_DQ_ODELAY_FINAL_BYTE4_BIT3
WRITE_DQ_ODELAY_FINAL_BYTE4_BIT4
WRITE_DQ_ODELAY_FINAL_BYTE4_BIT5
WRITE_DQ_ODELAY_FINAL_BYTE4_BIT6
WRITE_DQ_ODELAY_FINAL_BYTE4_BIT7
WRITE_DQ_ODELAY_FINAL_BYTE5_BIT0
WRITE_DQ_ODELAY_FINAL_BYTE5_BIT1
WRITE_DQ_ODELAY_FINAL_BYTE5_BIT2
WRITE_DQ_ODELAY_FINAL_BYTE5_BIT3
WRITE_DQ_ODELAY_FINAL_BYTE5_BIT4
WRITE_DQ_ODELAY_FINAL_BYTE5_BIT5
WRITE_DQ_ODELAY_FINAL_BYTE5_BIT6
WRITE_DQ_ODELAY_FINAL_BYTE5_BIT7
WRITE_DQ_ODELAY_FINAL_BYTE6_BIT0
WRITE_DQ_ODELAY_FINAL_BYTE6_BIT1
WRITE_DQ_ODELAY_FINAL_BYTE6_BIT2
WRITE_DQ_ODELAY_FINAL_BYTE6_BIT3
WRITE_DQ_ODELAY_FINAL_BYTE6_BIT4
WRITE_DQ_ODELAY_FINAL_BYTE6_BIT5
WRITE_DQ_ODELAY_FINAL_BYTE6_BIT6
WRITE_DQ_ODELAY_FINAL_BYTE6_BIT7
WRITE_DQ_ODELAY_FINAL_BYTE7_BIT0
WRITE_DQ_ODELAY_FINAL_BYTE7_BIT1
WRITE_DQ_ODELAY_FINAL_BYTE7_BIT2
WRITE_DQ_ODELAY_FINAL_BYTE7_BIT3
WRITE_DQ_ODELAY_FINAL_BYTE7_BIT4

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

033
030
02b
02b
033
02c
011
00e
00d
00c
00e
00e
010
009
023
01b
01d
019
019
01a
01d
014
02b
02a
025
025
028
029
021
02b
008
005
00b
008
004
000
009
007
031
02f
02e
02d
030
030
030
02a
020
023
01f
01f
01f
01d
01d
01b
033
031
028
02a
02d

Send Feedback

415

Chapter 24: Debugging

WRITE_DQ_ODELAY_FINAL_BYTE7_BIT5
WRITE_DQ_ODELAY_FINAL_BYTE7_BIT6
WRITE_DQ_ODELAY_FINAL_BYTE7_BIT7
WRITE_DQ_ODELAY_FINAL_BYTE8_BIT0
WRITE_DQ_ODELAY_FINAL_BYTE8_BIT1
WRITE_DQ_ODELAY_FINAL_BYTE8_BIT2
WRITE_DQ_ODELAY_FINAL_BYTE8_BIT3
WRITE_DQ_ODELAY_FINAL_BYTE8_BIT4
WRITE_DQ_ODELAY_FINAL_BYTE8_BIT5
WRITE_DQ_ODELAY_FINAL_BYTE8_BIT6
WRITE_DQ_ODELAY_FINAL_BYTE8_BIT7
WRITE_DQS_ODELAY_FINAL_BYTE0
WRITE_DQS_ODELAY_FINAL_BYTE1
WRITE_DQS_ODELAY_FINAL_BYTE2
WRITE_DQS_ODELAY_FINAL_BYTE3
WRITE_DQS_ODELAY_FINAL_BYTE4
WRITE_DQS_ODELAY_FINAL_BYTE5
WRITE_DQS_ODELAY_FINAL_BYTE6
WRITE_DQS_ODELAY_FINAL_BYTE7
WRITE_DQS_ODELAY_FINAL_BYTE8
WRITE_DQS_TO_DQ_DQS_ODELAY_BYTE0
WRITE_DQS_TO_DQ_DQS_ODELAY_BYTE1
WRITE_DQS_TO_DQ_DQS_ODELAY_BYTE2
WRITE_DQS_TO_DQ_DQS_ODELAY_BYTE3
WRITE_DQS_TO_DQ_DQS_ODELAY_BYTE4
WRITE_DQS_TO_DQ_DQS_ODELAY_BYTE5
WRITE_DQS_TO_DQ_DQS_ODELAY_BYTE6
WRITE_DQS_TO_DQ_DQS_ODELAY_BYTE7
WRITE_DQS_TO_DQ_DQS_ODELAY_BYTE8
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE0_BIT0
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE0_BIT1
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE0_BIT2
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE0_BIT3
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE0_BIT4
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE0_BIT5
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE0_BIT6
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE0_BIT7
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE1_BIT0
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE1_BIT1
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE1_BIT2
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE1_BIT3
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE1_BIT4
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE1_BIT5
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE1_BIT6
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE1_BIT7
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE2_BIT0
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE2_BIT1
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE2_BIT2
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE2_BIT3
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE2_BIT4
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE2_BIT5
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE2_BIT6
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE2_BIT7
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE3_BIT0
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE3_BIT1
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE3_BIT2
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE3_BIT3
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE3_BIT4
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE3_BIT5

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

02b
031
02e
01f
020
017
01c
018
013
01f
012
02b
010
020
02b
00b
02c
01b
02b
016
02b
010
020
02b
010
02c
01b
02b
016
030
031
030
02d
028
028
030
029
00d
00a
009
008
00a
00a
00c
005
01f
017
019
015
015
016
019
010
028
027
022
022
025
026

Send Feedback

416

Chapter 24: Debugging

WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE3_BIT6
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE3_BIT7
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE4_BIT0
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE4_BIT1
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE4_BIT2
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE4_BIT3
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE4_BIT4
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE4_BIT5
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE4_BIT6
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE4_BIT7
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE5_BIT0
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE5_BIT1
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE5_BIT2
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE5_BIT3
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE5_BIT4
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE5_BIT5
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE5_BIT6
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE5_BIT7
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE6_BIT0
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE6_BIT1
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE6_BIT2
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE6_BIT3
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE6_BIT4
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE6_BIT5
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE6_BIT6
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE6_BIT7
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE7_BIT0
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE7_BIT1
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE7_BIT2
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE7_BIT3
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE7_BIT4
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE7_BIT5
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE7_BIT6
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE7_BIT7
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE8_BIT0
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE8_BIT1
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE8_BIT2
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE8_BIT3
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE8_BIT4
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE8_BIT5
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE8_BIT6
WRITE_DQS_TO_DQ_DQ_ODELAY_BYTE8_BIT7
WRITE_DQS_TO_DQ_MARGIN_LEFT_BYTE0
WRITE_DQS_TO_DQ_MARGIN_LEFT_BYTE1
WRITE_DQS_TO_DQ_MARGIN_LEFT_BYTE2
WRITE_DQS_TO_DQ_MARGIN_LEFT_BYTE3
WRITE_DQS_TO_DQ_MARGIN_LEFT_BYTE4
WRITE_DQS_TO_DQ_MARGIN_LEFT_BYTE5
WRITE_DQS_TO_DQ_MARGIN_LEFT_BYTE6
WRITE_DQS_TO_DQ_MARGIN_LEFT_BYTE7
WRITE_DQS_TO_DQ_MARGIN_LEFT_BYTE8
WRITE_DQS_TO_DQ_MARGIN_RIGHT_BYTE0
WRITE_DQS_TO_DQ_MARGIN_RIGHT_BYTE1
WRITE_DQS_TO_DQ_MARGIN_RIGHT_BYTE2
WRITE_DQS_TO_DQ_MARGIN_RIGHT_BYTE3
WRITE_DQS_TO_DQ_MARGIN_RIGHT_BYTE4
WRITE_DQS_TO_DQ_MARGIN_RIGHT_BYTE5
WRITE_DQS_TO_DQ_MARGIN_RIGHT_BYTE6
WRITE_DQS_TO_DQ_MARGIN_RIGHT_BYTE7

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

01e
028
008
005
00b
008
004
000
009
007
02c
02a
029
028
02b
02b
02b
025
01b
01e
01a
01a
01a
018
018
016
02e
02c
023
025
028
026
02c
029
019
01a
011
016
012
00d
019
00c
028
026
02a
028
028
027
027
02a
026
027
028
028
02a
029
029
027
02b

Send Feedback

417

Chapter 24: Debugging

WRITE_DQS_TO_DQ_MARGIN_RIGHT_BYTE8

string true true 025

Hardware Measurements
Probe the DQS to DQ write phase relationship at the memory. DQS should be center aligned
to DQ at the end of this stage of calibration. Trigger at the start (cal_r*_status
cal_r*_status[18] = R for Rising Edge) and again at the end (cal_r*_status[19] =
R for Rising Edge) of Write DQS Centering to view the starting and ending alignments.

Expected Results
Hardware measurements should show that the write DQ bits are deskewed and that the
write DQS are centered in the write DQ window at the end of these calibration stages.

Look at the individual WRITE_DQS_TO_DQ_DQS_ODELAY and

WRITE_DQS_TO_DQ_DQ_ODELAY tap settings for each nibble. The taps should only vary
by 0 to 20 taps. See Determining Window Size in ps, page 513 to calculate the write
window.

Determine if any bytes completed successfully. The write calibration algorithm

sequentially steps through each DQS byte group detecting the capture edges.

If the incorrect data pattern is detected, determine if the error is due to the write access
or the read access. See Determining If a Data Error is Due to the Write or Read,
page 510.

Both edges need to be found. This is possible at all frequencies because the algorithm
uses 90 of ODELAY taps to find the edges.

To analyze the window size in ps, see Determining Window Size in ps, page 513. As a
general rule of thumb, the window size for a healthy system should be 30% of the
expected UI size.

Using the Vivado Hardware Manager and while running the Memory IP Example Design
with Debug Signals enabled, set the trigger (cal_r*_status[18] = R for Rising Edge).
The simulation examples shown in the Debugging Write Per-Bit Deskew Failures > Expected
Results section can be used to additionally monitor the expected behavior for Write DQS
Centering.

Write Data Mask Calibration

Calibration Overview
In all previous stages of calibration, data mask signals are driven low before and after the
required amount of time to ensure they have no impact on calibration. Now, both the read
and the writes have been calibrated and data mask can reliably be adjusted. If DM signals
are not used within the interface, this stage of calibration is skipped.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

418

Chapter 24: Debugging

During DM Calibration, a data pattern of 55555555_55555555 is first written to address
0x000 followed by a write to the same address but with a data pattern of
BBBBBBBB_BBBBBBBB with DM asserted during the rising edge of DQS. A read is then issued
where the expected read back pattern is all B except for the data where DM was asserted.
In these masked locations, a 5 is expected. The same series of steps completed during Write
Per-Bit Deskew and Write DQS Centering is then completed but for the DM bits.

Debug
To determine the status of Write Data Mask Calibration, click the Write DQS to DM/DBI
(Simple) stage under the Status window and view the results within the Memory IP
Properties window. The message displayed in Memory IP Properties identifies how the
stage failed or notes if it passed successfully.
X-Ref Target - Figure 24-32

Figure 24-32:

Memory IP XSDB Debug GUI Example Write DQS to DM/DMBI (Simple)

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

419

Chapter 24: Debugging

The status of Write Data Mask Calibration can also be determined by decoding the
DDR_CAL_ERROR_0 and DDR_CAL_ERROR_1 results according to Table 24-23. Execute the Tcl
commands noted in the XSDB Debug section to generate the XSDB output containing the
signal results.
Table 24-23:

DDR_CAL_ERROR Decode for Write Data Mask Calibration

Write DQS to
DM Deskew DDR_CAL_ DDR_CAL_
DDR_CAL_
ERROR_1 ERROR_0
ERROR_
CODE

0x1

Byte

Description

Recommended Debug Steps

N/A

DQS Deskew Error. Ran out of

taps, no valid data found.

Check BUS_DATA_BURST XSDB field to

check what values were returned. Check
the alignment of DQS to DM during a
write burst with a scope on the PCB.
Check the DQS-to-CK alignment. Check
the WRLVL fields in XSDB for a given
byte. Check the signal level of the DM on
a write.
Check for a mapping issue. This usually
implies a delay is not moving when it
should. Check the connections going to
the XIPHY and ensure the correct RIU is
selected based on the byte being
adjusted.
Check the dbg_cal_seq_rd_cnt and
dbg_cal_seq_cnt.

0x2

Byte

N/A

DQ (or DM) Deskew Error.

Failure point not found (bit
only indicated when set to
CAL_FULL)

0xF

Byte

N/A

Timeout error waiting for

read data to return

Table 24-24 shows the signals and values adjusted or used during the Write Data Mask
stage of calibration. The values can be analyzed in both successful and failing calibrations to
determine the resultant values and the consistency in results across resets. These values can
be found within the Memory IP Core Properties within the Hardware Manager or by
executing the Tcl commands noted in the XSDB Debug section.
Table 24-24:

Signals of Interest for Write Data Mask Calibration

Signal

Usage

Signal Description

WRITE_DQS_TO_DM_DESKEW_BYTE*

One per byte

ODELAY value required to place DQS

into the byte write data valid window
during write per-bit deskew.

WRITE_DQS_TO_DM_PRE_ADJUST_MARGIN_LEFT_BYTE*

One per byte

Left side of the write DQS-to-DM

window measured during calibration
before adjustments made.

WRITE_DQS_TO_DM_PRE_ADJUST_MARGIN_RIGHT _BYTE*

One per byte

Right side of the write DQS-to-DM

window measured during calibration
before adjustments made.

WRITE_DQS_TO_DM _MARGIN_LEFT_BYTE*

One per byte

Left side of the write DQS-to-DM

window.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

420

Chapter 24: Debugging

Table 24-24:

Signals of Interest for Write Data Mask Calibration (Contd)

Signal

Usage

Signal Description

WRITE_DQS_TO_DM _MARGIN_RIGHT _BYTE*

One per byte

Right side of the write DQS-to-DM

window.

WRITE_DQS_TO_DM_DQS_ODELAY_BYTE*

One per byte

Final DQS ODELAY value after Write

DQS-to-DM (simple).

WRITE_DQS_TO_DM_DM_ODELAY_BYTE*_BIT*

One per bit

Final DM ODELAY value after Write

DQS-to-DQ (simple).

WRITE_DQS_ODELAY_FINAL_BYTE*_BIT*

One per byte

Final DQS ODELAY value.

WRITE_DM_ODELAY_FINAL_BYTE*_BIT*

One per bit

Final DM ODELAY value.

BUS_DATA_BURST (2014.3+)

During calibration for a byte an

example data burst is saved for later
analysis in case of failure.
BUS_DATA_BURST_0 holds an initial
read data burst pattern for a given
byte with the starting alignment
prior to write DM deskew
(TX_DATA_PHASE set to 1 for DQS, 0
for DM and DM).
BUS_DATA_BURST_1 holds a read
data burst after write DM deskew
and at the start of write DQS-to-DM
centering, after TX_DATA_PHASE for
DQS is set to 1 and the
TX_DATA_PHASE for DQ/DM is set to
1.
After a byte calibrates, the example
read data saved in the
BUS_DATA_BURST registers is
cleared. BUS_DATA_BURST_2 and
BUS_DATA_BURST_3 are not used.
See Interpreting BUS_DATA_BURST
Data Pattern for additional details.

Data swizzling (bit reordering) is completed within the UltraScale PHY. Therefore, the data
visible on BUS_DATA_BURST and a scope in hardware is ordered differently compared to
what would be seen in ChipScope. Figure 24-33 and Figure 24-34 are examples of how the
data is converted.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

421

Chapter 24: Debugging

X-Ref Target - Figure 24-33

Figure 24-33:

Example First Read Where DM is Opposite Desired Position

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

422

Chapter 24: Debugging

X-Ref Target - Figure 24-34

Figure 24-34:

Read Post DM Deskew Where DM is in Desired Position

This is a sample of results for the Write Data Mask XSDB debug signals:
WRITE_DM_ODELAY_FINAL_BYTE0
WRITE_DM_ODELAY_FINAL_BYTE1
WRITE_DM_ODELAY_FINAL_BYTE2
WRITE_DM_ODELAY_FINAL_BYTE3
WRITE_DM_ODELAY_FINAL_BYTE4
WRITE_DM_ODELAY_FINAL_BYTE5
WRITE_DM_ODELAY_FINAL_BYTE6
WRITE_DM_ODELAY_FINAL_BYTE7
WRITE_DM_ODELAY_FINAL_BYTE8
WRITE_DQS_ODELAY_FINAL_BYTE0
WRITE_DQS_ODELAY_FINAL_BYTE1
WRITE_DQS_ODELAY_FINAL_BYTE2
WRITE_DQS_ODELAY_FINAL_BYTE3
WRITE_DQS_ODELAY_FINAL_BYTE4
WRITE_DQS_ODELAY_FINAL_BYTE5
WRITE_DQS_ODELAY_FINAL_BYTE6
WRITE_DQS_ODELAY_FINAL_BYTE7
WRITE_DQS_ODELAY_FINAL_BYTE8
WRITE_DQS_TO_DM_DESKEW_BYTE0
WRITE_DQS_TO_DM_DESKEW_BYTE1

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

031
01b
02a
036
011
036
029
039
029
02b
010
020
02b
00b
02c
01b
02b
016
035
01d

Send Feedback

423

Chapter 24: Debugging

WRITE_DQS_TO_DM_DESKEW_BYTE2
WRITE_DQS_TO_DM_DESKEW_BYTE3
WRITE_DQS_TO_DM_DESKEW_BYTE4
WRITE_DQS_TO_DM_DESKEW_BYTE5
WRITE_DQS_TO_DM_DESKEW_BYTE6
WRITE_DQS_TO_DM_DESKEW_BYTE7
WRITE_DQS_TO_DM_DESKEW_BYTE8
WRITE_DQS_TO_DM_DM_ODELAY_BYTE0
WRITE_DQS_TO_DM_DM_ODELAY_BYTE1
WRITE_DQS_TO_DM_DM_ODELAY_BYTE2
WRITE_DQS_TO_DM_DM_ODELAY_BYTE3
WRITE_DQS_TO_DM_DM_ODELAY_BYTE4
WRITE_DQS_TO_DM_DM_ODELAY_BYTE5
WRITE_DQS_TO_DM_DM_ODELAY_BYTE6
WRITE_DQS_TO_DM_DM_ODELAY_BYTE7
WRITE_DQS_TO_DM_DM_ODELAY_BYTE8
WRITE_DQS_TO_DM_DQS_ODELAY_BYTE0
WRITE_DQS_TO_DM_DQS_ODELAY_BYTE1
WRITE_DQS_TO_DM_DQS_ODELAY_BYTE2
WRITE_DQS_TO_DM_DQS_ODELAY_BYTE3
WRITE_DQS_TO_DM_DQS_ODELAY_BYTE4
WRITE_DQS_TO_DM_DQS_ODELAY_BYTE5
WRITE_DQS_TO_DM_DQS_ODELAY_BYTE6
WRITE_DQS_TO_DM_DQS_ODELAY_BYTE7
WRITE_DQS_TO_DM_DQS_ODELAY_BYTE8
WRITE_DQS_TO_DM_MARGIN_LEFT_BYTE0
WRITE_DQS_TO_DM_MARGIN_LEFT_BYTE1
WRITE_DQS_TO_DM_MARGIN_LEFT_BYTE2
WRITE_DQS_TO_DM_MARGIN_LEFT_BYTE3
WRITE_DQS_TO_DM_MARGIN_LEFT_BYTE4
WRITE_DQS_TO_DM_MARGIN_LEFT_BYTE5
WRITE_DQS_TO_DM_MARGIN_LEFT_BYTE6
WRITE_DQS_TO_DM_MARGIN_LEFT_BYTE7
WRITE_DQS_TO_DM_MARGIN_LEFT_BYTE8
WRITE_DQS_TO_DM_MARGIN_RIGHT_BYTE0
WRITE_DQS_TO_DM_MARGIN_RIGHT_BYTE1
WRITE_DQS_TO_DM_MARGIN_RIGHT_BYTE2
WRITE_DQS_TO_DM_MARGIN_RIGHT_BYTE3
WRITE_DQS_TO_DM_MARGIN_RIGHT_BYTE4
WRITE_DQS_TO_DM_MARGIN_RIGHT_BYTE5
WRITE_DQS_TO_DM_MARGIN_RIGHT_BYTE6
WRITE_DQS_TO_DM_MARGIN_RIGHT_BYTE7
WRITE_DQS_TO_DM_MARGIN_RIGHT_BYTE8
WRITE_DQS_TO_DM_PRE_ADJUST_MARGIN_LEFT_BYTE0
WRITE_DQS_TO_DM_PRE_ADJUST_MARGIN_LEFT_BYTE1
WRITE_DQS_TO_DM_PRE_ADJUST_MARGIN_LEFT_BYTE2
WRITE_DQS_TO_DM_PRE_ADJUST_MARGIN_LEFT_BYTE3
WRITE_DQS_TO_DM_PRE_ADJUST_MARGIN_LEFT_BYTE4
WRITE_DQS_TO_DM_PRE_ADJUST_MARGIN_LEFT_BYTE5
WRITE_DQS_TO_DM_PRE_ADJUST_MARGIN_LEFT_BYTE6
WRITE_DQS_TO_DM_PRE_ADJUST_MARGIN_LEFT_BYTE7
WRITE_DQS_TO_DM_PRE_ADJUST_MARGIN_LEFT_BYTE8
WRITE_DQS_TO_DM_PRE_ADJUST_MARGIN_RIGHT_BYTE0
WRITE_DQS_TO_DM_PRE_ADJUST_MARGIN_RIGHT_BYTE1
WRITE_DQS_TO_DM_PRE_ADJUST_MARGIN_RIGHT_BYTE2
WRITE_DQS_TO_DM_PRE_ADJUST_MARGIN_RIGHT_BYTE3
WRITE_DQS_TO_DM_PRE_ADJUST_MARGIN_RIGHT_BYTE4
WRITE_DQS_TO_DM_PRE_ADJUST_MARGIN_RIGHT_BYTE5
WRITE_DQS_TO_DM_PRE_ADJUST_MARGIN_RIGHT_BYTE6

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

030
03a
019
039
028
039
028
031
01b
02a
036
011
036
029
039
029
02b
015
026
033
013
02e
01d
02e
019
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
026
01e
01c
019
022
025
023
025
01e
033
03f
03e
03f
039
036
03b

Send Feedback

424

Chapter 24: Debugging

WRITE_DQS_TO_DM_PRE_ADJUST_MARGIN_RIGHT_BYTE7
WRITE_DQS_TO_DM_PRE_ADJUST_MARGIN_RIGHT_BYTE8

string true true 03a

string true true 041

Hardware Measurements

Probe the DM to DQ bit alignment at the memory during writes. Trigger at the start
(cal_r*_status[20] = R for Rising Edge) and again at the end
(cal_r*_status[21] = R for Rising Edge) of Simple Pattern Write Data Mask
Calibration to view the starting and ending alignments.

Probe the DM to DQ bit alignment at the memory during writes. Trigger at the start
(cal_r*_status[38] = R for Rising Edge) and again at the end
(cal_r*_status[39] = R for Rising Edge) of Complex Pattern Write Data Mask
Calibration to view the starting and ending alignments.

The following simulation examples show how the debug signals should behave during
successful Write DQS-to-DM Calibration.
X-Ref Target - Figure 24-35

Figure 24-35:

RTL Debug Signals during Write DQS-to-DM Calibration #1

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

425

Chapter 24: Debugging

X-Ref Target - Figure 24-36

Figure 24-36:

RTL Debug Signals during Write DQS-to-DM Calibration #2

Expected Results

Look at the individual WRITE_DQS_TO_DM_DQS_ODELAY and

WRITE_DQS_TO_DM_DM_ODELAY tap settings for each nibble. The taps should only
vary by 0 to 20 taps. See Determining Window Size in ps, page 513 to calculate the
write window.

Determine if any bytes completed successfully. The write calibration algorithm

sequentially steps through each DQS byte group detecting the capture edges.

If the incorrect data pattern is detected, determine if the error is due to the write access
or the read access. See Determining If a Data Error is Due to the Write or Read,
page 510.

Both edges need to be found. This is possible at all frequencies because the algorithm
uses 90 of ODELAY taps to find the edges.

Write Latency Calibration

Calibration Overview
Write Latency Calibration is required to align DQS to the correct CK edge. During write
leveling, DQS is aligned to the nearest rising edge of CK. However, this might not be the
edge that captures the write command.
Depending on the interface type (UDIMM, RDIMM, or component), the DQS could either be
one CK cycle earlier than, two CK cycles earlier than, or aligned to the CK edge that captures
the write command.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

426

Chapter 24: Debugging

This is a pattern based calibration where coarse adjustments are made on a per byte basis
until the expected on time write pattern is read back. The process is as follows:
1. Issue extended writes followed by a single read.
2. Check the pattern readback against the expected patterns.
3. If necessary add coarse adjustments.
4. Repeat until the on time write pattern is read back, signifying DQS is aligned to the
correct CK cycle, or an incorrect pattern is received resulting in a Write Latency failure.
The following data is written at address 0x000:

Data pattern before (with extra DQS pulses): 0000000000000000

Data pattern written to address 0x000: FF00AA5555AA9966

Data pattern after (with extra DQS pulses): FFFFFFFFFFFFFFFFFF

Reads are then performed where the following patterns can be calibrated:

On time write pattern read back: FF00AA5555AA9966 (no adjustments needed)

One DQS early write pattern read back: AA5555AA9966FFFF

Two DQS early write pattern read back: 55AA9966FFFFFFFF

Three DQS early write pattern read back: 9966FFFFFFFFFFFF

Write Latency Calibration can fail for the following cases and signify a board violation
between DQS and CK trace matching:

Four DQS early pattern FFFFFFFFFFFFFFFF

One DQS late write pattern read back: 0000FF00AA5555AA

Two DQS late write pattern read back: 00000000FF00AA55

Three DQS late write pattern read back: 000000000000FF00

See Interpreting BUS_DATA_BURST Data Pattern for additional details on how these patterns
appear on BUS_DATA_BURST.

Debug
To determine the status of Write Latency Calibration, click the Write Latency Calibration
stage under the Status window and view the results within the Memory IP Properties
window. The message displayed in Memory IP Properties identifies how the stage failed or
notes if it passed successfully.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

427

Chapter 24: Debugging

X-Ref Target - Figure 24-37

Figure 24-37:

Memory IP XSDB Debug GUI Example Write Latency Calibration

The status of Write Latency Calibration can also be determined by decoding the
DDR_CAL_ERROR_0 and DDR_CAL_ERROR_1 results according to Table 24-25. Execute the Tcl
commands noted in the XSDB Debug section to generate the XSDB output containing the
signal results.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

428

Chapter 24: Debugging

Table 24-25:

DDR_CAL_ERROR Decode for Write Latency Calibration

Write Latency
DDR_CAL_ DDR_CAL_ DDR_CAL_
ERROR_
ERROR_1 ERROR_0
CODE

0x1

0x2

0x3

Byte

Byte

Byte

Description

Recommended Debug Steps

Could not find the data pattern

given the amount of movement
available.

Check BUS_DATA_BURST XSDB data to

check which bits failed or what data
looked like when failed. Check margin
for the byte for earlier stages of
calibration. Probe the DQS/DQ signals
(and DM if applicable).

Data pattern not found. Data

late at the start, instead of
F0A55A96, found 00F0A55A.

Check trace lengths for signals

against what is allowed. If other Bytes
calibrated properly check the
WRITE_LATENCY_CALIBRATION_COAR
SE setting for them and check how
much movement was required to
calibrate them. Check that the CAS
write latency is set properly during
the initialization sequence.

N/A

Data pattern not found. Data

too early, not enough
movement to find pattern.
Found pattern of A55A96FF,
5A96FFFF, or 96FFFFFF.

Check trace lengths for signals

against what is allowed. If other Bytes
calibrated properly check the
WRITE_LATENCY_CALIBRATION_COAR
SE setting for them and check how
much movement was required to
calibrate them. Check that the CAS
write latency is set properly during
the initialization sequence.
Check read data margins from earlier
stages of calibration. Check signal
integrity during reads on the DQs and
DQ. Check BUS_DATA_BURST XSDB
data to check which bits failed.
Check the dbg_cal_seq_rd_cnt and
dbg_cal_seq_cnt.

N/A

N/A

0x4

Byte

N/A

Data pattern not found.

Multiple reads to the same
address resulted in a read
mismatch.

0xF

Byte

N/A

Timeout error waiting for read

data to return

Table 24-26 shows the signals and values adjusted or used during the Write Latency stage of
calibration. The values can be analyzed in both successful and failing calibrations to
determine the resultant values and the consistency in results across resets. These values can
be found within the Memory IP Core Properties in the Hardware Manager or by executing
the Tcl commands noted in the XSDB Debug section.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

429

Chapter 24: Debugging

Table 24-26:

Signals of Interest for Write Latency Calibration

Signal

WRITE_LATENCY_CALIBRATION_COARSE

BUS_DATA_BURST (2014.3+)

Usage
One per byte

Signal Description
Number of coarse taps added during Write Latency
calibration.
During calibration for a byte the read data is saved
to XSDB for later analysis in case of a failure.
BUS_DATA_BURST_0 holds the read burst for at the
starting coarse tap value left by write leveling (initial
coarse tap setting).
BUS_DATA_BURST_1 holds the read burst at initial
coarse tap + 4.
BUS_DATA_BURST_2 holds the read burst at initial
coarse tap + 8.
BUS_DATA_BURST_3 holds the read burst at initial
coarse tap + 12.
After a given byte finishes calibration, the
BUS_DATA_BURST registers are cleared to 0 for use
by the next byte.
See Interpreting BUS_DATA_BURST Data Pattern for
additional details.

Data swizzling (bit reordering) is completed within the UltraScale PHY. Therefore, the data
visible on BUS_DATA_BURST and a scope in hardware is ordered differently compared to
what would be seen in ChipScope. Figure 24-38 to Figure 24-40 show examples of how the
data is converted. Because all Fs are written before this expected Write Latency pattern and
all 0s after, this pattern can have Fs before and 0s after until Write Latency calibration is
completed at which time Figure 24-38 to Figure 24-40 are accurate representation.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

430

Chapter 24: Debugging

X-Ref Target - Figure 24-38

Figure 24-38:

Expected Read Pattern of All 0s

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

431

Chapter 24: Debugging

X-Ref Target - Figure 24-39

Figure 24-39:

Expected Read Pattern of FF00AA55AA9966

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

432

Chapter 24: Debugging

X-Ref Target - Figure 24-40

Figure 24-40:

Expected Read Pattern of All 1s

This is a sample of results for the Write Latency XSDB debug signals:
WRITE_LATENCY_CALIBRATION_COARSE_RANK0_BYTE0
WRITE_LATENCY_CALIBRATION_COARSE_RANK0_BYTE1
WRITE_LATENCY_CALIBRATION_COARSE_RANK0_BYTE2
WRITE_LATENCY_CALIBRATION_COARSE_RANK0_BYTE3
WRITE_LATENCY_CALIBRATION_COARSE_RANK0_BYTE4
WRITE_LATENCY_CALIBRATION_COARSE_RANK0_BYTE5
WRITE_LATENCY_CALIBRATION_COARSE_RANK0_BYTE6
WRITE_LATENCY_CALIBRATION_COARSE_RANK0_BYTE7
WRITE_LATENCY_CALIBRATION_COARSE_RANK0_BYTE8

string
string
string
string
string
string
string
string
string

true
true
true
true
true
true
true
true
true

true
true
true
true
true
true
true
true
true

003
004
004
004
006
005
005
005
005

Hardware Measurements
If the design is stuck in the Write Latency stage, the issue could be related to either the write
or the read. Determining whether the write or read is causing the failure is critical. The
following steps should be completed. For additional details and examples, see the
Determining If a Data Error is Due to the Write or Read, page 510 section.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

433

Chapter 24: Debugging

1. To trigger on the start of Write Latency Calibration, set the trigger to
(cal_r*_status[24] = R for Rising Edge).
2. To trigger on the end of Write Latency Calibration, set the trigger to
(cal_r*_status[25] = R for Rising Edge). To look at each byte, additionally add a
trigger on dbg_cmp_byte and set to the byte of interest.
3. To ensure the writes are correct, observe the write DQS to write DQ relationship at the
memory using high quality scope and probes. During Write Latency, a write is followed
by a read so care needs to be taken to ensure the write is captured.For more
information, see the Determining If a Data Error is Due to the Write or Read, page 510
section. If there is a failing bit, determining the write DQS to write DQ relationship for
the specific DQ bit is critical. The write ideally has the DQS center aligned in the DQ
window. Misalignment between DQS and DQ during Write Calibration points to an issue
with Write DQS Centering calibration. Review the Debugging Write DQS Centering
Failures, page 411 section.
4. If the DQ-DQS alignment looks correct, next observe the we_n to DQS relationship at
the memory during a write again using high quality scope and probes. The we_n to DQS
delay must equal the CAS Write Latency (CWL).
5. Using high quality scope and probes, verify the expected pattern (FF00AA5555AA9966)
is being written to the DRAM during a write and that the expected pattern is being read
back during the first Write Calibration read. If the pattern is correct during write and
read at the DRAM, verify the DQS-CK alignment. During Write Calibration, these two
signals should be aligned. Write Leveling aligned these two signals which has
successfully completed before Write Latency.
6. Probe ODT and we_n during a write command.For ODT to be properly powered on in
the memory, ODT must assert before the write command.
7. Probe DM to ensure it is held low during calibration.If a board issue exists causing DM
to improperly assert, incorrect data can be read back during calibration causing a write
calibration failure.An example of a board issue on DM is when DM is not used and tied
low at the memory with improper termination.
Using the Vivado Hardware Manager and while running the Memory IP Example Design with
Debug Signals enabled, set the trigger.

To trigger on the start of Write Latency Calibration, set the trigger to

(cal_r*_status[24] = R for Rising Edge).

To trigger on the end of Write Latency Calibration, set the trigger to

(cal_r*_status[25] = R for Rising Edge). To look at each byte, additionally add a
trigger on dbg_cmp_byte and set to the byte of interest.

The following simulation example shows how the debug signals should behave during
successful Write Latency Calibration.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

434

Chapter 24: Debugging

X-Ref Target - Figure 24-41

Figure 24-41:

RTL Debug Signals during Write Latency Calibration (x4 Example Shown)

Expected Results
The expected value on WRITE_LATENCY_CALIBRATION_COARSE is dependent on the
starting point set by Write Leveling (which can be 0 to 4). The PCB skew to the SDRAM
typically adds up to two memory clock cycles to this starting point where each clock cycle is
four coarse taps.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

435

Chapter 24: Debugging

Debugging Read Complex Pattern Calibration Failures

Calibration Overview
The final stage of DQS read centering that is completed before normal operation is
repeating the steps performed during MPR DQS read centering but with a difficult/complex
pattern. The purpose of using a complex pattern is to stress the system for SI effects such as
ISI and noise while calculating the read DQS center position. This ensures that the read
center position can reliably capture data with margin in a true system.

Debug
To determine the status of Complex Read Leveling Calibration, click the Read DQS
Centering (Complex) stage under the Status window and view the results within the
Memory IP Properties window. The message displayed in Memory IP Properties identifies
how the stage failed or notes if it passed successfully.
X-Ref Target - Figure 24-42

Figure 24-42:

Memory IP XSDB Debug GUI Example Read DQS Centering (Complex)

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

436

Chapter 24: Debugging

The status of Read Leveling Complex can also be determined by decoding the
DDR_CAL_ERROR_0 and DDR_CAL_ERROR_1 results according to Table 24-27. Execute the Tcl
commands noted in the XSDB Debug section to generate the XSDB output containing the
signal results.
Table 24-27:

DDR_CAL_ERROR Decode for Complex Read Leveling

Read DQS
Centering DDR_CAL_ DDR_CAL_
DDR_CAL_
ERROR_1 ERROR_0
ERROR_
CODE

0x1

Nibble

Description

Recommended Debug Steps

N/A

No Valid data found for a

given bit in the nibble

Check if the design meets timing. Check the

margin found for the simple pattern for the
given nibble/byte. Check if the IDELAY
values used for each bit are reasonable to
others in the byte. Check the
dbg_cplx_config, dbg_cplx_status,
dbg_cplx_err_log, dbg_rd_data, and
dbg_expected_data during this stage of
calibration. Determine if it is a read or a
write error by measuring the signals on the
bus after the write.
Check the dbg_cplx_config,
dbg_cplx_status, dbg_cplx_err_log,
dbg_rd_data, and dbg_expected_data and
see if the data changes during this stage of
calibration.
Check the dbg_cal_seq_rd_cnt and
dbg_cal_seq_cnt.

0x2

Nibble

N/A

Could not find the left Edge

(error condition) to
determine window size.

0xF

Nibble

N/A

Timeout error waiting for

read data to return

Table 24-28 shows the signals and values adjusted or used during the Read Leveling
Complex stage of calibration. The values can be analyzed in both successful and failing
calibrations to determine the resultant values and the consistency in results across resets.
These values can be found within the Memory IP Core Properties within the Hardware
Manager or by executing the Tcl commands noted in the XSDB Debug section.
Table 24-28:

Signals of Interest for Complex Pattern Calibration

Signal

Usage

Signal Description

RDLVL_COMPLEX_PQTR_LEFT_Rank*_Nibble*

One per
nibble

Read leveling PQTR tap position when left edge

of read data valid window is detected (complex
pattern).

RDLVL_COMPLEX_NQTR_LEFT_Rank*_Nibble*

One per
nibble

Read leveling NQTR tap position when left edge

of read data valid window is detected (complex
pattern).

RDLVL_COMPLEX_PQTR_RIGHT_Rank*_Nibble*

One per
nibble

Read leveling PQTR tap position when right

edge of read data valid window is detected
(complex pattern).

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

437

Chapter 24: Debugging

Table 24-28:

Signals of Interest for Complex Pattern Calibration (Contd)

Signal

Usage

Signal Description

RDLVL_COMPLEX_NQTR_RIGHT_Rank*_Nibble*

One per
nibble

Read leveling NQTR tap position when right

edge of read data valid window is detected
(complex pattern).

RDLVL_COMPLEX_PQTR_CENTER_Rank*_Nibble*

One per
nibble

Read leveling PQTR center tap position found at

the end of read DQS centering (complex
pattern).

RDLVL_COMPLEX_NQTR_CENTER_Rank*_Nibble*

One per
nibble

Read leveling NQTR center tap position found at

the end of read DQS centering (complex
pattern).

RDLVL_COMPLEX_IDELAY_Rank*_Bit*

One per bit

Read leveling IDELAY delay value (complex

pattern).

RDLVL_COMPLEX_IDELAY_DBI_Byte*

One per
byte

Reserved

This is a sample of results for Complex Read Leveling using the Memory IP Debug GUI within
the Hardware Manager.
Note: Either the Table or Chart view can be used to look at the calibration windows.
Figure 24-43 and Figure 24-44 are screen captures from 2015.1 and might vary from the
current version.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

438

Chapter 24: Debugging

X-Ref Target - Figure 24-43

Figure 24-43:

Example of Complex Read Calibration Margin

This is a sample of results for the Read Leveling Complex XSDB debug signals:
RDLVL_COMPLEX_IDELAY_DBI_BYTE0
RDLVL_COMPLEX_IDELAY_DBI_BYTE1
RDLVL_COMPLEX_IDELAY_DBI_BYTE2
RDLVL_COMPLEX_IDELAY_DBI_BYTE3
RDLVL_COMPLEX_IDELAY_DBI_BYTE4
RDLVL_COMPLEX_IDELAY_DBI_BYTE5
RDLVL_COMPLEX_IDELAY_DBI_BYTE6
RDLVL_COMPLEX_IDELAY_DBI_BYTE7
RDLVL_COMPLEX_IDELAY_RANK0_BYTE0_BIT0
RDLVL_COMPLEX_IDELAY_RANK0_BYTE0_BIT1
RDLVL_COMPLEX_IDELAY_RANK0_BYTE0_BIT2

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

string
string
string
string
string
string
string
string
string
string
string

true
true
true
true
true
true
true
true
true
true
true

true
true
true
true
true
true
true
true
true
true
true

000
000
000
000
000
000
000
000
040
03e
042

Send Feedback

439

Chapter 24: Debugging

RDLVL_COMPLEX_IDELAY_RANK0_BYTE0_BIT3
RDLVL_COMPLEX_IDELAY_RANK0_BYTE0_BIT4
RDLVL_COMPLEX_IDELAY_RANK0_BYTE0_BIT5
RDLVL_COMPLEX_IDELAY_RANK0_BYTE0_BIT6
RDLVL_COMPLEX_IDELAY_RANK0_BYTE0_BIT7
RDLVL_COMPLEX_IDELAY_RANK0_BYTE1_BIT0
RDLVL_COMPLEX_IDELAY_RANK0_BYTE1_BIT1
RDLVL_COMPLEX_IDELAY_RANK0_BYTE1_BIT2
RDLVL_COMPLEX_IDELAY_RANK0_BYTE1_BIT3
RDLVL_COMPLEX_IDELAY_RANK0_BYTE1_BIT4
RDLVL_COMPLEX_IDELAY_RANK0_BYTE1_BIT5
RDLVL_COMPLEX_IDELAY_RANK0_BYTE1_BIT6
RDLVL_COMPLEX_IDELAY_RANK0_BYTE1_BIT7
RDLVL_COMPLEX_IDELAY_RANK0_BYTE2_BIT0
RDLVL_COMPLEX_IDELAY_RANK0_BYTE2_BIT1
RDLVL_COMPLEX_IDELAY_RANK0_BYTE2_BIT2
RDLVL_COMPLEX_IDELAY_RANK0_BYTE2_BIT3
RDLVL_COMPLEX_IDELAY_RANK0_BYTE2_BIT4
RDLVL_COMPLEX_IDELAY_RANK0_BYTE2_BIT5
RDLVL_COMPLEX_IDELAY_RANK0_BYTE2_BIT6
RDLVL_COMPLEX_IDELAY_RANK0_BYTE2_BIT7
RDLVL_COMPLEX_IDELAY_RANK0_BYTE3_BIT0
RDLVL_COMPLEX_IDELAY_RANK0_BYTE3_BIT1
RDLVL_COMPLEX_IDELAY_RANK0_BYTE3_BIT2
RDLVL_COMPLEX_IDELAY_RANK0_BYTE3_BIT3
RDLVL_COMPLEX_IDELAY_RANK0_BYTE3_BIT4
RDLVL_COMPLEX_IDELAY_RANK0_BYTE3_BIT5
RDLVL_COMPLEX_IDELAY_RANK0_BYTE3_BIT6
RDLVL_COMPLEX_IDELAY_RANK0_BYTE3_BIT7
RDLVL_COMPLEX_IDELAY_RANK0_BYTE4_BIT0
RDLVL_COMPLEX_IDELAY_RANK0_BYTE4_BIT1
RDLVL_COMPLEX_IDELAY_RANK0_BYTE4_BIT2
RDLVL_COMPLEX_IDELAY_RANK0_BYTE4_BIT3
RDLVL_COMPLEX_IDELAY_RANK0_BYTE4_BIT4
RDLVL_COMPLEX_IDELAY_RANK0_BYTE4_BIT5
RDLVL_COMPLEX_IDELAY_RANK0_BYTE4_BIT6
RDLVL_COMPLEX_IDELAY_RANK0_BYTE4_BIT7
RDLVL_COMPLEX_IDELAY_RANK0_BYTE5_BIT0
RDLVL_COMPLEX_IDELAY_RANK0_BYTE5_BIT1
RDLVL_COMPLEX_IDELAY_RANK0_BYTE5_BIT2
RDLVL_COMPLEX_IDELAY_RANK0_BYTE5_BIT3
RDLVL_COMPLEX_IDELAY_RANK0_BYTE5_BIT4
RDLVL_COMPLEX_IDELAY_RANK0_BYTE5_BIT5
RDLVL_COMPLEX_IDELAY_RANK0_BYTE5_BIT6
RDLVL_COMPLEX_IDELAY_RANK0_BYTE5_BIT7
RDLVL_COMPLEX_IDELAY_RANK0_BYTE6_BIT0
RDLVL_COMPLEX_IDELAY_RANK0_BYTE6_BIT1
RDLVL_COMPLEX_IDELAY_RANK0_BYTE6_BIT2
RDLVL_COMPLEX_IDELAY_RANK0_BYTE6_BIT3
RDLVL_COMPLEX_IDELAY_RANK0_BYTE6_BIT4
RDLVL_COMPLEX_IDELAY_RANK0_BYTE6_BIT5
RDLVL_COMPLEX_IDELAY_RANK0_BYTE6_BIT6
RDLVL_COMPLEX_IDELAY_RANK0_BYTE6_BIT7
RDLVL_COMPLEX_IDELAY_RANK0_BYTE7_BIT0
RDLVL_COMPLEX_IDELAY_RANK0_BYTE7_BIT1
RDLVL_COMPLEX_IDELAY_RANK0_BYTE7_BIT2
RDLVL_COMPLEX_IDELAY_RANK0_BYTE7_BIT3
RDLVL_COMPLEX_IDELAY_RANK0_BYTE7_BIT4
RDLVL_COMPLEX_IDELAY_RANK0_BYTE7_BIT5

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

040
03d
03e
03d
03e
03d
042
03a
040
03f
042
03e
040
043
040
047
03d
000
03f
043
03c
03d
03d
03d
03c
03e
040
038
040
044
045
046
042
046
041
043
041
040
048
040
047
03f
04c
040
048
038
043
038
042
03b
041
03d
042
044
041
048
043
048
043

Send Feedback

440

Chapter 24: Debugging

RDLVL_COMPLEX_IDELAY_RANK0_BYTE7_BIT6
RDLVL_COMPLEX_IDELAY_RANK0_BYTE7_BIT7
RDLVL_COMPLEX_NQTR_CENTER_RANK0_NIBBLE0
RDLVL_COMPLEX_NQTR_CENTER_RANK0_NIBBLE1
RDLVL_COMPLEX_NQTR_CENTER_RANK0_NIBBLE2
RDLVL_COMPLEX_NQTR_CENTER_RANK0_NIBBLE3
RDLVL_COMPLEX_NQTR_CENTER_RANK0_NIBBLE4
RDLVL_COMPLEX_NQTR_CENTER_RANK0_NIBBLE5
RDLVL_COMPLEX_NQTR_CENTER_RANK0_NIBBLE6
RDLVL_COMPLEX_NQTR_CENTER_RANK0_NIBBLE7
RDLVL_COMPLEX_NQTR_CENTER_RANK0_NIBBLE8
RDLVL_COMPLEX_NQTR_CENTER_RANK0_NIBBLE9
RDLVL_COMPLEX_NQTR_CENTER_RANK0_NIBBLE10
RDLVL_COMPLEX_NQTR_CENTER_RANK0_NIBBLE11
RDLVL_COMPLEX_NQTR_CENTER_RANK0_NIBBLE12
RDLVL_COMPLEX_NQTR_CENTER_RANK0_NIBBLE13
RDLVL_COMPLEX_NQTR_CENTER_RANK0_NIBBLE14
RDLVL_COMPLEX_NQTR_CENTER_RANK0_NIBBLE15
RDLVL_COMPLEX_NQTR_LEFT_RANK0_NIBBLE0
RDLVL_COMPLEX_NQTR_LEFT_RANK0_NIBBLE1
RDLVL_COMPLEX_NQTR_LEFT_RANK0_NIBBLE2
RDLVL_COMPLEX_NQTR_LEFT_RANK0_NIBBLE3
RDLVL_COMPLEX_NQTR_LEFT_RANK0_NIBBLE4
RDLVL_COMPLEX_NQTR_LEFT_RANK0_NIBBLE5
RDLVL_COMPLEX_NQTR_LEFT_RANK0_NIBBLE6
RDLVL_COMPLEX_NQTR_LEFT_RANK0_NIBBLE7
RDLVL_COMPLEX_NQTR_LEFT_RANK0_NIBBLE8
RDLVL_COMPLEX_NQTR_LEFT_RANK0_NIBBLE9
RDLVL_COMPLEX_NQTR_LEFT_RANK0_NIBBLE10
RDLVL_COMPLEX_NQTR_LEFT_RANK0_NIBBLE11
RDLVL_COMPLEX_NQTR_LEFT_RANK0_NIBBLE12
RDLVL_COMPLEX_NQTR_LEFT_RANK0_NIBBLE13
RDLVL_COMPLEX_NQTR_LEFT_RANK0_NIBBLE14
RDLVL_COMPLEX_NQTR_LEFT_RANK0_NIBBLE15
RDLVL_COMPLEX_NQTR_RIGHT_RANK0_NIBBLE0
RDLVL_COMPLEX_NQTR_RIGHT_RANK0_NIBBLE1
RDLVL_COMPLEX_NQTR_RIGHT_RANK0_NIBBLE2
RDLVL_COMPLEX_NQTR_RIGHT_RANK0_NIBBLE3
RDLVL_COMPLEX_NQTR_RIGHT_RANK0_NIBBLE4
RDLVL_COMPLEX_NQTR_RIGHT_RANK0_NIBBLE5
RDLVL_COMPLEX_NQTR_RIGHT_RANK0_NIBBLE6
RDLVL_COMPLEX_NQTR_RIGHT_RANK0_NIBBLE7
RDLVL_COMPLEX_NQTR_RIGHT_RANK0_NIBBLE8
RDLVL_COMPLEX_NQTR_RIGHT_RANK0_NIBBLE9
RDLVL_COMPLEX_NQTR_RIGHT_RANK0_NIBBLE10
RDLVL_COMPLEX_NQTR_RIGHT_RANK0_NIBBLE11
RDLVL_COMPLEX_NQTR_RIGHT_RANK0_NIBBLE12
RDLVL_COMPLEX_NQTR_RIGHT_RANK0_NIBBLE13
RDLVL_COMPLEX_NQTR_RIGHT_RANK0_NIBBLE14
RDLVL_COMPLEX_NQTR_RIGHT_RANK0_NIBBLE15
RDLVL_COMPLEX_PQTR_CENTER_RANK0_NIBBLE0
RDLVL_COMPLEX_PQTR_CENTER_RANK0_NIBBLE1
RDLVL_COMPLEX_PQTR_CENTER_RANK0_NIBBLE2
RDLVL_COMPLEX_PQTR_CENTER_RANK0_NIBBLE3
RDLVL_COMPLEX_PQTR_CENTER_RANK0_NIBBLE4
RDLVL_COMPLEX_PQTR_CENTER_RANK0_NIBBLE5
RDLVL_COMPLEX_PQTR_CENTER_RANK0_NIBBLE6
RDLVL_COMPLEX_PQTR_CENTER_RANK0_NIBBLE7
RDLVL_COMPLEX_PQTR_CENTER_RANK0_NIBBLE8

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

049
045
03c
041
03b
038
03a
039
038
038
03a
03f
041
03a
03d
039
036
040
01a
020
01c
018
01a
018
017
017
016
01d
020
01a
01b
018
013
020
05f
062
05b
059
05b
05a
059
059
05e
061
062
05b
05f
05a
05a
061
03b
03e
038
036
03e
03b
037
037
03c

Send Feedback

441

Chapter 24: Debugging

RDLVL_COMPLEX_PQTR_CENTER_RANK0_NIBBLE9
RDLVL_COMPLEX_PQTR_CENTER_RANK0_NIBBLE10
RDLVL_COMPLEX_PQTR_CENTER_RANK0_NIBBLE11
RDLVL_COMPLEX_PQTR_CENTER_RANK0_NIBBLE12
RDLVL_COMPLEX_PQTR_CENTER_RANK0_NIBBLE13
RDLVL_COMPLEX_PQTR_CENTER_RANK0_NIBBLE14
RDLVL_COMPLEX_PQTR_CENTER_RANK0_NIBBLE15
RDLVL_COMPLEX_PQTR_LEFT_RANK0_NIBBLE0
RDLVL_COMPLEX_PQTR_LEFT_RANK0_NIBBLE1
RDLVL_COMPLEX_PQTR_LEFT_RANK0_NIBBLE2
RDLVL_COMPLEX_PQTR_LEFT_RANK0_NIBBLE3
RDLVL_COMPLEX_PQTR_LEFT_RANK0_NIBBLE4
RDLVL_COMPLEX_PQTR_LEFT_RANK0_NIBBLE5
RDLVL_COMPLEX_PQTR_LEFT_RANK0_NIBBLE6
RDLVL_COMPLEX_PQTR_LEFT_RANK0_NIBBLE7
RDLVL_COMPLEX_PQTR_LEFT_RANK0_NIBBLE8
RDLVL_COMPLEX_PQTR_LEFT_RANK0_NIBBLE9
RDLVL_COMPLEX_PQTR_LEFT_RANK0_NIBBLE10
RDLVL_COMPLEX_PQTR_LEFT_RANK0_NIBBLE11
RDLVL_COMPLEX_PQTR_LEFT_RANK0_NIBBLE12
RDLVL_COMPLEX_PQTR_LEFT_RANK0_NIBBLE13
RDLVL_COMPLEX_PQTR_LEFT_RANK0_NIBBLE14
RDLVL_COMPLEX_PQTR_LEFT_RANK0_NIBBLE15
RDLVL_COMPLEX_PQTR_RIGHT_RANK0_NIBBLE0
RDLVL_COMPLEX_PQTR_RIGHT_RANK0_NIBBLE1
RDLVL_COMPLEX_PQTR_RIGHT_RANK0_NIBBLE2
RDLVL_COMPLEX_PQTR_RIGHT_RANK0_NIBBLE3
RDLVL_COMPLEX_PQTR_RIGHT_RANK0_NIBBLE4
RDLVL_COMPLEX_PQTR_RIGHT_RANK0_NIBBLE5
RDLVL_COMPLEX_PQTR_RIGHT_RANK0_NIBBLE6
RDLVL_COMPLEX_PQTR_RIGHT_RANK0_NIBBLE7
RDLVL_COMPLEX_PQTR_RIGHT_RANK0_NIBBLE8
RDLVL_COMPLEX_PQTR_RIGHT_RANK0_NIBBLE9
RDLVL_COMPLEX_PQTR_RIGHT_RANK0_NIBBLE10
RDLVL_COMPLEX_PQTR_RIGHT_RANK0_NIBBLE11
RDLVL_COMPLEX_PQTR_RIGHT_RANK0_NIBBLE12
RDLVL_COMPLEX_PQTR_RIGHT_RANK0_NIBBLE13
RDLVL_COMPLEX_PQTR_RIGHT_RANK0_NIBBLE14
RDLVL_COMPLEX_PQTR_RIGHT_RANK0_NIBBLE15

string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

03d
040
038
03d
038
03a
042
01c
021
019
016
01e
01b
018
016
018
01c
01f
018
01c
01a
01b
022
05b
05c
057
057
05e
05c
057
058
061
05f
062
058
05f
057
059
062

Expected Results

Look at the individual PQTR/NQTR tap settings for each nibble. The taps should only
vary by 0 to 20 taps. Use the BISC values to compute the estimated bit time in taps.

For example, Byte 7 Nibble 0 in Figure 24-44 is shifted and smaller compared to the
remaining nibbles. This type of result is not expected. For this specific example, the
SDRAM was not properly loaded into the socket.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

442

Chapter 24: Debugging

X-Ref Target - Figure 24-44

Figure 24-44:

Suspicious Calibrated Read Window for Byte 7 Nibble 0

Look at the individual IDELAY taps for each bit. The IDELAY taps should only vary by 0 to
20 taps, and is dependent on PCB trace delays. For Deskew the IDELAY taps are typically
in the 50 to 70 tap range, while PQTR and NQTR are usually in the 0 to 5 tap range.

Determine if any bytes completed successfully. The read leveling algorithm sequentially
steps through each DQS byte group detecting the capture edges.

If the incorrect data pattern is detected, determine if the error is due to the write access
or the read access. See Determining If a Data Error is Due to the Write or Read,
page 510.

To analyze the window size in ps, see Determining Window Size in ps, page 513. As a
general rule of thumb, the window size for a healthy system should be 30% of the
expected UI size.

Compare read leveling window (read margin size) results from the simple pattern
calibration versus the complex pattern calibration. The windows should all shrink but
the reduction in window size should shrink relatively across the data byte lanes.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

443

Chapter 24: Debugging

Use the Memory IP Debug GUI to quickly compare simple versus complex window
sizes.

Figure 24-45 is a screen capture from 2015.1 and might vary from the current version.
X-Ref Target - Figure 24-45

Figure 24-45:

Comparing Simple and Complex Read Calibration Windows

Hardware Measurements
1. Probe the write commands and read commands at the memory:

Write = cs_n= 1; ras_n = 0; cas_n = 1; we_n = 1; act_n = 1 (DDR4 only)

Read = cs_n = 1; ras_n = 0; cas_n = 1; we_n = 0; act_n = 1 (DDR4 only)

2. Probe a data pin to check for data being returned from the DRAM.
3. Probe the V REF level at the DRAM (for DDR3).
4. Probe the DM pin which should be deasserted during the write burst (or tied off on the
board with an appropriate value resistor).
5. Probe the read burst after the write and check if the expected data pattern is being
returned.
6. Check for floating address pins if the expected data is not returned.
7. Check for any stuck-at level issues on DQ pins whose signal level does not change. If at
all possible probe at the receiver to check termination and signal integrity.
8. Check the DBG port signals and the full read data and comparison result to check the
data in general interconnect. The calibration algorithm has RTL logic to issue the

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

444

Chapter 24: Debugging

commands and check the data. Check if the dbg_rd_valid aligns with the data pattern
or is off. Set up a trigger when the error gets asserted to capture signals in the hardware
debugger for analysis.
9. Re-check results from previous calibration stages. Compare passing byte lanes against
failing byte lanes for previous stages of calibration. If a failure occurs during complex
pattern calibration, check the values found during simple pattern calibration for
example.
10. All of the data comparison for complex read calibration occur in the general
interconnect, so it can be useful to pull in the debug data in the hardware debugger and
take a look at what the data looks like coming back as taps are adjusted, see
Figure 24-46 and Figure 24-47. Screenshots shown are from simulation, with a small
loop count set for the data pattern. Look at dbg_rd_data, dbg_rd_valid, and
dbg_cplx_err_log.
11. Using the Vivado Hardware Manager and while running the Memory IP Example Design
with Debug Signals enabled, set the Read Complex calibration trigger to
cal_r*_status[28] = R (rising edge). To view each byte, add an additional trigger on
dbg_cmp_byte and set to the byte of interest. The following simulation example shows
how the debug signals should behave during Read Complex Calibration.
Figure 24-46 shows the start of the complex calibration data pattern with an emphasis
on the dbg_cplx_config bus shown. The read start bit is Bit[0] and the number of
loops is set based on Bits[15:9], hence Figure 24-46 shows the start of complex read
pattern and the loop count set to 1 (for simulation only). The dbg_cplx_status goes
to 1 to indicate the pattern is in progress. See Table 24-2, page 350 for the list of all
debug signals.
X-Ref Target - Figure 24-46

Figure 24-46:

RTL Debug Signals during Read Complex (Start)

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

445

Chapter 24: Debugging

X-Ref Target - Figure 24-47

Figure 24-47:

RTL Debug Signals during Read Complex (Writes and Reads)

12. Analyze the debug signal dbg_cplx_err_log. This signal shows comparison
mismatches on a per-bit basis. When a bit error occurs, signifying an edge of the window
has been found, typically a single bit error is shown on dbg_cplx_err_log. Meaning,
all bits of this bus are 0 except for the single bit that had a comparison mismatch which
is set to 1. When an unexpected data error occurs during complex read calibration, for
example a byte shift, the entire bus would be 1. This is not the expected bit mismatch
found in window detection but points to a true read versus write issue. Now, the read
data should be compared with the expected (compare) data and the error debugged to
determine if it is a read or write issue. Use dbg_rd_data and dbg_rd_dat_cmp to
compare the received data to the expected data.
13. For more information, see Debugging Data Errors, page 492.
14. After failure during this stage of calibration, the design goes into a continuous loop of
read commands to allow board probing.

Debugging Read VREF Calibration Failures (DDR4 Only)

Calibration Overview
During this stage of calibration, the default FPGA Internal VREF value is calibrated to
determine the setting that results in the largest read eye. The default value for component
designs is defined in Table 24-29.
Table 24-29:

Default Read VREF

Default Read VREF Value
(Encoding in Hex)

Default Read VREF Value

(Voltage)

Component (Single or Twin Die)

0x2A (range1)

0.951

Dual Slot, Single Rank DIMM per slot

0x38 (range1)

1.030

Single Slot, Dual Rank DIMM per slot

0x2E (range1)

0.972

Dual Slot, Dual Rank DIMM per slot

0x34 (range1)

1.009

Memory Configuration

The read eye size is initially found with the nominal VREF to set the eye size baseline. The
VREF is then updated, the eye again scanned, and the resultant eye size recorded. The same
steps are then completed by searching through different VREF values. At the end of this
stage of calibration, VREF is set to the value that resulted in the largest read eye size.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

446

Chapter 24: Debugging

Debug
To determine the status of Read VREF Calibration, click the Read V REF Training stage under
the Status window and view the results within the Memory IP Properties window. The
message displayed in Memory IP Properties identifies how the stage failed or notes if it
passed successfully.
X-Ref Target - Figure 24-48

Figure 24-48:

Memory IP XSDB Debug GUI Example Read V REF Training

The status of Read VREF Training can also be determined by decoding the
DDR_CAL_ERROR_1 results according to Table 24-30. Execute the Tcl commands noted in the
XSDB Debug section to generate the XSDB output containing the signal results.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

447

Chapter 24: Debugging

Table 24-30:

DDR_CAL_ERROR Decode for Read V REF Calibration

Read VREF
DDR_CAL_ DDR_CAL_ DDR_CAL_
ERROR_
ERROR_1 ERROR_0
CODE

Description

Recommended Debug Steps

0x1

Byte

N/A

No Valid window found for

any V REF value

Check earlier stages of calibration for

margin seen in the read path. Check if the
design meets timing.

0xF

Nibble

N/A

Timeout error waiting for

read data to return

Check the dbg_cal_seq_rd_cnt and

dbg_cal_seq_cnt.

Table 24-31:

Signals of Interest for Complex Pattern Calibration

Signal

Usage

Signal Description

READ_VREF_CAL_EYE_LEFT_EDGE_BYTE*

One per byte

The left edge PQTR/NQTR tap value measured at

the maximum eye VREF value
READ_VREF_CAL_VREF_FINAL_VALUE_BYTE*.

READ_VREF_CAL_EYE_RIGHT_EDGE_BYTE*

One per byte

The right edge PQTR/NQTR tap value measured

at the maximum eye VREF value
READ_VREF_CAL_VREF_FINAL_VALUE_BYTE*.

READ_VREF_CAL_EYE_SIZE_BYTE*

One per byte

Eye Size measured at the maximum eye V REF

value
READ_VREF_CAL_VREF_FINAL_VALUE_BYTE*.
(READ_VREF_CAL_EYE_RIGHT_EDGE_BYTE* -

READ_VREF_CAL_EYE_LEFT_EDGE_BYTE*)
READ_VREF_CAL_VREF_COARSE_VALUE_BYTE*

READ_VREF_CAL_VREF_VALUE_BYTE*

One per byte

V REF value resulted in maximum eye width in

COARSE search.

One per byte

Final V REF value resulted in maximum eye width.

For DDR4 1866 and above, this represents FINE
search value. Below DDR 1866, this represents
COARSE search value.

This is a sample of results for the Read VREF Training XSDB debug signals:.
Note: In x4 72-bit case, as Read VREF is calibrated per byte, BYTE0 to 8 are populated. BYTE9 to 17 are
set to 0 and can be ignored.
Table 24-32:

Read VREF XSDB from x8 72-bit Design

Signal

Offset

READ_VREF_CAL_EYE_LEFT_EDGE_BYTE0

014

READ_VREF_CAL_EYE_LEFT_EDGE_BYTE1

00B

READ_VREF_CAL_EYE_LEFT_EDGE_BYTE2

007

READ_VREF_CAL_EYE_LEFT_EDGE_BYTE3

009

READ_VREF_CAL_EYE_LEFT_EDGE_BYTE4

008

READ_VREF_CAL_EYE_LEFT_EDGE_BYTE5

00F

READ_VREF_CAL_EYE_LEFT_EDGE_BYTE6

008

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

448

Chapter 24: Debugging

Table 24-32:

Read VREF XSDB from x8 72-bit Design (Contd)

Signal

Offset

READ_VREF_CAL_EYE_LEFT_EDGE_BYTE7

00F

READ_VREF_CAL_EYE_LEFT_EDGE_BYTE8

00E

READ_VREF_CAL_EYE_RIGHT_EDGE_BYTE0

073

READ_VREF_CAL_EYE_RIGHT_EDGE_BYTE1

06B

READ_VREF_CAL_EYE_RIGHT_EDGE_BYTE2

066

READ_VREF_CAL_EYE_RIGHT_EDGE_BYTE3

069

READ_VREF_CAL_EYE_RIGHT_EDGE_BYTE4

067

READ_VREF_CAL_EYE_RIGHT_EDGE_BYTE5

06E

READ_VREF_CAL_EYE_RIGHT_EDGE_BYTE6

068

READ_VREF_CAL_EYE_RIGHT_EDGE_BYTE7

06E

READ_VREF_CAL_EYE_RIGHT_EDGE_BYTE8

06C

READ_VREF_CAL_EYE_SIZE_BYTE0

05F

READ_VREF_CAL_EYE_SIZE_BYTE1

060

READ_VREF_CAL_EYE_SIZE_BYTE2

05F

READ_VREF_CAL_EYE_SIZE_BYTE3

060

READ_VREF_CAL_EYE_SIZE_BYTE4

05F

READ_VREF_CAL_EYE_SIZE_BYTE5

05F

READ_VREF_CAL_EYE_SIZE_BYTE6

060

READ_VREF_CAL_EYE_SIZE_BYTE7

05F

READ_VREF_CAL_EYE_SIZE_BYTE8

05E

READ_VREF_CAL_VREF_COARSE_VALUE_BYTE0

012

READ_VREF_CAL_VREF_COARSE_VALUE_BYTE1

01B

READ_VREF_CAL_VREF_COARSE_VALUE_BYTE2

01B

READ_VREF_CAL_VREF_COARSE_VALUE_BYTE3

012

READ_VREF_CAL_VREF_COARSE_VALUE_BYTE4

01B

READ_VREF_CAL_VREF_COARSE_VALUE_BYTE5

01B

READ_VREF_CAL_VREF_COARSE_VALUE_BYTE6

01B

READ_VREF_CAL_VREF_COARSE_VALUE_BYTE7

01B

READ_VREF_CAL_VREF_COARSE_VALUE_BYTE8

01B

READ_VREF_CAL_VREF_FINAL_VALUE_BYTE0

016

READ_VREF_CAL_VREF_FINAL_VALUE_BYTE1

01A

READ_VREF_CAL_VREF_FINAL_VALUE_BYTE2

017

READ_VREF_CAL_VREF_FINAL_VALUE_BYTE3

016

READ_VREF_CAL_VREF_FINAL_VALUE_BYTE4

01A

READ_VREF_CAL_VREF_FINAL_VALUE_BYTE5

017

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

449

Chapter 24: Debugging

Table 24-32:

Read VREF XSDB from x8 72-bit Design (Contd)

Signal

Offset

READ_VREF_CAL_VREF_FINAL_VALUE_BYTE6

01C

READ_VREF_CAL_VREF_FINAL_VALUE_BYTE7

017

READ_VREF_CAL_VREF_FINAL_VALUE_BYTE8

01A

Table 24-33:

Read VREF XSDB from x4 72-bit Design

Signal

Offset

READ_VREF_CAL_EYE_LEFT_EDGE_BYTE0

015

READ_VREF_CAL_EYE_LEFT_EDGE_BYTE1

011

READ_VREF_CAL_EYE_LEFT_EDGE_BYTE2

010

READ_VREF_CAL_EYE_LEFT_EDGE_BYTE3

00F

READ_VREF_CAL_EYE_LEFT_EDGE_BYTE4

005

READ_VREF_CAL_EYE_LEFT_EDGE_BYTE5

016

READ_VREF_CAL_EYE_LEFT_EDGE_BYTE6

009

READ_VREF_CAL_EYE_LEFT_EDGE_BYTE7

016

READ_VREF_CAL_EYE_LEFT_EDGE_BYTE8

01C

READ_VREF_CAL_EYE_LEFT_EDGE_BYTE9

000

READ_VREF_CAL_EYE_LEFT_EDGE_BYTE10

000

READ_VREF_CAL_EYE_LEFT_EDGE_BYTE11

000

READ_VREF_CAL_EYE_LEFT_EDGE_BYTE12

000

READ_VREF_CAL_EYE_LEFT_EDGE_BYTE13

000

READ_VREF_CAL_EYE_LEFT_EDGE_BYTE14

000

READ_VREF_CAL_EYE_LEFT_EDGE_BYTE15

000

READ_VREF_CAL_EYE_LEFT_EDGE_BYTE16

000

READ_VREF_CAL_EYE_LEFT_EDGE_BYTE17

000

READ_VREF_CAL_EYE_RIGHT_EDGE_BYTE0

06C

READ_VREF_CAL_EYE_RIGHT_EDGE_BYTE1

060

READ_VREF_CAL_EYE_RIGHT_EDGE_BYTE2

062

READ_VREF_CAL_EYE_RIGHT_EDGE_BYTE3

064

READ_VREF_CAL_EYE_RIGHT_EDGE_BYTE4

05A

READ_VREF_CAL_EYE_RIGHT_EDGE_BYTE5

069

READ_VREF_CAL_EYE_RIGHT_EDGE_BYTE6

05C

READ_VREF_CAL_EYE_RIGHT_EDGE_BYTE7

067

READ_VREF_CAL_EYE_RIGHT_EDGE_BYTE8

06E

READ_VREF_CAL_EYE_RIGHT_EDGE_BYTE9

000

READ_VREF_CAL_EYE_RIGHT_EDGE_BYTE10

000

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

450

Chapter 24: Debugging

Table 24-33:

Read VREF XSDB from x4 72-bit Design (Contd)

Signal

Offset

READ_VREF_CAL_EYE_RIGHT_EDGE_BYTE11

000

READ_VREF_CAL_EYE_RIGHT_EDGE_BYTE12

000

READ_VREF_CAL_EYE_RIGHT_EDGE_BYTE13

000

READ_VREF_CAL_EYE_RIGHT_EDGE_BYTE14

000

READ_VREF_CAL_EYE_RIGHT_EDGE_BYTE15

000

READ_VREF_CAL_EYE_RIGHT_EDGE_BYTE16

000

READ_VREF_CAL_EYE_RIGHT_EDGE_BYTE17

000

READ_VREF_CAL_EYE_SIZE_BYTE0

057

READ_VREF_CAL_EYE_SIZE_BYTE1

04F

READ_VREF_CAL_EYE_SIZE_BYTE2

052

READ_VREF_CAL_EYE_SIZE_BYTE3

055

READ_VREF_CAL_EYE_SIZE_BYTE4

055

READ_VREF_CAL_EYE_SIZE_BYTE5

053

READ_VREF_CAL_EYE_SIZE_BYTE6

053

READ_VREF_CAL_EYE_SIZE_BYTE7

051

READ_VREF_CAL_EYE_SIZE_BYTE8

052

READ_VREF_CAL_EYE_SIZE_BYTE9

000

READ_VREF_CAL_EYE_SIZE_BYTE10

000

READ_VREF_CAL_EYE_SIZE_BYTE11

000

READ_VREF_CAL_EYE_SIZE_BYTE12

000

READ_VREF_CAL_EYE_SIZE_BYTE13

000

READ_VREF_CAL_EYE_SIZE_BYTE14

000

READ_VREF_CAL_EYE_SIZE_BYTE15

000

READ_VREF_CAL_EYE_SIZE_BYTE16

000

READ_VREF_CAL_EYE_SIZE_BYTE17

000

READ_VREF_CAL_VREF_COARSE_VALUE_BYTE0

024

READ_VREF_CAL_VREF_COARSE_VALUE_BYTE1

024

READ_VREF_CAL_VREF_COARSE_VALUE_BYTE2

024

READ_VREF_CAL_VREF_COARSE_VALUE_BYTE3

024

READ_VREF_CAL_VREF_COARSE_VALUE_BYTE4

024

READ_VREF_CAL_VREF_COARSE_VALUE_BYTE5

024

READ_VREF_CAL_VREF_COARSE_VALUE_BYTE6

024

READ_VREF_CAL_VREF_COARSE_VALUE_BYTE7

024

READ_VREF_CAL_VREF_COARSE_VALUE_BYTE8

024

READ_VREF_CAL_VREF_COARSE_VALUE_BYTE9

000

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

451

Chapter 24: Debugging

Table 24-33:

Read VREF XSDB from x4 72-bit Design (Contd)

Signal

Offset

READ_VREF_CAL_VREF_COARSE_VALUE_BYTE10

000

READ_VREF_CAL_VREF_COARSE_VALUE_BYTE11

000

READ_VREF_CAL_VREF_COARSE_VALUE_BYTE12

000

READ_VREF_CAL_VREF_COARSE_VALUE_BYTE13

000

READ_VREF_CAL_VREF_COARSE_VALUE_BYTE14

000

READ_VREF_CAL_VREF_COARSE_VALUE_BYTE15

000

READ_VREF_CAL_VREF_COARSE_VALUE_BYTE16

000

READ_VREF_CAL_VREF_COARSE_VALUE_BYTE17

000

READ_VREF_CAL_VREF_FINAL_VALUE_BYTE0

028

READ_VREF_CAL_VREF_FINAL_VALUE_BYTE1

021

READ_VREF_CAL_VREF_FINAL_VALUE_BYTE2

024

READ_VREF_CAL_VREF_FINAL_VALUE_BYTE3

021

READ_VREF_CAL_VREF_FINAL_VALUE_BYTE4

020

READ_VREF_CAL_VREF_FINAL_VALUE_BYTE5

023

READ_VREF_CAL_VREF_FINAL_VALUE_BYTE6

020

READ_VREF_CAL_VREF_FINAL_VALUE_BYTE7

021

READ_VREF_CAL_VREF_FINAL_VALUE_BYTE8

021

READ_VREF_CAL_VREF_FINAL_VALUE_BYTE9

000

READ_VREF_CAL_VREF_FINAL_VALUE_BYTE10

000

READ_VREF_CAL_VREF_FINAL_VALUE_BYTE11

000

READ_VREF_CAL_VREF_FINAL_VALUE_BYTE12

000

READ_VREF_CAL_VREF_FINAL_VALUE_BYTE13

000

READ_VREF_CAL_VREF_FINAL_VALUE_BYTE14

000

READ_VREF_CAL_VREF_FINAL_VALUE_BYTE15

000

READ_VREF_CAL_VREF_FINAL_VALUE_BYTE16

000

READ_VREF_CAL_VREF_FINAL_VALUE_BYTE17

000

Table 24-34:

Read VREF XSDB from x16 72-bit Design

Signal

Offset

READ_VREF_CAL_EYE_LEFT_EDGE_BYTE0

00C

READ_VREF_CAL_EYE_LEFT_EDGE_BYTE1

012

READ_VREF_CAL_EYE_LEFT_EDGE_BYTE2

00C

READ_VREF_CAL_EYE_LEFT_EDGE_BYTE3

008

READ_VREF_CAL_EYE_LEFT_EDGE_BYTE4

00D

READ_VREF_CAL_EYE_LEFT_EDGE_BYTE5

00D

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

452

Chapter 24: Debugging

Table 24-34:

Read VREF XSDB from x16 72-bit Design (Contd)

Signal

Offset

READ_VREF_CAL_EYE_LEFT_EDGE_BYTE6

00B

READ_VREF_CAL_EYE_LEFT_EDGE_BYTE7

010

READ_VREF_CAL_EYE_LEFT_EDGE_BYTE8

00E

READ_VREF_CAL_EYE_RIGHT_EDGE_BYTE0

055

READ_VREF_CAL_EYE_RIGHT_EDGE_BYTE1

05D

READ_VREF_CAL_EYE_RIGHT_EDGE_BYTE2

053

READ_VREF_CAL_EYE_RIGHT_EDGE_BYTE3

055

READ_VREF_CAL_EYE_RIGHT_EDGE_BYTE4

059

READ_VREF_CAL_EYE_RIGHT_EDGE_BYTE5

058

READ_VREF_CAL_EYE_RIGHT_EDGE_BYTE6

056

READ_VREF_CAL_EYE_RIGHT_EDGE_BYTE7

05C

READ_VREF_CAL_EYE_RIGHT_EDGE_BYTE8

058

READ_VREF_CAL_EYE_SIZE_BYTE0

049

READ_VREF_CAL_EYE_SIZE_BYTE1

04B

READ_VREF_CAL_EYE_SIZE_BYTE2

047

READ_VREF_CAL_EYE_SIZE_BYTE3

04D

READ_VREF_CAL_EYE_SIZE_BYTE4

04C

READ_VREF_CAL_EYE_SIZE_BYTE5

04B

READ_VREF_CAL_EYE_SIZE_BYTE6

04B

READ_VREF_CAL_EYE_SIZE_BYTE7

04C

READ_VREF_CAL_EYE_SIZE_BYTE8

04A

READ_VREF_CAL_VREF_COARSE_VALUE_BYTE0

01B

READ_VREF_CAL_VREF_COARSE_VALUE_BYTE1

01B

READ_VREF_CAL_VREF_COARSE_VALUE_BYTE2

01B

READ_VREF_CAL_VREF_COARSE_VALUE_BYTE3

01B

READ_VREF_CAL_VREF_COARSE_VALUE_BYTE4

01B

READ_VREF_CAL_VREF_COARSE_VALUE_BYTE5

01B

READ_VREF_CAL_VREF_COARSE_VALUE_BYTE6

01B

READ_VREF_CAL_VREF_COARSE_VALUE_BYTE7

024

READ_VREF_CAL_VREF_COARSE_VALUE_BYTE8

01B

READ_VREF_CAL_VREF_FINAL_VALUE_BYTE0

01B

READ_VREF_CAL_VREF_FINAL_VALUE_BYTE1

01C

READ_VREF_CAL_VREF_FINAL_VALUE_BYTE2

01E

READ_VREF_CAL_VREF_FINAL_VALUE_BYTE3

01D

READ_VREF_CAL_VREF_FINAL_VALUE_BYTE4

01B

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

453

Chapter 24: Debugging

Table 24-34:

Read VREF XSDB from x16 72-bit Design (Contd)

Signal

Offset

READ_VREF_CAL_VREF_FINAL_VALUE_BYTE5

01C

READ_VREF_CAL_VREF_FINAL_VALUE_BYTE6

01D

READ_VREF_CAL_VREF_FINAL_VALUE_BYTE7

020

READ_VREF_CAL_VREF_FINAL_VALUE_BYTE8

01A

Expected Results

Look at READ_VREF_CAL_EYE_SIZE_BYTE* to check the eye width. This value should be similar
to the simple read window size. The same data pattern is used during simple DQS Read
Centering and Read VREF calibration.

Look at READ_VREF_CAL_VREF_VALUE_BYTE* if V REF value falls into the expected range

of the voltage value. VREF_VALUE approximately ranges from 1 to 72, represents 58% to
94% VCCO. VREF_VALUE = 0 represents 65% VCCO.

Debugging Write Complex Pattern Calibration Failures

Calibration Overview
The final stage of Write DQS-to-DQ centering that is completed before normal operation is
repeating the steps performed during Write DQS-to-DQ centering but with a difficult/
complex pattern. The purpose of using a complex pattern is to stress the system for SI
effects such as ISI and noise while calculating the write DQS center and write DQ positions.
This ensures the write center position can reliably capture data with margin in a true system.

Debug
To determine the status of Write Complex Pattern Calibration, click the Write DQS to DQ
(Complex) stage under the Status window and view the results within the Memory IP
Properties window. The message displayed in Memory IP Properties identifies how the
stage failed or notes if it passed successfully.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

454

Chapter 24: Debugging

X-Ref Target - Figure 24-49

Figure 24-49:

Memory IP XSDB Debug GUI Example Write DQS to DQ (Complex)

The status of Write Complex Pattern Calibration can also be determined by decoding the
DDR_CAL_ERROR_0 and DDR_CAL_ERROR_1 results according to Table 24-35. Execute the Tcl
commands noted in the XSDB Debug section to generate the XSDB output containing the
signal results.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

455

Chapter 24: Debugging

Table 24-35:

DDR_CAL_ERROR Decode for Read Leveling and Write DQS Centering Calibration

Write DQS to
DQ
DDR_CAL_ DDR_CAL_
DDR_CAL_ ERROR_1 ERROR_0
ERROR_
CODE

Description

Recommended Debug Steps

0x1

Byte

N/A

No Valid Data found

Check if the design meets timing. Check the

margin found for the simple pattern for the
given nibble/byte. Check if the ODELAY values
used for each bit are reasonable to others in
the byte. Check the dbg_cplx_config,
dbg_cplx_status, dbg_cplx_err_log,
dbg_rd_data, and dbg_expected_data during
this stage of calibration. Check the default
VREF value being used is correct for the
configuration.

0xF

Byte

N/A

Timeout error waiting

for read data to return

Check the dbg_cal_seq_rd_cnt and

dbg_cal_seq_cnt.

Table 24-36 shows the signals and values adjusted or used during the Write Complex
Pattern stage of calibration. The values can be analyzed in both successful and failing
calibrations to determine the resultant values and the consistency in results across resets.
These values can be found within the Memory IP Core Properties within the Hardware
Manager or by executing the Tcl commands noted in the XSDB Debug section.
Table 24-36:

Signals of Interest for Complex Pattern Calibration

Signal

Usage

Signal Description

WRITE_COMPLEX_DQS_TO_DQ_PRE_ADJUST_MARGIN_
LEFT_BYTE*

One per
byte

Left side of the write DQS-to-DQ window

measured during calibration before
adjustments made.

WRITE_ COMPLEX
_DQS_TO_DQ_PRE_ADJUST_MARGIN_RIGHT _BYTE*

One per
byte

Right side of the write DQS-to-DQ

window measured during calibration
before adjustments made.

WRITE_ COMPLEX _DQS_TO_DQ _MARGIN_LEFT_BYTE*

One per
byte

Left side of the write DQS-to-DQ window.

WRITE_ COMPLEX _DQS_TO_DQ _MARGIN_RIGHT

_BYTE*

One per
byte

Right side of the write DQS-to-DQ

window.

WRITE_ COMPLEX _DQS_TO_DQ_DQS_ODELAY_BYTE*

One per
byte

Final DQS ODELAY value after Write

DQS-to-DQ (Complex).

WRITE_ COMPLEX
_DQS_TO_DQ_DQ_ODELAY_BYTE*_BIT*

One per bit

Final DQ ODELAY value after Write

DQS-to-DQ (Complex).

WRITE_DQS_ODELAY_FINAL_BYTE*_BIT*

One per
byte

Final DQS ODELAY value.

WRITE_DQ_ODELAY_FINAL_BYTE*_BIT*

One per bit

Final DQ ODELAY value.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

456

Chapter 24: Debugging

Expected Results

Look at the individual WRITE_COMPLEX_DQS_TO_DQ_DQS_ODELAY and

WRITE_COMPLEX_DQS_TO_DQ_DQ_ODELAY tap settings for each nibble. The taps
should only vary by 0 to 20 taps. To calculate the write window, see Determining
Window Size in ps, page 513.

Determine if any bytes completed successfully. The write calibration algorithm

sequentially steps through each DQS byte group detecting the capture edges.

If the incorrect data pattern is detected, determine if the error is due to the write access
or the read access. See Determining If a Data Error is Due to the Write or Read,
page 510.

Both edges need to be found. This is possible at all frequencies because the algorithm
uses 90 of ODELAY taps to find the edges.

To analyze the window size in ps, see Determining Window Size in ps, page 513. As a
general rule of thumb, the window size for a healthy system should be 30% of the
expected UI size.

Using the Vivado Hardware Manager and while running the Memory IP Example Design with
the Debug Signals enabled, set the trigger (cal_r*_status[36] = R for Rising Edge).
The following simulation example shows how the debug signals should behave during
successful Write DQS-to-DQ.
X-Ref Target - Figure 24-50

Figure 24-50:

Expected Behavior during Write Complex Pattern Calibration

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

457

Chapter 24: Debugging

Hardware Measurements
1. If the write complex pattern fails, use high quality probes and scope the DQS-to-DQ
phase relationship at the memory during a write. Trigger at the start
(cal_r*_status[36] = R for Rising Edge) and again at the end
(cal_r*_status[37] = R for Rising Edge) of Write Complex DQS Centering to view
the starting and ending alignments. The alignment should be approximately 90.
2. If the DQS-to-DQ alignment is correct, observe the we_n-to-DQS relationship to see if it
meets CWL again using cal_r*_status[25] = R for Rising Edge as a trigger.
3. For all stages of write/read leveling, probe the write commands and read commands at
the memory:

Write = cs_n = 1; ras_n = 0; cas_n = 1; we_n = 1; act_n = 1 (DDR4 only)

Read = cs_n = 1; ras_n = 0; cas_n = 1; we_n = 0; act_n = 1 (DDR4 only)

Debugging Write VREF Calibration Failures (DDR4 Only)

Calibration Overview
DDR4 specifies an internally generated V REF that can be adjusted on a per-component basis.
The V REF can be adjusted so as to maximize the write eye that the DRAM sees at each
component. During this stage of calibration, the initial DRAM VREF value is calibrated to
determine the setting that results in the largest write eye. The default value for component
designs is defined in Table 24-37.
Table 24-37:

Default Write VREF

Default Write VREF Value
(Encoding in Hex)

Default Write VREF Value

(Voltage)

Component (Single or Twin Die)

0x15 (range1)

0.884

Dual Slot, Single Rank DIMM per slot

0x1F (range1)

0.962

Single Slot, Dual Rank DIMM per slot

0x14 (range1)

0.876

Dual Slot, Dual Rank DIMM per slot

0x27 (range1)

1.024

Memory Configuration

During this stage, the RANGE1 provided with the JEDEC DDR4 VREF_DQ Training
specification in MR6, Bit[6] is followed. The write eye size is initially found with the nominal
VREF to set the eye size baseline. The VREF is then updated, the eye again scanned, and the
resultant eye size recorded. The same steps are then completed by searching through
different V REF values. At the end of this stage of calibration, VREF is set to the value that
resulted in the largest write eye size.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

458

Chapter 24: Debugging

Debug
To determine the status of Write VREF Calibration, click the Write V REF Training stage under
the Status window and view the results within the Memory IP Properties window. The
message displayed in Memory IP Properties identifies how the stage failed or notes if it
passed successfully. For multi-rank design, Write VREF status is posted per rank.
X-Ref Target - Figure 24-51

Figure 24-51:

Memory IP XSDB Debug GUI Example Write V REF Training

The status of Write V REF Training can also be determined by decoding the
DDR_CAL_ERROR_1 results according to Table 24-38. Execute the Tcl commands noted in the
XSDB Debug section to generate the XSDB output containing the signal results.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

459

Chapter 24: Debugging

Table 24-38:

DDR_CAL_ERROR Decode for Write V REF Calibration

Write VREF
DDR_CAL_ DDR_CAL_ DDR_CAL_
ERROR_
ERROR_1 ERROR_0
CODE

Description

Recommended Debug Steps

0x1

Byte

N/A

No Valid window found for

any V REF value

Check earlier stages of calibration for

margin seen in the write path. Check if
the design meets timing

0xF

Nibble

N/A

Timeout error waiting for read

data to return

Check the dbg_cal_seq_rd_cnt and

dbg_cal_seq_cnt.

Table 24-39 shows the signals and values adjusted or used during Write V REF Training. The
values can be analyzed in both successful and failing calibrations to determine the resultant
values and the consistency in results across resets. These values can be found within the
Memory IP Core Properties within the Hardware Manager or by executing the Tcl
commands noted in the XSDB Debug section.
Table 24-39:

Signals of Interest for Write V REF Training

Signal

Usage

Signal Description

WRITE_VREF_CAL_EYE_LEFT_EDGE_BYTE*

One per
nibble/
byte/word

The left margin measured in DQ_ODELAY tap at

the maximum eye VREF value
WRITE_VREF_CAL_VREF_FINAL_VALUE_BYTE*.

WRITE_VREF_CAL_EYE_RIGHT_EDGE_BYTE*

One per
nibble/
byte/word

The right margin measured in DQS_ODELAY at the

maximum eye V REF value
WRITE_VREF_CAL_VREF_FINAL_VALUE_BYTE*.

WRITE_VREF_CAL_EYE_SIZE_BYTE*

One per
nibble/
byte/word

Eye Size measured at the maximum eye V REF value

WRITE_VREF_CAL_VREF_FINAL_VALUE_BYTE*.
(WRITE_VREF_CAL_EYE_RIGHT_EDGE_BYTE*

+ WRITE_VREF_CAL_EYE_LEFT_EDGE_BYTE*)

WRITE_VREF_CAL_VREF_COARSE_VALUE_BYTE*

One per
nibble/
byte/word

V REF value resulted in maximum eye width in

COARSE search.

WRITE_VREF_CAL_VREF_VALUE_BYTE*

One per
nibble/
byte/word

Final V REF value resulted in maximum eye width.

For DDR4 1866 and above, this represents FINE
search value. Below DDR 1866, this represents
COARSE search value.

This is a sample of results for the Write VREF Training XSDB debug signals.
Note: In x16 72-bit case, as Write V REF is calibrated per Word, only even bytes are populated.
Table 24-40:

Write V REF XSDB from Dual Rank x4 72-bit Design

Signal

Offset

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK0_BYTE0

027

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK0_BYTE1

027

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK0_BYTE2

025

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

460

Chapter 24: Debugging

Table 24-40:

Write V REF XSDB from Dual Rank x4 72-bit Design (Contd)

Signal

Offset

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK0_BYTE3

024

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK0_BYTE4

025

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK0_BYTE5

027

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK0_BYTE6

028

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK0_BYTE7

02B

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK0_BYTE8

028

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK0_BYTE9

027

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK0_BYTE10

028

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK0_BYTE11

028

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK0_BYTE12

020

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK0_BYTE13

023

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK0_BYTE14

02A

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK0_BYTE15

028

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK0_BYTE16

028

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK0_BYTE17

026

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK1_BYTE0

022

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK1_BYTE1

021

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK1_BYTE2

026

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK1_BYTE3

019

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK1_BYTE4

023

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK1_BYTE5

023

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK1_BYTE6

01A

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK1_BYTE7

02A

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK1_BYTE8

016

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK1_BYTE9

01C

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK1_BYTE10

018

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK1_BYTE11

025

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK1_BYTE12

00D

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK1_BYTE13

01E

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK1_BYTE14

01E

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK1_BYTE15

01B

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK1_BYTE16

021

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK1_BYTE17

026

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK0_BYTE0

031

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK0_BYTE1

032

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

461

Chapter 24: Debugging

Table 24-40:

Write V REF XSDB from Dual Rank x4 72-bit Design (Contd)

Signal

Offset

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK0_BYTE2

032

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK0_BYTE3

02F

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK0_BYTE4

030

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK0_BYTE5

02E

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK0_BYTE6

033

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK0_BYTE7

02F

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK0_BYTE8

02E

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK0_BYTE9

02C

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK0_BYTE10

032

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK0_BYTE11

030

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK0_BYTE12

02F

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK0_BYTE13

02E

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK0_BYTE14

02F

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK0_BYTE15

033

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK0_BYTE16

02F

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK0_BYTE17

02E

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK1_BYTE0

033

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK1_BYTE1

02F

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK1_BYTE2

02F

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK1_BYTE3

034

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK1_BYTE4

02F

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK1_BYTE5

032

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK1_BYTE6

035

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK1_BYTE7

02E

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK1_BYTE8

036

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK1_BYTE9

037

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK1_BYTE10

038

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK1_BYTE11

029

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK1_BYTE12

037

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK1_BYTE13

02C

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK1_BYTE14

034

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK1_BYTE15

036

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK1_BYTE16

033

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK1_BYTE17

02E

WRITE_VREF_CAL_EYE_SIZE_RANK0_BYTE0

058

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

462

Chapter 24: Debugging

Table 24-40:

Write V REF XSDB from Dual Rank x4 72-bit Design (Contd)

Signal

Offset

WRITE_VREF_CAL_EYE_SIZE_RANK0_BYTE1

059

WRITE_VREF_CAL_EYE_SIZE_RANK0_BYTE2

057

WRITE_VREF_CAL_EYE_SIZE_RANK0_BYTE3

053

WRITE_VREF_CAL_EYE_SIZE_RANK0_BYTE4

055

WRITE_VREF_CAL_EYE_SIZE_RANK0_BYTE5

055

WRITE_VREF_CAL_EYE_SIZE_RANK0_BYTE6

05B

WRITE_VREF_CAL_EYE_SIZE_RANK0_BYTE7

05A

WRITE_VREF_CAL_EYE_SIZE_RANK0_BYTE8

056

WRITE_VREF_CAL_EYE_SIZE_RANK0_BYTE9

053

WRITE_VREF_CAL_EYE_SIZE_RANK0_BYTE10

05A

WRITE_VREF_CAL_EYE_SIZE_RANK0_BYTE11

058

WRITE_VREF_CAL_EYE_SIZE_RANK0_BYTE12

04F

WRITE_VREF_CAL_EYE_SIZE_RANK0_BYTE13

051

WRITE_VREF_CAL_EYE_SIZE_RANK0_BYTE14

059

WRITE_VREF_CAL_EYE_SIZE_RANK0_BYTE15

05B

WRITE_VREF_CAL_EYE_SIZE_RANK0_BYTE16

057

WRITE_VREF_CAL_EYE_SIZE_RANK0_BYTE17

054

WRITE_VREF_CAL_EYE_SIZE_RANK1_BYTE0

055

WRITE_VREF_CAL_EYE_SIZE_RANK1_BYTE1

050

WRITE_VREF_CAL_EYE_SIZE_RANK1_BYTE2

055

WRITE_VREF_CAL_EYE_SIZE_RANK1_BYTE3

04D

WRITE_VREF_CAL_EYE_SIZE_RANK1_BYTE4

052

WRITE_VREF_CAL_EYE_SIZE_RANK1_BYTE5

055

WRITE_VREF_CAL_EYE_SIZE_RANK1_BYTE6

04F

WRITE_VREF_CAL_EYE_SIZE_RANK1_BYTE7

058

WRITE_VREF_CAL_EYE_SIZE_RANK1_BYTE8

04C

WRITE_VREF_CAL_EYE_SIZE_RANK1_BYTE9

053

WRITE_VREF_CAL_EYE_SIZE_RANK1_BYTE10

050

WRITE_VREF_CAL_EYE_SIZE_RANK1_BYTE11

04E

WRITE_VREF_CAL_EYE_SIZE_RANK1_BYTE12

044

WRITE_VREF_CAL_EYE_SIZE_RANK1_BYTE13

04A

WRITE_VREF_CAL_EYE_SIZE_RANK1_BYTE14

052

WRITE_VREF_CAL_EYE_SIZE_RANK1_BYTE15

051

WRITE_VREF_CAL_EYE_SIZE_RANK1_BYTE16

054

WRITE_VREF_CAL_EYE_SIZE_RANK1_BYTE17

054

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

463

Chapter 24: Debugging

Table 24-40:

Write V REF XSDB from Dual Rank x4 72-bit Design (Contd)

Signal

Offset

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK0_BYTE0

01E

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK0_BYTE1

01E

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK0_BYTE2

01E

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK0_BYTE3

01E

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK0_BYTE4

01E

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK0_BYTE5

01E

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK0_BYTE6

01E

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK0_BYTE7

01E

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK0_BYTE8

01E

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK0_BYTE9

01E

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK0_BYTE10

01E

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK0_BYTE11

01E

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK0_BYTE12

01E

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK0_BYTE13

01E

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK0_BYTE14

01E

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK0_BYTE15

01E

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK0_BYTE16

01E

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK0_BYTE17

01E

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK1_BYTE0

01E

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK1_BYTE1

01E

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK1_BYTE2

01E

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK1_BYTE3

01E

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK1_BYTE4

01E

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK1_BYTE5

01E

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK1_BYTE6

01E

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK1_BYTE7

01E

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK1_BYTE8

01E

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK1_BYTE9

01E

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK1_BYTE10

01E

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK1_BYTE11

01E

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK1_BYTE12

01E

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK1_BYTE13

01E

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK1_BYTE14

01E

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK1_BYTE15

01E

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK1_BYTE16

01E

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

464

Chapter 24: Debugging

Table 24-40:

Write V REF XSDB from Dual Rank x4 72-bit Design (Contd)

Signal

Offset

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK1_BYTE17

01E

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK0_BYTE0

01D

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK0_BYTE1

01C

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK0_BYTE2

01C

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK0_BYTE3

01C

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK0_BYTE4

01E

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK0_BYTE5

01F

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK0_BYTE6

01D

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK0_BYTE7

01F

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK0_BYTE8

01C

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK0_BYTE9

01E

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK0_BYTE10

01D

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK0_BYTE11

01D

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK0_BYTE12

01D

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK0_BYTE13

01C

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK0_BYTE14

01E

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK0_BYTE15

01C

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK0_BYTE16

01E

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK0_BYTE17

01D

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK1_BYTE0

01D

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK1_BYTE1

01C

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK1_BYTE2

01F

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK1_BYTE3

01D

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK1_BYTE4

01E

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK1_BYTE5

01E

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK1_BYTE6

01E

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK1_BYTE7

01D

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK1_BYTE8

01B

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK1_BYTE9

01D

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK1_BYTE10

01C

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK1_BYTE11

01C

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK1_BYTE12

01D

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK1_BYTE13

01D

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK1_BYTE14

01D

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK1_BYTE15

01B

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

465

Chapter 24: Debugging

Table 24-40:

Write V REF XSDB from Dual Rank x4 72-bit Design (Contd)

Signal

Offset

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK1_BYTE16

01C

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK1_BYTE17

01D

Table 24-41:

Write V REF XSDB from Single Rank x8 72-bit Design

Signal

Offset

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK0_BYTE0

02F

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK0_BYTE1

02F

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK0_BYTE2

02A

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK0_BYTE3

028

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK0_BYTE4

02F

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK0_BYTE5

02D

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK0_BYTE6

027

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK0_BYTE7

028

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK0_BYTE8

029

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK0_BYTE0

034

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK0_BYTE1

02D

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK0_BYTE2

031

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK0_BYTE3

032

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK0_BYTE4

032

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK0_BYTE5

032

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK0_BYTE6

031

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK0_BYTE7

031

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK0_BYTE8

02E

WRITE_VREF_CAL_EYE_SIZE_RANK0_BYTE0

063

WRITE_VREF_CAL_EYE_SIZE_RANK0_BYTE1

05C

WRITE_VREF_CAL_EYE_SIZE_RANK0_BYTE2

05B

WRITE_VREF_CAL_EYE_SIZE_RANK0_BYTE3

05A

WRITE_VREF_CAL_EYE_SIZE_RANK0_BYTE4

061

WRITE_VREF_CAL_EYE_SIZE_RANK0_BYTE5

05F

WRITE_VREF_CAL_EYE_SIZE_RANK0_BYTE6

058

WRITE_VREF_CAL_EYE_SIZE_RANK0_BYTE7

059

WRITE_VREF_CAL_EYE_SIZE_RANK0_BYTE8

057

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK0_BYTE0

01E

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK0_BYTE1

018

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK0_BYTE2

018

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

466

Chapter 24: Debugging

Table 24-41:

Write V REF XSDB from Single Rank x8 72-bit Design (Contd)

Signal

Offset

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK0_BYTE3

018

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK0_BYTE4

012

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK0_BYTE5

018

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK0_BYTE6

018

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK0_BYTE7

012

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK0_BYTE8

018

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK0_BYTE0

01C

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK0_BYTE1

01A

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK0_BYTE2

014

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK0_BYTE3

016

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK0_BYTE4

015

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK0_BYTE5

019

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK0_BYTE6

015

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK0_BYTE7

015

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK0_BYTE8

016

Table 24-42:

Write V REF XSDB from Single Rank x16 72-bit Design

Signal

Offset

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK0_BYTE0

022

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK0_BYTE1

000

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK0_BYTE2

025

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK0_BYTE3

000

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK0_BYTE4

022

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK0_BYTE5

000

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK0_BYTE6

01F

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK0_BYTE7

000

WRITE_VREF_CAL_EYE_LEFT_EDGE_RANK0_BYTE8

024

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK0_BYTE0

02B

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK0_BYTE1

000

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK0_BYTE2

027

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK0_BYTE3

000

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK0_BYTE4

027

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK0_BYTE5

000

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK0_BYTE6

02C

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK0_BYTE7

000

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

467

Chapter 24: Debugging

Table 24-42:

Write V REF XSDB from Single Rank x16 72-bit Design (Contd)
Signal

Offset

WRITE_VREF_CAL_EYE_RIGHT_EDGE_RANK0_BYTE8

028

WRITE_VREF_CAL_EYE_SIZE_RANK0_BYTE0

04A

WRITE_VREF_CAL_EYE_SIZE_RANK0_BYTE1

000

WRITE_VREF_CAL_EYE_SIZE_RANK0_BYTE2

04A

WRITE_VREF_CAL_EYE_SIZE_RANK0_BYTE3

000

WRITE_VREF_CAL_EYE_SIZE_RANK0_BYTE4

049

WRITE_VREF_CAL_EYE_SIZE_RANK0_BYTE5

000

WRITE_VREF_CAL_EYE_SIZE_RANK0_BYTE6

04B

WRITE_VREF_CAL_EYE_SIZE_RANK0_BYTE7

000

WRITE_VREF_CAL_EYE_SIZE_RANK0_BYTE8

04C

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK0_BYTE0

018

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK0_BYTE1

000

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK0_BYTE2

018

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK0_BYTE3

000

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK0_BYTE4

018

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK0_BYTE5

000

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK0_BYTE6

018

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK0_BYTE7

000

WRITE_VREF_CAL_VREF_COARSE_VALUE_RANK0_BYTE8

018

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK0_BYTE0

016

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK0_BYTE1

000

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK0_BYTE2

016

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK0_BYTE3

000

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK0_BYTE4

018

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK0_BYTE5

000

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK0_BYTE6

016

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK0_BYTE7

000

WRITE_VREF_CAL_VREF_FINAL_VALUE_RANK0_BYTE8

015

Expected Results

Look at WRITE_VREF_CAL_EYE_SIZE_BYTE* to check the eye width per x4/x8/x16. This value
should be similar to the simple write window size. The same data pattern is used during simple
DQS Write Centering and Write V REF calibration.

Look at WRITE_VREF_CAL_VREF_VALUE_BYTE* to ensure that the VREF value falls within

the expected voltage range as per VREF_DQ Training RANGE1 from the JEDEC DDR4
standard.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

468

Chapter 24: Debugging

Multi-Rank Adjustments and Checks (Multi-Rank Designs Only)

Calibration Overview
For multi-rank designs, previously calibrated positions must be validated and adjusted
across each rank within the system. The previously calibrated areas that need further
adjustment for multi-rank systems are Read Level, DQS Preamble, and Write Latency. The
adjustments are described in the following sections.
Note: Only dual rank parts are currently supported. Multi-slot support is not yet available.

Common Read Leveling Settings

Each DQS has a single IDELAY/PQTR/NQTR value that is used across ranks. During Read
Leveling Calibration, each rank is allowed to calibrate independently to find the ideal
IDELAY/PQTR/NQTR tap positions for each DQS to each separate rank. During the
multi-rank checks, the minimum and maximum value found for each DQS IDELAY/PQTR/
NQTR positions are checked, the range is computed, and the center point is used as the final
setting. For example, if a DQS has a PQTR that sees values of rank0 = 50, rank1 = 50, rank2
= 50, and rank3 = 75, the final value would be 62. This is done to ensure a value can work
well across all ranks rather than averaging the values and giving preference to values that
happen more frequently.

DQS Gate Adjustment

During DQS gate calibration for multi-rank systems, each rank is allowed to calibrate
independently. After all ranks have been calibrated, an adjustment is required before
normal operation to ensure fast rank-to-rank switching.
Across all ranks within a byte, the read latency and general interconnect delay
(clb2phy_rd_en) must match. During the DQS Gate Adjustment stage of calibration, the
coarse taps found during DQS Preamble Detection for each rank are adjusted such that a
common read latency and clb2phy_rd_en can be used. Additionally, the coarse taps have
to be within four taps within the same byte lane across all ranks. Table 24-43 shows the DQS
Gate adjustment examples.
Table 24-43:
Example
#1
#2
#3

DQS gate Adjustment Examples

Setting

Calibration

After Multi-Rank Adjustment

Rank 0

Rank 1

Rank 0

Rank 1

Read latency

14

15

14

14

Coarse taps

10

Read latency

22

21

21

21

Coarse taps

10

Read latency

10

15

N/A

N/A

Coarse taps

N/A

N/A

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Result
Pass
Pass
Error

Send Feedback

469

Chapter 24: Debugging

Table 24-43:
Example
#4

DQS gate Adjustment Examples (Contd)

Setting

Calibration

After Multi-Rank Adjustment

Rank 0

Rank 1

Rank 0

Rank 1

Read latency

10

11

10

10

Coarse taps

13

Result
Error

Write Latency Check between Ranks

The write leveling and write latency values are calibrated separately for each rank. After all
ranks have been calibrated, a check is made to ensure certain XIPHY requirements are met
on the write path. The difference in write latency between the ranks is allowed to be 180 (or
two XIPHY coarse taps). This is checked during this stage.

Debug
To determine the status of Multi-Rank Adjustments and Checks, click the Read DQS
Centering Multi Rank Adjustment or Multi Rank Adjustments and Checks stage under
the Status window and view the results within the Memory IP Properties window. The
message displayed in Memory IP Properties identifies how the stage failed or notes if it
passed successfully.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

470

Chapter 24: Debugging

X-Ref Target - Figure 24-52

Figure 24-52:

Memory IP XSDB Debug GUI Example Read DQS Centering Multi-Rank Adjustment and
Multi-Rank Adjustment and Checks

The status of Read Level Multi-Rank Adjustment can also be determined by decoding the
DDR_CAL_ERROR_0 and DDR_CAL_ERROR_1 results according to Table 24-44. Execute the Tcl
commands noted in the XSDB Debug section to generate the XSDB output containing the
signal results.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

471

Chapter 24: Debugging

Table 24-44:

DDR_CAL_ERROR Decode for Multi-Rank Adjustments and Checks

Multi-Rank
Adjustments &
Checks
DDR_CAL_ DDR_CAL_
DDR_CAL_
ERROR_1 ERROR_0
ERROR_
CODE

0x1

Byte

0x2

Byte

0x3

Byte

RIU
Nibble

RIU
Nibble

RIU
Nibble

Description

Recommended Debug Steps

Could not find common setting

across ranks for general
interconnect read latency setting
for given byte. Variance between
ranks could not be compensated
with coarse taps.

Check PCB Trace lengths

against what is allowed. Check
the calibration results for
DQS_GATE_COARSE, and
DQS_GATE_READ_LATENCY for
the byte that failed.

Read skew between ranks for a

given byte larger than 360

Check PCB Trace lengths

against what is allowed. Check
the calibration results for
DQS_GATE_COARSE and
DQS_GATE_READ_LATENCY for
the byte that failed.

Write skew between ranks for a

given byte larger than 180

Check PCB Trace lengths

against what is allowed. Check
the calibration results for
WRLVL_COARSE_STABLE0 and
WRITE_LATENCY_CALIBRATIO
N_COARSE for the byte that
failed.

Table 24-45 shows the signals and values adjusted or used during Read Level Multi-Rank
Adjustment and Multi-Rank DQS Gate. The values can be analyzed in both successful and
failing calibrations to determine the resultant values and the consistency in results across
resets. These values can be found within the Memory IP Core Properties within the
Hardware Manager or by executing the Tcl commands noted in the XSDB Debug section.
Table 24-45:

Signals of Interest for Multi-Rank Adjustments and Checks

Signal

Usage

Signal Description

RDLVL_PQTR_FINAL_NIBBLE*

One per
nibble

Final Read leveling PQTR tap position from

the XIPHY.

RDLVL_NQTR_FINAL_NIBBLE*

One per
nibble

Final Read leveling NQTR tap position from

the XIPHY.

RDLVL_IDELAY_FINAL_BYTE*_BIT*

One per Bit

Final IDELAY tap position from the XIPHY.

RDLVL_IDELAY_DBI_FINAL_BYTE*

One per Byte

Reserved

MULTI_RANK_DQS_GATE_READ_LATENCY_BYTE*

One per Byte

Final common general interconnect read

latency setting used for a given byte.

MULTI_RANK_DQS_GATE_COARSE_RANK*_BYTE*

One per Rank

per Byte

Final RL_DLY_COARSE tap value used for a

given byte (might differ from calibrated
value).

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

472

Chapter 24: Debugging

Expected Results
If no adjustments are required then the MULTI_RANK_* signals can be blank as shown, the
field is only populated when a change is made to the values.
MULTI_RANK_DQS_GATE_COARSE_RANK0_BYTE0
MULTI_RANK_DQS_GATE_COARSE_RANK0_BYTE1
MULTI_RANK_DQS_GATE_COARSE_RANK0_BYTE2
MULTI_RANK_DQS_GATE_COARSE_RANK0_BYTE3
MULTI_RANK_DQS_GATE_COARSE_RANK0_BYTE4
MULTI_RANK_DQS_GATE_COARSE_RANK0_BYTE5
MULTI_RANK_DQS_GATE_COARSE_RANK0_BYTE6
MULTI_RANK_DQS_GATE_COARSE_RANK0_BYTE7
MULTI_RANK_DQS_GATE_COARSE_RANK0_BYTE8
MULTI_RANK_DQS_GATE_COARSE_RANK1_BYTE0
MULTI_RANK_DQS_GATE_COARSE_RANK1_BYTE1
MULTI_RANK_DQS_GATE_COARSE_RANK1_BYTE2
MULTI_RANK_DQS_GATE_COARSE_RANK1_BYTE3
MULTI_RANK_DQS_GATE_COARSE_RANK1_BYTE4
MULTI_RANK_DQS_GATE_COARSE_RANK1_BYTE5
MULTI_RANK_DQS_GATE_COARSE_RANK1_BYTE6
MULTI_RANK_DQS_GATE_COARSE_RANK1_BYTE7
MULTI_RANK_DQS_GATE_COARSE_RANK1_BYTE8
MULTI_RANK_DQS_GATE_READ_LATENCY_BYTE0
MULTI_RANK_DQS_GATE_READ_LATENCY_BYTE1
MULTI_RANK_DQS_GATE_READ_LATENCY_BYTE2
MULTI_RANK_DQS_GATE_READ_LATENCY_BYTE3
MULTI_RANK_DQS_GATE_READ_LATENCY_BYTE4
MULTI_RANK_DQS_GATE_READ_LATENCY_BYTE5
MULTI_RANK_DQS_GATE_READ_LATENCY_BYTE6
MULTI_RANK_DQS_GATE_READ_LATENCY_BYTE7
MULTI_RANK_DQS_GATE_READ_LATENCY_BYTE8

000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000
000

The Read level Multi-Rank Adjustment changes the values of the FINAL fields for the read
path. The margin for each individual rank is given in the table and chart but the final value
is stored here.
RDLVL_IDELAY_FINAL_BYTE0_BIT0
RDLVL_IDELAY_FINAL_BYTE0_BIT1
RDLVL_IDELAY_FINAL_BYTE0_BIT2
RDLVL_IDELAY_FINAL_BYTE0_BIT3
RDLVL_IDELAY_FINAL_BYTE0_BIT4
RDLVL_IDELAY_FINAL_BYTE0_BIT5
RDLVL_IDELAY_FINAL_BYTE0_BIT6
RDLVL_IDELAY_FINAL_BYTE0_BIT7
RDLVL_IDELAY_FINAL_BYTE1_BIT0
RDLVL_IDELAY_FINAL_BYTE1_BIT1
RDLVL_IDELAY_FINAL_BYTE1_BIT2
RDLVL_IDELAY_FINAL_BYTE1_BIT3
RDLVL_IDELAY_FINAL_BYTE1_BIT4
RDLVL_IDELAY_FINAL_BYTE1_BIT5
RDLVL_IDELAY_FINAL_BYTE1_BIT6
RDLVL_IDELAY_FINAL_BYTE1_BIT7
RDLVL_IDELAY_FINAL_BYTE2_BIT0
RDLVL_IDELAY_FINAL_BYTE2_BIT1
RDLVL_IDELAY_FINAL_BYTE2_BIT2
RDLVL_IDELAY_FINAL_BYTE2_BIT3

04d
052
055
051
04f
04e
050
04b
04d
050
04f
04c
050
051
052
04e
04f
052
053
049

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

473

Chapter 24: Debugging

RDLVL_IDELAY_FINAL_BYTE2_BIT4
RDLVL_IDELAY_FINAL_BYTE2_BIT5
RDLVL_IDELAY_FINAL_BYTE2_BIT6
RDLVL_IDELAY_FINAL_BYTE2_BIT7
RDLVL_IDELAY_FINAL_BYTE3_BIT0
RDLVL_IDELAY_FINAL_BYTE3_BIT1
RDLVL_IDELAY_FINAL_BYTE3_BIT2
RDLVL_IDELAY_FINAL_BYTE3_BIT3
RDLVL_IDELAY_FINAL_BYTE3_BIT4
RDLVL_IDELAY_FINAL_BYTE3_BIT5
RDLVL_IDELAY_FINAL_BYTE3_BIT6
RDLVL_IDELAY_FINAL_BYTE3_BIT7
RDLVL_IDELAY_FINAL_BYTE4_BIT0
RDLVL_IDELAY_FINAL_BYTE4_BIT1
RDLVL_IDELAY_FINAL_BYTE4_BIT2
RDLVL_IDELAY_FINAL_BYTE4_BIT3
RDLVL_IDELAY_FINAL_BYTE4_BIT4
RDLVL_IDELAY_FINAL_BYTE4_BIT5
RDLVL_IDELAY_FINAL_BYTE4_BIT6
RDLVL_IDELAY_FINAL_BYTE4_BIT7
RDLVL_IDELAY_FINAL_BYTE5_BIT0
RDLVL_IDELAY_FINAL_BYTE5_BIT1
RDLVL_IDELAY_FINAL_BYTE5_BIT2
RDLVL_IDELAY_FINAL_BYTE5_BIT3
RDLVL_IDELAY_FINAL_BYTE5_BIT4
RDLVL_IDELAY_FINAL_BYTE5_BIT5
RDLVL_IDELAY_FINAL_BYTE5_BIT6
RDLVL_IDELAY_FINAL_BYTE5_BIT7
RDLVL_IDELAY_FINAL_BYTE6_BIT0
RDLVL_IDELAY_FINAL_BYTE6_BIT1
RDLVL_IDELAY_FINAL_BYTE6_BIT2
RDLVL_IDELAY_FINAL_BYTE6_BIT3
RDLVL_IDELAY_FINAL_BYTE6_BIT4
RDLVL_IDELAY_FINAL_BYTE6_BIT5
RDLVL_IDELAY_FINAL_BYTE6_BIT6
RDLVL_IDELAY_FINAL_BYTE6_BIT7
RDLVL_IDELAY_FINAL_BYTE7_BIT0
RDLVL_IDELAY_FINAL_BYTE7_BIT1
RDLVL_IDELAY_FINAL_BYTE7_BIT2
RDLVL_IDELAY_FINAL_BYTE7_BIT3
RDLVL_IDELAY_FINAL_BYTE7_BIT4
RDLVL_IDELAY_FINAL_BYTE7_BIT5
RDLVL_IDELAY_FINAL_BYTE7_BIT6
RDLVL_IDELAY_FINAL_BYTE7_BIT7
RDLVL_IDELAY_FINAL_BYTE8_BIT0
RDLVL_IDELAY_FINAL_BYTE8_BIT1
RDLVL_IDELAY_FINAL_BYTE8_BIT2
RDLVL_IDELAY_FINAL_BYTE8_BIT3
RDLVL_IDELAY_FINAL_BYTE8_BIT4
RDLVL_IDELAY_FINAL_BYTE8_BIT5
RDLVL_IDELAY_FINAL_BYTE8_BIT6
RDLVL_IDELAY_FINAL_BYTE8_BIT7
RDLVL_NQTR_CENTER_FINAL_NIBBLE0
RDLVL_NQTR_CENTER_FINAL_NIBBLE1
RDLVL_NQTR_CENTER_FINAL_NIBBLE2
RDLVL_NQTR_CENTER_FINAL_NIBBLE3
RDLVL_NQTR_CENTER_FINAL_NIBBLE4
RDLVL_NQTR_CENTER_FINAL_NIBBLE5
RDLVL_NQTR_CENTER_FINAL_NIBBLE6

04f
052
04e
04c
051
056
04c
04b
04f
050
055
050
04b
04c
046
048
054
055
054
04f
044
049
04a
045
04d
052
04e
04b
03d
03e
039
03c
053
052
04d
04c
040
03f
040
03c
046
047
048
045
04b
050
051
04e
04a
04c
04d
04a
064
06b
066
06b
062
06c
067

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

474

Chapter 24: Debugging

RDLVL_NQTR_CENTER_FINAL_NIBBLE7
RDLVL_NQTR_CENTER_FINAL_NIBBLE8
RDLVL_NQTR_CENTER_FINAL_NIBBLE9
RDLVL_NQTR_CENTER_FINAL_NIBBLE10
RDLVL_NQTR_CENTER_FINAL_NIBBLE11
RDLVL_NQTR_CENTER_FINAL_NIBBLE12
RDLVL_NQTR_CENTER_FINAL_NIBBLE13
RDLVL_NQTR_CENTER_FINAL_NIBBLE14
RDLVL_NQTR_CENTER_FINAL_NIBBLE15
RDLVL_NQTR_CENTER_FINAL_NIBBLE16
RDLVL_NQTR_CENTER_FINAL_NIBBLE17
RDLVL_PQTR_CENTER_FINAL_NIBBLE0
RDLVL_PQTR_CENTER_FINAL_NIBBLE1
RDLVL_PQTR_CENTER_FINAL_NIBBLE2
RDLVL_PQTR_CENTER_FINAL_NIBBLE3
RDLVL_PQTR_CENTER_FINAL_NIBBLE4
RDLVL_PQTR_CENTER_FINAL_NIBBLE5
RDLVL_PQTR_CENTER_FINAL_NIBBLE6
RDLVL_PQTR_CENTER_FINAL_NIBBLE7
RDLVL_PQTR_CENTER_FINAL_NIBBLE8
RDLVL_PQTR_CENTER_FINAL_NIBBLE9
RDLVL_PQTR_CENTER_FINAL_NIBBLE10
RDLVL_PQTR_CENTER_FINAL_NIBBLE11
RDLVL_PQTR_CENTER_FINAL_NIBBLE12
RDLVL_PQTR_CENTER_FINAL_NIBBLE13
RDLVL_PQTR_CENTER_FINAL_NIBBLE14
RDLVL_PQTR_CENTER_FINAL_NIBBLE15
RDLVL_PQTR_CENTER_FINAL_NIBBLE16
RDLVL_PQTR_CENTER_FINAL_NIBBLE17

069
065
05d
05d
05c
061
051
054
04f
063
06d
064
06a
066
068
061
06d
067
06c
069
060
061
061
066
056
058
058
061
06b

Hardware Measurements
No hardware measurements are available because no command or data are sent to the
memory during this stage. Algorithm only goes through previously collected data.

Write and Read Sanity Checks

Calibration Overview
Throughout calibration, read and write/read sanity checks are performed to ensure that as
each stage of calibration completes, proper adjustments and alignments are made allowing
writes and reads to be completed successfully. Sanity checks are performed as follows:

Check for DQS Gate after DQS Preamble Detection

Read Sanity Check after Read DQS Centering (Simple)

Write/Read Sanity Check after Write Latency Calibration

Write/Read Sanity Check after Read DQS Centering (Complex)

Write/Read Sanity Check after Read V REF Training (Reserved)

Write/Read Sanity Check after Write DQS-to-DQ Centering (Complex)

Write/Read Sanity Check after Write VREF Training (Reserved)

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

475

Chapter 24: Debugging

Write/Read Sanity check after Read DQS Centering Multi-Rank Adjustment (For ranks
other than the first one)

Write/Read Sanity check after DQS Gate Multi-Rank Adjustment when there is more
than one rank

Each sanity check performed uses a different data pattern to expand the number of patterns
checked during calibration.
Table 24-46:

Sanity Check Data Patterns

Sanity Check Stage

Data Pattern (as stored) 32

bits, 4 bits concatenated
together each as
{f3,r3,f2,r2,f1,r1,f0,r0}.

Data on DQ bus (nibble) as would

be seen in a simulation or a scope
r0 f0 r1 f1 r2 f2 r3 f3

DQS Gate Sanity Check

0xAAAAAAAA

0F0F_0F0F

Read Sanity Check

0xAAAAAAAA

0F0F_0F0F

Write/Read Sanity Check 0

0x399C4E27

937E_C924

Write/Read Sanity Check 1

0x3587D5DC

E4F1_B837

Write/Read Sanity Check 2

0x919CD315

B254_F02E

Write/Read Sanity Check 3

0x4E2562E5

5AD8_07B1

Write/Read Sanity Check 4

0x2C6C9AAA

03CF_2D43

Write/Read Sanity Check 5

Rank
Rank
Rank
Rank

=
=
=
=

0
1
2
3

(No sanity check)

(0x75294A2F)
(0x75294A30)
(0x75294A31)

Rank
Rank
Rank
Rank

=
=
=
=

0
1
2
3

(No sanity check)

(D397_8DA0)
(C286_9DA0)
(D286_9DA0)

Write/Read Sanity Check 6

Rank
Rank
Rank
Rank

=
=
=
=

0
1
2
3

(0xE5742542)
(0xE5742543)
(0xE5752442)
(0xE5752443)

Rank
Rank
Rank
Rank

=
=
=
=

0
1
2
3

(A1E0_4ED8)
(B1E0_4ED8)
(C1E0_4ED8)
(D1E0_4ED8)

Data swizzling (bit reordering) is completed within the UltraScale PHY. Therefore, the data
visible on BUS_DATA_BURST and a scope in hardware is ordered differently compared to
what would be seen in ChipScope. Figures are examples of how the data is converted for the
sanity check data patterns.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

476

Chapter 24: Debugging

X-Ref Target - Figure 24-53

Figure 24-53:

Expected Read Pattern of DQS Gate and Read Sanity Checks

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

477

Chapter 24: Debugging

X-Ref Target - Figure 24-54

Figure 24-54:

Expected Read Back of Sanity Check 0 Data Pattern

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

478

Chapter 24: Debugging

X-Ref Target - Figure 24-55

Figure 24-55:

Expected Read Back of Sanity Check 1 Data Pattern

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

479

Chapter 24: Debugging

X-Ref Target - Figure 24-56

Figure 24-56:

Expected Read Back of Sanity Check 2 Data Pattern

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

480

Chapter 24: Debugging

X-Ref Target - Figure 24-57

Figure 24-57:

Expected Read Back of Sanity Check 3 Data Pattern

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

481

Chapter 24: Debugging

X-Ref Target - Figure 24-58

Figure 24-58:

Expected Read Back of Sanity Check 4 Data Pattern

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

482

Chapter 24: Debugging

X-Ref Target - Figure 24-59

Figure 24-59:

Expected Read Back of Sanity Check 5 Data Pattern

Debug
To determine the status of each sanity check, analyze the Memory IP Status window to view
the completion of each check. Click the sanity check of interest to view the specific results
within the Memory IP Properties window. The message displayed in Memory IP
Properties identifies how the stage failed or notes if it passed successfully.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

483

Chapter 24: Debugging

X-Ref Target - Figure 24-60

Figure 24-60:

Memory IP XSDB Debug GUI Example Write and Read Sanity Checks

The status of each sanity check can also be determined by decoding

DDR_CAL_STATUS_RANK*_* as shown in Table 24-4. Only two possible errors can occur
during this stage of calibration, as shown Table 24-47. The data pattern used changes
depending on which sanity check stage is run.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

484

Chapter 24: Debugging

Table 24-47:

DDR_CAL_ERROR Decode for Sanity Checks

Check for
DQS Gate
DDR_CAL_ DDR_CAL_
DDR_CAL_ ERROR_1 ERROR_0
ERROR_
CODE

Description

Recommended Debug Steps

Check the BUS_DATA_BURST XSDB

Fields to determine which nibbles/bits
failed. Check margin found during
previous stages of calibration for the
given byte that failed.

Check the dbg_cal_seq_rd_cnt and

dbg_cal_seq_cnt.

0x1

nibble

Writes to error reg for each

nibble that has compare failure.
Register for XSDB holds the last
nibble that had an error. For
2014.3+ the data and expected
data for up to three nibble errors
is written to the data burst
registers of XSDB. The fourth
data burst location holds the
array of all the nibble failures to
indicate which of all nibbles
showed an error.

0xF

N/A

N/A

Timeout error waiting for read

data to return

Table 24-48 shows the signals and values used to help determine which bytes the error
occurred on, as well as to provide some data returned for comparison with the expected
data pattern. These values can be found within the Memory IP Core Properties within the
Hardware Manager or by executing the Tcl commands noted in the XSDB Debug section.
Table 24-48:

Signals of Interest for Sanity Check

Signal

BUS_DATA_BURST (2014.3+)

Usage

Signal Description
Stored sample data and list of which nibbles had an error. Determine
which bytes or bits had a failure.
BUS_DATA_BURST_0 (BIT0-BIT3 addresses) stores the received data
for the first nibble in which an error occurred. BUS_DATA_BURST_0
(BIT4-BIT7 addresses) stores the expected data pattern.
BUS_DATA_BURST_1 (BIT0-BIT3 addresses) stores the received data
for the second nibble in which an error occurred. BUS_DATA_BURST_1
(BIT4-BIT7 addresses) stores the expected data pattern.
BUS_DATA_BURST_2 (BIT0-BIT3 addresses) stores the received data
for the third nibble in which an error occurred. BUS_DATA_BURST_2
(BIT4-BIT7 addresses) stores the expected data pattern.
BUS_DATA_BURST_3 stores an array which indicates which nibbles
saw an error (indicated by a 1 in that bit location). Each address
locations stores an array for up to eight nibbles. For example,
Bus_Data_Burst_3_Bit_0 = 0x3 would indicate nibble 0 and nibble 1
saw an error. Bus_Data_Burst_3_Bit_0 = 0x14 would indicate nibble 2
and nibble 4 saw an error.
Bus_Data_Burst_3_Bit_1 = 0x5 would indicate nibble 8 and nibble 10
saw an error.
See Interpreting BUS_DATA_BURST Data Pattern for additional
details.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

485

Chapter 24: Debugging

Hardware Measurements
The calibration status bits (cal_r*_status) can be used as hardware triggers to capture
the write (when applicable) and read command and data on the scope. The entire interface
is checked with one write followed by one read command, so any bytes or bits that need to
be probed can be checked on a scope. The cal_r*_status triggers are as follows for the
independent sanity checks:

Check for DQS Gate after DQS Preamble Detection:

Start > cal_r*_status[2] = R for Rising Edge

End > cal_r*_status[3] = R for Rising Edge

Read Sanity Check:

Start > cal_r*_status[12] = R for Rising Edge

End > cal_r*_status[13] = R for Rising Edge

Write/Read Sanity Check 0:

Start > cal_r*_status[26] = R for Rising Edge

End > cal_r*_status[27] = R for Rising Edge

Write/Read Sanity Check 1:

Start > cal_r*_status[30] = R for Rising Edge

End > cal_r*_status[31] = R for Rising Edge

Write/Read Sanity Check 2:

Start > cal_r*_status[34] = R for Rising Edge

End > cal_r*_status[35] = R for Rising Edge

Write/Read Sanity Check 3:

Start > cal_r*_status[40] = R for Rising Edge

End > cal_r*_status[41] = R for Rising Edge

Write/Read Sanity Check 4:

Start > cal_r*_status[44] = R for Rising Edge

End > cal_r*_status[45] = R for Rising Edge

Write/Read Sanity Check 5 (for more than 1 rank):

Start > cal_r*_status[48] = R for Rising Edge

End > cal_r*_status[49] = R for Rising Edge

Write/Read Sanity Check 6 (all ranks):

Start > cal_r*_status[52] = R for Rising Edge

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

486

Chapter 24: Debugging

End > cal_r*_status[53] = R for Rising Edge

VT Tracking
Tracking Overview
Calibration occurs one time at start-up, at a set voltage and temperature to ensure relation
capture of the data, but during normal operation the voltage and temperature can change
or drift if conditions change. Voltage and temperature (VT) change can adjust the
relationship between DQS and DQ used for read capture and change the time in which the
DQS/DQ arrive at the FPGA as part of a read.

DQS Gate Tracking

The arrival of the DQS at the FPGA as part of a read is calibrated at start-up, but as VT
changes the time in which the DQS arrives can change. DQS gate tracking monitors the
arrival of the DQS with a signal from the XIPHY and makes small adjustments as required if
the DQS arrives earlier or later a sampling clock in the XIPHY. This adjustment is recorded as
shown in Table 24-49.

Debug
Table 24-49:

Signals of Interest for DQS Tracking

Signal

Usage

Signal Description

DQS_TRACK_COARSE_BYTE*

One per byte

Last recorded value for DQS gate coarse setting.

DQS_TRACK_FINE_BYTE*

One per byte

Last recorded value for DQS gate fine setting.

DQS_TRACK_COARSE_MAX_BYTE*

One per byte

Maximum coarse tap recorded during DQS gate tracking.

DQS_TRACK_FINE_MAX_BYTE*

One per byte

Maximum fine tap recorded during DQS gate tracking.

DQS_TRACK_COARSE_MIN_BYTE*

One per byte

Maximum coarse tap recorded during DQS gate tracking.

DQS_TRACK_FINE_MIN_BYTE*

One per byte

Minimum fine tap recorded during DQS gate tracking.

BISC_ALIGN_PQTR

One per nibble

Initial 0 offset value provided by BISC at power-up.

BISC_ALIGN_NQTR

One per nibble

Initial 0 offset value provided by BISC at power-up.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

487

Chapter 24: Debugging

Table 24-49:

Signals of Interest for DQS Tracking (Contd)

Signal

BISC_PQTR

BISC_NQTR

Usage

Signal Description

One per nibble

Initial 90 offset value provided by BISC at power-up.

Compute 90 value in taps by taking (BISC_PQTR
BISC_ALIGN_PQTR). To estimate tap resolution take ( of
the memory clock period)/ (BISC_PQTR
BISC_ALIGN_PQTR). Useful to know how many fine taps
make up a coarse tap to compute amount of DQS gate
drift (Average of the P & N values used for computation).

One per nibble

Initial 90 offset value provided by BISC at power-up.

Compute 90 value in taps by taking (BISC_NQTR
BISC_ALIGN_NQTR). To estimate tap resolution take ( of
the memory clock period)/ (BISC_NQTR
BISC_ALIGN_NQTR). Useful to know how many fine taps
make up a coarse tap to compute amount of DQS gate
drift. (Average of the P & N values used for computation).

Expected Results
DQS_TRACK_COARSE_MAX_RANK0_BYTE0
DQS_TRACK_COARSE_MAX_RANK0_BYTE1
DQS_TRACK_COARSE_MAX_RANK0_BYTE2
DQS_TRACK_COARSE_MAX_RANK0_BYTE3
DQS_TRACK_COARSE_MAX_RANK0_BYTE4
DQS_TRACK_COARSE_MAX_RANK0_BYTE5
DQS_TRACK_COARSE_MAX_RANK0_BYTE6
DQS_TRACK_COARSE_MAX_RANK0_BYTE7
DQS_TRACK_COARSE_MAX_RANK0_BYTE8
DQS_TRACK_COARSE_MIN_RANK0_BYTE0
DQS_TRACK_COARSE_MIN_RANK0_BYTE1
DQS_TRACK_COARSE_MIN_RANK0_BYTE2
DQS_TRACK_COARSE_MIN_RANK0_BYTE3
DQS_TRACK_COARSE_MIN_RANK0_BYTE4
DQS_TRACK_COARSE_MIN_RANK0_BYTE5
DQS_TRACK_COARSE_MIN_RANK0_BYTE6
DQS_TRACK_COARSE_MIN_RANK0_BYTE7
DQS_TRACK_COARSE_MIN_RANK0_BYTE8
DQS_TRACK_COARSE_RANK0_BYTE0
DQS_TRACK_COARSE_RANK0_BYTE1
DQS_TRACK_COARSE_RANK0_BYTE2
DQS_TRACK_COARSE_RANK0_BYTE3
DQS_TRACK_COARSE_RANK0_BYTE4
DQS_TRACK_COARSE_RANK0_BYTE5
DQS_TRACK_COARSE_RANK0_BYTE6
DQS_TRACK_COARSE_RANK0_BYTE7
DQS_TRACK_COARSE_RANK0_BYTE8
DQS_TRACK_FINE_MAX_RANK0_BYTE0
DQS_TRACK_FINE_MAX_RANK0_BYTE1
DQS_TRACK_FINE_MAX_RANK0_BYTE2
DQS_TRACK_FINE_MAX_RANK0_BYTE3
DQS_TRACK_FINE_MAX_RANK0_BYTE4
DQS_TRACK_FINE_MAX_RANK0_BYTE5
DQS_TRACK_FINE_MAX_RANK0_BYTE6
DQS_TRACK_FINE_MAX_RANK0_BYTE7
DQS_TRACK_FINE_MAX_RANK0_BYTE8

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

007
006
007
007
008
008
008
008
008
006
006
007
007
008
008
008
007
007
007
006
007
007
008
008
008
008
007
02d
02d
027
01a
021
020
012
02e
02e

Send Feedback

488

Chapter 24: Debugging

DQS_TRACK_FINE_MIN_RANK0_BYTE0
DQS_TRACK_FINE_MIN_RANK0_BYTE1
DQS_TRACK_FINE_MIN_RANK0_BYTE2
DQS_TRACK_FINE_MIN_RANK0_BYTE3
DQS_TRACK_FINE_MIN_RANK0_BYTE4
DQS_TRACK_FINE_MIN_RANK0_BYTE5
DQS_TRACK_FINE_MIN_RANK0_BYTE6
DQS_TRACK_FINE_MIN_RANK0_BYTE7
DQS_TRACK_FINE_MIN_RANK0_BYTE8
DQS_TRACK_FINE_RANK0_BYTE0
DQS_TRACK_FINE_RANK0_BYTE1
DQS_TRACK_FINE_RANK0_BYTE2
DQS_TRACK_FINE_RANK0_BYTE3
DQS_TRACK_FINE_RANK0_BYTE4
DQS_TRACK_FINE_RANK0_BYTE5
DQS_TRACK_FINE_RANK0_BYTE6
DQS_TRACK_FINE_RANK0_BYTE7
DQS_TRACK_FINE_RANK0_BYTE8
BISC_ALIGN_NQTR_NIBBLE0
BISC_ALIGN_NQTR_NIBBLE1
BISC_ALIGN_NQTR_NIBBLE2
BISC_ALIGN_NQTR_NIBBLE3
BISC_ALIGN_NQTR_NIBBLE4
BISC_ALIGN_NQTR_NIBBLE5
BISC_ALIGN_NQTR_NIBBLE6
BISC_ALIGN_NQTR_NIBBLE7
BISC_ALIGN_PQTR_NIBBLE0
BISC_ALIGN_PQTR_NIBBLE1
BISC_ALIGN_PQTR_NIBBLE2
BISC_ALIGN_PQTR_NIBBLE3
BISC_ALIGN_PQTR_NIBBLE4
BISC_ALIGN_PQTR_NIBBLE5
BISC_ALIGN_PQTR_NIBBLE6
BISC_ALIGN_PQTR_NIBBLE7
BISC_NQTR_NIBBLE0
BISC_NQTR_NIBBLE1
BISC_NQTR_NIBBLE2
BISC_NQTR_NIBBLE3
BISC_NQTR_NIBBLE4
BISC_NQTR_NIBBLE5
BISC_NQTR_NIBBLE6
BISC_NQTR_NIBBLE7
BISC_PQTR_NIBBLE0
BISC_PQTR_NIBBLE1
BISC_PQTR_NIBBLE2
BISC_PQTR_NIBBLE3
BISC_PQTR_NIBBLE4
BISC_PQTR_NIBBLE5
BISC_PQTR_NIBBLE6
BISC_PQTR_NIBBLE7

string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string
string

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true
true

000
023
01d
00f
019
018
00a
000
000
001
028
022
014
01d
01c
00e
001
02b
000
000
000
000
000
000
000
000
007
004
006
005
005
004
004
004
036
033
037
035
037
036
036
036
038
036
038
035
037
037
035
036

BISC VT Tracking
The change in the relative delay through the FPGA for the DQS and DQ is monitored in the
XIPHY and adjustments are made to the delays to account for the change in resolution of
the delay elements. The change in the delays are recorded in the XSDB.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

489

Chapter 24: Debugging

Debug
Table 24-50:

Signals of Interest for DQS Tracking

Signal

Usage

Signal Description

VT_TRACK_PQTR_NIBBLE*

One per nibble

PQTR position last read during BISC VT Tracking.

VT_TRACK_NQTR_NIBBLE*

One per nibble

NQTR position last read during BISC VT Tracking.

VT_TRACK_PQTR_MAX_NIBBLE*

One per nibble

Maximum PQTR value found during BISC VT Tracking.

VT_TRACK_NQTR_MAX_NIBBLE*

One per nibble

Maximum NQTR value found during BISC VT Tracking.

VT_TRACK_PQTR_MIN_NIBBLE*

One per nibble

Minimum PQTR value found during BISC VT Tracking.

VT_TRACK_NQTR_MIN_NIBBLE*

One per nibble

Minimum NQTR value found during BISC VT Tracking.

RDLVL_PQTR_CENTER_FINAL_NIBBLE*

One per nibble

Final PQTR position found during calibration.

RDLVL_NQTR_CENTER_FINAL_NIBBLE*

One per nibble

Final NQTR position found during calibration.

BISC_ALIGN_PQTR

One per nibble

Initial 0 offset value provided by BISC at power-up.

BISC_ALIGN_NQTR

One per nibble

Initial 0 offset value provided by BISC at power-up.

One per nibble

Initial 90 offset value provided by BISC at power-up.

Compute 90 value in taps by taking (BISC_PQTR
BISC_ALIGN_PQTR). To estimate tap resolution take
( of the memory clock period)/ (BISC_PQTR
BISC_ALIGN_PQTR). Useful to know how many fine
taps make up a coarse tap to compute amount of DQS
gate drift (Average of the P & N values used for
computation).

One per nibble

Initial 90 offset value provided by BISC at power-up.

Compute 90 value in taps by taking (BISC_NQTR
BISC_ALIGN_NQTR). To estimate tap resolution take
( of the memory clock period)/ (BISC_NQTR
BISC_ALIGN_NQTR). Useful to know how many fine
taps make up a coarse tap to compute amount of DQS
gate drift. (Average of the P & N values used for
computation).

BISC_PQTR

BISC_NQTR

Expected Results
To see where the PQTR and NQTR positions have moved since calibration, compare the
VT_TRACK_PQTR_NIBBLE* and VT_TRACK_NQTR_NIBBLE* XSDB values to the final calibrated
positions which are stored in RDLVL_PQTR_CENTER_FINAL_NIBBLE* and
RDLVL_NQTR_CENTER_FINAL_NIBBLE*.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

490

Chapter 24: Debugging

To see how much movement the PQTR and NQTR taps exhibit over environmental changes,
monitor:
VT_TRACK_PQTR_NIBBLE*
VT_TRACK_NQTR_NIBBLE*
VT_TRACK_PQTR_MAX_NIBBLE*
VT_TRACK_NQTR_MAX_NIBBLE*
VT_TRACK_PQTR_MIN_NIBBLE*
VT_TRACK_NQTR_MIN_NIBBLE*

Calibration Times
Calibration time depends on a number of factors, such as:

General Interconnect Clock Frequency

Number of DDR Ranks

Memory Width

Board Trace Lengths

Table 24-51 gives an example of calibration times for a DDR memory interface.
Table 24-51:
Memory
Interface

DDR Calibration Times

Component Type

x8 components

Width

Memory Interface
Speed (MT/s)

Calibration Time (s)

2,133

0.91

1,866

1.15

1,600

0.88

1,333

1.15

1,066

0.83

800

1.26

1,600

0.69

1,333

1.13

1,600

0.70

1,333

1.13

72-bit

DDR3

Dual Rank SO-DIMM x8

Dual Rank RDIMM x8

72-bit

72-bit

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

491

Chapter 24: Debugging

Table 24-51:

DDR Calibration Times (Contd)

Memory
Interface

Component Type

X8 components

DDR4

UDIMM x8

RDIMM x8

Dual Rank RDIMM x4

Width

Memory Interface
Speed (MT/s)

Calibration Time (s)

2,400

2.69

2,133

3.59

1,866

4.01

1,600

5.36

1,333

3.72

2,133

3.25

1,600

5.10

1,333

3.55

2,133

3.46

1,600

5.19

1,333

3.64

1,600

4.91

1,333

7.52

72-bit

72-bit

72-bit

72-bit

Debugging Data Errors

General Checks
As with calibration error debug, the General Checks section should be reviewed. Strict
adherence to proper board design is critical in working with high speed memory interfaces.
Violation of these general checks is often the root cause of data errors.

Replicating Data Errors Using the Advanced Traffic Generator

When data errors are seen during normal operation, the Memory IP Advanced Traffic
Generator (ATG) should be used to replicate the error. The ATG is a verified solution that can
be configured to send a wide range of data, address, and command patterns. It additionally
presents debug status information for general memory traffic debug post calibration. The
ATG stores the write data and compares it to the read data. This allows comparison of
expected and actual data when errors occur. This is a critical step in data error debug as this
section will go through in detail.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

492

Chapter 24: Debugging

ATG Setup
The ATG can be enabled within the DDR3/DDR4 example_top.sv by defining HW_TG_EN.
`define HW_TG_EN

The default ATG configuration exercises predefined traffic instructions which are included in
the mem_v1_0_tg_instr_bram.sv module.
To move away from the default configuration and use the ATG for data error debug, the
following changes are needed:

Enable hardware debug within the Vivado Hardware Manager. VIO and ILA cores need
to be created and connected to relevant General Control, Instruction Programming, and
viewing of Status registers. The following tables provide information on the signals
included in each of these signal groups.

Table 24-52:

General Control

General Control

I/O

Width

Description

vio_tg_start

Enable traffic generator to proceed from "START" state to "LOAD" state

after calibration completes.
If you do not plan to program instruction table NOR PRBS data seed, tie this
signal to 1'b1.
If you plan to program instruction table OR PRBS data seed, set this bit to
0 during reset. After reset deassertion and done with instruction/seed
programming, set this bit to 1 to start traffic generator.

vio_tg_rst

Reset traffic generator (synchronous reset, level sensitive)

If there is outstanding traffic in memory pipeline, assert this signal long
enough until all outstanding transactions have completed.

vio_tg_restart

Restart traffic generator after traffic generation is complete, paused, or

stopped with error (level sensitive)
If there is outstanding traffic in memory pipeline, assert this signal long
enough until all outstanding transactions have completed.

vio_tg_pause

Pause traffic generator (level sensitive)

vio_tg_err_chk_en

If enabled, stop upon first error detected. Read test is performed to

determine whether "READ" or "WRITE" error occurred. If not enabled,
continue traffic without stop.

vio_tg_err_clear

Clear all errors excluding sticky error bit (positive edge sensitive)
Only use this signal when vio_tg_status_state is either TG_INSTR_ERRDONE
or TG_INSTR_PAUSE

vio_tg_err_clear_all

Clear all errors including sticky error bit (positive edge sensitive)
Only use this signal when vio_tg_status_state is either TG_INSTR_ERRDONE
or TG_INSTR_PAUSE

vio_tg_err_continue

Continue traffic after error(s) at TG_INSTR_ERRDONE state (positive edge

sensitive)

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

493

Chapter 24: Debugging

Table 24-53:

Instruction Programming

Instruction Programming

I/O Width

Description

vio_tg_direct_instr_en

0: Traffic Table Mode Traffic Generator uses traffic patterns

programmed in 32-entry traffic table
1: Direct Instruction Mode Traffic Generator uses current
traffic pattern presented at VIO interface

vio_tg_instr_program_en

Enable instruction table programming (level sensitive)

vio_tg_instr_num

Instruction number to be programmed

vio_tg_instr_addr_mode

vio_tg_instr_data_mode

vio_tg_instr_rw_mode

vio_tg_instr_rw_submode

Address mode to be programmed.

LINEAR = 0; (with user defined start address)
PRBS = 1; (PRBS supported range from 8 to 34 based on
address width)
WALKING1 = 2;
WALKING0 = 3;
4:15 Reserved

Data mode to be programmed.

LINEAR = 0;
PRBS = 1; (PRBS supported 8,10,23)
WALKING1 = 2;
WALKING0 = 3;
HAMMER1 = 4;
HAMMER0 = 5;
Block RAM = 6;
CAL_CPLX = 7; (Must be programmed along with victim
mode CAL_CPLX)
8:15: Reserved

0: Read Only (No data check)

1: Write Only (No data check)
2: Write / Read (Read performs after Write and data value is
checked against expected write data. For QDR II+ SRAM, one
port is used for write and another port is used for read)
3: Write Once and Read forever (Data check on Read data)
4-15: Reserved

Read/Write sub-mode to be programmed.

This is a sub-mode option when vio_tg_instr_rw_mode is set
to "WRITE_READ" mode.
This mode is only valid for DDR3/DDR4 and RLDRAM 3. For
QDR II+ SRAM, this mode should be set to 0
WRITE_READ = 0; // Send all Write commands follow by Read
commands defined in the instruction
WRITE_READ_SIMULTANEOUSLY = 1; // Send Write and Read
commands pseudo-randomly. Note that Write is always
ahead of Read.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

494

Chapter 24: Debugging

Table 24-53:

Instruction Programming (Contd)

Instruction Programming

vio_tg_instr_victim_mode

vio_tg_instr_victim_aggr_delay

I/O Width

Description

Victim mode to be programmed.

One victim bit could be programmed using global register
vio_tg_victim_bit.
The rest of the bits on signal bus are considered to be
aggressors.
The following program options define aggressor behavior:
NO_VICTIM = 0;
HELD1 = 1; // All aggressor signals held at 1
HELD0 = 2; // All aggressor signals held at 0
NONINV_AGGR = 3; // All aggressor signals are same as
victim
INV_AGGR = 4; // All aggressor signals are inversion of
victim
DELAYED_AGGR = 5; // All aggressor signals are delayed
version of victim (num of cycle of delay is programmed at
vio_tg_victim_aggr_delay)
DELAYED_VICTIM = 6; // Victim signal is delayed version of
all aggressors
CAL_CPLX = 7; Complex Calibration pattern (Must be
programed along with Data Mode CAL_CPLX)

Define aggressor/victim pattern to be N-delay cycle of

victim/aggressor.
It is used when victim mode "DELAY_AGGR" or "DELAY
VICTIM" mode is used in traffic pattern.

vio_tg_instr_victim_select

Victim bit behavior programmed.

VICTIM_EXTERNAL = 0; // Use Victim bit provided in
vio_tg_glb_victim_bit
VICTIM_ROTATE4 = 1; // Victim bit rotates from Bit[0] to
Bit[3] for every Nibble
VICTIM_ROTATE8 = 2; // Victim bit rotates from Bit[0] to
Bit[7] for every byte
VICTIM_ROTATE_ALL = 3; // Victim bit rotates through all
bits

vio_tg_instr_num_of_iter

32

Number of Read/Write commands to issue (number of issue

must be > 0 for each instruction programmed)

10

M: Number of NOP cycles in between Read/Write commands

at User interface at general interconnect clock.
N: Number of Read/Write commands before NOP cycle
insertion at User interface at general interconnect clock.

32

M: Number of NOP cycles in between Read/Write commands

at User interface at general interconnect clock.
N: Number of Read/Write commands before NOP cycle
insertion at User interface at general interconnect clock.

Next instruction to run.

To end traffic, next instruction should point at EXIT
instruction.
6b000000-6b011111 valid instruction
6b1????? EXIT instruction

vio_tg_instr_m_nops_btw_n_burst_m

vio_tg_instr_m_nops_btw_n_burst_n

vio_tg_instr_nxt_instr

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

495

Chapter 24: Debugging

Table 24-54:

Status Registers

Status Registers

I/O

Width

Description

vio_tg_status_state

Traffic Generator state machine state

vio_tg_status_err_bit_valid

Intermediate error detected

Used as trigger to detect read error

vio_tg_status_err_bit

APP_DATA_WIDTH

Intermediate error bit mismatch

Bitwise mismatch pattern

vio_tg_status_err_addr

APP_ADDR_WIDTH

Intermediate error address

Address location of failed read

vio_tg_status_exp_bit_valid

Expected read data valid

vio_tg_status_exp_bit

APP_DATA_WIDTH

Expected read data

vio_tg_status_read_bit_valid

Memory read data valid

vio_tg_status_read_bit

APP_DATA_WIDTH

Memory read data

vio_tg_status_first_err_bit_valid

If vio_tg_err_chk_en is set to 1,
first_err_bit_valid is set to 1 when first mismatch
error is encountered.
This register is not overwritten until
vio_tg_err_clear, vio_tg_err_continue,
vio_tg_restart is triggered.

vio_tg_status_first_err_bit

APP_DATA_WIDTH

If vio_tg_status_first_err_bit_valid is set to 1,
error mismatch bit pattern is stored in this
register.

vio_tg_status_first_err_addr

APP_ADDR_WIDTH

If vio_tg_status_first_err_bit_valid is set to 1,
error address is stored in this register.

vio_tg_status_first_exp_bit_valid

If vio_tg_err_chk_en is set to 1,
this represents expected read data valid when
first mismatch error is encountered.

vio_tg_status_first_exp_bit

APP_DATA_WIDTH

If vio_tg_status_first_exp_bit_valid is set to 1,
expected read data is stored in this register.

vio_tg_status_first_read_bit_valid

If vio_tg_err_chk_en is set to 1,
this represents read data valid when first
mismatch error is encountered.

vio_tg_status_first_read_bit

APP_DATA_WIDTH

If vio_tg_status_first_read_bit_valid is set to 1,
read data from memory is stored in this register.

vio_tg_status_err_bit_sticky_valid

Accumulated error mismatch valid over time.

This register is reset by vio_tg_err_clear,
vio_tg_err_continue, vio_tg_restart.

vio_tg_status_err_bit_sticky

APP_DATA_WIDTH

If vio_tg_status_err_bit_sticky_valid is set to 1,
this represents accumulated error bit

If vio_tg_err_chk_en is set to 1,
read test is performed upon the first mismatch
error. Read test returns error type of either
"READ" or "WRITE" error.
This register stores valid status of read test error
type.

vio_tg_status_err_type_valid

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

496

Chapter 24: Debugging

Table 24-54:

Status Registers (Contd)

Status Registers

I/O

Width

vio_tg_status_err_type

vio_tg_status_done

Description
If vio_tg_status_err_type_valid is set to 1,
this represents error type result from read test.
0 = Write Error
1 = Read Error
All traffic programmed completes.
Note: If infinite loop is programmed,
vio_tg_status_done does not assert.

vio_tg_status_wr_done

This signal pulses after a WRITE-READ mode

instruction completes

vio_tg_status_watch_dog_hang

Watchdog hang. This register is set to 1 if there is

no READ/WRITE command sent or no READ data
return for a period of time (defined in
tg_param.vh).

compare_error

Accumulated error mismatch valid over time.

This register resets by vio_tg_err_clear,
vio_tg_err_continue, vio_tg_restart.

ATG Debug Programming

The ATG provides three ways for traffic pattern programming:
1. Instruction block RAM (mem_v1_0_tg_instr_bram.sv)

Used for regression with predefined traffic instructions

Defines default traffic pattern

Override default traffic pattern (re-compilation required)

2. Direct instruction through VIO input

Used for quick Debug with SINGLE traffic instruction

Reprogram through VIO without re-compilation

3. Program instruction table

Used for Debug with MULTIPLE traffic instructions

Reprogram through VIO without re-compilation

This document assumes debug using Direct Instruction through VIO. The same concepts
extend to both Instruction Block RAM and Program Instruction Table. Direct Instruction
through VIO is enabled using vio_tg_err_chk_en. After vio_tg_err_chk_en is set to
1, all of the traffic instruction fields can be driven by the targeted traffic instruction.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

497

Chapter 24: Debugging

Table 24-55:

VIO Signals
Signal

vio_tg_instr_addr_mode
vio_tg_instr_data_mode
vio_tg_instr_rw_mode
vio_tg_instr_rw_submode
vio_tg_instr_victim_mode
vio_tg_instr_victim_select
vio_tg_instr_victim_aggr_delay
vio_tg_instr_num_of_iter
vio_tg_instr_m_nops_btw_n_burst_m
vio_tg_instr_m_nops_btw_n_burst_n
vio_tg_instr_nxt_instr

ATG Debug Read/Write Error/First Error Bit/First Error Address

ATG identifies if a traffic error is a Read or Write Error when vio_tg_err_chk_en is set to
1. Assume EXP_WR_DATA is the expected write data. After the first traffic error is seen from
a read (with a value of EXP_WR_DATA), ATG issues multiple read commands to the failed
memory address. If all reads return data EXP_WR_DATA, ATG classifies the error as a
WRITE_ERROR(0). Otherwise, ATG classifies the error as READ_ERROR(1). ATG also tracks the
first error bit, first error address seen.
Example 1: The following VIO setting powers on Read/Write Error Type check.
.vio_tg_err_chk_en
.vio_tg_direct_instr_en
.vio_tg_instr_num
.vio_tg_instr_addr_mode
.vio_tg_instr_data_mode
.vio_tg_instr_rw_mode
.vio_tg_instr_rw_submode
.vio_tg_instr_victim_mode
.vio_tg_instr_victim_select
.vio_tg_instr_victim_aggr_delay
.vio_tg_instr_num_of_iter
.vio_tg_instr_m_nops_btw_n_burst_m
.vio_tg_instr_m_nops_btw_n_burst_n
.vio_tg_instr_nxt_instr

(1'b1), // Powers on Error Type Check

(1'b1), // Powers on Direct Instruction Mode
(5'b00000),
(TG_PATTERN_MODE_LINEAR),
(TG_PATTERN_MODE_PRBS),
(TG_RW_MODE_WRITE_READ),
(2'b00),
(TG_VICTIM_MODE_NO_VICTIM),
(3'b000),
(5'd0),
(32'd1000),
(10'd0),
(32'd10),
(6d0),

Figure 24-61 shows a Write Error waveform. When vio_tg_status_err_type_valid is

1, vio_tg_status_err_type shows a WRITE ERROR (0). When
vio_tg_status_first_err_bit_valid,

vio_tg_status_first_err_bit 0x8 as the corrupted bit

vio_tg_first_err_addr shows address with corrupted data is 0x678

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

498

Chapter 24: Debugging

X-Ref Target - Figure 24-61

Figure 24-61:

VIO Write Error Waveform

Figure 24-61 shows a Read Error waveform. When vio_tg_status_err_type_valid is

1, vio_tg_status_err_type shows a READ ERROR (0). When
vio_tg_status_first_err_bit_valid,

vio_tg_status_first_err_bit 0x60 as the corrupted bit

vio_tg_first_err_addr shows address with corrupted data is 0x1b0

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

499

Chapter 24: Debugging

X-Ref Target - Figure 24-62

Figure 24-62:

VIO Read Error Waveform

ATG Debug First Error Bit/First Error Address/Sticky Error Bit

When vio_tg_err_chk_en is set to 1, ATG stops after the first error. When
vio_tg_err_chk_en is set to 0, ATG does not stop after the first error and would track
error continuously using vio_tg_status_err_bit_valid/
vio_tg_status_err_bit/vio_tg_status_err_addr.
The signals vio_tg_status_err_bit_sticky_valid/
vio_tg_status_err_bit_sticky accumulate all data bit(s) with error(s) seen.
Example 2: The following VIO setting powers off Read/Write Error Type check:
.vio_tg_err_chk_en
.vio_tg_direct_instr_en
.vio_tg_instr_num
.vio_tg_instr_addr_mode
.vio_tg_instr_data_mode
.vio_tg_instr_rw_mode
.vio_tg_instr_rw_submode
.vio_tg_instr_victim_mode
.vio_tg_instr_victim_select
.vio_tg_instr_victim_aggr_delay
.vio_tg_instr_num_of_iter
.vio_tg_instr_m_nops_btw_n_burst_m
.vio_tg_instr_m_nops_btw_n_burst_n
.vio_tg_instr_nxt_instr

(1'b0), // Powers on Error Type Check

(1'b1), // Powers on Direct Instruction Mode
(5'b00000),
(TG_PATTERN_MODE_LINEAR),
(TG_PATTERN_MODE_PRBS),
(TG_RW_MODE_WRITE_READ),
(2'b00),
(TG_VICTIM_MODE_NO_VICTIM),
(3'b000),
(5'd0),
(32'd1000),
(10'd0),
(32'd10),
(6d0),

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

500

Chapter 24: Debugging

Figure 24-63 shows six addresses with read error (note that this is the same example as was
used with Write Error earlier. Write Error is not presented because
vio_tg_err_chk_en is disabled here):
vio_tg_status_err_bit_valid is asserted six times.

For each assertion, the corresponding bit error is presented at vio_tg_status_err_bit.

After five assertions in vio_tg_status_err_bit_valid (yellow marker),
vio_tg_status_err_bit_sticky shows bits 0x1e (binary 11110) have bit corruption.
X-Ref Target - Figure 24-63

Figure 24-63:

VIO Read Error Waveform

ATG Debug WatchDog Hang

ATG expects the application interface to accept a command within a certain wait time. ATG
also looks for the application interface to return data within a certain wait time after a read
command is issued. If either case is violated, ATG flags a WatchDog Hang.
When WatchDogHang is asserted, if vio_tg_status_state is in *Wait states, ATG is
waiting for read data return. If vio_tg_status_state is in Exe state, ATG is waiting for
application interface to accept the next command.
Example 3: The following example shows that ATG asserts WatchDogHang. This example
shares the same VIO control setting as Example 2. In this example, ATG
vio_tg_status_state shows a DNWait state. Hence, ATG is waiting for read data
return.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

501

Chapter 24: Debugging

X-Ref Target - Figure 24-64

Figure 24-64:

ATG Debug Watchdog Hang Waveform

To further debug, vio_tg_instr_data_mode is updated to Linear data for better

understanding in data return sequence.
.vio_tg_err_chk_en
.vio_tg_direct_instr_en
.vio_tg_instr_num
.vio_tg_instr_addr_mode
.vio_tg_instr_data_mode
.vio_tg_instr_rw_mode
.vio_tg_instr_rw_submode
.vio_tg_instr_victim_mode
.vio_tg_instr_victim_select
.vio_tg_instr_victim_aggr_delay
.vio_tg_instr_num_of_iter
.vio_tg_instr_m_nops_btw_n_burst_m
.vio_tg_instr_m_nops_btw_n_burst_n
.vio_tg_instr_nxt_instr

(1'b0), // Powers on Error Type Check

(1'b1), // Powers on Direct Instruction Mode
(5'b00000),
(TG_PATTERN_MODE_LINEAR),
(TG_PATTERN_MODE_LINEAR),
(TG_RW_MODE_WRITE_READ),
(2'b00),
(TG_VICTIM_MODE_NO_VICTIM),
(3'b000),
(5'd0),
(32'd1000),
(10'd0),
(32'd10),
(6d0),

With Linear Data, Figure 24-65 shows that when an error is detected, read data
(vio_tg_status_read_bit) is one request ahead of expected data
(vio_tg_status_exp_bit). One possibility is read command with address 0x1b0 is
dropped. Hence the next returned data with read address 0x1b8 is being compared against
the expected data of read address 0x1b0.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

502

Chapter 24: Debugging

X-Ref Target - Figure 24-65

Figure 24-65:

ATG Debug Watchdog Hang Waveform with Linear Data

ATG VIO and ILA Connectivity

Depending on debug usage, connect the ATG control and status signal to the VIO and ILA.
This is an example on modifying the example_top.sv to add ATG control and status
monitor using the VIO and ILA.
In this example code, all ATG controls are connected to VIO for control. All ATG status are
connected to the ILA for monitoring. For ILA monitor on data and data error buses, an extra
layer of MUX is added to reduce bus width connected to the ILA. The MUX is controlled by
the vio_tg_status_select signal.
// Flop all VIO inputs before connect to Memory IP
reg
vio_tg_rst_r;
reg
vio_tg_start_r;
reg
vio_tg_restart_r;
reg
vio_tg_pause_r;
reg
vio_tg_err_chk_en_r;
reg
vio_tg_err_clear_r;
reg
vio_tg_err_clear_all_r;
reg
vio_tg_err_continue_r;
reg
vio_tg_instr_program_en_r;
reg
vio_tg_direct_instr_en_r;
reg [4:0]
vio_tg_instr_num_r;
reg [3:0]
vio_tg_instr_addr_mode_r;
reg [3:0]
vio_tg_instr_data_mode_r;
reg [3:0]
vio_tg_instr_rw_mode_r;
reg [1:0]
vio_tg_instr_rw_submode_r;
reg [2:0]
vio_tg_instr_victim_mode_r;
reg [4:0]
vio_tg_instr_victim_aggr_delay_r;
reg [2:0]
vio_tg_instr_victim_select_r;
reg [31:0]
vio_tg_instr_num_of_iter_r;

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

503

Chapter 24: Debugging

reg
reg
reg
reg
reg
reg
reg
reg
reg

[9:0]
[31:0]
[5:0]
[7:0]
[22:0]
[7:0]
[APP_ADDR_WIDTH-1:0]
[6:0]

vio_tg_instr_m_nops_btw_n_burst_m_r;
vio_tg_instr_m_nops_btw_n_burst_n_r;
vio_tg_instr_nxt_instr_r;
vio_tg_seed_program_en_r;
vio_tg_seed_num_r;
vio_tg_seed_r;
vio_tg_glb_victim_bit_r;
vio_tg_glb_start_addr_r;
vio_tg_status_select_r;

// Flop all VIO outputs before connect to ILA or VIO

reg [6:0]
vio_tg_status_select_r;
reg [3:0]
vio_tg_status_state_r;
reg
vio_tg_status_err_bit_valid_r;
reg [APP_DATA_WIDTH-1:0]
vio_tg_status_err_bit_r;
reg [APP_ADDR_WIDTH-1:0]
vio_tg_status_err_addr_r;
reg
vio_tg_status_exp_bit_valid_r;
reg [APP_DATA_WIDTH-1:0]
vio_tg_status_exp_bit_r;
reg
vio_tg_status_read_bit_valid_r;
reg [APP_DATA_WIDTH-1:0]
vio_tg_status_read_bit_r;
reg
vio_tg_status_first_err_bit_valid_r;
reg [APP_DATA_WIDTH-1:0]
vio_tg_status_first_err_bit_r;
reg [APP_ADDR_WIDTH-1:0]
vio_tg_status_first_err_addr_r;
reg
vio_tg_status_first_exp_bit_valid_r;
reg [APP_DATA_WIDTH-1:0]
vio_tg_status_first_exp_bit_r;
reg
vio_tg_status_first_read_bit_valid_r;
reg [APP_DATA_WIDTH-1:0]
vio_tg_status_first_read_bit_r;
reg
vio_tg_status_err_bit_sticky_valid_r;
reg [APP_DATA_WIDTH-1:0]
vio_tg_status_err_bit_sticky_r;
reg
vio_tg_status_err_type_valid_r;
reg
vio_tg_status_err_type_r;
reg
vio_tg_status_wr_done_r;
reg
vio_tg_status_done_r;
reg
vio_tg_status_watch_dog_hang_r;
reg
reg
reg
reg
reg
reg
reg
reg
reg
reg
reg
reg
reg
reg
reg
reg
reg
reg
reg
reg
reg
reg
reg
reg

[6:0]
[3:0]
[APP_DATA_MUX_WIDTH-1:0]
[APP_DATA_MUX_IDX_WIDTH-1:0]
[APP_ADDR_WIDTH-1:0]
[APP_DATA_MUX_WIDTH-1:0]
[APP_DATA_MUX_WIDTH-1:0]
[APP_DATA_MUX_WIDTH-1:0]
[APP_DATA_MUX_IDX_WIDTH-1:0]
[APP_ADDR_WIDTH-1:0]
[APP_DATA_MUX_WIDTH-1:0]
[APP_DATA_MUX_WIDTH-1:0]
[APP_DATA_MUX_WIDTH-1:0]
[APP_DATA_MUX_IDX_WIDTH-1:0]

vio_tg_status_select_r2;
vio_tg_status_state_r2;
vio_tg_status_err_bit_valid_r2;
vio_tg_status_err_bit_mux_r2;
vio_tg_status_err_bit_idx_r2;
vio_tg_status_err_addr_r2;
vio_tg_status_exp_bit_valid_r2;
vio_tg_status_exp_bit_mux_r2;
vio_tg_status_read_bit_valid_r2;
vio_tg_status_read_bit_mux_r2;
vio_tg_status_first_err_bit_valid_r2;
vio_tg_status_first_err_bit_mux_r2;
vio_tg_status_first_err_bit_idx_r2;
vio_tg_status_first_err_addr_r2;
vio_tg_status_first_exp_bit_valid_r2;
vio_tg_status_first_exp_bit_mux_r2;
vio_tg_status_first_read_bit_valid_r2;
vio_tg_status_first_read_bit_mux_r2;
vio_tg_status_err_bit_sticky_valid_r2;
vio_tg_status_err_bit_sticky_mux_r2;
vio_tg_status_err_bit_sticky_idx_r2;
vio_tg_status_err_type_valid_r2;
vio_tg_status_err_type_r2;
vio_tg_status_wr_done_r2;

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

504

Chapter 24: Debugging

reg
reg

vio_tg_status_done_r2;
vio_tg_status_watch_dog_hang_r2;

ddr4_v1_0_0_hw_tg #
(
.SIMULATION
(SIMULATION),
.MEM_TYPE
("DDR4"),
.APP_DATA_WIDTH (APP_DATA_WIDTH),
.APP_ADDR_WIDTH (APP_ADDR_WIDTH),
.NUM_DQ_PINS
(72),
.ECC
(ECC),
.DEFAULT_MODE
("2015_3")
)
u_hw_tg
(
.clk
(c0_ddr4_clk),
.rst
(c0_ddr4_rst),
.init_calib_complete (c0_init_calib_complete),
.app_rdy
(c0_ddr4_app_rdy),
.app_wdf_rdy
(c0_ddr4_app_wdf_rdy),
.app_rd_data_valid
(c0_ddr4_app_rd_data_valid),
.app_rd_data
(c0_ddr4_app_rd_data),
.app_cmd
(c0_ddr4_app_cmd),
.app_addr
(c0_ddr4_app_addr),
.app_en
(c0_ddr4_app_en),
.app_wdf_mask
(c0_ddr4_app_wdf_mask),
.app_wdf_data
(c0_ddr4_app_wdf_data),
.app_wdf_end
(c0_ddr4_app_wdf_end),
.app_wdf_wren
(c0_ddr4_app_wdf_wren),
.app_wdf_en
(), // valid for QDRII+ only
.app_wdf_addr
(), // valid for QDRII+ only
.app_wdf_cmd
(), // valid for QDRII+ only
.compare_error
(c0_data_compare_error),
.vio_tg_rst
(vio_tg_rst_r),
.vio_tg_start
(vio_tg_start_r),
.vio_tg_restart
(vio_tg_restart_r),
.vio_tg_pause
(vio_tg_pause_r),
.vio_tg_err_chk_en
(vio_tg_err_chk_en_r),
.vio_tg_err_clear
(vio_tg_err_clear_r),
.vio_tg_err_clear_all
(vio_tg_err_clear_all_r),
.vio_tg_err_continue
(vio_tg_err_continue_r),
.vio_tg_instr_program_en
(vio_tg_instr_program_en_r),
.vio_tg_direct_instr_en
(vio_tg_direct_instr_en_r),
.vio_tg_instr_num
(vio_tg_instr_num_r),
.vio_tg_instr_addr_mode
(vio_tg_instr_addr_mode_r),
.vio_tg_instr_data_mode
(vio_tg_instr_data_mode_r),
.vio_tg_instr_rw_mode
(vio_tg_instr_rw_mode_r),
.vio_tg_instr_rw_submode
(vio_tg_instr_rw_submode_r),
.vio_tg_instr_victim_mode
(vio_tg_instr_victim_mode_r),
.vio_tg_instr_victim_aggr_delay
(vio_tg_instr_victim_aggr_delay_r),
.vio_tg_instr_victim_select
(vio_tg_instr_victim_select_r),
.vio_tg_instr_num_of_iter
(vio_tg_instr_num_of_iter_r),
.vio_tg_instr_m_nops_btw_n_burst_m (vio_tg_instr_m_nops_btw_n_burst_m_r),
.vio_tg_instr_m_nops_btw_n_burst_n (vio_tg_instr_m_nops_btw_n_burst_n_r),
.vio_tg_instr_nxt_instr
(vio_tg_instr_nxt_instr_r),
.vio_tg_seed_program_en
(vio_tg_seed_program_en_r),
.vio_tg_seed_num
(vio_tg_seed_num_r),
.vio_tg_seed
(vio_tg_seed_r),
.vio_tg_glb_victim_bit
(vio_tg_glb_victim_bit_r),

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

505

Chapter 24: Debugging

.vio_tg_glb_start_addr

(vio_tg_glb_start_addr_r),

.vio_tg_status_state
.vio_tg_status_err_bit_valid
.vio_tg_status_err_bit
.vio_tg_status_err_addr
.vio_tg_status_exp_bit_valid
.vio_tg_status_exp_bit
.vio_tg_status_read_bit_valid
.vio_tg_status_read_bit
.vio_tg_status_first_err_bit_valid
.vio_tg_status_first_err_bit
.vio_tg_status_first_err_addr
.vio_tg_status_first_exp_bit_valid
.vio_tg_status_first_exp_bit
.vio_tg_status_first_read_bit_valid
.vio_tg_status_first_read_bit
.vio_tg_status_err_bit_sticky_valid
.vio_tg_status_err_bit_sticky
.vio_tg_status_err_type_valid
.vio_tg_status_err_type
.vio_tg_status_wr_done
.vio_tg_status_done
.vio_tg_status_watch_dog_hang
.tg_ila_debug
);

(vio_tg_status_state),
(vio_tg_status_err_bit_valid),
(vio_tg_status_err_bit),
(vio_tg_status_err_addr),
(vio_tg_status_exp_bit_valid),
(vio_tg_status_exp_bit),
(vio_tg_status_read_bit_valid),
(vio_tg_status_read_bit),
(vio_tg_status_first_err_bit_valid),
(vio_tg_status_first_err_bit),
(vio_tg_status_first_err_addr),
(vio_tg_status_first_exp_bit_valid),
(vio_tg_status_first_exp_bit),
(vio_tg_status_first_read_bit_valid),
(vio_tg_status_first_read_bit),
(vio_tg_status_err_bit_sticky_valid),
(vio_tg_status_err_bit_sticky),
(vio_tg_status_err_type_valid),
(vio_tg_status_err_type),
(vio_tg_status_wr_done),
(vio_tg_status_done),
(vio_tg_status_watch_dog_hang),
(tg_ila_debug),

// Flop all VIO inputs before connect to Memory IP

always @(posedge c0_ddr4_clk) begin
vio_tg_rst_r
<= #TCQ vio_tg_rst;
vio_tg_start_r
<= #TCQ vio_tg_start;
vio_tg_restart_r <= #TCQ vio_tg_restart;
vio_tg_pause_r
<= #TCQ vio_tg_pause;
vio_tg_err_chk_en_r
<= #TCQ vio_tg_err_chk_en;
vio_tg_err_clear_r
<= #TCQ vio_tg_err_clear;
vio_tg_err_clear_all_r
<= #TCQ vio_tg_err_clear_all;
vio_tg_err_continue_r
<= #TCQ vio_tg_err_continue;
vio_tg_instr_program_en_r <= #TCQ vio_tg_instr_program_en;
vio_tg_direct_instr_en_r <= #TCQ vio_tg_direct_instr_en;
vio_tg_instr_num_r
<= #TCQ vio_tg_instr_num;
vio_tg_instr_addr_mode_r <= #TCQ vio_tg_instr_addr_mode;
vio_tg_instr_data_mode_r <= #TCQ vio_tg_instr_data_mode;
vio_tg_instr_rw_mode_r
<= #TCQ vio_tg_instr_rw_mode;
vio_tg_instr_rw_submode_r <= #TCQ vio_tg_instr_rw_submode;
vio_tg_instr_victim_mode_r
<= #TCQ vio_tg_instr_victim_mode;
vio_tg_instr_victim_aggr_delay_r <= #TCQ vio_tg_instr_victim_aggr_delay;
vio_tg_instr_victim_select_r
<= #TCQ vio_tg_instr_victim_select;
vio_tg_instr_num_of_iter_r
<= #TCQ vio_tg_instr_num_of_iter;
vio_tg_instr_m_nops_btw_n_burst_m_r <= #TCQ vio_tg_instr_m_nops_btw_n_burst_m;
vio_tg_instr_m_nops_btw_n_burst_n_r <= #TCQ vio_tg_instr_m_nops_btw_n_burst_n;
vio_tg_instr_nxt_instr_r <= #TCQ vio_tg_instr_nxt_instr;
vio_tg_seed_program_en_r <= #TCQ vio_tg_seed_program_en;
vio_tg_seed_num_r <= #TCQ vio_tg_seed_num;
vio_tg_seed_r
<= #TCQ vio_tg_seed;
vio_tg_glb_victim_bit_r
<= #TCQ vio_tg_glb_victim_bit;
vio_tg_glb_start_addr_r
<= #TCQ vio_tg_glb_start_addr;
end

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

506

Chapter 24: Debugging

// Flop all VIO outputs before connect to ILA or VIO
always @(posedge c0_ddr4_clk) begin
vio_tg_status_select_r
<= #TCQ vio_tg_status_select;
vio_tg_status_state_r
<= #TCQ vio_tg_status_state;
vio_tg_status_err_bit_valid_r
<= #TCQ vio_tg_status_err_bit_valid;
vio_tg_status_err_bit_r
<= #TCQ vio_tg_status_err_bit;
vio_tg_status_err_addr_r <= #TCQ vio_tg_status_err_addr;
vio_tg_status_exp_bit_valid_r
<= #TCQ vio_tg_status_exp_bit_valid;
vio_tg_status_exp_bit_r
<= #TCQ vio_tg_status_exp_bit;
vio_tg_status_read_bit_valid_r
<= #TCQ vio_tg_status_read_bit_valid;
vio_tg_status_read_bit_r <= #TCQ vio_tg_status_read_bit;
vio_tg_status_first_err_bit_valid_r <= #TCQ vio_tg_status_first_err_bit_valid;
vio_tg_status_first_err_bit_r
<= #TCQ vio_tg_status_first_err_bit;
vio_tg_status_first_err_addr_r
<= #TCQ vio_tg_status_first_err_addr;
vio_tg_status_first_exp_bit_valid_r <= #TCQ vio_tg_status_first_exp_bit_valid;
vio_tg_status_first_exp_bit_r
<= #TCQ vio_tg_status_first_exp_bit;
vio_tg_status_first_read_bit_valid_r <= #TCQ
vio_tg_status_first_read_bit_valid;
vio_tg_status_first_read_bit_r
<= #TCQ vio_tg_status_first_read_bit;
vio_tg_status_err_bit_sticky_valid_r <= #TCQ
vio_tg_status_err_bit_sticky_valid;
vio_tg_status_err_bit_sticky_r
<= #TCQ vio_tg_status_err_bit_sticky;
vio_tg_status_err_type_valid_r
<= #TCQ vio_tg_status_err_type_valid;
vio_tg_status_err_type_r <= #TCQ vio_tg_status_err_type;
vio_tg_status_wr_done_r
<= #TCQ vio_tg_status_wr_done;
vio_tg_status_done_r
<= #TCQ vio_tg_status_done;
vio_tg_status_watch_dog_hang_r
<= #TCQ vio_tg_status_watch_dog_hang;
vio_tg_status_select_r2
<= #TCQ vio_tg_status_select_r;
vio_tg_status_state_r2
<= #TCQ vio_tg_status_state_r;
vio_tg_status_err_bit_valid_r2 <= #TCQ vio_tg_status_err_bit_valid_r;
vio_tg_status_err_bit_mux_r2 <= #TCQ
vio_tg_status_err_bit_r[APP_DATA_MUX_WIDTH*vio_tg_status_select_r2+:APP_DATA_MUX_WI
DTH];
vio_tg_status_err_addr_r2 <= #TCQ vio_tg_status_err_addr_r;
vio_tg_status_exp_bit_valid_r2 <= #TCQ vio_tg_status_exp_bit_valid_r;
vio_tg_status_exp_bit_mux_r2 <= #TCQ
vio_tg_status_exp_bit_r[APP_DATA_MUX_WIDTH*vio_tg_status_select_r2+:APP_DATA_MUX_WI
DTH];
vio_tg_status_read_bit_valid_r2
<= #TCQ vio_tg_status_read_bit_valid_r;
vio_tg_status_read_bit_mux_r2
<= #TCQ
vio_tg_status_read_bit_r[APP_DATA_MUX_WIDTH*vio_tg_status_select_r2+:APP_DATA_MUX_W
IDTH];
vio_tg_status_first_err_bit_valid_r2
<= #TCQ
vio_tg_status_first_err_bit_valid_r;
vio_tg_status_first_err_bit_mux_r2
<= #TCQ
vio_tg_status_first_err_bit_r[APP_DATA_MUX_WIDTH*vio_tg_status_select_r2+:APP_DATA_
MUX_WIDTH];
vio_tg_status_first_err_addr_r2
<= #TCQ vio_tg_status_first_err_addr_r;
vio_tg_status_first_exp_bit_valid_r2
<= #TCQ
vio_tg_status_first_exp_bit_valid_r;
vio_tg_status_first_exp_bit_mux_r2
<= #TCQ
vio_tg_status_first_exp_bit_r[APP_DATA_MUX_WIDTH*vio_tg_status_select_r2+:APP_DATA_
MUX_WIDTH];
vio_tg_status_first_read_bit_valid_r2
<= #TCQ
vio_tg_status_first_read_bit_valid_r;
vio_tg_status_first_read_bit_mux_r2
<= #TCQ
vio_tg_status_first_read_bit_r[APP_DATA_MUX_WIDTH*vio_tg_status_select_r2+:APP_DATA
_MUX_WIDTH];

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

507

Chapter 24: Debugging

vio_tg_status_err_bit_sticky_valid_r2
<= #TCQ
vio_tg_status_err_bit_sticky_valid_r;
vio_tg_status_err_bit_sticky_mux_r2
<= #TCQ
vio_tg_status_err_bit_sticky_r[APP_DATA_MUX_WIDTH*vio_tg_status_select_r2+:APP_DATA
_MUX_WIDTH];
vio_tg_status_err_type_valid_r2
<= #TCQ vio_tg_status_err_type_valid_r;
vio_tg_status_err_type_r2 <= #TCQ vio_tg_status_err_type_r;
vio_tg_status_wr_done_r2 <= #TCQ vio_tg_status_wr_done_r;
vio_tg_status_done_r2
<= #TCQ vio_tg_status_done_r;
vio_tg_status_watch_dog_hang_r2
<= #TCQ vio_tg_status_watch_dog_hang_r;
end
genvar gen_i;
generate
for (gen_i=0; gen_i<APP_DATA_MUX_IDX_WIDTH; gen_i=gen_i+1) begin
always @(posedge c0_ddr4_clk) begin
vio_tg_status_err_bit_idx_r2[gen_i]
<= #TCQ |
vio_tg_status_err_bit_r[APP_DATA_MUX_WIDTH*gen_i+:APP_DATA_MUX_WIDTH];
vio_tg_status_first_err_bit_idx_r2[gen_i] <= #TCQ |
vio_tg_status_first_err_bit_r[APP_DATA_MUX_WIDTH*gen_i+:APP_DATA_MUX_WIDTH];
vio_tg_status_err_bit_sticky_idx_r2[gen_i] <= #TCQ |
vio_tg_status_err_bit_sticky_r[APP_DATA_MUX_WIDTH*gen_i+:APP_DATA_MUX_WIDTH];
end
end
endgenerate
ila_ddrx u_ila_ddrx (
.clk (c0_ddr4_clk),
.probe0 (dbg_init_calib_complete),
// Signifies the status of calibration
.probe1 (dbg_data_compare_error),
// Signifies the status of Traffic Error
from The TG
.probe20 (vio_tg_status_state_r2),
.probe21 (vio_tg_status_err_bit_valid_r2),
.probe22 (vio_tg_status_err_bit_mux_r2),
// Muxed out version in 1-byte
width, mux controlled by vio_tg_status_select
.probe23 (vio_tg_status_err_addr_r2),
.probe24 (vio_tg_status_exp_bit_valid_r2),
.probe25 (vio_tg_status_exp_bit_mux_r2),
// Muxed out version in 1-byte
width, mux controlled by vio_tg_status_select
.probe26 (vio_tg_status_read_bit_valid_r2),
.probe27 (vio_tg_status_read_bit_mux_r2),
// Muxed out version in 1-byte
width, mux controlled by vio_tg_status_select
.probe28 (vio_tg_status_first_err_bit_valid_r2),
.probe29 (vio_tg_status_first_err_bit_mux_r2),
// Muxed out version in 1-byte
width, mux controlled by vio_tg_status_select
.probe30 (vio_tg_status_first_err_addr_r2),
.probe31 (vio_tg_status_first_exp_bit_valid_r2),
.probe32 (vio_tg_status_first_exp_bit_mux_r2),
// Muxed out version in 1-byte
width, mux controlled by vio_tg_status_select
.probe33 (vio_tg_status_first_read_bit_valid_r2),
.probe34 (vio_tg_status_first_read_bit_mux_r2),
// Muxed out version in 1-byte
width, mux controlled by vio_tg_status_select
.probe35 (vio_tg_status_err_bit_sticky_valid_r2),
.probe36 (vio_tg_status_err_bit_sticky_mux_r2),
// Muxed out version in 1-byte
width, mux controlled by vio_tg_status_select
.probe37 (vio_tg_status_err_type_valid_r2),
.probe38 (vio_tg_status_err_type_r2),
.probe39 (vio_tg_status_wr_done_r2),
.probe40 (vio_tg_status_done_r2),

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

508

Chapter 24: Debugging

.probe41 (vio_tg_status_watch_dog_hang_r2)
);
vio_0 u_vio_0
(
.probe_out0 (vio_tg_rst),
// 1
.probe_out1 (vio_tg_start),
// 1
.probe_out2 (vio_tg_restart),
// 1
.probe_out3 (vio_tg_pause),
// 1
.probe_out4 (vio_tg_err_chk_en), // 1
.probe_out5 (vio_tg_err_clear),
// 1
.probe_out6 (vio_tg_err_clear_all),
// 1
.probe_out7 (vio_tg_err_continue),
// 1
.probe_out8 (vio_tg_instr_program_en), // 1
.probe_out9 (vio_tg_direct_instr_en),
// 1
.probe_out10 (vio_tg_instr_num),
// 5
.probe_out11 (vio_tg_instr_addr_mode), // 4
.probe_out12 (vio_tg_instr_data_mode), // 4
.probe_out13 (vio_tg_instr_rw_mode),
// 4
.probe_out14 (vio_tg_instr_rw_submode), // 2
.probe_out15 (vio_tg_instr_victim_mode),// 3
.probe_out16 (vio_tg_instr_victim_aggr_delay), //
.probe_out17 (vio_tg_instr_victim_select),
//
.probe_out18 (vio_tg_instr_num_of_iter),
//
.probe_out19 (vio_tg_instr_m_nops_btw_n_burst_m),
.probe_out20 (vio_tg_instr_m_nops_btw_n_burst_n),
.probe_out21 (vio_tg_instr_nxt_instr),
//
.probe_out22 (vio_tg_seed_program_en),
//
.probe_out23 (vio_tg_seed_num),
//
.probe_out24 (vio_tg_seed),
//
.probe_out25 (vio_tg_glb_victim_bit),
//
.probe_out26 (vio_tg_glb_start_addr),
//
.probe_out28 (vio_tg_status_select) //7
);

5
3
32
// 10
// 32
6
1
8
23
8
28

Isolating the Data Error

Using either the Advanced Traffic Generator or the user design, the first step in data error
debug is to isolate when and where the data errors occur. To perform this, the expected data
and actual data must be known and compared. Looking at the data errors, the following
should be identified:

Are the errors bit or byte errors?

Are errors seen on data bits belonging to certain DQS groups?

Are errors seen on specific DQ bits?

Is the data shifted, garbage, swapped, etc.?

Are errors seen on accesses to certain addresses, banks, or ranks of memory?

Designs that can support multiple varieties of DIMM modules, all possible address
and bank bit combinations should be supported.

Do the errors only occur for certain data patterns or sequences?

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

509

Chapter 24: Debugging

This can indicate a shorted or open connection on the PCB. It can also indicate an
SSO or crosstalk issue.

Determine the frequency and reproducibility of the error

Does the error occur on every calibration/reset?

Does the error occur at specific temperature or voltage conditions?

Determine if the error is correctable

Rewriting, rereading, resetting, recalibrating.

The next step is to isolate whether the data corruption is due to writes or reads.

Determining If a Data Error is Due to the Write or Read

Determining whether a data error is due to the write or the read can be difficult because if
writes are the cause, read back of the data is bad as well. In addition, issues with control or
address timing affect both writes and reads.
Some experiments that can help to isolate the issue include:

If the errors are intermittent, issue a small initial number of writes, followed by
continuous reads from those locations. If the reads intermittently yield bad data, there
is a potential read issue. If the reads always yield the same (wrong) data, there is a write
issue.

Using high quality probes and scope, capture the write at the memory and the read at
the FPGA to view data accuracy, appropriate DQS-to-DQ phase relationship, and signal
integrity. To ensure the appropriate transaction is captured on DQS and DQ, look at the
initial transition on DQS from 3-state to active. During a Write, DQS does not have a low
preamble. During a read, the DQS has a low preamble. The following is an example of a
DDR3 Read and a Write to illustrate the difference:

X-Ref Target - Figure 24-66

Figure 24-66:

DDR3 Read vs. Write Scope Capture

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

510

Chapter 24: Debugging

Analyze read timing:

Check the PQTR/NQTR values after calibration. Look for variations between PQTR/
NQTR values. PQTR/NQTR values should be very similar for DQs in the same DQS
group.

Analyzing Read and Write Margin

The XSDB output can be used to determine the available read and write margins during
calibration. Starting with 2014.3, an XSDB Memory IP GUI is available through the Hardware
Manager to view the read calibration margins for both rising edge clock and failing edge
clock. The margins are provided for both simple and complex pattern calibration. The
complex pattern results are more representative of the margin expected during post
calibration traffic.
X-Ref Target - Figure 24-67

Figure 24-67:

Calibration Rising Edge Clocked Read Margin

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

511

Chapter 24: Debugging

X-Ref Target - Figure 24-68

Figure 24-68:

Calibration Falling Edge Clocked Read Margin

The following Tcl command can also be used when the Hardware Manager is open to get an
output of the window values:
report_hw_mig [get_hw_migs]

Table 24-56:

Signals of Interest for Read and Write Margin Analysis

Signal

Usage

Signal Description

MARGIN_CONTROL

Per Interface

Reserved

MARGIN_STATUS

Per Interface

Reserved

RDLVL_MARGIN_PQTR_LEFT_RANK*_BYTE*_BIT*

Per Bit

Number of taps from center of window to

left edge.

RDLVL_MARGIN_NQTR_LEFT_RANK*_BYTE*_BIT*

Per Bit

Number of taps from center of window to

left edge.

RDLVL_MARGIN_PQTR_RIGHT_RANK*_BYTE*_BIT*

Per Bit

Number of taps from center of window to

right edge.

RDLVL_MARGIN_NQTR_RIGHT_RANK*_BYTE*_BIT*

Per Bit

Number of taps from center of window to

right edge.

WRITE_DQS_DQ_MARGIN_LEFT_RANK*_BYTE*_BIT*

Per Bit

Number of taps from center of window to

left edge.

WRITE_DQS_DQ_MARGIN_RIGHT_RANK*_BYTE*_BIT*

Per Bit

Number of taps from center of window to

right edge.

Analyzing Calibration Results

When data errors occur, the results of calibration should be analyzed to ensure that the
results are expected and accurate. Each of the debugging calibration sections notes what
the expected results are such as how many edges should be found, how much variance

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

512

Chapter 24: Debugging

across byte groups should exist, etc. Follow these sections to capture and analyze the
calibration results.

Determining Window Size in ps

To determine the window size in ps, first calculate the tap resolution and then multiply the
resolution by the number of taps found in the read and/or write window.The tap resolution
varies across process (down to variance at each nibble within a part).
However, within a specific process, each tap within the delay chain is the same precise
resolution.
1. To compute the 90 offset in taps, take (BISC_PQTR BISC_ALIGN_PQTR).
2. To estimate tap resolution, take (1/4 of the memory clock period) / (BISC_PQTR
BISC_ALIGN_PQTR).
3. The same then applies for NQTR.
BISC is run on a per nibble basis for both PQTR and NQTR. The write tap results are given on
a per byte basis. To use the BISC results to determine the write window, take the average of
the BISC PQTR and NQTR results for each nibble. For example, ((BISC_NQTR_NIBBLE0 +
BISC_NQTR_NIBBLE1 + BISC_PQTR_NIBBLE0 + BISC_PQTR_NIBBLE1) / 4).

Conclusion
If this document does not help to resolve calibration or data errors, create a WebCase with
Xilinx Technical Support. Attach all of the captured waveforms, XSDB and debug signal
results, and the details of your investigation and analysis.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

513

SECTION VIII: APPENDICES

Migrating and Upgrading
Additional Resources and Legal Notices

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

514

Appendix A

Migrating and Upgrading

There are no port or parameter changes for upgrading the Memory IP core in the Vivado
Design Suite at this time.
For general information on upgrading the Memory IP, see the Upgrading IP section in
Vivado Design Suite User Guide: Designing with IP (UG896) [Ref 9].

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

515

Appendix B

Additional Resources and Legal Notices

Xilinx Resources
For support resources such as Answers, Documentation, Downloads, and Forums, see Xilinx
Support.

References
These documents provide supplemental material useful with this product guide:
1. JESD79-3F, DDR3 SDRAM Standard and JESD79-4, DDR4 SDRAM Standard, JEDEC Solid
State Technology Association
2. Kintex UltraScale FPGAs Data Sheet: DC and AC Switching Characteristics (DS892)
3. UltraScale Architecture SelectIO Resources User Guide (UG571)
4. UltraScale Architecture Clocking Resources User Guide (UG572)
5. Vivado Design Suite Properties Reference Guide (UG912)
6. UltraScale Architecture PCB Design and Pin Planning User Guide (UG583)
7. ARM AMBA Specifications
8. Vivado Design Suite User Guide: Designing IP Subsystems using IP Integrator (UG994)
9. Vivado Design Suite User Guide: Designing with IP (UG896)
10. Vivado Design Suite User Guide: Getting Started (UG910)
11. Vivado Design Suite User Guide: Logic Simulation (UG900)
12. Vivado Design Suite User Guide: Implementation (UG904)
13. Vivado Design Suite User Guide: I/O and Clock Planning (UG899)
14. Vivado Design Suite User Guide: Release Notes, Installation, and Licensing (UG973)
15. Vivado Design Suite User Guide: Programming and Debugging (UG908)

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

516

Appendix B: Additional Resources and Legal Notices

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

Version

09/30/2015

1.0

Revision

Reset core version to v1.0.

Updated BUFGCE_DIV to BUFG.
Added description to all TXPLL sections.
Added Reference Input Clock Period option in all Sharing of Input Clock
Source (sys_clk_p) sections.
Added TXPLL Usage and Additional Clocks sections to all interfaces.
Updated Customizing and Generating the Core figures.
Added note in all Non-Project-Based Simulation sections.
DDR3/DDR4
Added DDR3L (1.35V), dual slot support and quad rank support in Feature
Summary.
Updated PHY Block Diagram and table.
Updated Fig. 3-6: PHY Overview Initialization and Cal. Seq.
Updated Error Signals Descriptions table.
Updated Read and Write VREF Calibration sections.
Added description to app_wdf_data[APP_DATA_WIDTH 1:0] and
app_wdf_mask[APP_MASK_WIDTH 1:0] sections.
Added Pin Swapping section.
Updated Pin and Bank Rules section.
Added description in DQS Gate section.
Updated descriptions for SLOT0_CONFIG, SLOT1_CONFIG, and
SLOT0_FUNC_CS in PHY Only Parameters table.
Added DIMM Configurations section.
Added description in Basic Tab section.
Updated figures in Customizing and Generating the Core section.
Updated Simulating the Performance Traffic Generator section.
QDR II+
Added description in Customizing and Generating the Core section.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

517

Appendix B: Additional Resources and Legal Notices

Date

Continued

Version

Revision
RLDRAM 3
Added interface widths to Supported Configurations table.
Updated signal for user_rd_valid[CMD_PER_CLK 1:0] in User Interface
Request Signals table.
Added RLDRAM 3 Address Width table.
Updated PHY Overall Initialization and Calibration Sequence.
Added description in Customizing and Generating the Core section.
Updated description in Required Constraints section.
Traffic Generator
Updated chapter.
Multiple IP
Updated MMCM Constraints section.
Debugging Appendix
Updated Hardware Debug section.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

518

Appendix B: Additional Resources and Legal Notices

Date

Version

06/24/2015

7.1

Revision

Updated all Resource Utilization sections.

Added clocking reference in all Requirements sections.
Updated description in all Resets section.
Updated all Clocking sections.
Updated all CLOCK_DEDICATED_ROUTE Constraints and BUFG Instantiation
sections.
DDR3/DDR4
Added x4 devices are not supported in AXI note in Feature Summary
section.
Updated Fig. 3-6: PHY Overall Initialization and Calibration Sequence.
Added Table 3-4: Pre-Calibration XSDB Status Signal Description.
Updated Table 3-5: XSDB Status Signal Description
Added Table 3-6: Post-Calibration XSDB Status Signal Description.
Updated Read per-bit Deskew description in Table 3-6: Error Signal
Descriptions.
Updated description in Write DQS-to-DQ Centering section.
Added Read DQS Centering (Complex) and Write DQS-to-DQ Centering
(Complex) sections.
Added Notes to Write DQS-to-DQ, Write DQS-to-DM, Write DQS-to-DQ
Centering (Complex), Read V REF, and Read DQS Centering (Complex).
Added Read V REF and Write VREF Calibrations section.
Updated letter b and c descriptions in DDR3 Pin Rules section.
Updated AXI4-Lite Slave Control/Status Register Map Detailed
Descriptions.
Added description in Project-Based Simulation Flow Using Vivado
Simulator section.
QDR II+
Added HSTL_I I/O standard support in Feature Summary.
Added description to the Memory Initialization bullet in Overview section.
RLDRAM 3
Updated description in Required Constraints section.
Updated Fig. 17-4: PHY Overall Initialization and Calibration Sequence.
Updated description d. in RLDRAM 3 Pin Rules.
Traffic Generator
Updated Advanced Traffic Generator section.
Debugging Appendix
Added AR: 60305 in General Checks section.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

519

Appendix B: Additional Resources and Legal Notices

Date

Version

Revision

04/01/2015

7.0

Updated Supported User Interface and added #3 footnote in IP Facts table.

Updated Application Interface description in the Overview chapter.
Updated descriptions and added BACKBONE description in all Clocking
sections.
Added sys_rst and dbg_clk references throughout book.
Added Simulation Flow and Simulation Speed to all sections.
Added Project-Based Simulation Flow Using Vivado Simulator to all
sections.
Added CLOCK_DEDICATED_ROUTE Constraints and BUFG Instantiation to
all sections.
DDR3/DDR4
Updated Fig. 1-1: UltraScale Architecture-Based FPGAs Memory Interface
Solution.
Updated Feature Summary section.
Updated Memory Controller section.
Updated Group Machines section.
Updated DQS section.
Updated parameters in Write Leveling section.
Updated and added Important note in Read DQS Centering section.
Updated Read Leveling Multi-Rank Adjustment, Multi-Rank Adjustments
and Checks, and added Write Latency Multi-Rank Check.
Updated Write Per-bit Deskew section.
Updated Write DQS-to-DM section.
Updated Table 3-5: Error Signal Descriptions.
Updated Table 3-6: Examples of DQS Gate Multi-Rank Adjustment (2
Ranks).
Updated DDR3 and DDR4 Pin Rules sections.
Added Pin Mapping for x4 RDIMMs.
Added app_ref_req, app_ref_ack, app_zq_req, and app_zq_ack in Table 4-7:
User Interface.
Updated Write Path section.
Added Performance section.
Added descriptions for app_ref_req, app_ref_ack, app_zq_req, and
app_zq_ack.
Added Maintenance Commands section.
Updated Table 4-16: AXI4 Slave Interface Parameters.
Added dbg_clk to Table 4-17: AXI4 Slave Interface Signals.
Updated Time Division Multiplexing (TDM), Round-Robin, and Read
Priority (RD_PRI_REG) sections.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

520

Appendix B: Additional Resources and Legal Notices

Date

Continued

Version

Revision
Updated Table 4-76: Read Data to Table 4-77: PHY Only Parameters.
Updated to 11 writes in Multiple Writes and Reads with Same Address to
Page Wrap During Writes sections.
Added Minimum Write CAS Command Spacing and System Considerations
for CAS Command Spacing sections.
Updated the Design Flow Steps chapter.
QDR II+
Updated Feature Summary.
RLDRAM 3
Added User Interface Allocation section.
Added User Address Bit Allocation Based on RLDRAM 3 Configuration
section.
Added description to Interfacing with the Core through the User Interface
section.
Traffic Generator
Added Traffic Generator section.
Multiple IP
Added Multiple IP section.
Migrating and Upgrading Appendix
Added link to UG973 and description in Migrating and Upgrading chapter.
Debugging Appendix
Added description in General Checks section.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

521

Appendix B: Additional Resources and Legal Notices

Date

Version

Revision

11/19/2014

6.1

QDR II+
Added interface calibration in Feature Summary section.
Updated description #2 in Sharing of Input Clock Source (sys_clk_p)
section.
Added read data pins description and cross-ref to system clock pins
description in QDR II+ Pin Rules section.
Added vrp description in QDR II+ Pin Rules section.
Updated User Parameters table.
Updated GUIs in Example Design chapter.
DDR3/DDR4
Updated Fig. 1-1: UltraScale Architecture-Based FPGAs Memory Interface
Solution.
Added interface calibration in Feature Summary section.
Updated RIU code in Overall PHY Architecture section.
Updated description #2 in Sharing of Input Clock Source (sys_clk_p)
section.
Added ECC description in Datapath section and ECC section.
Updated resetn, input clock description, and added x4 Part Contained in
One Bank tables in DDR3 and DDR4 Pin Rules sections.
Added app_raw_not_ecc in Table 4-5: User Interface.
Updated descriptions in app_cmd[2:0] section.
Updated Fig. 4-2 and Fig. 4-6 to Fig. 4-8.
Added examples for DRAM clock in Write Path section.
Added PHY Only section in Protocol Description.
Updated RTT (nominal)-ODT default values in Table 5:1: Vivado IDE
Parameter to User Parameter Relationship.
Updated GUIs in Customizing and Generating the Core section.
Updated User Parameters table.
Updated GUIs in Example Design chapter.
RLDRAM 3
Added interface calibration in Feature Summary section.
Updated Table 15-1: Supported Configurations and removed support for
Read Latency in Feature Summary.
Added CMD_PER_CLK description in Memory Controller section.
Updated description #2 in Sharing of Input Clock Source (sys_clk_p)
section.
Updated input clock description in RLDRAM 3 Pin Rules section.
Added note in Interfacing with the Core through the User Interface section.
Updated Fig. 18-2: Multiple Commands for user_cmd Signal.
Updated User Parameters table.
Updated GUIs in Example Design chapter.
Updated description in Simulating the Example Design (Designs with
Standard User Interface) section.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

522

Appendix B: Additional Resources and Legal Notices

Date

Version

Revision

10/01/2014

6.0

DDR3/DDR4
Updated Standards section.
Updated Feature Summary section.
Updated description in Memory Initialization and Calibration Sequence
section.
Updated Overall PHY Architecture section.
Updated Fig. 3-4: PHY Overall Initialization and Calibration Sequence.
Added new calibration status descriptions in Memory Initialization and
Calibration Sequence section.
Added DQS Gate, Write Leveling, Read Leveling, Read Sanity Check, Write
DQS-to-DQ, Write Latency Calibration, Write/Read Sanity Check, Write
DQS-to-DM, and Multi-Rank Adjustment sections.
Updated DDR3/DDR4 Pin Rules section.
Added AXI4 Slave Interface in Protocol Description section.
Added Multiple IP Cores and Sharing of Input Clock Source in Clocking
section.
Removed Special Designation column in Table 4-1: 16-Bit Interface
Contained in One Bank and Table 4-2: 32-Bit Interface Contained in Two
Banks.
Added app_autoprecharge to Table 4-3: User Interface.
Added app_autoprecharge section.
Updated app_rdy section.
Updated ref_req and zq_req sections.
Updated Table 5-1: Vivado IDE Parameter to User Parameter Relationship.
Updated note description in Required Constraints section.
Updated description in Simulation section.
Updated GUIs in Example Design chapter.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

523

Appendix B: Additional Resources and Legal Notices

Date

Continued

Version

Revision
QDR II+
Updated Feature Summary section.
Updated Table 9-1: Device Utilization Kintex UltraScale FPGAs.
Updated Fig. 10-3: PHY Overall Initialization and Calibration Sequence.
Updated MicroBlaze description in Overall PHY Architecture section.
Updated Memory Initialization and Calibration Sequence section.
Updated Resets section.
Deleted Special Designation column in Table 11-1: 18-Bit QDR II+ Interface
Contained in Two Banks.
Added Multiple IP Cores and Sharing of Input Clock Source in Clocking
section.
Updated Protocol Description section.
Updated Simulation section.
Updated description in Simulating the Example Design (Designs with
Standard User Interface) section.
Updated GUIs in Example Design chapter.
RLDRAM 3
Added Configuration table in Feature Summary section.
Updated Memory Initialization bullet in Overview chapter.
Added description to burst support in Feature Summary section.
Updated Table 16-1: Device Utilization Kintex UltraScale FPGAs.
Updated Memory Controller section.
Updated Overall PHY Architecture section.
Updated Memory Initialization and Calibration Sequence section.
Added Multiple IP Cores and Sharing of Input Clock Source in Clocking
section.
Added data mask description to RLDRAM 3 Pin Rules section.
Updated GUIs in Example Design chapter.
Appendix
Added Migrating Appendix.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

524

Appendix B: Additional Resources and Legal Notices

Date

Version

Revision

06/04/2014

5.0

Removed PCB sections and added link to UG583.

Global replace BUFGCE to BUFGCE_DIV.
DDR3/DDR4
Updated CAS cycle description in DDR3 Feature Summary.
Updated descriptions in Native Interface section.
Updated Control Path section.
Updated Read and Write Coalescing section.
Updated Reordering section.
Updated DDR4 x16 parts in Group Machines section.
Updated Fig. 3-3: PHY Block Diagram.
Updated Table 3-1: PHY Modules.
Updated module names in Overall PHY Architecture section.
Updated Fig. 3-4: PHY Overall Initialization and Calibration Sequence.
Added description to Memory Initialization and Calibration Sequence
section.
Added SSI rule in Clocking section.
Added SSI rule and updated Address and ck descriptions in DDR3/DDR4
Pin Rules sections.
Added Important Note for calibration stage in DDR3/DDR4 Pinout
Examples sections.
Updated signal descriptions in Table 4-3: User Interface.
Added new content in app_addr[ADDR_WIDTH 1:0] section.
Updated Write Path section.
Updated Native Interface section.
Added Important Note relating to Data Mask in Controller Options section.
Added PHY Only section.
Updated Fig. 5-1 to 5-8 in Customizing and Generating the Core section.
Added User Parameters section in Design Flow Steps chapter.
Updated I/O Standard and Placement section.
Added Synplify Black Box Testing section in Example Design chapter.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

525

Appendix B: Additional Resources and Legal Notices

Date

Continued

Version

Revision
QDR II+
Updated Read Latency in Feature Summary section.
Updated Fig. 10-2: PHY Block Diagram and Table 17-1: PHY Modules.
Updated Table 11-2: User Interface.
Added SSI rule in Clocking section.
Added Important Note for calibration stage in QDR II+ Pinout Examples
section.
Added SSI rule in QDR II+ Pin Rules section.
Updated I/O Standard and Placement section.
Added User Parameters section in Design Flow Steps chapter.
Updated the descriptions in Simulating the Example Design (Designs with
Standard User Interface) section.
Added Synplify Black Box Testing section in Example Design chapter.
RLDRAM 3
Added 18 bits in Feature Summary section.
Updated Fig. 17-4: PHY Block Diagram.
Updated module names in Table 17-1: PHY Modules.
Updated module names in Overall PHY Architecture section.
Added SSI rule in Clocking section.
Updated c) and d) descriptions and added SSI rule in RLDRAM 3 Pin Rules
section.
Updated Table 18-2: User Interface Request Signals.
Updated Fig. 18-2: Multiple Commands for user_cmd Signal.
Added Important Note for calibration stage in RLDRAM 3 Pinout Examples
section.
Updated I/O Standard and Placement section.
Added User Parameters section in Design Flow Steps chapter.
Updated Test Bench chapter.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

526

Appendix B: Additional Resources and Legal Notices

Date

Version

Revision

04/02/2014

5.0

Added Verilog Test Bench in IP Facts table.

DDR3/DDR4
Added Overview chapter.
Updated component support to 80 bits in Feature Summary section.
Updated DDR Device Utilization tables.
Updated DDR Clocking section.
Updated x4 DRAM to Four Component DRAM Configuration in Designing
with the Core chapter.
Updated Important note in PCB Guidelines for DDR3 and DDR4 Overview
sections.
Updated Important note in Reference Stack-Up for DDR3 and DDR4
sections.
Updated trace length descriptions in DDR3 and DDR4 sections.
Added V TT Terminations guideline in Generic Routing Guideline for DDR3
and DDR4 sections.
Removed Limitations section.
Added V REF note in Required Constraints section.
Updated new figures in Design Flow Steps chapter.
Added new descriptions in Example Design chapter.
Added new description in Test Bench chapter.
QDR II+ SRAM
Added new QDR II+ section.
RLDRAM 3
Added Overview chapter.
Added new Clocking section.
Added new descriptions in Example Design chapter.
Appendix
Updated Debug Appendix.

12/18/2013

4.2

Initial Xilinx release.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

527

Appendix B: Additional Resources and Legal Notices

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
in contract 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
result of any action brought by a third party) even if such damage or loss was reasonably foreseeable or Xilinx had been advised
of the possibility of the same. Xilinx assumes no obligation to correct any errors contained in the Materials or to notify you of
updates to the Materials or to product specifications. You may not reproduce, modify, distribute, or publicly display the Materials
without prior written consent. 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 of Sale which can be viewed at http://www.xilinx.com/legal.htm#tos.
Copyright 20132015 Xilinx, Inc. Xilinx, the Xilinx logo, Artix, ISE, Kintex, Spartan, UltraScale, 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 their respective owners.

UltraScale Architecture FPGAs Memory IP v1.0www.xilinx.com

PG150 September 30, 2015

Send Feedback

528