Without this change, kernel 6.12 generates the following warning:
nixge 40000000.ethernet (unnamed net_device) (uninitialized): fixed link full duplex 1000Mbps not recognised
With the change, the link is correctly detected as 1G:
nixge 40000000.ethernet sfp0: configuring for fixed/gmii link mode
Fixed an issue when multiple timed DDS commands were present, where
the first one was popped and then the second command immediately
got popped as well to the stale a lookahead signal.
The fix is to clear the lookahead signal and threshold signal on
every fifo pop command.
- Fix target link libraries (UHD::uhd instead of uhd)
- Updated README
- Better describe the different ways to build the FPGA bitfiles
- Mention pybind11 requirement
- Add x410 image core to CMakeList to enable using make for this image
We see this warning about lingering references during UHD operations
like image load even if they are not. We did some testing to verify.
It seems the garbage collector could take some time to remove these
reference. But the warning here could be misleading. Hence, removed.
UHD hosts <4.10 speak mprpc and unconditionally connect to the RPC port
(49601) of any device they discover. When they reach a gRPC-based MPM
device, the protocol mismatch crashes uhd_find_device.
UHd host 4.10, prevents this by using rpc_version key from discovery
response and skips RPC attempt if mprpc device found during
uhd_find_devices.
This change moves the RPC port to 49602. Now, old UHD <4.10 hosts can
still discover both mprpc and grpc devices. But their mprpc connection
attempt on 49601 during uhd_find_devices is refused by grpc device
(running on new rpc port 49602) and is marked as not reachable instead
of crashing.
Since with the availability of discoverable features in Python it is
possible to use the front panel SPI of the X4xx series from there, this
example shows how to do this. It is pretty much on par with the C++
version.
The main RPC channel can sit idle for a long time (e.g. an interactive
Python session) while only the claim-loop channel sees traffic. Without
keepalive, gRPC self-closes the idle transport (~30 min) and the next
RPC fails re-establishing within its per-call deadline.
With this change the client now pings every 30 s to keep the channel
warm, and the server is configured to accept that cadence instead of
replying GOAWAY "too_many_pings".
The MPM gRPC server runs on a single-threaded gevent hub. gRPC's BDP
(bandwidth-estimation) probe fires repeatedly while the reclaim loop
keeps the link busy, and its ACK must return within grpcio's short,
RTT-derived internal BDP deadline. Any blocking hardware register read
(e.g. a ClkMgr PLL-lock poll) stalls all socket I/O on the hub until it
returns; , but these polls also run periodically in steady state.
When a stall outlasts the BDP deadline the server sends GOAWAY
"ping_timeout" and drops the transport. The fix is to disable BDP on
the server. The default flow-control window is fine on the LAN link,
so this costs nothing here. BDP is left enabled on the client, whose
native-threaded stack never freezes.
Enable clock watch circuit for images with 200 and 400MHz bandwidth
as well. With this we also move from watch the rfdc_clk to watch the
radio_clk. This makes is easier to calculate the max clock rate for
all flavours of images.
Updated the references to DDC and DUC RFNoC blocks to reflect the
new split between legacy(singlesample) and wideband(multisample)
implementations.
Updated the related manual references as well as the C++ block
controller API comments that are pulled in by doxygen.
Also fixed a minor outdated comment in the FPGA source code.
