[USRP-users] Direct Programming the FPGA
martin.braun at ettus.com
Wed Dec 3 05:17:05 EST 2014
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
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 :)
More information about the USRP-users