(Xilinx Answer 42298) Reading of the ODD metric and peak-expansion of each Tx during DCL process has been added.
Bug Fixes
Fixed CR 543208, 552808, 552809
Known Issues
None
DPD Reference Design v3.0New Features
Now supports Virtex-5, Virtex-6, and Spartan-6 devices
Up to 4 antenna/datapath support
Predistortion correction architecture selection for cost-performance trade-off
More control over resource sharing and clock speeds (1 to 4 clocks/input samples)
Support for fs mode for srx inputs
Support for non-fs/4 down conversion for srx inputs
Improved ODD accuracy and stability
Bug Fixes
Fixed CR 541702, 541817
Known Issues
(xilinx answer 35104) CR 552808 - The example UCF file in the zip file has a type error for the timing group name. What is the correct timing group name?
CR 543213 - Change to the internal coefficient scaling routine will have no impact on most installations. It fixes some performance issues observed in extremely rare cases.
Known Issues
None
DPD Reference Design v2.1New Features
None
Bug Fixes
(Xilinx Answer 33449) CR 529627 Why do I see poor performance or diagnostics with Over-Drive Protection (ODP) and damped-Newton updates?
Digital Predistortion IP uses MicroBlaze Processor by utilizing the EDK Import flow offered by System Generator for DSP. However, System Generator for DSP does not support HDL Simulation and "Create Testbench" capability when EDK processor block is used in a design; this is documented in (Xilinx Answer 32331).
When the DPD IP netlist is generated, System Generator incorrectly generates a "vcom.do" file. If a user tries to use it with a ModelSim simulator, it errors out; this is documented in (Xilinx Answer 32321).
As a result, the DPD IP netlist currently does not support HDL Simulation. A user can choose to run a standalone DPD netlist through XST, NGDBuild, and then the NetGen tool, and generate a post-synthesis back-annotated HDL netlist, if they need some HDL simulation support for verifying their code's syntax and connection to the DPD netlist. For more information on back-annotated simulation with a MicroBlaze processor, refer to the Xilinx documentation at: http://www.xilinx.com/support/documentation/index.htm.
In the files generated by System Generator for the DPD design (dpd.mdl), there is a clock forwarding occurring through a black box netlist. In certain conditions, it is likely that users might see two BUFGs (one on xps_clk input or appropriate name in user's code that drives that clock input and the second on sg_splb_clk* signal). This is due to a bug in XST in ISE Design Suite 10.1sp3 and there are various workarounds documented in (Xilinx Answer 32362). The most non-intrusive workaround is used in the build subdirectory of the DPD zip file as follows:
Refer to the "dpd_1/2tx_wrap.xcf" file in the build subdirectory. This file is not documented in the Application Note (XAPP1128C).
It applies an additional attribute to one of the signals to prevent the cascaded BUFGs.
Users should make sure XST reads the xcf file, or merge it into their top level xcf file.
Users should refer to the build subdirectory for an example of how the xcf is used.
If the user migrates to the ISE design tools 11.1, this issue does not occur and the workaround is not necessary, but it can be used for consistency with no side-effects.
XAPP1128 indicates that the srx_din0 and srx_din1 should be parallel input streams for fs/4 real input stream where srx_din0 should contain data at any given time which is an earlier data than the data on srx_din1. However, that is inconsistent with the design and users are advised to ensure that srx_din1 contains data at any given time which is an earlier data than the data on srx_din0.
For example, if the srx_adc_din is the input data from ADC (sampled at 2x the input data rate) and srx_adc_clk is the synchronizing clock from ADC, a simple dual aspect Asynchronous FIFO could be used to create srx_din0 and srx_din1 data streams which are synchronized to DPD IP Core's input clock "clk" and clock enable "ce3_out".
srx_fifo_dmux_inst : srx_fifo_dmux port map ( din => srx_adc_din, -- 16 bit input data from ADCs rd_clk => clk, rd_en => ce3_out, rst => user_reset, -- released only after clk and -- ce3_out are stable wr_clk => srx_adc_clk, wr_en => '1', dout(15 downto 0) => srx_din0, dout(31 downto 16) => srx_din1, empty => open, full => open);
DPD Reference Design v2.0.1 New Features
Support for damped-Newton coefficients updates. When QSNL mode is selected, Damped-Newton updates are available. When the user runs DCL, it will use Least Square estimates and Damped-Newton updates for the new coefficient calculations based on signal dynamics. This feature now also helps reduce the ACLR fluctuations seen during DCL.
Bug Fixes
(Xilinx Answer 33448) CR 531697 Why do I see a fluctuation in the correction performance or when output power is enabled?
CR 517376, DCLUPDATEINPROGRESS_A[490] register never indicates a 1;
CR 511634, The ACLR fluctuations seen during DCL
CR 525726, When a user uses 2Tx design with ENABLE_EXT_RXSEL{28} command, the EXIT_DCL{18} appears to fail.
CR 525727 When a user uses 2Tx design and tries to run EXIT_DCL{18}, DPD IP may take a long time (~10 seconds) to respond.
CR 525728. Virtex-4 FPGA DPD design errors out during net listing only when using System Generator 11.1 tools.
Known Issues
(Xilinx Answer 33449) CR 529627 Why do I see poor performance or diagnostics with Over-Drive Protection (ODP) and damped-Newton updates?