You are not logged in.
Hi, in the 802.11 Reference Design, what is the nominal sampling rate (in MSPS) of the ADCs and DACs? Do you have to interpolate / decimate to support different signal BWs (10 MHz, 20 MHz, and 40 MHz), or do the ADC / DACs change their sampling rate dynamically to support bandwidth scaling?
Thanks for your help.
Offline
We use the interpolation and decimation filters in the AD9963 (the integrated ADC/DAC chip); more details on these capabilities are in the WARP v3 user guide. The v1.5 design does not implement any rate-change filters in the FPGA.
The actual AD9963 configuration happens in wlan_mac_low.c : set_phy_samp_rate(). That function implements:
10MHz mode:
DAC clock: 20MHz
ADC clock: 20MHz
Interpolation: 2x
Decimation: 2x
20MHz mode:
DAC clock: 40MHz
ADC clock: 40MHz
Interpolation: 2x
Decimation: 2x
40MHz mode:
DAC clock: 40MHz
ADC clock: 40MHz
Interpolation: 1x
Decimation: 1x
It looks like the comments in set_phy_samp_rate() are wrong- I'll fix those now. The code matches the descriptions above.
Offline
Hi Patrick, it looks like in the v1.5 802.11 design, the ad_bridge_onBoard core is clocked at 160 MHz (same as wlan_phy_rx_pmd). If we runs the design in 20MHz BW mode, the oversampling factor would be 8x, is that correct?
Now suppose I want to run a portion of the 160MHz wlan_phy_rx_pmd pipeline (e.g., coarse and fine timing sync, CFO correction, and channel estimation) along side of the WARPLab buffer design, which is clocked only at 40 MHz together with its own w3_ad_bridge core, and further assume that the received signal is only 20 MHz BW (but being sampled by the 40 MHz ADC), would the wlan_phy_rx_pmd core still work?
Let me know if this question makes sense. Essentially, I'm gauging the possibility of taking some processing from the 802.11 PHY and put them inside the WARPLab design flow.
Best,
Danh
Last edited by dang2327 (2016-Apr-20 14:36:11)
Offline
The updated ad_bridge pcore uses the 160MHz clock for all its synchronous elements, but the sample registers themselves use the AD9963 TRXCLK as a clock enable. The AD9963 drives the TRXCLK signal at the data rate of the Rx I/Q (ADC clk / decim_rate). The ad_bridge uses the TRXCLK signal as the clock enable on the Tx and Rx I/Q registers and to generate the TXCLK signal driven to the AD9963. Altogether this means the digital sample rate in/out of the FPGA is controlled by the AD9963 ref clock frequency and its rate-change filter settings.
The WARPLab v7.7 design uses the previous ad_bridge core, which uses the TRXCLK signal as an actual clock for the IOB registers, then transfers samples to the FPGA clock domain through DFFs clocked at 40MHz. A future version of WARPLab will adopt the new ad_bridge design with the same support for slower sample rates as the 802.11 v1.5 design.
Offline
Now suppose I want to run a portion of the 160MHz wlan_phy_rx_pmd pipeline (e.g., coarse and fine timing sync, CFO correction, and channel estimation) along side of the WARPLab buffer design, which is clocked only at 40 MHz together with its own w3_ad_bridge core, and further assume that the received signal is only 20 MHz BW (but being sampled by the 40 MHz ADC), would the wlan_phy_rx_pmd core still work?
Something like this could work. The 802.11 v1.5 Rx PHY assumes the system clock (160MHz by default) is 4x the fastest sample rate. This assumption is baked into the LTS correlator which reuses logic 4x per sample. You can drive samples into the Rx pipeline at any rate up to (sysgen_clk/4). The WARPLab Rx pipeline is hard-coded capture samples at the sysgen_clk rate. Feeding both pipelines samples at 40MSps should work fine.
One nitpick- there is one ad_bridge core per pair of RF interfaces. If two "PHY" cores want to use the Rx samples, they should consume the same sample stream output by the interface's single ad_bridge core.
Offline