Hello all, Thanks for the combined effort and catching the bug. I will try to fix it manually and make the 4 port replay work. Looking forward for a robust fix from NI which will actually implement ports per the NUM_PORTS parameter in the YML file.
Wade - Can you share your thoughts on how you think a 2-port replay module could both record and play 2 streams simultaneously? I have this on-going debate with Rob. I think it does not work because the direction of what "record" and "play" do is derived from graph connectivity and you can't reconnect the graph while you are already recording or playing. Regards, Ofer Saferman On Fri, Feb 11, 2022 at 12:51 AM Wade Fife <[email protected]> wrote: > Thanks Jonathan for catching that! > > Ofer, I do think you also need to set the MEM_ADDR_W to 31. > > Another thought. I think I mentioned that you should be able to record and > play back at the same time, so I think it's possible to record 2 streams > and play 2 streams simultaneously with a 2-port Replay block. I need to > catch up on this email thread, so apologies if you already ruled that out > as an option. Expanding the AXI interconnect is also a viable option and > might give better DRAM performance. > > I'll see that this gets fixed on E320. > > Thanks, > > Wade > > On Thu, Feb 10, 2022 at 4:27 PM Jonathon Pendlum < > [email protected]> wrote: > >> Hello Ofer, >> >> I also sent this Rob in the other thread: >> >> It looks like the problem is that while there is a 4 port interconnect >> available, only ports 0 and 1 are hooked up: >> https://github.com/EttusResearch/uhd/blob/2c7ce2dbf72414b64f8a477be614e23bc12f086d/fpga/usrp3/top/e320/e320_core.v#L1050 >> . >> >> You could modify e320_core.v to hook up the extra ports as a stopgap >> until it is fixed. >> >> Jonathon >> >> On Thu, Feb 10, 2022 at 5:17 PM Ofer Saferman <[email protected]> wrote: >> >>> Hello Wade, >>> >>> Do you think that this is the reason that ports 2,3 don't work? >>> I can try to rebuild the image and see what happens. I will update. >>> >>> Regards, >>> Ofer Saferman >>> >>> On Thu, Feb 10, 2022 at 10:36 PM Wade Fife <[email protected]> wrote: >>> >>>> Hi Ofer, >>>> >>>> I think MEM_ADDR_W should be 31 for E320. Other than that everything >>>> looks correct. >>>> >>>> Wade >>>> >>>> On Thu, Feb 10, 2022 at 2:20 PM Ofer Saferman <[email protected]> >>>> wrote: >>>> >>>>> Hello, >>>>> >>>>> I am working on a USRP E320 unit using UHD 4.1.0.5. >>>>> I have made an FPGA image containing a radio, a 4-port replay block >>>>> and a NullSrcSink. >>>>> After investigating (with a lot of help from Rob Kossler) why my own >>>>> program doesn't work properly, per his suggestion I have tested >>>>> rfnoc_replay_samples_from_file on the 4 ports of the replay block. >>>>> Ports 0,1 work fine and the example is streaming my data. Ports 2,3 >>>>> get stuck on record and don't work properly. >>>>> Please find attached: >>>>> * 4 console logs, one for each replay port. >>>>> * My YML file with which I created the FPGA image. >>>>> * Console log of uhd_usrp_probe. >>>>> >>>>> Some further notes that might help: >>>>> * I also tried an original FPGA image of the E320 (with DUC, DDC and >>>>> all the static mapping) with the only change being that the replay block >>>>> has 4 ports (and adding 2 more endpoints). The result was the same. >>>>> * I also tried an FPGA image without the NullSrcSink. I added it >>>>> sometime in the debug process and it was just left there. It has no >>>>> bearing >>>>> on the problem. >>>>> >>>>> I would appreciate any assistance to debug the issue and make all >>>>> ports of the replay block work properly. >>>>> >>>>> Regards, >>>>> Ofer Saferman >>>>> >>>>> >>>>> -- >>>>> This message has been scanned for viruses and >>>>> dangerous content by *MailScanner* <http://www.mailscanner.info/>, >>>>> and is >>>>> believed to be clean. _______________________________________________ >>>>> USRP-users mailing list -- [email protected] >>>>> To unsubscribe send an email to [email protected] >>>>> >>>> >>> -- >>> This message has been scanned for viruses and >>> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and >>> is >>> believed to be clean. _______________________________________________ >>> USRP-users mailing list -- [email protected] >>> To unsubscribe send an email to [email protected] >>> >> -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
_______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
