Hello,
I have been using the cmd_out control source bus of the noc_shell in a custom
rfnoc block to generate timestamped stream_cmds for a downstream radio block. I
recently pulled in the latest changes from uhd rfnoc-devel
(eec24d7b0442616fdbe9adf6b426959677e67f92) and fpga rfnoc-devel
(1b40696a7ede5c2593f36276071460f08bbf24b2), upgraded to Vivado 2017.4, rebuilt,
etc and I am now seeing some strange behavior.
I am using the cmd_out control source noc_shell bus in a custom rfnoc block to
generate a timed RX streaming command to a downstream radio block. The
equivalent uhd command would be something like:
> stream_cmd.time_spec = _radio_ctrl->get_time_now() + uhd::time_spec_t(.1);
> const uint32_t cmd_word = {stream_now = 0, inst_chain = 0, inst_reload = 0,
> inst_stop= 0, stream_cmd.num_samps}
> const uint64_t ticks = stream_cmd.time_spec.to_ticks(_radio_ctrl->get_rate());
>
> _radio_ctrl->sr_write(uint32_t(RADIO_SR_RX_CTRL_CMD), cmd_word, chan);
> _radio_ctrl->sr_write(uint32_t(RADIO_SR_RX_CTRL_TIME_HI), uint32_t(ticks >>
> 32), chan);
> _radio_ctrl->sr_write(uint32_t(RADIO_SR_RX_CTRL_TIME_LO), uint32_t(ticks >>
> 0), chan); //latches the command
The command I am sending from my application this looks like:
> double sec_in_future = .1
> stream_cmd.time_spec = _radio_ctrl->get_time_now() +
> uhd::time_spec_t(sec_in_future);
> const uint64_t ticks = stream_cmd.time_spec.to_ticks(_radio_ctrl->get_rate());
>
> _my_custom_block->send_pulse_and_forward_rx_cmd(ticks)
I am observing a few symptoms for this issue:
Behavior 1:
- The first fpga-originated timed stream_cmd is successful and I receive the
expected number of samples from the radio at the correct time.
- All subsequent fpga-originated timed stream_cmds result in the following
error (sometimes one, sometimes two per cmd) as well as a timeout (0 samples
received):
> Receiver error: ERROR_CODE_LATE_COMMAND
> Timeout while streaming
Behavior 2:
- If I disable the fpga stream_cmd generation and just send them manually from
software
> _my_custom_block->send_pulse_only(ticks)
> _rx_stream->issue_stream_cmd(stream_cmd)
everything works as expected - radio starts tx and rx at the same time.
Behavior 3:
- If I call
> _radio_ctrl->set_time_now(uhd::time_spec_t(0.0)) //does not have to be 0.0
> — works for any value
before each call to
> double sec_in_future = .1
> stream_cmd.time_spec = _radio_ctrl->get_time_now() +
> uhd::time_spec_t(sec_in_future);
> const uint64_t ticks =
> stream_cmd.time_spec.to_ticks(_radio_ctrl->get_rate());
>
> _my_custom_block->send_pulse_and_forward_rx_cmd(ticks)
I get undefined/random behaviors: Generally the radio will get the stream
command and source rx samples, but with non-deterministic tx/rx timing offsets/
pulse movement within the receive window, sometimes dropped samples, sometimes
ERROR_CODE_LATE_COMMANDs (all in static cable loopback configuration).
I have tried to increase the command time delay (sec_in_future = 10.0), but
still get the ERROR_CODE_LATE_COMMAND. Interestingly the error does not come
until ~ 10 seconds after the command was sent (commands are sent to the radio
immediately). However, If sec_in_future = .1, the ERROR_CODE_LATE_COMMAND
shows up almost immediately.
I have reverted to a previous version of uhd rfnoc-devel
(ec9138eb6634b0af106762832c7518c887576a94) and, with a previously built
compatible FGPA image (no changes to custom block), everything works as
expected with no errors or unexpected behavior.
Block Configuration: custom_block (cmd+data source) -> Radio -> Host
Not really sure what to make of this. Perhaps this is a bug or a change to how
non-timed commands are treated?
Has anyone else seen something like this? Or is anyone able to reproduce such
behavior?
I would really appreciate if anyone had any thoughts on this one.
Thanks!
Sam
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
