I modified the three files described above, changing the CMD_FIFO_SIZE
parameter in dds_timed.v and axi_tag_time.v, and FIFO_SIZE in ddc.v. In all
cases I attempted to adjust to 20, but that used too much BRAM and I instead
tried 10, which successfully built.
I loaded the bitfile onto an x310, and ran the following code snippet to test:
```
uhd::time_spec_t initial_lat(1.0);
uhd::time_spec_t cmd_time(0.0);
// Amount of time to increment on each iteration
uhd::time_spec_t schedule_increment(0, FREQ_SCHEDULE_WINDOW_TICK,
CLOCK_RATE);
uhd::tx_metadata_t md;
md.has_time_spec = true;
md.start_of_burst = true;
md.end_of_burst = true;
global_usrp_time = usrp->get_time_now();
// Assume the first packet arrives some time before it is actually sent
cmd_time = global_usrp_time + initial_lat;
for (int i = 0; i < queue_size; i++)
{
// Transmit
md.time_spec = cmd_time;
tx_streamer->send(ppayload, nsamples, md);
cmd_time += schedule_increment;
// Hop at a scheduled time
usrp->set_command_time(cmd_time);
usrp->set_tx_freq(tune_request.getNextTuneRequest());
}
```
The idea is that I schedule approximately one second in the future a number of
transmits and hops spaced \~200 us apart. If the USRP has enough timed command
slots in both the digital resampling chain and the transmit chain, this will
work fine.
Running this code with queue_size = 5 against the base x310 image works, but
produces a bunch of late Ls to stdout when queue_size = 6. My image which I
built with the above parameter modifications has the same behavior as the base
image, failing at queue_size = 6.
Is there another FIFO somewhere I need to grow?
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
