[hpsdr] openHPSDR at the forefront of SDR development

[John Laur]

All,

Thank you for the good discussion. My intention was not to focus too
much on the Jetson discussion actually; I do know that if the code
runs on Jetson I can happily build a small linux machine that will
also run it, so nobody is "locking" anyone into any particular thing.
I just think the Jetson is a low mark to aim for. If it can do a
realtime 30mHz FFT, so can basically any current GPU. Even low power
cards like the GeForce 750 Ti will run circles around it, while
drawing 60W and costing less. I think anyone who has ever compiled up
the fosphor plugin on GNU Radio has probably lamented not having that
view available all the time. So I wont beat on Jetson any more.

I just thought while we were on the subject of architectures it would
be a good time to cut to the chase on the bandwidth problem. While I
will agree with Hermann that SDR hardware (and the HDL features of
HPSDR) seem to be changing as fast or faster than SDR software in
recent months, I also think it ought to be the other way around. On
the big list of SDR's from Wikipedia
http://en.wikipedia.org/wiki/List_of_software-defined_radios I note
only 2 devices use PCIe. I think the hardware is changing largely
because of all the ways that developers are choosing to deal with the
problems of interface constraints; hardware that can filter this
amount of data at this datarate is neither easy nor cheap to engineer.
There is no need to go to this length if you can just move all the
data in the first place. But if the GPU architecture is the way
forward, it's just silly to put an intermediate interface that
requires a lot of HDL work in the way. For a direct sampling design
the most future proof design possible is to make sure the hardware is
at minimum capable of sending the raw ADC/DAC/Clock data in and out at
full datarate to an attached device.

IMO the reason working with the SoCKit hardware and Scotty's boards is
probably so nice is because the interface from the FPGA to the
software is basically transparent. (This is half speculation as I have
a SoCKit that I have used quite a bit but have not yet put funds
together for a board set from Scotty) There is no ethernet PHY and
framing and protocol to get at the DDC data; the CPU just opens a
device and starts reading. If That eliminates a lot of complexity. But
you could easily plug his board set into a different dev kit like this
http://www.altera.com/products/devkits/altera/kit-cyclone-v-gt.html
and with some (admitted) effort you could make yourself a prototype
PCIe HPSDR card right now that could do DMA transfers of ADC samples
right into GPU memory with the same sort of ease. This is the beauty
of a high speed interconnect standard. In this case it is HSMC, useful
only within a certain scope, but it makes the point I think.

A comment for Marc: From what I have seen Mini-PCIe is generally only
ever offered with a x1 interface with the exception of MXM, so it
makes more sense to adapt a PCIe card to the mini-PCIe form factor
than vice versa; that way the card can be designed as a 4x or such.
(It can always be allowed to fall back to 1x)

Anyway to sum it all up neatly, a single integrated board like Hermes
with a Cyclone V SoC part on board that can be used standalone or
plugged in and used as a PCIe card would be pretty attractive HPSDR
platform, I gotta say.

73, John KF5SAB

 1409084842.0