Hi Wade, Thanks for the info. I still do not know what's going on, but here are a few updates:
- I built a new N310 image with 4 switchboards (1x1) and 1 splitstream (1x2) blocks in addition to the default blocks. All of the additional blocks are connected to SEPs for dynamic linking. I tried my best to get bad behavior using a chain of 1 to 4 switchboards, but I could not duplicate any I/Q swapping or negation issues. - I went back to my custom image (that I described below) and found different behavior today (sometimes things worked OK). So, this got me to thinking that I am somehow getting the FPGA in a bad state such that a reboot (or FPGA re-flashing) fixes things. I have had some success with re-booting and things working properly. But, I still do not have a true handle on things and cannot adequately predict when things are going to succeed or fail. - One thing that has been constant is that I have never seen bad behavior when I only have 1 block in my graph (no matter which block I choose). Note that for all of my tests, the graph looks like this: host_tx => block_chain => host_rx, where block_chain is a sequential chain of 1 or more rfnoc blocks. I will send a follow up once I figure things out. Rob On Fri, Dec 11, 2020 at 6:22 PM Wade Fife <wade.f...@ettus.com> wrote: > Hi Rob, > > The SEPs do have the ability to swap I and Q. This is because on the host > computer, I is usually in the lower bits and Q is in the upper bits of each > 32-bit word, but in RFNoC, for historical reasons, I goes in the upper bits > and Q in the lower bits. The software programs the IQ swapping when it sets > up the graph. > > I assume you're using dynamic connections (through the crossbar) to > control the number of FFTs the data is passed through, and not static > connections? If that's the case then I wonder if software configures IQ > swapping incorrectly in some configurations. I'll see if I can do some > testing next week to confirm if it's working correctly. > > As for negation, I'm not aware of anywhere we do that off the top of my > head. Is that behavior block dependent? I'll see if I can find anywhere > this happens. > > Thanks, > > Wade > > On Thu, Dec 10, 2020 at 3:54 PM Rob Kossler via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Hi, >> I am encountering very strange behavior with a custom FPGA image (N310). >> It appears that data streaming through SEPs can get swapped (I/Q) and/or >> negated. Is anyone at Ettus aware of anything that could cause this? Of >> course, the issue might be on my end, but I can't think of what it might be >> given that all of my custom blocks work as expected in isolation (if the >> block is the only block in graph). >> >> My custom image is the following: >> >> - default blocks of Radios, DDCs, DUCs (each 2x2 and statically >> connected as in default image) >> - custom blocks of two 1x1 windowed-fft blocks, two 1x1 vector-avg >> blocks, and one 2x2 custom block. Note: each of these blocks is connected >> to its own SEP, so I can connect dynamically in any fashion. >> >> My test case is transmitting 8192 random samples from host to FFT block >> and then optionally through a 2nd FFT block before back to host. In the >> test case, the radios/DDCs/DUCs are not used. >> >> Here is what I observed: >> >> - If I only include 1 FFT block in my RFNoC graph, I get the expected >> results (the output from the FPGA matches what I calculate in Matlab for >> the FFT). This is true for either of the two FFT blocks. >> - If I include both FFT blocks in series, I can only match the FPGA >> output if I swap the I/Q values in between my Matlab FFTs. >> - Note: that this issue is not FFT-related as I can also duplicate >> this issue with the other blocks. >> - If I use 3 blocks in series (each through SEP), I need to negate >> certain data in order to get it to match the FPGA output >> >> My next step is likely to build a new image with Ettus-developed FIFOs to >> prove that the data is getting swapped/negated when 2 or more are used in >> series through SEPs. >> >> Let me know if you have any suggestions for other things to try. >> >> Rob >> _______________________________________________ >> USRP-users mailing list >> USRP-users@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
