Hi again
I figured out the flow and discrepancy between "now" in "new_rx_control.v" and
"radio_ctrl_proc.v". The first is a time set in the register "RX_CTRL_TIME" the
second is 'command issuing time'. And typically the "RX_CTRL_TIME" is written
without a 'command issuing time' and hence HAS_TIME is false. So what I was
worried about can only happen if someone issues a timed command to update
"RX_CTRL_TIME" where the timed command has same time as the start time written
to "RX_CTRL_TIME". Since no API supports this, its will never be an issue... So
sorry for the fuss! ... though better naming in both fpga and driver code could
have helped, for instance "set_time" in "radio_ctrl_core_3000.cpp" could be
named "set_cmd_issuing_time" etc.
Med venlig hilsen / Best Regards
Thomas Fabricius, M.Sc.EE., Ph.D.
Chief Technical Officer (CTO)
Chora A/S
Mindet 2, 3.sal
DK-8000 Aarhus C
Denmark
Phone: +45 86 18 99 55
Mobile: +45 22 93 70 59
Fax: +45 87 30 07 75
E-mail: t...@chora.dk
www.chora.dk
-----Oprindelig meddelelse-----
Fra: USRP-users <usrp-users-boun...@lists.ettus.com> På vegne af Thomas via
USRP-users
Sendt: Wednesday, 23 May 2018 20.54
Til: 'Ian Buckley' <i...@ionconcepts.com>; 'kf' <k...@chora.dk>
Cc: usrp-users@lists.ettus.com
Emne: Re: [USRP-users] B210 initial tickcount offset
Hi
Ian: that was also partly what we figured out, so thanks for confirming.
But maybe someone can help clarify the start flow at a specific vita time from
fpga-source.
The "set_stb" generated in "radio_ctrl_proc.v", seems to depend on "vita_time"
equal "trigger_time" ie. "now" in case "HAS_TIME". "set_stb" is used to latch
in setting registers. Now in "new_rx_control.v", "command_valid" depends on
"store_command" which is changed after "set_stb" on "sr_time_l". This implies
that in the below "ibs_state" state "IBS_RUNNING" is achieved at "now", but
since this must be true some clk's after "set_stb", I see a kind of problematic
discrepancy between the "now" in "radio_ctrl_proc.v" and "new_rx_control.v". I
simple cant understand that they both can be now=true when "HAS_TIME" ?!?!?!
I must admit that the flow works (up to constant latency), but maybe the flow
is always without HAS_TIME ???
case (ibs_state)
IBS_IDLE : begin
clear_halt <= 1'b0; // Incase we got here through a
HALT.
if (command_valid)
// There is a valid command to pop from FIFO.
if (stop)
begin
// Stop bit set in this command, go
idle.
ibs_state <= IBS_IDLE;//IBS_ZEROLEN;
end
else if (late & ~send_imm)
begin
// Got this command later than its
execution time.
ibs_state <= IBS_LATECMD;
end
else if (now | send_imm)
begin
// Either its time to run this command
or it should run immediately without a time.
ibs_state <= IBS_RUNNING;
lines_left <= numlines;
repeat_lines <= numlines;
chain_sav <= chain;
reload_sav <= reload;
end
end // case: IBS_IDLE
_____________________________________________________________
"radio_ctrl_proc.v":
time_compare time_compare (.clk(clk), .reset(reset), .time_now(vita_time),
.trigger_time(ctrl_tdata), .now(now), .early(), .late(late), .too_early());
assign go = now | late; assign set_stb = (rc_state == RC_DATA) & ready &
ctrl_tvalid;
And further:
case(rc_state)
RC_HEAD :
if(ctrl_tvalid)
begin
sid <= ctrl_tdata[31:0];
seqnum <= ctrl_tdata[59:48];
HAS_TIME_reg <= HAS_TIME;
if(IS_EC)
if(HAS_TIME)
rc_state <= RC_TIME;
else
rc_state <= RC_DATA;
else
if(~ctrl_tlast)
rc_state <= RC_DUMP;
end
RC_TIME :
if(ctrl_tvalid)
if(ctrl_tlast)
rc_state <= RC_RESP_HEAD;
else if(go)
rc_state <= RC_DATA;
_____________________________________________________________
/fabric
-----Oprindelig meddelelse-----
Fra: USRP-users <usrp-users-boun...@lists.ettus.com> På vegne af Ian Buckley
via USRP-users
Sendt: Wednesday, 23 May 2018 20.11
Til: kf <k...@chora.dk>
Cc: usrp-users@lists.ettus.com
Emne: Re: [USRP-users] B210 initial tickcount offset
There is a certain amount of (deterministic) latency incurred in the pipelining
of H/W signals, both data and control.
The tick count applied to the data will be accurate w.r.t the instant the data
left the DDC and was packetized.
-Ian
> On May 23, 2018, at 2:26 AM, kf via USRP-users <usrp-users@lists.ettus.com>
> wrote:
>
> Hi.
>
> I am having trouble understanding why the first samples I receive have
> a tick count offset of 7.
>
> My setup is:
> - B210 with gpsdo
> - Time source and reference set to 'gspdo'
> - Two-channel RX
> - Sample rate set to 16Mhz
>
> The procedure is then to
> - Reset to time to 0 using the PPS signal
> - Requesting streaming to begin on time 2
> - The first samples received has a tick of 32000007, but it should
> have been 32000000 (time 2)
>
> Why is the tick count 32000007 on the initially received samples?
>
> It seems very consistent, as the received tick count is the same on
> three different B210 boards handled by three different PCs.
>
> Below is the relevant code parts mentioned above.
>
> Regards
> /KF
>
>
> === Code for resetting time to 0 ===
>
> const uhd::time_spec_t last_pps_time1 = usrp->get_time_last_pps();
> while (last_pps_time1 == usrp->get_time_last_pps())
> boost::this_thread::sleep(boost::posix_time::milliseconds(50));
> usrp->set_time_next_pps(uhd::time_spec_t(0.0));
> const uhd::time_spec_t last_pps_time2 = usrp->get_time_last_pps();
> while (last_pps_time2 == usrp->get_time_last_pps())
> boost::this_thread::sleep(boost::posix_time::milliseconds(50));
>
>
> === Code for streaming ===
>
> double seconds = 2.0;
> std::cout << "Issuing stream command to start streaming at time " <<
> seconds << std::endl; uhd::stream_cmd_t
> stream_cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
> stream_cmd.num_samps = 0;
> stream_cmd.stream_now = false;
> stream_cmd.time_spec = uhd::time_spec_t(seconds);
> rx_stream->issue_stream_cmd(stream_cmd);
>
>
> === Printing the first tick received ===
>
> size_t num_rx_samps = rx_stream->recv(buffers,
> _startArguments.samplesPerBuffer, md, 10.0, false); std::cout <<
> "Received first samples. Tick: " <<
> md.time_spec.to_ticks(16000000) << std::endl;
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
