logicore ip digital pre-distortion v4.0 debug interface · dpd v4.0 debug interface 11 ug776 (v1.0)...
TRANSCRIPT
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.
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
DPD v4.0 Debug Interface www.xilinx.com 7UG776 (v1.0) November 23, 2010
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
8 www.xilinx.com DPD v4.0 Debug InterfaceUG776 (v1.0) November 23, 2010
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
DPD v4.0 Debug Interface www.xilinx.com 9UG776 (v1.0) November 23, 2010
Chapter 1: Introduction
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
Appendix A: Abbreviations
Schedule of Tables
10 www.xilinx.com DPD v4.0 Debug InterfaceUG776 (v1.0) November 23, 2010
DPD v4.0 Debug Interface www.xilinx.com 11UG776 (v1.0) November 23, 2010
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.
12 www.xilinx.com DPD v4.0 Debug InterfaceUG776 (v1.0) November 23, 2010
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
DPD v4.0 Debug Interface www.xilinx.com 13UG776 (v1.0) November 23, 2010
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;
14 www.xilinx.com DPD v4.0 Debug InterfaceUG776 (v1.0) November 23, 2010
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.
Convention Meaning or Use Example
Convention Meaning or Use Example
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.
DPD v4.0 Debug Interface www.xilinx.com 15UG776 (v1.0) November 23, 2010
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
16 www.xilinx.com DPD v4.0 Debug InterfaceUG776 (v1.0) November 23, 2010
Chapter 1: Introduction
DPD v4.0 Debug Interface www.xilinx.com 17UG776 (v1.0) November 23, 2010
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
18 www.xilinx.com DPD v4.0 Debug InterfaceUG776 (v1.0) November 23, 2010
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
X-Ref Target - Figure 2-3
Figure 2-2: Main GUI
1 23
5
4
6
DPD v4.0 Debug Interface www.xilinx.com 19UG776 (v1.0) November 23, 2010
X-Ref Target - Figure 2-3
Figure 2-3: DCL Monitor GUI
7
20 www.xilinx.com DPD v4.0 Debug InterfaceUG776 (v1.0) November 23, 2010
Chapter 2: Overview
DPD v4.0 Debug Interface www.xilinx.com 21UG776 (v1.0) November 23, 2010
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
22 www.xilinx.com DPD v4.0 Debug InterfaceUG776 (v1.0) November 23, 2010
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.
DPD v4.0 Debug Interface www.xilinx.com 23UG776 (v1.0) November 23, 2010
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.
X-Ref Target - Figure 4-1
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
24 www.xilinx.com DPD v4.0 Debug InterfaceUG776 (v1.0) November 23, 2010
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.
DPD v4.0 Debug Interface www.xilinx.com 25UG776 (v1.0) November 23, 2010
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
26 www.xilinx.com DPD v4.0 Debug InterfaceUG776 (v1.0) November 23, 2010
Chapter 4: Hardware Design
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
DPD v4.0 Debug Interface www.xilinx.com 27UG776 (v1.0) November 23, 2010
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
X-Ref Target - Figure 4-3
Figure 4-3: JTAG user extensible memory map timing diagram
28 www.xilinx.com DPD v4.0 Debug InterfaceUG776 (v1.0) November 23, 2010
Chapter 4: Hardware Design
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
X-Ref Target - Figure 4-4
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
DPD v4.0 Debug Interface www.xilinx.com 29UG776 (v1.0) November 23, 2010
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.
30 www.xilinx.com DPD v4.0 Debug InterfaceUG776 (v1.0) November 23, 2010
Chapter 4: Hardware Design
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.
X-Ref Target - Figure 4-5
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
DPD v4.0 Debug Interface www.xilinx.com 31UG776 (v1.0) November 23, 2010
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.
X-Ref Target - Figure 5-1
Figure 5-1: Board Setup GUI
32 www.xilinx.com DPD v4.0 Debug InterfaceUG776 (v1.0) November 23, 2010
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.
X-Ref Target - Figure 5-2
Figure 5-2: iMPACT Screenshot After a Successful Boundary Scan
DPD v4.0 Debug Interface www.xilinx.com 33UG776 (v1.0) November 23, 2010
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:
X-Ref Target - Figure 5-3
Figure 5-3: Chipscope Analyzer Screenshot After Successful Boundary Scan
34 www.xilinx.com DPD v4.0 Debug InterfaceUG776 (v1.0) November 23, 2010
Chapter 5: Using the Debug Interface
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.
X-Ref Target - Figure 5-4
Figure 5-4: Selection of Pre-canned Bitfile
DPD v4.0 Debug Interface www.xilinx.com 35UG776 (v1.0) November 23, 2010
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).
X-Ref Target - Figure 5-5
Figure 5-5: DPD Configuration Read from Hardware (highlighted)
36 www.xilinx.com DPD v4.0 Debug InterfaceUG776 (v1.0) November 23, 2010
Chapter 5: Using the Debug Interface
X-Ref Target - Figure 5-7
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.
X-Ref Target - Figure 5-6
Figure 5-6: DPD configuration panel
DPD v4.0 Debug Interface www.xilinx.com 37UG776 (v1.0) November 23, 2010
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.
X-Ref Target - Figure 5-8
Figure 5-8: Essential Checks
38 www.xilinx.com DPD v4.0 Debug InterfaceUG776 (v1.0) November 23, 2010
Chapter 5: Using the Debug Interface
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.
X-Ref Target - Figure 5-9
Figure 5-9: Scripts and DPD Command Execution
X-Ref Target - Figure 5-10
Figure 5-10: Real Time Monitoring
DPD v4.0 Debug Interface www.xilinx.com 39UG776 (v1.0) November 23, 2010
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.
X-Ref Target - Figure 5-11
Figure 5-11: DCL Monitor GUI
40 www.xilinx.com DPD v4.0 Debug InterfaceUG776 (v1.0) November 23, 2010
Chapter 5: Using the Debug Interface
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
DPD v4.0 Debug Interface www.xilinx.com 41UG776 (v1.0) November 23, 2010
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:
X-Ref Target - Figure 5-13
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.
42 www.xilinx.com DPD v4.0 Debug InterfaceUG776 (v1.0) November 23, 2010
Chapter 5: Using the Debug Interface
DPD v4.0 Debug Interface www.xilinx.com 43UG776 (v1.0) November 23, 2010
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.
44 www.xilinx.com DPD v4.0 Debug InterfaceUG776 (v1.0) November 23, 2010
Chapter 6: Supplied Commands
X-Ref Target - Figure 6-1
Figure 6-1: capture_and_align
DPD v4.0 Debug Interface www.xilinx.com 45UG776 (v1.0) November 23, 2010
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.)
4. 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.)
5. Reads the capture RAM data using GET_CAPTURE_RAM_CONTENTS command and format both transmit and receive samples into I/Q format.
6. Plots the results.
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).
46 www.xilinx.com DPD v4.0 Debug InterfaceUG776 (v1.0) November 23, 2010
Chapter 6: Supplied Commands
X-Ref Target - Figure 6-2
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
DPD v4.0 Debug Interface www.xilinx.com 47UG776 (v1.0) November 23, 2010
capture_swap_rx_and_align
X-Ref Target - Figure 6-4
Figure 6-4: Adjacent Channel Leakage Ratio Results
48 www.xilinx.com DPD v4.0 Debug InterfaceUG776 (v1.0) November 23, 2010
Chapter 6: Supplied Commands
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.)
3. 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.)
4. Reads the capture RAM data using the GET_CAPTURE_RAM_CONTENTS command and formats both transmit and receive samples into I/Q format.
5. Plots the results.
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]); }}
DPD v4.0 Debug Interface www.xilinx.com 49UG776 (v1.0) November 23, 2010
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
50 www.xilinx.com DPD v4.0 Debug InterfaceUG776 (v1.0) November 23, 2010
Chapter 6: Supplied Commands
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.
3. Plots the results.X-Ref Target - Figure 6-6
Figure 6-6: compute_CCDF
DPD v4.0 Debug Interface www.xilinx.com 51UG776 (v1.0) November 23, 2010
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.
2. Plots the results.X-Ref Target - Figure 6-7
Figure 6-7: read_full_histogram
52 www.xilinx.com DPD v4.0 Debug InterfaceUG776 (v1.0) November 23, 2010
Chapter 6: Supplied Commands
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.
4. Plots the results.X-Ref Target - Figure 6-8
Figure 6-8: read_capture_measurement
DPD v4.0 Debug Interface www.xilinx.com 53UG776 (v1.0) November 23, 2010
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.
3. Plots the results.
4. Optionally saves the coefficients to file.X-Ref Target - Figure 6-9
Figure 6-9: read_coefficients
54 www.xilinx.com DPD v4.0 Debug InterfaceUG776 (v1.0) November 23, 2010
Chapter 6: Supplied Commands
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.
5. Plots the results.X-Ref Target - Figure 6-10
Figure 6-10: load_coefficients
DPD v4.0 Debug Interface www.xilinx.com 55UG776 (v1.0) November 23, 2010
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.
56 www.xilinx.com DPD v4.0 Debug InterfaceUG776 (v1.0) November 23, 2010
Chapter 6: Supplied Commands
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
DPD v4.0 Debug Interface www.xilinx.com 57UG776 (v1.0) November 23, 2010
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
58 www.xilinx.com DPD v4.0 Debug InterfaceUG776 (v1.0) November 23, 2010
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
DPD v4.0 Debug Interface www.xilinx.com 59UG776 (v1.0) November 23, 2010
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)
60 www.xilinx.com DPD v4.0 Debug InterfaceUG776 (v1.0) November 23, 2010
Chapter 7: Debugging Guidance
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.
DPD v4.0 Debug Interface www.xilinx.com 61UG776 (v1.0) November 23, 2010
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
62 www.xilinx.com DPD v4.0 Debug InterfaceUG776 (v1.0) November 23, 2010
Chapter 7: Debugging Guidance
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
DPD v4.0 Debug Interface www.xilinx.com 63UG776 (v1.0) November 23, 2010
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
64 www.xilinx.com DPD v4.0 Debug InterfaceUG776 (v1.0) November 23, 2010
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.
X-Ref Target - Figure 8-1
Figure 8-1: GUI Axes Handles
DPD v4.0 Debug Interface www.xilinx.com 65UG776 (v1.0) November 23, 2010
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
66 www.xilinx.com DPD v4.0 Debug InterfaceUG776 (v1.0) November 23, 2010
Appendix A: Abbreviations
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