[USRP-users] Direct Programming the FPGA

Ian Buckley ianb at ionconcepts.com
Tue Dec 2 02:50:22 EST 2014


On Dec 1, 2014, at 8:18 PM, Eddie Carle <eddie at isatec.ca> wrote:

> On Mon, 2014-12-01 at 10:45 -0800, Ian Buckley wrote:
>> Eddie, 
>> You are right to be concerned about the amount of work involved in
>> building an X300 image from scratch. Some of the interfaced logic
>> use's high speed interfaces and/or has tricky programming and there's
>> been a vast amount of man hours spent on getting that all working
>> well. All the HDL code is published here:
>> https://github.com/EttusResearch/fpga/tree/master look under the usrp3
>> directory for X300 related code. Most X300 peripheral programming is
>> actually done on the host from the UHD code base, just the actual
>> SPI/I2C controllers etc are on the X300.
>> 
>> In most cases such as your own it's possible to do a little creative
>> hacking and insert your custom HDL into the Ettus HDL and then
>> piggyback on all the work already done in UHD.
>> 
>> There is also a new Ettus methodology to customize the X300 HDL called
>> RFNoC which might work for
>> you: https://github.com/EttusResearch/uhd/wiki/RFNoC:-Getting-Started
>> 
>> I have built entirely custom FPGA designs for older USRP's such as the
>> N210 which are simpler system designs and that might be another
>> approach to consider if you don't need the full X300
>> performance/capacity. However older USRPs only support ISE rather than
>> Vivado.
> 
> Thank you very much for the links. That certainly clarifies things.
> Looking the the HDL collection I'm a little unsure of how I should
> proceed. There is a lot of stuff in there that likely doesn't apply to
> me but I'm not sure what to axe and how to interface with it. Ultimately
> this is all we are trying to accomplish:
>      * My VHDL code generates a sequence of signed integers clocked at
>        about 200MHz that needs to find it's way to the DAC.

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.

>      * We need access to the system clock.
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.

>      * We need to generate our own clock with a PLL on the FPGA and use
>        that clock to control the DAC.

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. 

Page11 of the X300 schematic captures the bulk of this.

>      * 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.

>      * We need to get the daughterboard receiver to downmix that signal
>        and sample it with the ADC at a clock that we also control.

Same applies to ADC as DAC…clocks are driven by LMK04186, tuning and down conversion is for free via UHD. Note X300 logic design assumes ADC and DAC clock use the same sample rate (ignoring the fact that the DAC internally up samples also).

>      * We don't need access to any other peripherals. All data being
>        transmitted will be generated randomly on the FPGA and received
>        on 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.

> To me this must be super simple (relatively) since we only need to talk
> to the DAC/ADC, daughterboard and access clocking mechanisms. The goal
> of this is simply to generate a test signal we can look at on a spectrum
> analyzer. Surely this would only involve a few HDL files and some pin
> constraints? Any suggestions beyond what you've said thus far on
> proceeding? Is there any sort of block diagram showing which verilog
> modules are responsible for interfacing with which peripherals?
> -- 
> 	Eddie Carle
> 

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


More information about the USRP-users mailing list