Hi Rob, Yes it is possible. All of these modifications require editing the core FPGA code and UHD. Removing the DmaFIFO is not too difficult. Althought it can be done, I would not suggest modifying the Eth or PCIe interfaces.
Jonathon On Tue, Apr 9, 2019 at 6:35 AM Rob Kossler <[email protected]> wrote: > Hi Jonathon, > Is it possible to increase the 10 available to 13 by: > - building an HG image that only needs one 10GigE > - excluding the DmaFIFO (assuming underruns not an issue w/o this block) > - building without PCIe support (is this even possible?) > > Rob > > > On Thu, Apr 4, 2019 at 10:12 AM Jonathon Pendlum via USRP-users < > [email protected]> wrote: > >> Hi, >> >> On the X310, the crossbar is limited to 16 ports. Of the 16 ports, only >> 10 are available because the other 6 are already occupied: 2x 10GigE, 1x >> PCIe, 2x Radio Core RFNoC blocks, 1x DmaFIFO RFNoC block. >> >> Jonathon >> >> On Thu, Apr 4, 2019 at 11:03 PM Jason Matusiak via USRP-users < >> [email protected]> wrote: >> >>> I don't know why this would be, but it almost feels like a hex issue >>> somewhere. Where are you setting the block size to 10? It feels like >>> something is interpreting that as 0x10, and I think 16 is a magic number >>> that is too large. >>> >>> ------------------------------ >>> *From:* USRP-users <[email protected]> on behalf of >>> Armin Schmidt via USRP-users <[email protected]> >>> *Sent:* Thursday, April 4, 2019 4:13 AM >>> *To:* [email protected] >>> *Subject:* [USRP-users] Maximal number of RFNoC-blocks >>> >>> Hallo everyone and Ettus development team, >>> >>> We use uhd 3.14 rc1 and we have the strange behaviour, that after the >>> magic number of 10 RFNoC-blocks on the FPGA, we get the following error: >>> >>> [ERROR] [UHD] Exception caught in safe-call. >>> in ctrl_iface_impl<_endianness>::~ctrl_iface_impl() [with >>> uhd::endianness_t _endianness = (uhd::endianness_t)0u] >>> at /home/gab2/rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:60 >>> this->send_cmd_pkt(0, 0, true); -> EnvironmentError: IOError: Block ctrl >>> (CE_13_Port_00) no response packet - AssertionError: bool(buff) >>> in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double) >>> [with uhd::endianness_t _endianness = (uhd::endianness_t)0u; uint64_t = >>> long unsigned int] >>> at /home/gab2/rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:155 >>> >>> terminate called after throwing an instance of 'uhd::io_error' >>> what(): EnvironmentError: IOError: Block ctrl (CE_00_Port_30) packet >>> parse error - EnvironmentError: IOError: Expected SID: 02:30>00:00 >>> Received SID: 00:12>02:00 >>> Aborted (core dumped) >>> >>> It is not a problem of the FPGA-Capacity and also not a timing issue. So >>> it seems to be somehow a hardcoded limit from ettus. Does someone know how >>> to stretch this limit? So 10 RFNoC-blocks works just fine, but with 12 we >>> get this error! It is also not dependant of the type of blocks, we put on >>> the FPGA. >>> >>> Many thanks for your help! >>> >>> Armin Schmidt >>> _______________________________________________ >>> USRP-users mailing list >>> [email protected] >>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >>> >> _______________________________________________ >> USRP-users mailing list >> [email protected] >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> >
_______________________________________________ USRP-users mailing list [email protected] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
