Sylvain,
the UHD/C++ code you're quoting is for USRP2/B100. timekeeper.v on the
other hand is in the usrp3/ subdirectory, so it's for the Gen-3 devices,
and B200 (because B200 is Gen-2.5 and we round it up to 3... or something
like that).
If we take a look at time_core_3000.cpp, then we see:
86 void set_time_now(const uhd::time_spec_t& time)
87 {
88 const uint64_t ticks = time.to_ticks(_tick_rate);
89 _iface->poke32(REG_TIME_HI, uint32_t(ticks >> 32));
90 _iface->poke32(REG_TIME_LO, uint32_t(ticks >> 0));
91 _iface->poke32(REG_TIME_CTRL, CTRL_LATCH_TIME_NOW);
92 }
93
94 void set_time_sync(const uhd::time_spec_t& time)
95 {
96 const uint64_t ticks = time.to_ticks(_tick_rate);
97 _iface->poke32(REG_TIME_HI, uint32_t(ticks >> 32));
98 _iface->poke32(REG_TIME_LO, uint32_t(ticks >> 0));
99 _iface->poke32(REG_TIME_CTRL, CTRL_LATCH_TIME_SYNC);
100 }
101
102 void set_time_next_pps(const uhd::time_spec_t& time)
103 {
104 const uint64_t ticks = time.to_ticks(_tick_rate);
105 _iface->poke32(REG_TIME_HI, uint32_t(ticks >> 32));
106 _iface->poke32(REG_TIME_LO, uint32_t(ticks >> 0));
107 _iface->poke32(REG_TIME_CTRL, CTRL_LATCH_TIME_PPS);
108 }
...as you say, we latch on CTRL.
Note that on master branch / UHD 4.0, only b200 uses time_core_3000.cpp (at
this point, the naming is confusing, I admit, but it's for historical
reasons).
X300 sets the time via the ZPU (see
https://github.com/EttusResearch/uhd/blob/master/host/lib/usrp/x300/x300_mb_controller.cpp#L97-L118),
and the other USRPs set the time via MPM, which then also pokes motherboard
registers (
https://github.com/EttusResearch/uhd/blob/master/host/lib/usrp/mpmd/mpmd_mb_controller.cpp#L43-L61
).
This is because the timekeeper has moved out of the RFNoC blocks, and runs
as a global clock/timekeeper on the side.
--M
On Thu, Aug 27, 2020 at 10:17 AM Sylvain Munaut via USRP-users <
[email protected]> wrote:
> Hi,
>
> In UHD you find :
>
> void set_time_next_pps(const uhd::time_spec_t &time){
> const uint64_t ticks = time.to_ticks(_tick_rate);
> _iface->poke32(REG_TIME64_TICKS_LO, uint32_t(ticks >> 0));
> _iface->poke32(REG_TIME64_IMM, FLAG_TIME64_LATCH_NEXT_PPS);
> _iface->poke32(REG_TIME64_TICKS_HI, uint32_t(ticks >> 32));
> //latches all 3
> }
>
> with seemingly the write of the 'HI' part being the trigger point.
>
> In the FPGA code (timekeeper.v) you have :
>
> setting_reg #(.my_addr(SR_TIME_CTRL), .width(3)) sr_ctrl
> (.clk(clk), .rst(reset), .strobe(set_stb), .addr(set_addr), .in(set_data),
> .out({set_time_sync, set_time_pps, set_time_now}), .changed(cmd_trigger));
>
> So the 'cmd_trigger' that synchronizes the action is on the 'CTRL'
> (aka REG_TIME64_IMM) register and not on the hi part of the time.
>
>
> TBH I'm not even sure how set_time_now works at all ... it has the
> same issue and AFAICT it would always end up using the previous value
> of the 'hi' register...
>
> Am I missing something here ?
>
> Cheers,
>
> Sylvain Munaut
>
> _______________________________________________
> 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
