IWR6843: Channel-interleaved raw ADC data

HI, there:

Please check the data format on figure 11 under https://www.ti.com/lit/an/swra581b/swra581b.pdf

I believe you are looking for complex data, right?   The interleaved mode in this document is mentioned for xWR1443 and xWR1243 only, where the system has 4 channel LVDS lane.  But XWR1642/1843/6843, only 2 LVDS lane is provided,  So, I doubt even you program the driver to save data in interleaved mode, the data process and LVDS transfer part will act accordingly.    The data in the memory can be different than the format that transferred through LVDS.  

Best,

Zigang

Yes, this is about complex data. I also am not interested in the data processing code on the TI device, so it is not an issue if it does not support interleaved ADC data (which it doesn't).

As far as I know, the non-interleaved data in the adcbuf memory is stored as

rx0_sample0_real

rx0_sample0_imag

rx0_sample1_real

rx0_sample1_imag

rx0_sample2_real

rx0_sample2_imag

rx0_sample3_real

rx0_sample3_imag

...

and the output on LVDS is (as figure 11 in your link shows) is:

data lane 0 | rx0_sample0_real   | rx0_sample1_real  | rx0_sample2_real   | rx0_sample3_real   | ...

data lane 1 | rx0_sample0_imag | rx0_sample1_imag | rx0_sample2_imag | rx0_sample3_imag | ...

So if I program the adcbuf to interleaved mode it should write ADC data in memory as:

rx0_sample0_real

rx0_sample0_imag

rx1_sample0_real

rx1_sample0_imag

rx2_sample0_real

rx2_sample0_imag

rx3_sample0_real

rx3_sample0_imag

...

The output on LVDS should then be:

data lane 0 | rx0_sample0_real   | rx1_sample0_real  | rx2_sample0_real   | rx3_sample0_real   | ...

data lane 1 | rx0_sample0_imag | rx1_sample0_imag | rx2_sample0_imag | rx3_sample0_imag | ...

Is this correct? As far as I can see the CBUFF driver code does not know how the samples are stored in memory when it sets up the transfer, it just points to the start of the adcbuf memory.

And is it correct to assume that the BSS on IWR6843 does support writing data to memory in interleaved mode?

HI, 

This is not document any where.  I will have to ask the expert on this.  Will get back to you soon.  

Best,

Zigang

HI, 

Here is the feedback from the design team: 

---------------------

. If customer is only doing LVDS data shipment, then they could use either interleaved or non-interleaved – with the caveat that they need to modify the driver to enable the interleaved mode (simple change) and silicon team hasn’t verified it (and hence SDK team hasn’t verified it either).

----------------------

Regarding the data format from LVDS lane, here is the feedback from the design team: 

----------------------

How the data shows up on the lanes depends on CFG_LVDS_MAPPING_LANEx_FMTy registers in CBUFF. SDK CBUFF driver hard codes to use Format 0 and 68xx has only 2 lanes – so values in CFG_LVDS_MAPPING_LANE0_FMT_0 and CFG_LVDS_MAPPING_LANE1_FMT_0 register determine what is sent on which lane.

Looking at CBUFF_openLVDS() function in the driver, CBUFF_LANES2_COMPLEX_FMT0 is what is used to config the above registers and decoding that:

Lane 0: 5410

Lane1: 7632

i.e.:

data lane 0 | rx0_sample0_real   | rx0_sample0_imag  | rx2_sample0_real   | rx2_sample0_imag   | ...

data lane 1 | rx1_sample0_real | rx1_sample0_imag | rx3_sample0_real | rx3_sample0_imag | ...

-------------------------

Let me know whether it makes sense to you.

Best,

Zigang

Hi,

This makes sense and matches the behavior I am seeing, thank you for the detailed response. Since the data I'm reading looks OK the interleave functionality seems to work. Is there any way you could consider adding it to the silicon verification process for future xwr68xx devices?