[hpsdr] openHPSDR at the forefront of SDR development

[John Laur]

Ideas for discussion:

First, isn't this similar to the architecture that has been
implemented by PA3FWM's wideband websdr for some time?
ADC->FPGA->Ethernet->FFT with GPU and then individual receivers only
have to grab the bins and do an IFFT? If so, it's a clear winner as
far as scaling the capabilities go. I am very excited to see the
excitement for it. But I am concerned with the discussion dwelling
around the Jetson board as being central and essential to this
architecture long-term although I do think it is valuable as a
motivator.

For a hardware architecture that will hang around for a while and be
the most compatible, I would like to discuss the option of designing
instead for regular (non-mini) PCI-e.

While it's great to have these 'fun-size' SBC's there is really
nothing that I have seen to conclude that NVidia or a 3rd party will
continue to ship such a thing as a developer or retail product with
extremely similar architecture and form factor over the long term. So
unless there is someone who wants to keep up with the hassle of
actually integrating NVidia silicon onto an HPSDR board and making a
wholly integrated system a la the Flex-6k, I do not think it is worth
exploring too far into that paradigm. Designing for the Jetson's
mini-pcie interface would severely limit future flexibility should the
product be dropped and limit the use of the HPSDR hardware in cases
where mini-pcie is not available on a board with a suitable CUDA GPU.
Plus, Jetson itself has a huge disadvantage (for the HPSDR server
application) of having only a single Ethernet interface. I understand
that there is still 16Mbps of bandwidth 'left over' (and that the
interface itself is full duplex) but that is an awfully limiting
margin considering the possibilities that exist with the architecture.
Yes; one could be added on USB without occupying the mini-PCIe, but at
the expense of the limited CPU resources. Running ethernet interfaces
at 99% capacity is a tricky business anyway. It would be nice to
simply eliminate that challenge.

There is one thing we can be sure of though: NVidia will continue to
ship regular PCI-e graphics cards for the foreseeable future.
Depending on the version of CUDA required, an inexpensive NVidia
GeForce card will likely exceed Jetson's performance by quite a lot. A
small dedicated system with dual PCIe slots and a GPU can be designed
and built with specifications exceeding those of the Jetson board at
similar cost, and the same architecture can be implemented. I do not
see that the Jetson has any advantage over such system other than
perhaps power consumption or having fixed design. The problem of power
consumption is likely not to be a large concern in this application,
and the second problem can be eliminated by specifying a tested
reference design.

* PCI-e is the fastest common interface available. Current standards
take speeds to 250gbps (PCI-e 4.0 x16), and even the lowest common
denominator (PCI-e 1.0 1x) is still 2gbps.

* PCI-e can be bridged to Mini-PCIe, Thunderbolt, or Expresscard
interfaces with off-the-shelf hardware.

* PCI-e supports DMA, RDMA, and peer to peer data transfer. Data can
be moved from HPDSR to GPU without involving the CPU. A passive PCI-e
backplane could be used as a future replacement for Atlas with the
ability to use off the shelf parts.

* PCI-e is easy to interface in the modern Altera FPGAs with hardware
controllers and does not require the difficult task of writing IP for
3rd party interface chips (Existing IP for things like USB 3.0
controllers and 10gbE chips are licensed and generally not compatible
with open-source licenses. I believe this is one of the major pain
points with the current HPSDR FPGA efforts.)

* PCI-e is generally backwards (and forwards!) compatible. So modern
high-bandwidth hardware can be designed and still used with older or
less powerful hosts.

An external interface of some sort has the advantage that the RF bits
can be somewhat isolated from the noisy computer bits, but there are
ways to mitigate that and still use PCI-e, such as using a case design
that ensures the RF side is well shielded. The design could also be
broken into two parts with the ADC/DAC/Clocks isolated and connected
to the FPGA on a PCI-e card by means of line driver ICs and
off-the-shelf cables.

Any thoughts from those more involved with the software or hardware design?

73, John KF5SAB


On Fri, Aug 22, 2014 at 10:31 PM, Phil Harman <phil at pharman.org> wrote:
>
> ***** High Performance Software Defined Radio Discussion List *****
>
> Hi Marc,
>
> Thanks for your email.
>
> We still have a way to go with fully proving the DFC idea but so far its looking good.
>
> We actually had this discussion a few minutes ago during the weekly Teamspeak session.
>
> Whilst the GPIO is one solution our concern is that the Jetson board is not going to be a production item for Nvidia.  There is no guarantee that what board replaces it, be it  64 bit Jeston  or something completely different, may not have the same GIPO port.
>
> What does look viable  is a board  using miniPCIe since there is a good possibility that future SBCs will carry this interface.
>
> What was suggested was a miniPCIe board with an Altera Cyclone V FPGA (since this has PCIe implement in hardware on the chip) plus an ADC, DAC and I/O. The I/O could include an interface to the Alex board so we can use that rather than reproduce that hardware.
>
> With an FPGA on the board we have many options from DFC down to porting the existing DDC/DUC code,  which is all ready proven to work.
>
> If such a PCB design is of interest to you then please lets discuss further.
>
> 73 Phil....VK6PH
>
>
> -----Original Message----- From: Marc Lalonde
> Sent: Saturday, August 23, 2014 10:31 AM
> To: hpsdr at lists.openhpsdr.org
> Subject: Re: [hpsdr] openHPSDR at the forefront of SDR development
>
>
> ***** High Performance Software Defined Radio Discussion List *****
>
> Hi
>
> guess some one already work on a ADC /DAC Board that go on the expansion
> connector of the DEV kit ?
> seem to have 5 LVDS pair available + some GPIO  ,so need probably FPGA
> as Glue logic..
>
> that may remove the LAN / PHY from equation  and permit made nice self
> contained platform ;-)
>
> if no one yet ,i may willing to help  work on this  ,i was a senior PCB
> designer whit some design backgrond ..
>
> Best 73!
> Marc   VE2OLM

 1409065684.0