On 03/24/2020 12:24 AM, Lukas Haase wrote:
Hi Marcus,
I would have two possible solutions but both of them are non-trivial:
1. As you say, parallelism. For each of N supported timed commands, the
decoding of the timed commands is cloned
2. If the timed commands are enough clock cycles in the future, they can be
decoded immideately once they come in. For each type of register they set, they
set the following: value of the register. Clock cycle at which it should occur.
Then we would have something like:
reg [31:0] cycle_number; // how to handle overflow? commands can be a max
of 1/200e6 * 2^32 seconds in advance
always @(posedge clk) begin
cycle_number <= cycle_number + 1;
if cycle_number == when_to_set_phase_accumulator_register
phase_accumulator <= data_for_phase_accumulator;
if cycle_number == when_to_set_phase_increment_register
phase_increment <= data_for_phase_increment;
end
Right, but the timed-command FIFO handler doesn't really *KNOW* anything
about the semantics of the registers its setting, and indeed, given
the large variety of daughter-cards, and other "things" it probably
shouldn't *KNOW* too much about anything, because that, among other things,
makes the code MUCH harder to maintain, and occupies more room in the
limited-space FPGA.
Absolute phase coherence (with predictable/zero phase-offset) is, in
practice, incredibly hard to achieve--PARTICULARLY PHASE OFFSET.
Which is why most fielded RF systems work just fine with "wobbly"
phase-offset, with mechanisms to factor it out "at startup" (for whatever
definition of "start up" is appropriate).
I know it is hard to achieve and I know normal *comm* systems do not care.
BUT: There is a large class of practically relevent applications that require
TX/RX phase coherence: Ranging and radar.
Everything that that needs to deduce time of flight (=range) via carrier phase
shift.
If it's just one frequency we can again calibrate.
But to make systems robust, they use multiple frequencies and obtain phase
shifts from diverse (hopped) frequencies.
Yes, it's hard to implement but these systems do exist, have been built and
work.
Yup, those systems have hardware that "understands" all of the subtle
semantics of the application at hand.
(I am also aware that there are other options to implement these systems
outside of USRP/SDR context: a single PLL for both TX/RX with potential freq
dividers/multipliers, coupling transmitted signal harmonics back, bandpass
filter and use as RX LO etc).
The problem with the "marvelous generality" of an SDR solution (whether
it's USRP or something else) is that there are *specific* applications
that don't necessarily slide easily into the model of "marvelous
generality".
Your application seems to have two things that are sometimes hard to
achieve in a generic SDR:
o Rapid frequency hopping (RF synthesizers for rapid
frequency-hopping systems are often designed very differently than for
more-general systems).
o Predictable and reliable phase-offset across hops. [That is,
hop to X, hop to Y, come back to X, and have an expectation of the same
systemic
phase offset].
In other words: How would you implement such a ranging system with USRP?
Currently I only see two options that work but none of them are acceptable:
Option 1: Use analog only tuning. But this is not flexible because it only
works with integer-N tuning (poor resolution) and has huge settling timed
Option 2: Do everything (=hopping) in software on the host computer, e.g.
within gnuradio. But this requires unnecessary huge data rates (200MSsps)
Option 2 leaves you in a situation where the hardware isn't changing
across hops. I agree that it carries a heavy implementation burden on
the software side.
There's a 3rd option you didn't mention:
Implement application-specific "stuff" in the FPGA, using either the
RFNoC framework or "raw". RFNoC and the whole open-source FPGA code
were designed to allow that, and many Ettus customers do custom
things in the FPGA specifically because the as-shipped architecture doesn't
quite fit their application model. That is, as I'll re-iterate, an
attribute of highly-generalized systems--they have this natural tendency to
not deal well speciic "edge cases".
I hope that someone with better understanding of the timed-command FIFO
can chime in and tell me that I'm completely wrong.
Indeed much appreciated.
Thanks,
Lukas
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
