Re: [USRP-users] FPGA Repository and Stability

On Tue, Sep 4, 2018 at 8:07 AM, Brian Padalino via USRP-users wrote: > Recently there was a significant change to the noc_block_vector_iir > (specifically the vector_iir): > > >

Re: [USRP-users] SFP Transceivers for N310 1/10Gbps Fiber Ethernet

Hi Zhongyuan, >> Does 10Gbps SFP+ transceiver backward compatible with 1Gbps socket? No it's not. Depending on what N310 FPGA image you build/use, the port speeds are locked down. The HG image is 1G on SFP0 and 10G on SFP1 whereas the XG image has 10G on both SFP ports. The transceiver might

Re: [USRP-users] RFNoC FPGA clear_tx_seqnum behavior

Hi EJ, Sorry for the delay here. From the FPGA's perspective if you have something streaming between one set of blocks and then you start streaming a different application on another set of previously unused blocks, then the current clear implementation should still work as long as the new

Re: [USRP-users] RFNoC FPGA clear_tx_seqnum behavior

Hi EJ, On Thu, May 3, 2018 at 5:06 AM, EJ Kreinar wrote: > Hi Ashish, > > Thanks for the info about rfnoc changes. Quick question: > >> In rfnoc, we make a >> distinction between reset and clear. A "reset" is meant to reset >> everything in a module to the power-up state. A

Re: [USRP-users] RFNoC FPGA clear_tx_seqnum behavior

Hi Brian, I finally got a chance to look at that change in a bit more detail. I need to test out this theory out but we may have added a regression with the throttle commit I pointed out earlier. The issue would apply to "sink" blocks only. We assert the clear_tx_seqnum signal when the block is

Re: [USRP-users] RFNoC FPGA clear_tx_seqnum behavior

Hi Brian, >> > Moreover, it seems like axi_wrapper.v uses clear_tx_seqnum to pass out >> > config bus messages, so now that clear_tx_seqnum is set I am not able to >> > use >> > the config bus from the axi_wrapper. >> >> I think this is a side effect of the assumption that data cannot flow >>