Hi Rob, Yup, that should fix the issue.
Jonathon On Thu, Feb 10, 2022 at 4:56 PM Rob Kossler <rkoss...@nd.edu> wrote: > Thanks Jonathon! > This sure seems like a smoking gun. It doesn't seem like this is an > auto-generated file so it seems we could manually modify it to include > ports 2 and 3 in the same fashion as the N310 and then rebuild. Is this > true? > Rob > > On Thu, Feb 10, 2022 at 4:22 PM Jonathon Pendlum < > jonathon.pend...@ettus.com> wrote: > >> 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 >> >> This actually brings up a design suggestion: the Replay Block could have >> it's own internal AXI4 interconnect that scales based on NUM_PORTS. I've >> done this myself in a custom RFNoC block using the Xilinx AXI4 Interconnect >> IP and it worked out well. >> >> Jonathon >> >> On Thu, Feb 10, 2022 at 3:33 PM Wade Fife <wade.f...@ettus.com> wrote: >> >>> I would start by double checking the YAML. For example, make sure the >>> MEM_ADDR_W parameter is correct (for E320 it should be 31, for 2 GiB) and >>> make sure each in/out port is connected the way you want. >>> >>> If you share the YAML with me, I'm happy to take a look to see if >>> anything jumps out at me. >>> >>> Thanks, >>> >>> Wade >>> >>> On Thu, Feb 10, 2022 at 10:34 AM Rob Kossler <rkoss...@nd.edu> wrote: >>> >>>> Thanks Wade, >>>> I am helping Ofer Saferman with an issue with the E320 and a 4-port >>>> replay block. Apart from your response (& Jonathon's response) indicating >>>> that data rates should not be an issue, I have also come to the same >>>> conclusion by trying some tests. After these tests, the issue now seems to >>>> be that Replay ports 0 and 1 work as expected, but Replay ports 2 and 3 do >>>> not. I know that a 4-port Replay block works fine on an N310 because I use >>>> it often. So, I'm wondering why we have this issue on the E320. Perhaps >>>> the E320 yml file is wrong - I am still waiting to take a look at this. I >>>> have also requested that Ofer run the stock example >>>> "rfnoc_replay_samples_from_file" and use the --replay_chan option to prove >>>> that ports 0 and 1 work fine but ports 2 and 3 do not. >>>> >>>> Anyway, if you have any suggestions, I'd love to hear them. >>>> Rob >>>> >>>> >>>> On Thu, Feb 10, 2022 at 11:17 AM Wade Fife <wade.f...@ettus.com> wrote: >>>> >>>>> The E320's DRAM is pretty fast. It should have no problem keeping up >>>>> for your use case. >>>>> >>>>> Wade >>>>> >>>>> On Thu, Feb 10, 2022 at 1:56 AM Jonathon Pendlum < >>>>> jonathon.pend...@ettus.com> wrote: >>>>> >>>>>> Hi Rob, >>>>>> >>>>>> As long as the DRAM can keep up throughput wise, you should be fine >>>>>> in that configuration. I think the E320 has a BIST you can run that >>>>>> reports >>>>>> the throughput. >>>>>> >>>>>> Jonathon >>>>>> >>>>>> On Wed, Feb 9, 2022 at 3:29 PM Rob Kossler <rkoss...@nd.edu> wrote: >>>>>> >>>>>>> Hi, >>>>>>> I am wondering if there are any data rate restrictions for using the >>>>>>> Replay block on the E320. I have a 4-port Replay block for >>>>>>> simultaneously >>>>>>> playing two streams to the 2-port Radio and capturing two streams from >>>>>>> the >>>>>>> 2-port Radio. If the master_clock_rate is equal to the sample rate, >>>>>>> does >>>>>>> this imply that I will have a data throughput issue? >>>>>>> Rob >>>>>>> _______________________________________________ >>>>>>> USRP-users mailing list -- usrp-users@lists.ettus.com >>>>>>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com >>>>>>> >>>>>> _______________________________________________ >>>>>> USRP-users mailing list -- usrp-users@lists.ettus.com >>>>>> To unsubscribe send an email to usrp-users-le...@lists.ettus.com >>>>>> >>>>>
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
