[USRP-users] Direct Programming the FPGA

Eddie Carle eddie at isatec.ca
Wed Dec 3 00:53:54 EST 2014

Hi again Ian.

On Mon, 2014-12-01 at 23:50 -0800, Ian Buckley wrote:
> These signed integers represent baseband IQ data ready to be directly
> presented to a DAC? If so then you can plumb this in directly at the
> input to the CORDIC processor in the transmit DSP chain replacing the
> existing sample data path. You will be expected to provide an I and Q
> sample every rising clock edge. Refer to
> http://http://ianbuckley.net/X300_radio.pdf. This way the digital
> portion of the UHD tuning function continues to work unchanged and you
> use the DAC interface logic and programming unchanged (Trust me, you
> don't want to alter this 400MHz DDR interface and the DAC programming
> that supports it). You could do this very quickly if you are prepared
> to run at the default 200MHz clock rate. You would need to figure out
> what your programming interface to this custom logic block is.
Hmm. That is interesting. Perhaps I had misinterpreted how exactly this
whole process works. Currently my logic is generating a QPSK signal by
multiplexing the I and Q signals at 200 MHz in a I,Q,-I,-Q pattern in
order to generate an IF signal at a carrier of 50 MHz. Does this mean
there are separate DACs for both the I and Q baseband signals and the
daughterboard mixes them up with two orthogonal carrier waves? That
would certainly make my life easier. I know some SDRs operate like this
but if it was the case how would one handle more complex schemes like
OFDM? Looking over the schematics it was my interpretation that this was
not the case. Looking at the block diagram I am a little unclear as to
what some blocks do. Specifically the I/Q balance and I/Q swap. Also
what purpose does the DC Offset serve? Is this effectively turning the
signed integers into unsigned integers? Beyond that, what does the
cordic processor do in this case? If we don't have separate DAC for the
I and Q, is this what turns them into a combined intermediate signal?

> By system clock you mean? In X300 there are a great number of clocks
> but of interest to you are the radio_clk (aka master_clock_rate aka
> converter sample clock), and the bus_clock which is used for the small
> microprocessor, much of the networking logic and many of the FPGA
> peripherals. Radio clock is discussed more below. The bus_clock is
> synthesized on the FPGA in a PLL and is currently approx 165MHz and
> must always be greater than 156MHz for 10GE networking to work….best
> not to alter this without very good reason.
Well, in this case I only need access to the 200 MHz clock. I can
generate all the other clocks I need with a PLL in the FPGA. I guess it
obviously shouldn't be an issue getting this.

> On pretty much all USRP's the actual sample clocks are sent directly
> with differential matched length traces from the discrete PLL/VCO that
> generates all the radio related clocks system wide, to both the
> converters and the radio daughter cards. In addition the same clock is
> sent to the FPGA. This is because its desirable to have absolutely the
> lowest jitter and best possible matched delay for radio performance
> reasons. The clock to/from FPGA to converters is generally the same
> frequency or double the frequency, but in all cases derived from this
> high quality clock, and serves only to clock the data between the
> device interfaces. Thus the sample rate can not be altered by use of
> an internal FPGA PLL, if you want to change the sample clock rate then
> the discrete PLL/VCO must be programmed appropriately to synthesize
> the desired frequency(s). X300 and UHD currently ship with factory
> support for 200MHz (default), 184.32MHz (CPRI applications), 120MHz
> (NI applications). If you need something other than that then you will
> need to develop new programming for the LMK04186 (which is very
> flexible..but non
> trivial)..see: https://github.com/EttusResearch/uhd/blob/master/host/lib/usrp/x300/x300_clock_ctrl.cpp. 
Good to know. I really don't actually need to change the 200 MHz clock
rate at all. Not sure why I alluded to it cause 200 MHz is exactly what
I've been planning around.

> >     * We need to somehow tell the daughterboard what frequency to
> > mix
> >       our baseband up to.
> Provided the appropriate SPI and networking logic are left in X300 you
> get that for free via UHD to a python or C API.
Hmmm. At this point I am hoping to have the unit operate in a standalone
fashion. Meaning I'd like to be able to configure the peripherals with
parameters I've burned into the FPGA. Thus they'd be configured upon
reset. Does this seem feasible to you? Certainly I'd need the SPI logic
but I wouldn't need the networking logic right?

> You presumably need some type of interface to get to a host to
> control/observe your custom logic. You also haven't discussed receive
> which presumably is non-trivial.
These presumptions would normally be very correct but as far as this
project's scope goes, they are not. What we need to do is this: generate
a random binary sequence in the FPGA (via some sort of linear feedback
shift register), encode it, modulate it, transmit it, receive it,
demodulate it, decode it, verify that it matches what we sent (this
could be as simple as blinking an LED if an error occurred). This is
entirely for academic purposes at this point thus why we don't need to
send any real data. We are testing using an experimental channel coding
technique to introduce spectral nulls into QPSK signals. Thus we do not,
in this case, require any interface or ability to send or receive actual
data. I'm sure this will come eventually but the goals at this point are
clearly defined.

Thank you for all the help thus far. You have been incredibly
	Eddie Carle

More information about the USRP-users mailing list