On 2021-12-08 18:57, EGR Email wrote:
The offset is computed based on the assumption that the radios can
properly timestamp received messages and transmit messages accurate to
the clock tick using schedule transmissions. This is done using by
performing scheduled RX bursts by filling the stream_cmd_t struct with
a receive time spec before issuing the rx_streamer::issue_stream_cmd()
to the rx_streamer, and similarly by filling the tx_metadata struct
with a time spec before using the tx_streamer::send() command. From my
testing this appears to properly schedule TX and RX bursts within one
clock tick (which I believe is the intended function of these commands).
Because the synchronization bursts are happening via scheduled/timed
commands from the FPGA, the latencies of the network layer and OS will
have no effect on synchronization as the timing of the critical
section is happening entirely within the FPGAs. The host PC is only
scheduling the synchronization bursts at some time in the future and
performing the processing on the bursts after they’ve occurred.
I am fairly confident this technique is working and the time bias
offset is being computed correctly and with sufficient accuracy to
align the clocks to a fraction of a clock cycle. Thus, the issue
remains adding a delta to the local clock of the device with a
deterministic latency to correct for the computed bias; This seems
reasonable to achieve if it can be done on the FPGA, even if the
implementation may be somewhat involved. Fundamentally it’s a fetch,
add, and write back.
Primarily, I’m concerned with if it is possible to instruct the FPGA
to do this via pre-existing API calls, or if I will need to implement
my own RFNoC block to perform it (again I’m not too familiar with
RFNoC, but this seems like it should be possible, if the time register
can be accessed directly).
Unfortunately, our desired applications wouldn’t allow for a White
Rabbit implementation, this would be an alternative to White Rabbit as
it will be infeasible to run fiber between the devices.
Thanks,
Jason
There's no "Clock, adjust thyself" primitive in the FPGA already. So it
would have to be added.
Normally, the TOD (time of day) clock is set either "right now" to the
value provided, or a holding register is loaded with the provided value,
and then when triggered by a 1PPS
even, the TOD clock is loaded from the "holding" register.
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
