Adapting DAQ Server for SDRLab122-16

[tlpurz]

Hey folks, I am currently trying to use this on the SDRLab122-16 and it works relatively well with a few changes on Vivado (clocks, 16 bit ADC). The issue I have is that 16 bit values works fine until I reach the 14 bit limit, i.e., I can send numbers up to 8192 (I tested this by just wiring a 16 bit constant to the cic_Compiler), but for numbers above that it wraps around. E.g., sending 12000, it sets the first two bits to "11", yielding a negative number. Is there anything on the FPGA/Vivado or C-Code side that I am overlooking that would be forcing this behavior?

Thanks!

[tknopp]

Independent of the issue, it would be great to get your code into our repo.

[tknopp]

@nHackel: I am not 100% sure anymore, but IIRC we somewhere use the upper two bits somewhere for the enable bit?

[tknopp]

But maybe its just: https://github.com/tknopp/RedPitayaDAQServer/blob/e68bedaf93a142abc3810db2eefbbe88ad95d7e7/src/lib/rp-daq-lib.c#L224

[jonschumacher]

First of all I am no completely sure if you are talking about the send or receive side. Send side looks all 16 bit except for the output:

If it is the receive side (which I guess because you mention the CIC compiler), check the AXI stream block:

This part could also be relevant:

Please be also aware of the fact that the decimation can actually get you a higher ENOB than the 16 bit that are available (at least at higher decimations). Switching to 32 bit per channel ist the only feasible option but this would require higher decimations due to the limited bandwidth of the NIC.

[tlpurz]

Hi Tobias and Jonas, thanks for your quick reply. Here's some additional information: I am looking at the receiving side, and I'm not too worried about the ADC being the issue (I did adjust the AXI stream block to 16 bit already and it seems to work fine). I confirmed that the issue is elsewhere by plugging a 16 bit constant directly into the cic_compiler in the write_to_ram block, so whatever my ADC does shouldn't matter if I am not mistaken: I saw the sign_extend blocks but bypassed those, however the effect I am getting is exactly the same, that's why I was wondering whether there is some additional sign_extend function or something along those liens buried either deeper on the firmware/Vivado side or somewhere in the C-Code. The specific C-Code line @tknopp was referencing is on the DAC side I believe, so this should not have an effect. I hope this clarification helps, let me know if you have any additional ideas!

[jonschumacher]

Did you check the FIR compiler? C code looks fine to me.

[tknopp]

Sorry for confusing Send/Receive. Since we handle receive data as 16 bit already, I hope that we can figure this out. @jonschumacher: Very good input! I share your concern regarding the issue that we might need 32 (or maybe 24?) bit due to decimation. But maybe @tlpurz can start with 16 bit support, which seems to be easier to integrate right now. 32/24 bit support is than a little bit more work but doable. I currently think, 24 bit would be quite nice. The client would then of course handle the conversion to a processing friendly format. But before that, I don't see issues with 24 bit.

[tlpurz]

Hey folks, Sorry for the late reply, I got sidetracked with other projects. The FIR Compiler was a good find; however, now, the bottom two bits seem to be missing. I think I need to go through more functions and ensure both the timing with the external clock and the bit numbers are right. I will keep you posted!

[nHackel]

I vaguely remember having this 2-bit cutoff issue when I implemented the FIR together with @jusack. Have you tried setting the output of the FIR compiler to 18 and then taking the upper 16-bits of each path?