[USRP-users] Direct Programming the FPGA

Ian Buckley ianb at ionconcepts.com
Wed Dec 3 12:15:15 EST 2014

Martin has already given you some good feedback here so I'll keep it short.

Here's a link to a block diagram of an older N210 USRP….essentially half of an X300 showing the ADC/DAC's and RF mixers and LO's.

IQ imbalance and DC offset are intrinsic issues with direct-conversion radio's and the corresponding blocks in the USRP are used to digitally cancel these analog impefections.
After running Ettus's calibration S/W utilities then calibration data recorded against each daughter card radio's serial number will be applied by UHD as available using these blocks.

IQ swap is generally a transparent block for most daughter card radio's , don't worry about this block it will be managed by UHD.

The CORDIC in essence provides tuning with arbitrary frequency precision, as Martin mentioned, allowing us to go beyond the minimum tuning quanta of the daughter card radio synthesizer.
But in the context of direct conversion it has other interesting uses. Its for example very common to use the CORDIC to move the baseband signal signal significantly away from the DC offset artifact or LO leakage that results intrinsically in direct conversion radios.
Another great advantage of having the the CORDIC is the ability to frequency hop instantaneously within the bandwidth of the converters. In multi-channel applications multiple CORDIC instances can be used as a channelizer. Etc etc.
If UHD apportions no tuning component to the CORDIC then it too will be a transparent block to your signal.

Take a general read on google hits for direct conversion, most of this stuff is not USRP specific.

As for stand-alone operation, that is where your potential workload is going to jump exponentially. The USRP's are designed primarily as SDR front ends, the intent being that the "S" part of SDR runs on a connected Host, not on the USRP. No software based signal processing is done on the USRP, it's all classic digital radio design. For the same reason all the intelligence of the device drivers for IC's in the X300 is pushed off to the host, and just the physical interfaces implemented in the FPGA. The network connection provides the linkage between all this host functionality and the FPGA. Thats not to say that the chassis couldn't be used as the foundation for a powerful standalone SDR, but that is not the FPGA design and support host S/W architecture that is supplied as part of the product. Ettus has a brand new product aimed directly at standalone operation and thats the E310. There is likely no reason why you could not use a very modest miniature host running UHD with an X300 for proof of concept style work like you are embarking on since you will be dealing with your real sample stream on the FPGA….you just need to trick UHD a little so it's handling a dummy sample stream of very low bit rate that is just discarded - thus avoiding any major S/W changes to UHD.


On Dec 3, 2014, at 2:17 AM, Martin Braun via USRP-users <usrp-users at lists.ettus.com> wrote:

> On 12/03/2014 06:53 AM, Eddie Carle via USRP-users wrote:
>> On Mon, 2014-12-01 at 23:50 -0800, Ian Buckley wrote:
>>> 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. 
> Ian most definitely has some more details on this, but while it's
> daytime here I can add some info: The process you describe is called
> 'direct conversion' and is what we use in all of our devices.
> So yes, you always operate at baseband (i.e. an IF of 0 Hz).
> As for the DACs, you can think of it this way, but it's really a single
> chip. The AD9146 is a 'dual' DAC, which serves exactly this purpose. You
> can grab the datasheets and will see an abstract, simple schematic for
> I/Q mode on the front page.
> The daughterboard will then do the conversion to a higher frequency. The
> PLLs on the daughterboards aren't able to generate any LO frequency
> (e.g., maybe it's only possible to have multiples of X kHz), so we have
> to help in baseband by shifting the 'digital' IF to the remaining
> offset. If you have have a look at the verbosity output of the tuning
> call, you will see this whole process.
> So, you only need the CORDIC if you want to change that digital IF.
> I'm not sure, though, why you think generating OFDM signals is more
> complicated in baseband than at an IF. On the transmit side, the output
> of the IFFT is already a baseband signal. All you need to do is append
> the CP and add pulse shaping, and there you are.
>> 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?
> See my comment above on the CORDIC. DC offset and I/Q balance are used
> to correct inaccuracies from the analog daughterboards. The output of DC
> Offset correction is still signed. I/Q swap you can probably ignore.
> Some of our daughterboards connect I and Q lines differently to the DAC
> (e.g., for layout purposes). We just keep note of what the d'board did
> and then swap it back in the FPGA.
>>> 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.
> This sounds very interesting! First, a quick reminder that you might
> want to make use of the Front-panel GPIO connectors if you want to blink
> a LED. But if you're already using that, you could just as well use it
> to connect a serial line to the FPGA (or probably the ZPU) to give you
> output.
> The rest of this email you can read as a fellow nerd who loves this kind
> of research (if there's classified stuff here, just ignore me): I'd be
> interested to know why you're planning to do this all on the FPGA, and
> bypassing the host entirely, especially if you say this is just for
> academic purposes? When I was still in academia I pretty much always
> went the route results first, paper next, optimize later (although
> probably not). It sounds like generating and verifying your channel
> coding method would be much simpler on the host (e.g., in GNU Radio or
> whatever your tool of choice is). You could even use the same code you
> were using (if any) to run simulations. This was a method I preferred,
> since it allowed very rapid iterations between simulations and
> measurement. It also made publishing results with both simulations and
> measurements trivial, and editors and reviewers love that stuff :)
> Cheers,
> Martin
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141203/27ad82b5/attachment-0002.html>

More information about the USRP-users mailing list