Hi Marcus,
> Von: "Marcus D. Leech" <patchvonbr...@gmail.com>
> On 03/23/2020 11:53 PM, Lukas Haase wrote:
> >> Von: "Marcus D. Leech" <patchvonbr...@gmail.com>
> >> On 03/23/2020 11:08 PM, Lukas Haase wrote:
> >>> Hi Marcus,
> >>>> Von: "Marcus D. Leech" <patchvonbr...@gmail.com>
> >>>> On 03/13/2020 10:52 AM, Lukas Haase wrote:
> >>>>> Hi again Rob,
> >>>>>
> >>>>> Yes, I confirm:
> >>>>>
> >>>>> 1.) Finally I get the commands to execute at the same time (TX and RX
> >>>>> individually and both at the same time)
> >>>>> 2.) Yes, the phase is random after each retune, even when I retune back
> >>>>> to the same frequency
> >>>>> 3.) (2) is only true if it includes *DSP* retuning. With naalog
> >>>>> retuning (+integer-N retuning) I get phase coherence, as expected.
> >>>>>
> >>>>> I actually expected the PLL retuning much more challenging than the DSP
> >>>>> retuning but for some reason it seems to be the opposite...
> >>>> It depends on whether the phase-accumulator in the DSP is reset to zero,
> >>>> or whether just the increment register is updated with the
> >>>> new phase increment. There are good arguments for both approaches.
> >>> I just wanted to check in again if you know how this is implemented and
> >>> how your thoughts are regarding tuning in both cases. My take:
> >>>
> >>> Case #1: Phase accumulator and increment register is reset.
> >>> - This results in transients when re-tuning frequency because the
> >>> mixer LO always (re-)starts at zero phase.
> >>> - Since this completely defines the state of the DDC/DUC, I imagine
> >>> phase coherence must be preserved assuming the resets in TX and RX happen
> >>> exactly at the same time (which is still not certain to me)
> >
> >
> >
> > I have actually always wondered HOW these magic timed commands actually
> > work.
> >
> > The FPGA has a clock which to my knowledge is the system clock which is 200
> > MHz. Call this clock "clk".
> > But this is also the sample rate.
> > So everything that operates on a sample level accuracy must execute within
> > one clock cycle which seems hard to me.
> >
> > If I queue 16 timed commands how can they really be executed at the same
> > clock cycle?
> Well, you have to remember that FPGAs are inherently massively-parallel
> nano-computers. But in THIS case, it looks to me like there's
> a FIFO, and elements on it are processed one at a time. In an FPGA,
> all kinds of "stuff" can happen at the same time, because it's
> a whack of somewhat-independent logic cells (or, actually, LUTs, but
> that's an implementation issue).
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
> >> According to my study of the FPGA code, the register sets are serialized
> >> within the timed-command FIFO, which is an AXI FIFO, which means
> >> that said commands may be spread over several 10s of nanoseconds in
> > Is this an alternative way of saying "timed commands actually do NOT
> > execute at the same time on the x310" or alternatively "The x310 does
> > actually NOT support phase coherent operation"?
> I won't go that far, because I'm not an FPGA expert. But the whole
> "synchronize the things" via timed commands was originally intended to
> allow synchronizaton *across* multiple USRP units. Which will work,
> according to my analysis, because those FIFOs will all be executed
> in lock-step *across* the USRPs involved. But within a USRP, I think
> things are a bit murkier.
> >
> > That would come pretty much to a shock.
> >
> > It would explain why phase coherence works with analog-only tuning
> > (assuming one single register set is sufficient for analog tuning).
> >
> > On the other hand, it would not explain why RX-RX phase coherence (or
> > TX-TX) works. In that case, only the two DDCs are used. But there are still
> > several register sets which would equally break stuff.
> Like I said, I'm not an expert at FPGA stuff, and I'm hoping someone
> more priestly than me can comment.
That'd be amazing.
> 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.
(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).
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)
> 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
