WARP Project Forums - Wireless Open-Access Research Platform

The interpolation and decimation filters must adapt your PHY Tx/Rx rates to the DAC/ADC interface rates. Your design controls all these parameters. The interpolation/decimation rates depend on how you configure the rest of the system. The AD9963 ADC/DAC chip has on-board filters (see the WARP v3 user guide for details) that can implement part of your overall rate change. In general running the ADC/DAC faster is better. In the 802.11 ref design we run the ADCs and DACs at 40MSps and the 2x decimation and 2x interpolation filters to realize a 20MSps Tx and Rx interface at the FPGA.

DAC_CLK = 20MHz
ADC_CLK = 20MHz

For ADC/DAC clk of 20MHz it would be better to set the REF_CLK to 20MHz by adjusting the divider in the sampling clock buffer. The default configuration sets the divider to 2 (see wlan_phy_util.c) for a 40MHz REF_CLK.

For a DAC_CLK of 20MHz and interpolation by 8x in the AD9963 the FPGA-DAC data rate would be 2.5MHz. This brings you back to the same challenge of generating a 2.5MHz clock in the FPGA discussed in post #18 above. However, if you move part of the interpolation to the FPGA the DAC-FPGA data rate would be higher. For example, if you use a DAC_CLK of 20MHz and 2x interpolation in the AD9963, the DAC-FPGA interface would run at 10MHz. You could then implement 4x interpolation between the Tx PHY outputs and w3_ad_bridge inputs to realize 2.5MHz bandwidth.

For ADC_CLK of 20MHz and decimation by 2x in the AD9963 the ADC-FPGA interface would run at 10MHz. You would then need a 4x decimation filter in the FPGA between the w3_ad_bridge outputs and AGC/PHY inputs to realize 2.5MHz bandwidth.

The signal at w3_ad_bridge.sys_samp_clk_Tx and w3_ad_bridge.sys_samp_clk_Tx_90 must be stable clocks with 50% duty cycle running at the same rate as the FPGA->DAC digital interface. These clock signals should be generated by a single MMCM to assure the 90-degree phase relationship.

The Tx PHY DAC_TX_CLK signal is used as a clock-enable in the PHY pipeline. This does not need to be a 50%-duty-cycle clock. You can replace this input with a pulse using an upsampled, zero-inserted '1' constant like the AGC Rx IQ valid.

If you add an interpolation filter between the PHY and w3_ad_bridge, the frequency of the sys_samp_clk_Tx ports and the Tx PHY DAC_TX_CLK signal will differ by the interpolation rate.

murphpo wrote:

I don't believe the MMCM can generate a 2.5MHz clock. The only options I can think of:
-Build a small HDL pcore which wraps a BUFR instance. The BUFR can be configured to divide its input clock by [1:8]. Each BUFR can drive clocks in the same and adjacent regions as the buffer. You might need multiple BUFR instances to reach all the logic connected to the sample clock.

Dear murphpo,

Could you explain this option more in detail?

Thanks,

Alice

Last edited by alice_warp (2015-Dec-17 08:12:21)

Interesting. I've never run a simulation with MMCM_ADV and BUFG instances. I'm not sure if their simulation models match the clocking circuits in hardware. In the ref designs the only use of the LOCKED signal is to drive the reset logic in the proc_sys_reset block. The proc_sys_reset releases its output resets some time after LOCKED asserts and all reset inputs de-assert. If the delay from LOCKED to actual clocks in your sim also occurs in hardware, it is probably still fine given the reset logic design.

These are the images.

(1)


(2)


(3)


(4)


(1) Putty screen CPU Low. It seems good, but don't print anything (I insert a xil_printf in frame_receive function).
(2) Transmission channel bandwidth is good (so DAC is properly configured).
(3) Packet duration (time) with 2.5 MHz settings (about 0.4x10^4)
(4) Packet duration (time) with 10 MHz settings. It is possible to see that the duration @10MHz and @2.5MHz are similar...

Thank you in advance,

Alice

Sorry, I missed your BUFR post above. Do the BUFR outputs drive only the w3_ad_bridge.sys_samp_clk ports? If so I can't see how a startup delay on these clocks would break anything as these ports only drive clock inputs on IOB registers.

They drive the w3_ad_bridge.sys_samp_clk ports and the dac_tx_clk in wlan_phy_tx.

These images are interesting. The duration of the Tx waveform is controlled by the Tx PHY. Do you have an oscilloscope? It would be helpful to see the Tx PHY's actual "Tx Active" signal relative to the RF waveform durations you're observing. The Tx Active signal is driven to the debug header (pin 0 in the current design).

No, I haven't, but I can have it as soon as possible.

Do you expect the transmissions to be so densely packed in the 2.5MHz mode image (3) above? Were these packets generated by a backlogged broadcast traffic flow? What waveform duration did you expect (i.e. what is the rate/length of the packet)?

Yes, I expect something like this. I tried to do traffic iperf unicast to other WARP (the client's display turns to 1, but the server's display remains to 0; I don't know the reason, but I tried to do the same thing with the Reference Design v.1.3 and it has the same behaviour; but this is other strange thing). So one WARP can do traffic with 6Mbps rate and 1470 byte of length of the packets. I expected a waveform duration about 15000us.

Edit: I noticed that if I set the DAC @10MHz, I can receive beacon @10MHz. I have the impression that BUFR doesn't work. I'll try to understand the reason.

Last edited by alice_warp (2015-Dec-21 05:27:18)