We have a custom modem PCB with Zynq 7Z020 and AD9364 in production, 2000 units deployed so far and going well.
For the past one year everything is fine using our 'old' software, which was;
- using ADI 'no-OS' driver on one Zynq ARM core (with FreeRTOS)
- not using the ADI reference HDL in the PL (we used our own custom RTL in the PL for the Zynq<=>AD LVDS interface)
- so we defined AXI_ADC_NOT_PRESENT in config.h when building 'no-OS' driver
- 'no-OS' driver code we used was downloaded from ADI git on 05/06/2016 master branch, as at git commit cfabefc
Recently, I thought there will be some advantages to making 'new' software, which means;
- in zynq PS, move 'no-OS' driver forward to a later and more formal release (2016_R2)
- in Zynq PL, replace our custom RTL with the ADI axi_ad9361 IP core (also 2016_R2)
- so now we are using matching release of C and Verilog code from ADI; newer ADI C code than before, and using ADI Verilog code for the first time
The main advantage we sought was the auto-tuning of the digital interface timing between Zynq/AD during run-time initialisation; and the support in ADI RTL for the PN sequences generated by the AD9364 [in our old code, we just used fixed values for the rx/tx clock/data delays (for all boards, for all temperatures)
After moving the software forward, now we see an issue which is that, on only some of our modem boards, the transmit and receive spectrum is inverted.
That is;
- with our old software, on board A and board B, tx RF spectrum (and rx digital baseband) is always the same inversion sense, and always what we expect (ie correct)
- with the newer software, on board A the tx/rx spectrum inversion outcome is always correct (even over many power cycles), and on board B the tx/rx spectrum is always wrong (opposite) (even over many power cycles).
On board B, even when the tx RF spectrum (and rx digital baseband) is inverted, a digital loopback from Zynq=>AD(digital baseband loopback)=>Zynq still works
[And Zynq=>AD=>RF signal => AD =>Zynq also works, all on board B]
But we need Board A => RF => Board B to work and vice versa (not just work when talking to themselves ). For higher order modulations (>=QPSK) if one board has the wrong spectrum inversion sense in effect, this board to 'different board' link fails (BPSK is OK, as expected spectral inversion has no effect on decoded data for BPSK).
I suspect either;
a) somehow we have an I/Q swap on the Zynq<=>AD interface in both Zynq=>AD and AD=>Zynq directions (but somehow only occurring on some of our boards!), or
b) somehow the newer ADI 'no-OS' driver initialises the AD chip differently in a way that somehow the AD chip now behaves differently (wrt spectrum inversion) on different boards...
We are deciding whether the spectrum inversion is correct or not by transmitting (or receiving) QPSK from (or to) the 'board under test' to (or from) a reference modem (not by some detailed chipscope analysis of signals inside the Zynq - we haven't got to that debug point yet!). It seems very clear though it is a spectrum inversion issue => eg on board B with new software, if we negate Q (invert the spectrum deliberately ourselves in our own baseband RTL), the link has no errors. If we don't negate Q, the link SNR (as estimated by receiving modem) is the same but we have 100% errors (incorrect demapping of symbols to bits).
The axi_ad9361 core we are using (for first time) is configured in 1T1R mode, and for both tx/rx we have the datapath enabled (for the PN testing support), but with the data formatting and IQ corrections disabled (to save the PL utilisation)). [We fill the 12 MSB of the 16-bit samples accepted by the ADI core in tx path with exactly the 12-bits we want to go through to the AD chip. We take the 12 LSB of the 16-bit samples produced by the core in the rx path; and assume these are exactly the 12-bit samples the core got from the AD chip].
I guess before this initial post becomes too long... I am just looking for initial advice;
- anyone ever seen unpredictable spectrum inversion results before? (that appear to be varying between different hardware, but appear to be consistent on each hardware unit)
- anyone know of anything in ADI C or RTL code which has changed over the last year, that might affect the spectrum inversion outcome on a given bit of hardware
- anyone can think of any way an I/Q swap could occur on the Zynq<=>AD interface in a way that the axi_ad9361 RTL code and the 'no-OS' interface tuning code could not detect ?
- any way I/Q could be somehow swapped inside the AD chip in a way undetectable by the BIST/loopbacks ? (eg I/Q swapped on the digital path that is the entry/exit point to/from the tx/rx FIR filters ?
- any particular further information I can share that is useful ?
Many thanks!
