[USRP-users] Aurora core possible with an X310?

Ian Buckley ianb at ionconcepts.com
Tue Jul 14 16:14:29 EDT 2015

Given the same 10MHz reference that your front ends have there is no reason why you can't reconstruct the same exact sample clock locally, you would "just" have to re-reprogram the TI PLL that normally synthesizes the 200MHz sampling clock in a stock X300.
I guess my point was, (and I could have made it far better) you are in effect replacing the ADC/DAC interfaces on the FPGA which run at the exact sample clock and stream data to/from the USRP radio one sample/clock cycle/channel…thus you need that exact sample clock present on your front end also available in the USRP, since it drives a large portion of the logic.

As far as RFNoC goes, my point is that the only way you can get to high speed transceivers on X300 is to add an Aurora interface is to repurpose one of the SFP+'s. And that means you have to alter Verilog in the main X300 codebase, rather than just create new code (thats orthogonal to the main Ettus code) as you would for a new RFNoC block. If you are not adding significant new FPGA based DSP that would benefit from being within a single GRC flow graph, it would seem then that doing the re-implementation via RFNoC brings little benefit. Rather you should concentrate on adding your custom functionality in such a way that it creates as few knock-on changes to UHD as possible (i.e try not to alter the visible programming model of the FPGA), easing your maintenance burden if you continue to track new Ettus code. You will be forced to make UHD aware of your sampling clock frequency as so much depends on it, hopefully that could be done by following the existing code that currently provides the three 200/184/120MHz options.


On Jul 14, 2015, at 12:18 PM, Jason Matusiak <jason at gardettoengineering.com> wrote:

> Ian, Good points.  I guess I haven't really thought if there is "host
> processing".  The RF will be coming from/to something connected to the
> USRP, but if the USRP is just a front end that samples, mixes down/up,
> and does the Aurora conversion, I guess that the GRC won't have a "host"
> in that sense (unless allow for changing the IF frequency on the fly).
> I wouldn't say considerable in-house FPGA skills, but I've been the
> working on our in-house testbed emulator, so I would be the one working
> on the FPGA block for the X310.
>> I presume you reconstruct the sampling clock locally in the FPGA from the Aurora clock, the frontend being the clock 
>> source. That would also mean a few changes in X3x0, but nothing too hard.
> I'm not really sure, I haven't thought that far ahead.  Our current
> system has 10MHz clocks distributed throughout our system to all our
> boards for clock syncing.  That obviously won't work the exact same way
> with the USRP.
> So it sounds like your are saying to take the X310 project, and ignore
> the RFNoC side of things and just rework the Vivado project itself to do
> what I need?  That about right?  If so, what is the best way to work on
> it?  With the Ettus makefile build process being so tightly coupled with
> the TCL scripts, it hasn't appeared very straightforward to bring up the
> Vivado GUI and develop from within there (which would certainly be
> easiest since I can't really visualize the FPGA code structure yet).

More information about the USRP-users mailing list