[hpsdr] openHPSDR at the forefront of SDR development

Tue Aug 26 09:43:08 PDT 2014

HI

mini-PCI-e may put on PCI-e  whit common adapter ,then put on standard 
PC if need
or may use PCI-e to PCI-e backplane + CPU of some sort ,so many possibility

it need at last 2 lane for a decent SDR (make cation whit Bit Vs Byte)
ADC was 12 Bit x 122Mhx and DAC was 14 bit x 122Mhz this may also double 
in future...
so ~ 3.2Gbit/s

integrating NVidia silicon onto an HPSDR  ,not a thing that i doable at decent cost

Best 73!
Marc L.  VE2OLM

On 26/08/2014 11:08 AM, John Laur wrote:
> ***** High Performance Software Defined Radio Discussion List *****
>
> 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
> _______________________________________________
> HPSDR Discussion List
> To post msg: hpsdr at openhpsdr.org
> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org
> HPSDR web page: http://openhpsdr.org
> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/
>

 1409071388.0