LogiCORE IP Digital Pre-Distortion v4.0 Debug Interface · DPD v4.0 Debug Interface 11 UG776 (v1.0)...

LogiCORE IP Digital Pre-Distortion v4.0 Debug InterfaceUser Guide

UG776 (v1.0) November 23, 2010

DPD v4.0 Debug Interface www.xilinx.com UG776 (v1.0) November 23, 2010

Xilinx is providing this product documentation, hereinafter “Information,” to you “AS IS” with no warranty of any kind, express or implied. Xilinx makes no representation that the Information, or any particular implementation thereof, is free from any claims of infringement. You are responsible for obtaining any rights you may require for any implementation based on the Information. All specifications are subject to change without notice.

XILINX EXPRESSLY DISCLAIMS ANY WARRANTY WHATSOEVER WITH RESPECT TO THE ADEQUACY OF THE INFORMATION OR ANY IMPLEMENTATION BASED THEREON, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OR REPRESENTATIONS THAT THIS IMPLEMENTATION IS FREE FROM CLAIMS OF INFRINGEMENT AND ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Except as stated herein, none of the Information may be copied, reproduced, distributed, republished, downloaded, displayed, posted, or transmitted in any form or by any means including, but not limited to, electronic, mechanical, photocopying, recording, or otherwise, without the prior written consent of Xilinx.

CRITICAL APPLICATIONS DISCLAIMERXILINX PRODUCTS (INCLUDING HARDWARE, SOFTWARE AND/OR IP CORES) ARE NOT DESIGNED OR INTENDED TO BE FAIL-SAFE, OR FOR USE IN ANY APPLICATION REQUIRING FAIL-SAFE PERFORMANCE, SUCH AS IN LIFE-SUPPORT OR SAFETY DEVICES OR SYSTEMS, CLASS III MEDICAL DEVICES, NUCLEAR FACILITIES, APPLICATIONS RELATED TO THE DEPLOYMENT OF AIRBAGS, OR ANY OTHER APPLICATIONS THAT COULD LEAD TO DEATH, PERSONAL INJURY OR SEVERE PROPERTY OR ENVIRONMENTAL DAMAGE (INDIVIDUALLY AND COLLECTIVELY, “CRITICAL APPLICATIONS”). FURTHERMORE, XILINX PRODUCTS ARE NOT DESIGNED OR INTENDED FOR USE IN ANY APPLICATIONS THAT AFFECT CONTROL OF A VEHICLE OR AIRCRAFT, UNLESS THERE IS A FAIL-SAFE OR REDUNDANCY FEATURE (WHICH DOES NOT INCLUDE USE OF SOFTWARE IN THE XILINX DEVICE TO IMPLEMENT THE REDUNDANCY) AND A WARNING SIGNAL UPON FAILURE TO THE OPERATOR. CUSTOMER AGREES, PRIOR TO USING OR DISTRIBUTING ANY SYSTEMS THAT INCORPORATE XILINX PRODUCTS, TO THOROUGHLY TEST THE SAME FOR SAFETY PURPOSES. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, CUSTOMER ASSUMES THE SOLE RISK AND LIABILITY OF ANY USE OF XILINX PRODUCTS IN CRITICAL APPLICATIONS.

© Copyright 2010 Xilinx, Inc. XILINX, the Xilinx logo, Virtex, Spartan, ISE, and other designated brands included herein are trademarks of Xilinx in the United States and other countries. MATLAB is a registered trademark of The MathWorks, Inc. All other trademarks are the property of their respective owners.

http://www.xilinx.com

UG776 (v1.0) November 23, 2010 www.xilinx.com DPD v4.0 Debug Interface

Revision HistoryThe following table shows the revision history for this document.

Date Version Revision

11/23/10 1.0 Initial Xilinx release


DPD v4.0 Debug Interface www.xilinx.com UG776 (v1.0) November 23, 2010


DPD v4.0 Debug Interface www.xilinx.com 5UG776 (v1.0) November 23, 2010

Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Guide Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Additional Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Typographical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Online Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Chapter 1: IntroductionHardware Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Software Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Chapter 2: Overview

Chapter 3: Getting StartedZip File Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Modes of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Learning Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Debugging Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Chapter 4: Hardware DesignMemory Map Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Wrapper Interface Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Input/Output Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Example User Extensions to Memory Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Using HDL Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Using Pre-canned BIT Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Chapter 5: Using the Debug InterfaceBoard Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Verify DPD Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Configuring the DPD Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Running Essential Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36DPD Command Execution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Real Time Monitors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38DCL Monitors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Reading the Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Additional DCL Monitors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Table of Contents


6 www.xilinx.com DPD v4.0 Debug InterfaceUG776 (v1.0) November 23, 2010

Chapter 6: Supplied Commandscapture_and_align. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43capture_swap_rx_and_align . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45load_samples_and_align . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Collecting Raw Capture RAM Samples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48compute_capture_frequency_response. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49compute_ccdf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50read_full_histogram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51read_capture_measurements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52read_coefficients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53load_coefficients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54xilinx_support_data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Control Mode (commands) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Chapter 7: Debugging GuidanceError Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Debugging the ALIGN_FAILURE error. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

ALIGN_FAILURE Error Debug Flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Debugging the CAPTURE_FAILURE and SCA_FAILURE errors . . . . . . . . . . . . . 62

Chapter 8: Writing an Advanced ScriptAdding Utility Scripts to the GUI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Plotting to GUI Axes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64



Chapter 1: Introduction

Chapter 2: OverviewFigure 2-1: Board Setup GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Figure 2-2: Main GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Figure 2-3: DCL Monitor GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Chapter 3: Getting Started

Chapter 4: Hardware DesignFigure 4-1: Simplified Hardware Design Framework. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Figure 4-2: Wrapper Port Symbol Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Figure 4-3: JTAG user extensible memory map timing diagram . . . . . . . . . . . . . . . . . . . . 27Figure 4-4: HDL File Usage Flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Figure 4-5: Design in Pre-canned BIT Files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Chapter 5: Using the Debug InterfaceFigure 5-1: Board Setup GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Figure 5-2: iMPACT Screenshot After a Successful Boundary Scan . . . . . . . . . . . . . . . . . 32Figure 5-3: Chipscope Analyzer Screenshot After Successful Boundary Scan . . . . . . . . 33Figure 5-4: Selection of Pre-canned Bitfile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Figure 5-5: DPD Configuration Read from Hardware (highlighted) . . . . . . . . . . . . . . . . . 35Figure 5-6: DPD configuration panel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Figure 5-8: Essential Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Figure 5-9: Scripts and DPD Command Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Figure 5-10: Real Time Monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Figure 5-11: DCL Monitor GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Figure 5-12: Logged DSL Monitor for Single Set Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40Figure 5-13: Logged DCL Monitor for Multi-Set Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Chapter 6: Supplied CommandsFigure 6-1: capture_and_align . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Figure 6-2: capture_swap_rx_and_align - correctly connected ports . . . . . . . . . . . . . . . . . 46Figure 6-3: capture_swap_rx_and_align - incorrectly connected ports . . . . . . . . . . . . . . . 46Figure 6-4: Adjacent Channel Leakage Ratio Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Figure 6-5: compute_capture_frequency_response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Figure 6-6: compute_CCDF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Figure 6-7: read_full_histogram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Schedule of Figures



Figure 6-8: read_capture_measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Figure 6-9: read_coefficients. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Figure 6-10: load_coefficients. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Chapter 7: Debugging GuidanceFigure 7-1: ALIGN_FAILURE Error Debug Flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Figure 7-2: SCA and CAPTURE process flowchart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Chapter 8: Writing an Advanced ScriptFigure 8-1: GUI Axes Handles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Appendix A: Abbreviations




Chapter 2: Overview

Chapter 3: Getting StartedTable 3-1: Zip File Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Chapter 4: Hardware DesignTable 4-1: Memory Map Addresses for write and read access . . . . . . . . . . . . . . . . . . . . . . . 24Table 4-2: Top-level I/Os for the DPD IP Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Chapter 5: Using the Debug InterfaceTable 5-1: Required JTAG chain information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Table 5-2: DCL Monitor Expansion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Chapter 6: Supplied CommandsTable 6-1: Control Modes (Commands) Supported in GUI . . . . . . . . . . . . . . . . . . . . . . . . . 55

Chapter 7: Debugging GuidanceTable 7-1: DPD Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Chapter 8: Writing an Advanced ScriptTable 8-1: Value Pairs Passed by the GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64


Schedule of Tables



Preface

About This Guide

The LogicCORE™ IP Digital Pre-Distortion v4.0's Debug Interface User Guide describes the function and operation of the Debug Interface tool and provides information about designing, customizing, and implementing the Debug Interface. It also provides details about how to set various runtime Digital Pre-Distortion (DPD) parameters for optimized pre-distortion capability.

Guide ContentsThis manual contains the following chapters:

• Chapter 1, Introduction describes the hardware and software requirements of the Debug Interface.

• Chapter 2, Overview describes the features of the Debug Interface.

• Chapter 3, Getting Started describes the zip file contents and operational modes of the Debug Interface.

• Chapter 4, Hardware Design describes the hardware design of the wrapper and how to get it integrated into your system.

• Chapter 5, Using the Debug Interface describes the detailed steps performed while using the Debug Interface. This includes the steps required when connecting the MATLAB® session to the hardware as well as the steps required while interacting with the DPD core.

• Chapter 6, Supplied Commands describes the advance scripts and DPD commands that are supplied with the Debug Interface.

• Chapter 7, Debugging Guidance gives general guidance on the various error codes of DPD v4.0 and describes what steps should be taken when each is encountered.

• Chapter 8, Writing an Advanced Script describes the method required for integrating a custom advanced script into the GUI.

• Appendix A, Abbreviations identifies the acronyms used in this guide.

Additional ResourcesTo find additional documentation, see the Xilinx website at:

http://www.xilinx.com/support/documentation/index.htm.

To search the Answer Database of silicon, software, and IP questions and answers, or to create a technical support WebCase, see the Xilinx website at:

http://www.xilinx.com/support/mysupport.htm.


http://www.xilinx.com/support/documentation/index.htm

http://www.xilinx.com/support/mysupport.htm


Preface: About This Guide

References1. Digital Pre-Distortion Product Brief, v4.0, XMP143

2. Spartan-6 FPGA Configuration User Guide, UG380

3. Virtex-5 FPGA Configuration User Guide UG191

4. Virtex-6 FPGA Configuration User Guide UG360

5. System Generator 12.3 User Guide

6. Chipscope Analyzer 12.3 User Guide

7. Virtex-6 FPGA ML605 Evaluation Board


www.xilinx.com/support/documentation/dt_chipscopepro_chipscope12-3_userguides.htm

www.xilinx.com/support/documentation/dt_sysgendsp.htm

www.xilinx.com/products/devkits/EK-V6-ML605-G.htm

www.xilinx.com/support/documentation/ip_documentation/xmp143_dpd.pdf

www.xilinx.com/support/documentation/user_guides/ug191.pdf



www.xilinx.com/products/devkits/EK-V6-ML605-G.htm


Conventions

ConventionsThis document uses the following conventions. An example illustrates each convention.

TypographicalThe following typographical conventions are used in this document:

Convention Meaning or Use Example

Courier fontMessages, prompts, and program files that the system displays

speed grade: - 100

Courier boldLiteral commands that you enter in a syntactical statement

ngdbuild design_name

Helvetica bold

Commands that you select from a menu

File → Open

Keyboard shortcuts Ctrl+C

Italic font

Variables in a syntax statement for which you must supply values

ngdbuild design_name

References to other manuals See the User Guide for more information.

Emphasis in textIf a wire is drawn so that it overlaps the pin of a symbol, the two nets are not connected.

Dark ShadingItems that are not supported or reserved

This feature is not supported

Square brackets [ ]

An optional entry or parameter. However, in bus specifications, such as bus[7:0], they are required.

ngdbuild [option_name] design_name

Braces { } A list of items from which you must choose one or more

lowpwr ={on|off}

Vertical bar | Separates items in a list of choices

lowpwr ={on|off}

Angle brackets < > User-defined variable or in code samples

<directory name>

Vertical ellipsis...

Repetitive material that has been omitted

IOB #1: Name = QOUT’ IOB #2: Name = CLKIN’...

Horizontal ellipsis . . .Repetitive material that has been omitted

allow block block_name loc1 loc2 ... locn;



Preface: About This Guide

Online DocumentThe following conventions are used in this document:

Notations

The prefix ‘0x’ or the suffix ‘h’ indicate hexadecimal notation

A read of address 0x00112975 returned 45524943h.

An ‘_n’ means the signal is active low

usr_teof_n is active low.



Blue textCross-reference link to a location in the current document

See the section “Additional Resources” for details.

Refer to “Title Formats” in Chapter 1 for details.

Blue, underlined text Hyperlink to a website (URL)Go to http://www.xilinx.com for the latest speed files.



Chapter 1

Introduction

The DPD v4.0 Debug Interface tool consists of a HDL JTAG wrapper for the DPD v4.0 CORE Generator™ IP core and a user extensible MATLAB® control framework for communicating with the DPD core via the JTAG cable using JTAG based Hardware Co-simulation. The MATLAB interface consists of a GUI, for ease of use, and an extensible set of the drivers used for control and monitoring of the DPD core.

The GUI may be used for real-time control and monitoring of the DPD core in your native environment or in conjunction with a Xilinx ML605 development board as a learning and demonstration platform.

Hardware RequirementsTo use the Debug Interface for a DPD v4.0 IP, the FPGA must be on a JTAG chain which is accessible to the PC. The PC must be running MATLAB® software.

Software RequirementsThe software required to use the Debug Interface is:

• Xilinx ISE 12.3 Logic Edition (or DSP Edition or System Edition)

• The Mathworks, Inc MATLAB R2009a software

• Perl 5.8.5 (www.perl.org)

• DPD v4.0

www.perl.org



Chapter 2

Overview

The Debug Interface supplies a dedicated GUI to allow a connection to be established between the MATLAB session and JTAG wrapper. This GUI can be used to connect to an existing image on any board or to load an image onto an ML605 board.X-Ref Target - Figure 2-1

Once the connection between MATLAB and DPD has been established, another GUI is displayed that allows for control and monitoring of all aspects of DPD operation. This GUI gives access to the following features of DPD, annotated in Figure 2-2 and Figure 2-3:

1. DPD configuration panel - area used to view or change the DPD configuration parameters

2. Display/Console monitor panel - area used to display results returned from DPD

3. Essential Checks - predefined set of tests that should be passed in order to achieve good DPD performance.

4. Advanced scripting - user extensible advanced scripting feature

5. DPD Command Execution - easy access to DPD command list

X-Ref Target - Figure 2-2

Figure 2-1: Board Setup GUI



Chapter 2: Overview

6. Real Time Monitors - continuously updated monitor of the power meters, run-time and code-pointer.

7. DCL Monitor - Dedicated continuously updated Dynamic Control Layer monitoring.X-Ref Target - Figure 2-2


Figure 2-2: Main GUI

1 23

5

4

6




Figure 2-3: DCL Monitor GUI

7



Chapter 2: Overview



Chapter 3

Getting Started

Zip File DescriptionThe DPD v4.0 Debug Interface is provided as a zip file which is downloaded from the Xilinx website under a license agreement. The zip file contents are described in Table 3-1.

Modes of Operation

Learning ModeThe Debug Interface tool is used to visually understand various aspects of DPD and its configuration and runtime parameters. This tool is provided with pre-canned bitfiles for the ML605 platform that can be used for the learning exercise.

Table 3-1: Zip File Contents

Directory Notes

Dpd_v4_0_dbg.zip Zip file name

dpd_v4_0_dbg Top level directory

• vhdl Includes various vhdl files, templates and script to generate instantiation component and wrapper files

• netlists Includes family specific jtag decoder netlist.

• Matlab Includes the top level invocation script

dpd_drivers Includes various driver files that help the Debug Interface GUI interact with the host interface port of DPD.

fpga_images Includes pre-canned bitfilesa with lib to set up the bitfile for demonstrating the Debug Interface capabilities.

a. The pre-canned bitfiles are named to indicate the DPD configuration that they support. The bitfile names are constructed as dpd_v4_0_XXXXXX where 'XXXXXX' maps to <#antenna><clocks_per_sample><architecture><poly_order><qmc_true_or_false><hwaccelerator_true_or_false>.

jtag_drivers Includes files to establish jtag connection

gui Includes various GUI drawing MATLAB files

utilities Includes various MATLAB utilities to assist with debug operation

• doc Includes this User Guide



Chapter 3: Getting Started

Running a learning session on the ML605 board

1. You can start the Debug Interface GUIs in MATLAB® by launching start_debug_interface.m script at the MATLAB tool prompt (see Board Setup).

2. Now configure the ML605 board connections and load the pre-canned bitfile onto the board (see Figure 5-4).

3. Note the netlist configuration shown (see Figure 5-5) and then click on "Launch GUI".

4. Change the host interface accessible parameters as required. Use the DPD data sheet, v4.0, ds811 to understand their use and range (see Configuring the DPD Parameters).

5. Run essential checks (see Running Essential Checks) to validate the setup and then continue to run further MATLAB utilities and commands using the GUI and learn about DPD performance for the simple Power Amplifier (PA) model embedded within the pre-canned bitfiles (see Using Pre-canned BIT Files).

Debugging ModeThe Debug Interface capability is accessed by wrapping the DPD v4.0 netlist with a JTAG access module and then using MATLAB software to access the JTAG connection via the Debug Interface GUIs.

Inserting the Debug Interface Design in HDL Code

1. Open a DPD v4.0 GUI in CORE Generator™ and generate a netlist.

2. Navigate to the vhdl subdirectory of this zip file and run the perl script to generate the customized wrapper file for instantiation.

3. Instantiate the wrapper component in your own code, instead of directly instantiating the DPD netlist. You can customize the extensible memory mapped interface, if needed, to gain access to non-DPD portion of your design while debugging in MATLAB.

4. Complete the bitstream generation process using the Xilinx ISE® tools.

Running debug session on a board

Once you have a bitfile to test, it can be loaded on to your board using your bit image loading procedure. Launch the MATLAB software to navigate to the Matlab subdirectory in the unzipped area and launch start_debug_interface.m script at the MATLAB software prompt.

1. Release the DPD IP core resets (rst and proc_rst).

2. Configure the "Custom" board connections and establish connection with the board (see Board Setup).

3. Verify that the netlist configuration shown is correct and then click on "Launch GUI".

4. Ensure that all host interface accessible parameters are configured appropriately and then step through various essential checks (see Running Essential Checks).

5. Once the essential checks are satisfactory, continue to run further MATLAB utilities and commands using the GUI and start debugging/exploring options of interest.



Chapter 4

Hardware Design

The Debug interface hardware design is based on a simple memory mapped interface. The memory map decoder is defined in hardware design files and the simple processor access API is provided for the MATLAB framework.

Memory Map DescriptionThe Debug_interface.vhd file includes the memory map implementation. The memory map provides 32 bit address space and 32 bit read and write data bus.

The DPD v4.0's host interface access is mapped onto this memory map at the lowest address and then a control register is provided to allow the MATLAB software to take/release control of the host interface access. The MATLAB software can read from this memory map to obtain debug wrapper vhdl file's version string and to track who has access to the host interface. Higher memory mapped addresses are forwarded to the top level for a user expandable memory map. Example user extensions can be - write control registers/memory and read status registers for various other blocks - CFR, pre and post gain, reloadable filter taps, etc.

Table 4-1 describes the memory map address allocation.


Figure 4-1: Simplified Hardware Design Framework

PC: MATLAB

DPDHost i/f

User i/fpregain

postgaincapture memory

Dotted areas – user extension examples

AddrDecoder

Mux

HW cosim

jtag controlleduser address space

User access bus

UserLogic

Jtag HW Co-Sim

User Design

debug_interfacedpd_debug_wrapper

srx

UserLogic



Chapter 4: Hardware Design

Wrapper Interface DescriptionThe Debug Interface wrapper extends the DPD v4.0 netlist interface with additional extensible memory mapped connection ports. All the ports common to the DPD v4.0 netlist should be used as described in DPD Data Sheet v4.0, ds811. Additional ports provided with this wrapper have a prefix "jtag_". These are described in Table 4-2 and in JTAG Interface, page 26.

Table 4-1: Memory Map Addresses for write and read access

Starting Address Ending Address Description

0x00000000 0x000001FF DPD's host interface control via MATLAB

0x00000200 0x07FFFFFF reserved

0x08000000 0x08000000

Write: Bit(0) = 0 (release control) 1(MATLAB takes control), bit(31-1) = don't care

Read: bit(31) = access control switch status 0 (user has control over host interface) 1(MATLAB controls host interface), bit(29:0) - Debug Interface version string

0x08000001 0x0FFFFFFF reserved

0x10000000 0xFFFFFFFFUser expandable memory map for user code control via MATLAB.



Wrapper Interface Description

Input/Output PortsX-Ref Target - Figure 4-2

Figure 4-2: Wrapper Port Symbol Diagram

Table 4-2: Top-level I/Os for the DPD IP Core

Port Name Direction Width Notes

clk In 1 Refer to DPD Data Sheet v4.0, ds811

rst In 1 Refer to DPD Data Sheet, v4.0, ds811

proc_clk In 1 Refer to DPD Data Sheet, v4.0, ds811

proc_rst In 1 Refer to DPD Data Sheet, v4.0, ds811

accel_clk In 1 Refer to DPD Data Sheet, v4.0, ds811

ce_clr In 1 Refer to DPD Data Sheet, v4.0, ds811

ceN_out Out 1 Refer to DPD Data Sheet, v4.0, ds811

din_i In 16*TX Refer to DPD Data Sheet, v4.0, ds811

din_q In 16*TX Refer to DPD Data Sheet, v4.0, ds811

dout_i Out 16*TX Refer to DPD Data Sheet, v4.0, ds811

dout_q Out 16*TX Refer to DPD Data Sheet, v4.0, ds811

capture_sync In 1 Refer to DPD Data Sheet, v4.0, ds811

UG776_06_093010

clk

rst

proc_clk

proc_rst

accel_clk

ceN_out

din_i

din_q

srx_din0

srx_din1

dout_i

dout_q

capture_sync

jtag_clk

jtag_dout

srx_path_sel

ce_clr

jtag_addr

Jtag_din

jtag_we




InterfacesRefer to the DPD Data Sheet, v4.0, ds811 for interfaces common to DPD v4.0. The new interface is the extensible memory mapped interface using jtag_clk.

JTAG Interface

It is recommended that the jtag_clk clock input be driven by same clock source which provides the host_interface_clk clock and be in the 25-50 MHz frequency range. The user extensible memory map is a simple memory map with a 32 bit address with a single bit write enable signal. Absence of write is treated as a read operation and hence it is expected that normal connection of jtag_dout be always treated as such and have valid data from those address locations.

srx_din0 In 16 Refer to DPD Data Sheet, v4.0, ds811

srx_din1 In 16

srx_path_sel Out 1/2/3 Refer to DPD Data Sheet, v4.0, ds811

gp_input In 32 Refer to DPD Data Sheet, v4.0, ds811

gp_output Out 32 Refer to DPD Data Sheet, v4.0, ds811.

host_interface_clk In 1 Refer to DPD Data Sheet, v4.0, ds811

host_interface_we In 1 Refer to DPD Data Sheet, v4.0, ds811

host_interface_din In 32 Refer to DPD Data Sheet, v4.0, ds811.

host_interface_addr In 9 Refer to DPD Data Sheet, v4.0, ds811

host_interface_dout Out 32 Refer to DPD Data Sheet, v4.0, ds811.

jtag_clk In 1 Provide clock to drive jtag address decoder logic

jtag_we Out 1 Write Enable to control memory mapped logic for user extended memory mapped space

jtag_din Out 32 Input data written by jtag interface, available to get memory mapped content.

jtag_addr Out 9 Address to drive memory mapping logic for various control/status registers in user logic.

jtag_dout In 32 Data read back by jtag interface to read user extended memory mapped locations.

Table 4-2: Top-level I/Os for the DPD IP Core (Cont’d)

Port Name Direction Width Notes



Wrapper Interface Description

Write Operations:

Write operations from JTAG interface are standard with jtag_we, jtag_din and jtag_addr being synchronous to each other.

Read Operations:

During read operations, jtag_addr and jtag_we are synchronous and valid read values on jtag_dout will be present one jtag_clk clock cycle later, after the read address is posted on the jtag_addr port. JTAG Hardware Co-simulation framework has a single instruction engine and assumes either read or write operation (so read during write is not permitted and a separate read instruction is needed from the MATLAB software script). Hence it is not necessary to maintain accurate values on the jtag_dout port one clock cycle after jtag_we is high.

Example User Extensions to Memory MapWrite and read pages can be created within the large address space and then allocated based on functionality. Consider a simple example of a gain control block on the complex signal data path. pre_gain is 16 bit control registers for two channels, which are written to when the MATLAB software writes to its address location. This pre_gain value is used on multiple I and Q data paths. The following is an example of code:

-- Control Register Write Page-- can't use jtag_addr(31 downto 28) = X"0" in this file since it is used within -- debug_interface

control_we <= jtag_we when jtag_addr(31 downto 28) = X"1" else '0';

control_reg_decoder: process (jtag_clk) begin

if jtag_clk'event and jtag_clk = '1' thenif control_we = '1' then

case jtag_addr(7 downto 0) iswhen X"00" => control_register <= jtag_din; when X"08" => led <= jtag_din(7 downto 0);when X"15" => pre_gain(0) <= jtag_din(15 downto 0);-antenna 0's common I/Q gainwhen X"16" => pre_gain(1) <= jtag_din(15 downto 0);-antenna 1's common I/Q gainwhen others => null;

end case; end if;

-- can't use =X"0" since it is used within debug_interface


Figure 4-3: JTAG user extensible memory map timing diagram




case jtag_addr(31 downto 28) is when X"A" => jtag_dout <= VERSION_TXT; -- For example some 32-bit version stringwhen X"F" => jtag_dout <= host_interface_dout;when others => jtag_dout <= X"facedeed"; -- constant bits to cover rest of the

undefined casesend case;

end if;end process;

-- Gain Control block will use the pre_gain(0) and pre_gain(1) to -- multiply the two antenna's I/Q paths-- and generate output which is appropriately rounded off.

Using HDL Files

Generate DPD using CORE Generator 12.3

Use the CORE Generator 12.3 tool and generate a DPD netlist for your configuration. The details about this can be obtained from "Core Instantiation and Configuration" section in the DPD Data Sheet, v4.0, ds811.

Generate Wrapper VHDL Files

Run wrapper generation perl script by providing link to the .vho file generated by CORE Generator and pointing to the vht - vhdl template file.

:> perl create_wrapper.pl Usage: perl create_wrapper.pl <vht_file> <vho_file>Usage: perl create_wrapper.pl ../vhdl/dpd_debug_wrapper.vht ../dpd_netlist/dpd_netlist_name.vho


Figure 4-4: HDL File Usage Flowchart

Use create_wrapper.pl to generate debug interface

wrapper vhdl file

Add wrapper and debug interface module vhdl to

design project

Add dpd netlist directory and “netlist” subdirectory in

this debug interface unzipped area to ngdbuild

options for blackbox search

Translate using ngdbuild and ensure ucf has timing

constraints for jtag_clk

Map to Xilinx FPGA using map tool

Place and Route the design

Run Static timing analysis and ensure no timing

violations

Generate dpd using coregen 12.3

Create bit file using bitgen

Synthesize Design



Using Pre-canned BIT Files

The script generates a wrapper to match the netlist configuration and a component declaration vhdl package file to aid in the instantiation process.

Instantiate Wrapper File

Refer to the dpd_debug_wrapper.vhd file and instantiate this entity in your code, instead of instantiating the DPD netlist. Various I/Os on this entity are described in Input/Output Ports. The component declaration package file dpd_debug_wrapper_comp.vhd can be referred in your vhdl code at the top of the file along with other library references as follows:

• library work;

• use work.dpd_debug_wrapper_comp.all;

Add HDL Files to Project

Once the wrapper entity is instantiated, add the following files to the project, before synthesizing it:

• dpd_debug_wrapper.vhd (generated earlier)

• dpd_debug_wrapper_comp.vhd (generated earlier)

• debug_interface.vhd (provided in the zip file)

Synthesize and Translate

Synthesize the source with either XST 12.3 or any other third party synthesis tool that supports Xilinx devices. Ensure that Translate's search option has reference to the DPD netlist directory and the "netlist" subdirectory of the zip file which contains submodules for JTAG hardware co-simulation. When using the ML605 [Ref 7], associated documentation includes I/O placement constraints in an example .ucf file. This can be used as a starting point and timing and other placement constraints can be added.

Generating Bitfile

The design can then be processed through the rest of the FPGA design tool using Map, Place and Route, Static Timing Analysis and Bitstream generation to obtain the bitfile to load on the selected board. Once the bitfile is created, the bitfile should be loaded using the user loading process for that board and bring the board out of reset (see Debugging Mode).

Using Pre-canned BIT FilesPre-canned BIT files are provided to help learn about DPD's static and dynamic configurations. When the ML605 board is selected and the "Load Bit file" option on the Board Setup GUI is then selected, one of the basic pre-canned BIT files can be selected. These BIT files are provided in the fpga_images subdirectory of the zip file. These BIT files have a simplified design as shown in Figure 4-5.




Four streams of multiplexed complex data (with CFR applied) are loaded and streamed in a loop. The four streams are interpolated and provided to the first four channel inputs of DPD. If a BIT file with DPD set up for lesser channels is selected, a subset of streams is used. If a BIT file with 8 channels support in DPD is selected, the four streams are replicated on channels 5 to 8 (channel 5 has the same data as channel 1). A single digital RF and PA data path is modeled and is multiplexed across 8 channels. The data being loaded is randomly generated and shaped to imitate WCDMA, LTE and TD-SCDMA waveforms.


Figure 4-5: Design in Pre-canned BIT Files

CFR applied

data storage @

75MHz

LOAD DATA

DPDN channels

DPD control

Quad Mod Error

PA ModelMUX

Srx path control

LOAD GAIN

Multi-channel Gain + DUC



Chapter 5

Using the Debug Interface

The Debug interface GUIs are accessed in the MATLAB™ software by typing start_debug_interface at the MATLAB software command prompt. This launches the Board Setup GUI, described in the following section.

Board Setup

Board configuration is required in the left column before connecting to the board. The parameters are described in the following list.

• Board: Select ML605 or Custom board for non-ML605 boards.

• JTAG Chain and Boundary Scan Position: This tool requires some information about the FPGA board's JTAG chain to be able to program the FPGA. The required information is described in Table 5-1.


Figure 5-1: Board Setup GUI



Chapter 5: Using the Debug Interface

If devices in the board's boundary scan chain are not known, iMPACT or Chipscope™ Analyzer can be used to find this information. Both these tools are included with the Xilinx ISE® software. When iMPACT is invoked, it automatically detects the contents of your board's boundary scan chain when the board is locally connected, and displays these contents graphically, as shown in Figure 5-2.

When Chipscope Analyzer is invoked, it also automatically detects the contents of your board's boundary scan chain when the board is locally connected, and displays these

Table 5-1: Required JTAG chain information

Informationa

a. When the selected board is ML605, the tool already has this information.

Description

Instruction register lengths Instruction registers length of every device in the Boundary Scan Chain.

Device position in the Boundary Scan Chain

Tells the position of the target FPGA in the board's Boundary Scan Chain. Indexing begins at 1, with device 1 being the first device in the chain.


Figure 5-2: iMPACT Screenshot After a Successful Boundary Scan



Board Setup

contents graphically, as shown in Figure 5-3. A pop-up information table also provides the IR Length for various devices in the chain.

• Cable Type: For a successful connection, the tool needs to know which JTAG cable is used to connect a PC to the board. This tool supports USB and Parallel-IV cable types.

• Cable Port: When a USB JTAG cable is used, the tool allows up to four cable ports to allow multiple boards to be connected to the machine and be able to select one of them from the GUI. The identifiers are allocated to the physical USB ports in the order they are connected up with cables and powered on. Use iMPACT or Chipscope Analyzer to identify the required USB port on the board. If only one board is connected, 'USB21' option should be selected.

• Cable Location: The tool supports a remote JTAG cable connection via the CSE (ChipScope Engine) server (which is also being used with iMPACT software and ChipScope™ Pro software). This allows hardware co-simulation to be run over a JTAG cable that is connected to a board in a remote location. If the Cable Location is set to Local, a local JTAG cable is used. If the Cable Location is set to Remote, specify a CSE server, in form of a host name or an IP address, followed by an optional port number:

<host name or IP address> [ :<port number> ]

• Starting the CSE Server: Before clicking on the connect button, start the CSE server on the remote machine that connects to the target board with a JTAG cable. The CSE server can be started by simply running the CSE server executable located in the ISE installation:


Figure 5-3: Chipscope Analyzer Screenshot After Successful Boundary Scan




Windows 32-bit: <ISE_tree>\bin\nt\cse_server.exe

Windows 64-bit: <ISE_tree>\bin\nt64\cse_server.exe

Linux 32-bit: <ISE_tree>/bin/lin/cse_server

Linux 64-bit: <ISE_tree>/bin/lin64/cse_server

cse_server starts a CSE server with the default port number.

cse_server -port <port number> starts a CSE server with the given port number.

• Load Bitfile - When using the ML605 board, pre-canned bitfiles can be loaded on the board and the DPD features can be evaluated. To do this, the Load Bitfile checkbox should be checked and then the ‘connect’ button should be selected. A file browser pop up allows you to select one of the pre-canned bitfiles (see Figure 5-4). If one of the pre-canned bitfiles has already been loaded, the Load Bitfile checkbox can be left unchecked; simply select ‘connect’. If a custom bitfile is used, leave the Load Bitfile checkbox unchecked and load the custom bitfile using the iMPACT tool or other means. When "Custom" board is selected, this checkbox is disabled and you can only connect to the BIT file which has been pre-loaded on the board.For a local board connected via USB JTAG and when the fastest Cable Speed is selected in the GUI, it may take up to 20 seconds to load the bitfile. For remote boards, it may take more than a minute to load, depending upon the network and cable connection quality and speed.

Verify DPD ConfigurationOnce a JTAG hardware co-simulation connection is established with the Debug Interface in hardware, the DPD configuration is read from memory mapped locations (when Host Interface control is allowed) and reported on the Board Setup GUI as in Figure 5-5.


Figure 5-4: Selection of Pre-canned Bitfile



Configuring the DPD Parameters

This DPD configuration information should be checked with the original DPD instantiation used in the custom bitfile. If a pre-canned bitfile is used, the bitfile name indicates the DPD configuration. All the clocks used by DPD should be defined in MHz. For pre-canned bitfiles, this information is auto-populated.

Configuring the DPD ParametersThe first step when using the Debug Interface is to verify and/or set all of the parameters available in DPD. On the GUI, step through each of the major parameter sets; to change a parameter, type in the required value. Parameters such as SAMPLES2PROCESS, ARCH_SEL and METERLENGTH have parameter error checking built into the embedded software. When these parameters are set incorrectly the value is displayed in red and should be cleared before moving forward (to clear, set a valid value).


Figure 5-5: DPD Configuration Read from Hardware (highlighted)





Configuration states may be saved, loaded or refreshed using the button bar. When saved, the current state of the GUI is also saved which allows a known configuration to be loaded and avoids having to go through the various parameter setting steps.

Running Essential ChecksAfter the configuration has been set, the GUI runs a set of prerequisite tests on each available port. These tests are designed to ensure that, once passed, basic DPD operation is achieved. If a tests fails the test button is displayed in red, but this does not prevent you from continuing further testing. However, you should understand the cause of the failed test before moving forward.


Figure 5-6: DPD configuration panel



DPD Command Execution

• Test Power Meters is a simple check of the both transmit and receive power levels on each available port. The real time monitors are first enabled during this test. It is assumed that these tests are performed at the maximum power configuration of the system and show an error when any power is < -30dBFS or > -12dBFS.

• To clear a test error you should ensure the transmit signals are present at the expected level and that the receive port select is operational.

• Check PAPR estimates the PAPR of the signal on each port while DPD is off. The headroom available for DPD to expand the waveform is estimated using the PAPR and the transmit power level. These tests will error if there is less than 4dB of headroom available.

• To clear a test error you can reduce the PAPR of the waveform using CFR or reduce the transmit power level.

• Test Alignment attempts to perform the signal alignment routine on each port.

• To clear a test error follow the procedure described in Debugging the ALIGN_FAILURE error.

• Test Pre-Distortion performs a single iteration of DPD (using Least Squares (LS) updates) on each port. If successful the estimated peak expansion and update time is reported.

DPD Command ExecutionOnce all of the pre-requisite tests have been performed you have full access to the DPD commands as well as the advanced scripting environment. This feature also allows Xilinx support to supply customized scripts to help with specific issue resolution. A list of the advanced scripts that are supplied along with description of what they do is detailed in Chapter 8.


Figure 5-8: Essential Checks




The DPD commands are displayed under their feature heading in the command list. The commands supplied here are those that do not require user intervention to complete. The more complex commands can be executed using the scripting environment or are built into the GUI (e.g. reading the capture RAMs, reading coefficients or setting configurations).

Moreover, an advanced scripting environment is provided which is a user extensible feature that enables you to create your own script files and have the results displayed on the GUI (see Chapter 8).

Real Time MonitorsThe real time monitors display the values described in Table 12 of the DPD Data Sheet v4.0, ds811. These are the power meters for each of the transmit ports (dBFS), the power meter for the single SRX port (dBFS) and the run time (days:hours:minutes:seconds). Additionally, the CODEPOINTER(11) is displayed in real time.


Figure 5-9: Scripts and DPD Command Execution


Figure 5-10: Real Time Monitoring



DCL Monitors

The monitor displays the power for all available ports and the receive power is displayed under the currently active port. The active port may be manually changed using the port select drop down box.

DCL MonitorsDynamic Control Layer (DCL) is the mechanism by which Digital Pre-Distortion (DPD) adapts to power dynamics encountered in a cell due to call load, reconfiguration or other factors. While operating in DCL mode, the DPD core is unable to react to any external command (other than EXIT_DCL). In this mode, DPD continuously pushes various monitors into the host interface.

When one of the DCL modes is executed, the top panel of the GUI changes into a DCL monitor where you can easily observe and log the results to a file.

The only accepted command in this mode is EXIT_DCL. Once DCL has exited, the GUI converts back to the original display where the DPD core can respond to all available commands.

Reading the Log FilesWhen logging of the DCL monitor is enabled, three files are created:

<user_file_name>.log is an ascii log file containing the DCL monitor data.

<user_file_name>_rt.log is an ASCII log file containing the real time monitor data.

<user_file_name>_cfg.mat is a MATLAB file containing configuration data that is needed for parsing the log files.


Figure 5-11: DCL Monitor GUI




These log files may be read back into MATLAB using the read_dcl_monitor_log driver.

[dcl_diag, rt_diag] = read_dcl_monitor_log(<user_file_name>,port_number,show);

These diagnostics can be analyzed to track DPD performance during the logging period. An example can be seen by setting 'show' to a figure number. This example plots the measured transmit power level for the selected port against the coefficient set points. Figure 5-12 and Figure 5-13 show the monitoring of port 0 and 2 of a four port installation. In this example the transmit powers are modulated with a sinewave (different frequencies on each port).X-Ref Target - Figure 5-12

Figure 5-12: Logged DSL Monitor for Single Set Mode



DCL Monitors

All of the DCL monitor values and the real time monitor values are logged to a file and are available for post-processing analysis.

Additional DCL MonitorsThe DCL monitors described in the DPD Data Sheet v4.0, ds811, Table 14 have been expanded to include the following sets:


Figure 5-13: Logged DCL Monitor for Multi-Set Mode

Table 5-2: DCL Monitor Expansion

Address Mnemonic Description

384 + 32*k P_SET_0The average transmitted power during the last update of the first coefficient set. This set is used in both single set and multi-set DCL modes.

385 + 32*k P_SET_1The average transmitted power during the last update of the second coefficient set. This set is used only with multi-set DCL modes.

386 + 32*k P_SET_2The average transmitted power during the last update of the third coefficient set. This set is used only with multi-set DCL modes.

391+ 32*k TX_POWERThe average transmitted power during the last DCL processing for each port. This power is used by DCL to decide whether to update any of the coefficient sets.

406+ 32*k RX_POWER The average received power during the last DCL processing for each port.



Chapter 6

Supplied Commands

The Debug Interface is shipped with a number of predefined scripts that can be used for debugging and also to help understand the DPD commands. The scripts are supplied as open m-files that can be used as a basis for creating your own custom scripts.

capture_and_alignThe capture_and_align script is used to view the transmit and receive samples after going through the alignment process. This script executes the following commands in sequence:

1. Captures new samples using the CAPTURE_SAMPLES command.

2. Aligns the samples using the dpd_debug_run_alignment.p driver. (This feature is currently undocumented in the DPD Data Sheet, v4.0, ds811 and is provided here due to its value in debugging.)

3. Reads the capture RAM data using GET_CAPTURE_RAM_CONTENTS command and formats both transmit and receive samples into I/Q format.

4. Plots the results.

a. In Figure 6-1, the upper figure shows the envelope of the transmit and receive samples which should lay right on top each other.

b. The lower left figure shows the envelope of the transmit samples versus the envelope of the receive samples; this gives a visual representation of the AM/AM transfer curve of the system being pre-distorted.

c. The lower right figure shows the I/Q trajectory plots for both the transmit and receive samples.



Chapter 6: Supplied Commands


Figure 6-1: capture_and_align



capture_swap_rx_and_align

capture_swap_rx_and_alignThe capture_swap_rx_and_align script is used to help debug performance issues caused by having the srx_din ports swapped in hardware without having to rebuild the hardware. You can use this script to visualize the transmit and receive samples after going through the alignment process with the srx_din ports swapped. This script executes the following commands in sequence:

1. Captures new samples using the CAPTURE_SAMPLES command.

2. Reads the capture RAM data using GET_CAPTURE_RAM_CONTENTS command and formats both transmit and receive samples.

3. Changes the order of receive samples to emulate swapping the srx_din ports and writes back into the capture RAM, using the dpd_debug_write_capture_data.p driver. (This feature is currently undocumented in the DPD Data Sheet, v4.0, ds811 and is provided here due to its value in debugging.)


5. Reads the capture RAM data using GET_CAPTURE_RAM_CONTENTS command and format both transmit and receive samples into I/Q format.


a. The top figure shows the envelope of the transmit and receive samples which should right on top each other.

b. The bottom left figure shows the envelope of the transmit samples vs. the envelope of the receive samples, this gives a visual representation of the AM/AM transfer curve of the system being pre-distorted.

c. The bottom right figure show the I/Q trajectory plots for both the transmit and receive samples.

An example of this issue is shown in the following figures. In this example, the alignment routine is executed on the same input data twice. The first time is with the srx_din ports correctly connected and the second time is with the srx_din ports swapped. Both outputs achieve what appears to be reasonable signal alignment (only slightly more smearing of the AM/AM curve in the second case), but good ACLR correction is achieved only when the ports are correctly connected (see Figure 6-4).

Figure 6-2 shows the results of the alignment routine when processed when the srx_din ports are correctly connected (good ACLR performance) and Figure 6-3 are the results with the ports incorrectly connected (poor ACLR performance).





Figure 6-2: capture_swap_rx_and_align - correctly connected portsX-Ref Target - Figure 6-3

Figure 6-3: capture_swap_rx_and_align - incorrectly connected ports



capture_swap_rx_and_align


Figure 6-4: Adjacent Channel Leakage Ratio Results




load_samples_and_alignThe load_samples_and_align script can be used to help debug performance issues possibly without having a direct connection to the hardware. For instance, you could gather a set of samples from the lab and debug it on a desktop using an ML605. Using this script you can load samples saved in an ASCII file and visualize the transmit and receive samples after going through the alignment process (optionally with the srx_din ports swapped). This script executes the following commands in sequence:

1. Browses and selects file containing the raw capture RAM samples. The file must be a single column ASCII file containing the raw 32-bit capture RAM values in hex format (see Collecting Raw Capture RAM Samples for an example of how to collect the samples in the required file format).

2. Optionally changes the order of receive samples to emulate swapping the srx_din ports and writes back into the capture RAM, using the dpd_debug_write_capture_data.p driver. (This feature is currently undocumented in the DPD Data Sheet, v4.0, ds811 and is provided here due to its value in debugging.)


4. Reads the capture RAM data using the GET_CAPTURE_RAM_CONTENTS command and formats both transmit and receive samples into I/Q format.


Collecting Raw Capture RAM SamplesThis is an example, using C style coding, of how to collect all of the capture RAM contents in its raw 32-bit format. When writing the results to a text file use the hexadecimal format.

// create storage for capture RAM contentunsigned int capture_ram[8192];fid = fopen('capture_samples.dat','w');

// loop over the pagesfor (pagenum = 0; pagenum < 64; pagenum++) {

// set CONTROLMODEREGISTER to GET_CAPTURE_RAM_PAGE Host_Interface[1] = 4;

// set PAGENUMBER to the required page Host_Interface[122] = pagenum;

// write trigger value to CONTROLMODETRIGGER register Host_Interface[0] = 0xABCDEF12;

// wait while COMMAND_IN_PROGRESS value is in the COMMANDSTATUS register while(Host_Interface[8] == 1);

// reset the trigger Host_Interface[0] = 0;

// copy samples out of Host_Interface For (k = 0; k < 128; k++){ // read raw 32 bit value capture_ram[pagenum*128 + k] = Host_Interface[384 + k]; fprintf(fid, '%x\n', Host_Interface[384 + k]); }}



compute_capture_frequency_response

compute_capture_frequency_responseThe compute_capture_frequency_response script is used to view the frequency response of the transmit and receive samples in the capture RAM. This script executes the following commands in sequence:

1. (optionally) Captures new samples using the CAPTURE_SAMPLES command.

2. Reads the capture RAM data using GET_CAPTURE_RAM_CONTENTS command and format both transmit and receive samples.

3. Plots the results.X-Ref Target - Figure 6-5

Figure 6-5: compute_capture_frequency_response




compute_ccdfThe compute_ccdf script is used to view the computed Complementary Cumulative Distribution Function (CCDF) of the transmit samples. This script executes the following commands in sequence:

1. Reads the full histogram using the dpd_utilities_read_full_histogram driver.

2. Computes the CCDF from the histogram values.


Figure 6-6: compute_CCDF



read_full_histogram

read_full_histogramThe read_full_histogram script is used to view the histogram of the transmit samples. This script is used by the compute_CCDF script and is used to validate the distribution of the signal at the input of DPD is as expected (for example, is the CFR doing what is expected prior to DPD).This script executes the following commands in sequence:

1. Reads the full histogram using the GET_HISTOGRAM command.


Figure 6-7: read_full_histogram




read_capture_measurementsThe read_capture_measurement script is used to view the histogram and power of the captured transmit samples. This script can be used to help select the best sample delay for capture mode 1. This script executes the following commands in sequence:

1. (optionally) Captures new samples using the CAPTURE_SAMPLES command.

2. Reads the capture histogram using the GET_CAPTURE_HISTOGRAM command.

3. Reads the capture powers using the READ_CAPTURE_POWER command.


Figure 6-8: read_capture_measurement



read_coefficients

read_coefficientsThe read_coefficients script is used to read one of the three raw coefficients from DPD. While the format of the coefficient set is not disclosed, you may want to have access to the coefficients sets (typically to load a known good set at system startup). This script along with the load_coefficients script shows how to accomplish this task. This script executes the following commands in sequence:

1. Requests which set to read.

2. Reads coefficient from DPD using the REPORT_COEFFICIENTS command.


4. Optionally saves the coefficients to file.X-Ref Target - Figure 6-9

Figure 6-9: read_coefficients




load_coefficientsThe load_coefficients script is used to load coefficients into one of the three coefficient sets in DPD. While the format of the coefficient set is not disclosed, you may wish to have access to the coefficients sets (typically to load a known good set at system startup). This script along with the read_coefficients script shows how to accomplish this task. This script executes the following commands in sequence:

1. Selects file containing the coefficient set.

2. Requests which set to write to.

3. Loads coefficient from the file into DPD using the LOAD_COEFFICIENTS command (file should be generated using the read_coefficients command).

4. Reads back coefficients.


Figure 6-10: load_coefficients



xilinx_support_data

xilinx_support_dataThe xilinx_support_data script is used to collect a predefined set of diagnostics prior to contacting Xilinx support. The predefined data is gathered and then you will be prompted to save this data to a .mat file. Please have this file available before contacting Xilinx support.

Control Mode (commands)Table 6-1 shows the control modes that are directly available via the GUIs command list. The Control Modes are annotated using the mnemonic followed by the actual Control Mode Number in square brackets.

Table 6-1: Control Modes (Commands) Supported in GUI

Control Modes Description

ECF Commands

FULL_UPDATE[2] See DPD Data Sheet, v4.0, ds811

DAMPED_UPDATE[33] See DPD Data Sheet, v4.0, ds811

COEF Commands

RESET_COEFFICIENTS[3] See DPD Data Sheet, v4.0, ds811

DPD_OFF[7] See DPD Data Sheet, v4.0, ds811

DPD_ON[8] See DPD Data Sheet, v4.0, ds811

DPD_ON1[9] Update the data path from the internally stored coefficients (set 2 of multi-mode sets).

DPD_ON2[10] Update the data path from the internally stored coefficients (set 3 of multi-mode sets)

DCL Commands

RUN_DCL[14] See DPD Data Sheet, v4.0, ds811

EXIT_DCL[18] See DPD Data Sheet, v4.0, ds811

RUN_DCL_WITH_QMC[23] See DPD Data Sheet, v4.0, ds811

RUN_DCL_WITH_QMC_NORMAL[27] See DPD Data Sheet, v4.0, ds811

RESET_DCL[36] See DPD Data Sheet, v4.0, ds811

QMC Commands

QMC_RESET[21] See DPD Data Sheet, v4.0, ds811

QMC_SINGLE_STEP[22] See DPD Data Sheet, v4.0, ds811

QMC_ON[24] See DPD Data Sheet, v4.0, ds811

QMC_OFF[25] See DPD Data Sheet, v4.0, ds811

GEN Commands

READ_CONFIGURATION[1] Update the Host Interface with the DPD parameters.




RESTORE_DEFAULTS[19] See DPD Data Sheet, v4.0, ds811

CAPTURE_SAMPLES[20] See DPD Data Sheet, v4.0, ds811

Table 6-1: Control Modes (Commands) Supported in GUI (Cont’d)

Control Modes Description



Chapter 7

Debugging Guidance

This section shows you the steps to perform to clear status errors that may occur while using DPD.

Error CodesTable 7-1 shows the error codes that may occur during the operation of DPD. Also shown are the suggested steps to achieve resolution.

Table 7-1: DPD Error Codes

Value Mnemonic Description Resolution

-511 EVAL_LICENSE_TIMEOUT The evaluation license has timed out.

Reset the hardware to reset the evaluation timeout timer or purchase a license.

-126 CONFIG_FAILURE_L The number of samples to process is outside the valid range.

See SAMPLES2PROCESS in Table 11 of the DPD Data Sheet, v4.0, ds811 to see valid parameter range.

-125 CONFIG_FAILURE_DELAY The minimum delay is greater than the maximum delay requested.

See MINMAX_DELAY_ADJ in Table 11 of the DPD Data Sheet, v4.0, ds811 to see valid parameter range.

-124 CONFIG_METER_LENGTH The meter length is out of the valid range.

See METERLENGTH in Table 11 of the DPD Data Sheet, v4.0, ds811 to see valid parameter range.

-123 CONFIG_FAILURE_ARCH Invalid architecture selection

See ARCH_SEL in Table 11 of the DPD Data Sheet, v4.0, ds811 to see valid parameter range.

-121 CONFIG_FAILURE_DELAY_WIN_SIZE

The maximum delay search size is too big.

See MINMAX_DELAY_ADJ in Table 11 of the DPD Data Sheet, v4.0, ds811 to see valid parameter range.

-120 ALIGN_FAILURE Signal alignment failure

See Debugging the ALIGN_FAILURE error



Chapter 7: Debugging Guidance

-119 COEF_OVERFLOW Internal coefficient overflow

Collect data using the xilinx_support_data driver and contact Xilinx support.

-115 LEASTSQUARES_FAILURE A numerical issue was encountered during coefficient estimation.

Collect data using the xilinx_support_data driver and contact Xilinx support.

-114 SCA_FAILURE Failure to capture a statistically sufficient set of samples.

See Debugging the CAPTURE_FAILURE and SCA_FAILURE errors, page 62. Collect data using the xilinx_support_data driver and contact Xilinx support.

-113 CAPTURE_FAILURE Failure to capture new samples

See Debugging the CAPTURE_FAILURE and SCA_FAILURE errors, page 62. Collect data using the xilinx_support_data driver and contact Xilinx support.

-112 INVALID_PORT Invalid port was selected.

Read the PORTNUM register and ensure it is within the supported range.

-111 HISTOGRAM_FAILURE Histogram failure Collect data using the xilinx_support_data driver and contact Xilinx support.

-1 INVALID_COMMAND An invalid command was requested.

Read back the CONTROLMODEREGISTER and ensure a valid command was sent. If the CONTROLMODEREGISTER looks correct then read the EXECUTEDCOMMAND register and ensure it's the same as CONTROLMODEREGISTER. If these registers are different then there is likely a timing issue between the host interface and the MicroBlaze™.

Table 7-1: DPD Error Codes (Cont’d)

Value Mnemonic Description Resolution



Debugging the ALIGN_FAILURE error

Debugging the ALIGN_FAILURE errorThe debugging process for the ALIGN_FAILURE error code depends on the format of the receive input (RXINPUTFORMAT[107]). The ALIGN_FAILURE indicates that the signal alignment routine failed to achieve a good correlation between the transmit samples and the receive samples. This message is most often encountered during the initial system integration/configuration and is typically not seen during normal operation.

The alignment process goes through the following steps before indicating the ALIGN_FAILURE message.

1. (Optional) down conversion using the RXPHASESTEP parameter. This step converts the real receive inputs (either fs or 2fs sampled) into the baseband I/Q samples. This step is skipped when RXINPUTFORMAT[107] = 1 (IQ).

2. Gain alignment routine. This step adjusts the RMS value of both the transmit and receive samples to the same value.

3. Integer delay adjustment. This step searches for the best correlation between the transmit and receive samples over the range of samples defined by the MINMAX_DELAY_ADJ parameter.

The best correlation found during this step is compared against a threshold to determine whether a SUCCESSFUL or ALIGN_FAILURE message should be returned.

When the ALIGN_FAILURE is returned no further processing occurs. This prevents any DPD updates from possibly causing damage to the Power Amplifier (PA). If ALIGN_FAILURE occurs, follow the steps shown below to try and clear the message.

1. Read the transmit and receive power meters and ensure that the signals are present.

2. Use the READ_CONFIGURATION command (or the refresh button in the GUI) and ensure the ECF parameters are as expected. If not, re-send the UPDATE_ECF_PARAMETERS and ensure that the response to this command in the COMMANDSTATUS register is SUCCESSFUL.

Specifically ensure the RXPHASESTEP, RXINPUTFORMAT and MINMAX_DELAY_ADJ are correct.

3. For a multi-port installation, ensure that the srx path selection is correct. Try turning off all but one transmitter.

4. Test with spectral inversion on and off.

a. RXINPUTFORMAT[107] = 0 (2fs)

i. Test with spectral inversion on and off.

ii. 2fs has an interesting condition where when the srx_din0 and srx_din1 ports are incorrectly connected (i.e. when the early sample is applied to srx_din1 and the late sample is applied to srx_din0) an incorrect spectral inversion setting can cause the signal alignment routine to pass. However, the spectral correction achieved by DPD will be much less an expected. Pay careful attention to both the ordering of the samples applied to the srx_din0 and srx_din1 port along with the spectral inversion setting.

iii. A special utility has been supplied that allows you to test swapping the srx_din_x ports without having to re-build the hardware (see capture_swap_rx_and_align).

b. RXINPUTFORMAT[107] = 1 (IQ)




Test with spectral inversion on and off. In I/Q mode changing the spectral inversion parameter is the same as swapping the srx_din0 and srx_din1 ports.

c. RXINPUTFORMAT[107] = 2 (fs)

Test with spectral inversion on and off.

5. Ensure RXPHASESTEP is set correctly.

6. Adjust the minimum and maximum search delay. In most installations, the default value for the MINMAX_DELAY_ADJ parameter works. However, if your installation has a large digital delay (hundreds of samples) between the DPD transmit output and the DPD receive input then the MINMAX_DELAY_ADJ may need to be increased.



Debugging the ALIGN_FAILURE error

ALIGN_FAILURE Error Debug FlowchartX-Ref Target - Figure 7-1

Figure 7-1: ALIGN_FAILURE Error Debug Flowchart

Ensure Tx and Rx power is in valid

operational range

Ensure parameters:

MINMAX_DELAY_ADJ RXINPUTFORMAT

RXPHASESTEPSPECTRALINVERSION

Are set as expected.

Verify Rx port select is

operational and selecting the correct port

Mult-port installation

Swap srx_dinsChange spectral

inversion

Change spectral inversion

Change spectral inversion

Ensure RXPHASESTEP is set correctly

RXINPUTFORMAT

yes

no

I/Q

2fs fs

Expand search window usingMINMAX_DEL

AY_ADJ

Gather data and contract Xilinx support




Debugging the CAPTURE_FAILURE and SCA_FAILURE errorsThe process used by DPD for capturing new samples is detailed in the flow chart shown in Figure 7-2. This chart may be used to trace back from either the SCA_FAILURE or CAPTURE_FAILURE error to determine the potential causes.X-Ref Target - Figure 7-2

Figure 7-2: SCA and CAPTURE process flowchart



Chapter 8

Writing an Advanced Script

After a connection to the image under test has been established using the Board Setup GUI, two global variables are placed in memory that may be used in conjunction with the supplied drivers to write custom scripts in MATLAB to communicate with the DPD core. These scripts may be written such that they are accessible in the GUI (see Adding Utility Scripts to the GUI) or they can be used in a standard MATLAB scripting environment. The two global variables are the HWC_HANDLE and the DPD_MEMORY_MAP.

The HWC_HANDLE variable is the hardware co-simulation (hwc) token that is used with the drivers supplied in the jtag_drivers directory (for more information type 'help jtag_drivers' on the MATLAB command line). The primary drivers that are used while scripting are:

The DPD_MEMORY_MAP variable is a MATLAB structure that is used to define the available DPD commands and the host interface and it contains all of the relevant information about DPD that is defined in the DPD data sheet, v4.0, ds811. The content of the structure is:

DPD_MEMORY_MAP top level field

Description

hwc_readblock read a block of data from the FPGA using the hwc token

hwc_readword read a sample of data from the FPGA using the hwc token

hwc_writeblock write a block of data to the FPGA using the hwc token

hwc_writeword write a sample of data to the FPGA using the hwc token

DPD_MEMORY_MAP top level field

Description

commands Defines the available DPD commands and it's associated mode number

commands_loc Defines where in the GUI the commands will be displayed

host Defines the various register locations of the host interface

host_bases Defines the base address for certain regions in the host interface

suffix Defines the suffix used for multi-port definitions

help Defines the various help text string that are display in the GUI

status_values Defines the status values returned by DPD



Chapter 8: Writing an Advanced Script

The DPD_MEMORY_MAP, when used along with the drivers supplied under dpd_drivers (for more information type help dpd_drivers on the MATLAB command line) create a powerful scripting environment for monitoring and controlling all aspects of DPD operation. There are a number of open m-file scripts available in the dpd_drivers directory that can be used to understand how the drivers may be used (notably the dpd_utilities_*.m file or the read_capture_ram_example.m which shows how to perform the function described in Collecting Raw Capture RAM Samples).

Adding Utility Scripts to the GUIAny function located in the .\dpd_drivers directory with the naming prefix of "dpd_utilities_" is accessible via the GUI. The signature of the function must follow this general format:

outputs=dpd_utilities_<display_name>(h, varargin)

The GUI passes in the handle to the HWC token as the first argument (h) followed by a variable number of value pairs (e.g. arg_name, arg_value). The value pairs currently passed by the GUI are shown in Table 8-1.

These value pairs may be extracted using the following function call:

[show, freq, dont_save, configuration] = get_value_pairs(varargin);

The GUI saves the first output of the function call to the variable utility_out in the base workspace.

Plotting to GUI AxesThe handles to seven predefined axes are passed into the function as an array. The script may plot to any combination of these axes; however care should be taken to ensure the script does not utilize overlapping axes (e.g. axes 1 should be used alone while axes 3 could be used with axes 2 or axes 4 and 5 etc.).

Table 8-1: Value Pairs Passed by the GUI

Variable passed from GUI Notes

clk Sample rate clock define in the GUI in MHz

axes Array defining the axes handles available in the GUI (see Plotting to GUI Axes)

dont_save Not used by the GUI at this time, always set to 1.

configuration Various configuration data collected regarding the build.


Figure 8-1: GUI Axes Handles



Appendix A

Abbreviations

3G Third Generation

3GPP Third Generation Partnership Project

ACP Adjacent Channel Power

ACLR Adjacent Carrier Leakage Ratio

ADC Analog-to-Digital Converter

BTS Base Transceiver Station

BUFG Global Buffer (Xilinx FPGA component)

CAPEX Capital Expenditure

CDRSX Common Digital Radio System – Xilinx Edition

CFR Crest Factor Reduction

CMP Configured Maximum Power

CPICH Common Pilot Channel

DAC Digital-to-Analog Converter

dB decibel

dBc dB relative to carrier

dBm dB relative to one milliwatt

dBFS dB relative to digital full-scale

DCH Dedicated Transport Channel

DCL Dynamic Control Layer

DCM Digital Clock Manager (Xilinx FPGA component)

DPCH Dedicated Physical Channel

DPD Digital Pre-Distortion

DUC Digital Up Conversion

ECF Estimation Core Function

FCC Federal Communications Commission

FIFO First In, First Out

FIR Finite Impulse Response

HSDPA High Speed Downlink Packet Access

ISR Interrupt Service Routine

LDMOS Laterally Diffused Metal Oxide Silicon (Field Effect Transistor)

LMB Local Memory Bus

LO Local Oscillator




LTE Long Term Evolution

LUT Lookup Table

MCP Maximum Capacity Power

Msps Mega-samples per second

MIMO Multiple Input Multiple Output

MP Memory-Polynomial

NSNL Non-Static Non-Linearity

ODD Over-Drive Detection

ODP Over-Drive Protection

OPEX Operational Expenditure

PA Power Amplifier

PAR Peak-to-Average Ratio

PLB Peripheral Local Bus

QAM Quadrature Amplitude Modulation

QM Quadrature Modulator

QMC Quadrature Modulator Correction

QSNL Quasi-Static Non-Linearity

PAR Peak-to-Average Ratio

RMS Root Mean Square

RRC Root-Raised Cosine

SA Spectrum Analyzer

SBRAM Shared Block RAM

SCA Sample Capture Acceptance

SRx Sample Receiver

TDD Time Division Duplex

TD-SCDMA Time Division Synchronous Code Division Multiple Access

TM1 Test Model 1 (and similarly TM2, and so on)

WCDMA Wideband Code Division Multiple Access

WiMAX Worldwide Interoperability for Microwave Access


LogiCORE IP Digital Pre-Distortion v4.0 Debug Interface · DPD v4.0 Debug Interface 11 UG776 (v1.0)...

Documents

Transcript of LogiCORE IP Digital Pre-Distortion v4.0 Debug Interface · DPD v4.0 Debug Interface 11 UG776 (v1.0)...