Hi Maxim,
UHD/RFNoC doesn't need any "special" capabilities of your network stack; only the ability
to pass through relatively high-rate data without reordering packets. I had students
myself that worked with N-series USRPs under WSL, that works just fine.
The Radioconda installation method o
Have plans to take a GR flowgraff and port the design to the on-board FPGA
in one of the Ettus product (most likely E320). Currently, the GR flowgraff
has been developed inside a Docker desktop that uses WSL under windows. The
concern is that it may be non-trivial/impossible to use RFNoC to
incorpo
Hi Joe,
You could try stepping through the testbench code in the simulator to see
where it's hanging, or look at your block's signals in the simulation to
see what it does with the write. Make sure it behaves the same as one of
the register writes in a working testbench.
Perhaps a reset signal is
Hi Eugene,
I don't have any suggestions regarding reducing the latency as you
described. But, is it possible for you to move your data processing from
the c++ to the FPGA? Using the X310, I have built a "repeater" capability
that modifies the stream time stamp (tx_time = rx_time +
register-control
Ah, apologies. Some ambiguity in the naming.
>From the spec:
NOTE: The granularity of this field is item and not byte. This behavior is
different from the standard AXI4-Stream tkeep.
On Mon, 13 Feb 2023 at 14:43, Kevin Williams wrote:
> Hi Everyone,
>
> Why is TKEEP always 1-bit wide on m_in_p
Hi Everyone,
Why is TKEEP always 1-bit wide on m_in_payload_tkeep and
s_out_payload_tkeep in the rfnoc gain example, when, according to the AXI
spec, it should represent the number of bytes to be kept as far as I
understand?
Thanks,
--
Kevin Williams
