FPGA communication with a PC (Windows)

[David Brown]

On 27/03/2012 13:10, Bill Valores wrote:

Hello all,

My team needs to design our own piece of testing equipment for our
project. I'll spare you the gory details, and just say that we will
need to collect data at some 20 Mbyte/sec (possibly continuously) and
somehow get it to a PC computer running Windows. A fancy GUI
application will then present this to the operator. A similar link is
necessary in the other direction for signal injection.

The FPGA does some data processing, so we can't just buy a data
capture card. We may consider a capturing card to interface with the
FPGA digitally.

So my question is: What's your recommendation for the PC-FPGA
communication? Given a fairly skilled engineering team and a
management that understands this is not a cheap quickie (but still
wants to keep costs and efforts at a minimum, of course) what would
you suggest? USB? PCIe? Ethernet? Capture data from debug pins?
Something else?

And: Can anyone give me an idea about what we're up against (costs and
time) based upon experience?

Purchasing equipment and IP cores is fine as long as the costs can be
justified in terms of saved engineering time. It's our own salaries
weighted against spending the money on products (with due risk
calculations and stuff).

Thanks in advance,
Bill

Is Windows a requirement? Dealing with things like raw Ethernet packets
to keep overhead to an absolute minimum is an easy job in Linux. (If
you don't want to think about ARP, IP addresses, etc., why not force the
FPGA to have MAC address 1, and the dedicated PC interface to have MAC
address 2 - then send packets with nothing but the Ethernet frame overhead.)

It also means that the data packets won't have to compete for bandwidth
with other things Windows will want to send over the interface, such as
broadcasts scanning for network shares, ARP requests, or (if you are not
careful) malware sending out spam...

 

[Morten Leikvoll]

"scrts" <hidden@email.com> wrote in message
news:jku8sg$b46$1@dont-email.me...

I'd say SATA is not so easy as it could sound. Plus the FPGA will have to
have transceivers afaik. Anyway, is there any useful information about
implementing SATA in FPGA except a simple SATA standard?

Quick google:
http://www.xilinx.com/support/documentation/application_notes/xapp870.pdf

http://www.altera.com/literature/wp/wp-01093-arria-iv-gx-sata-sas.pdf

 

[MK]

On 27/03/2012 12:10, Bill Valores wrote:

Hello all,

My team needs to design our own piece of testing equipment for our
project. I'll spare you the gory details, and just say that we will
need to collect data at some 20 Mbyte/sec (possibly continuously) and
somehow get it to a PC computer running Windows. A fancy GUI
application will then present this to the operator. A similar link is
necessary in the other direction for signal injection.

The FPGA does some data processing, so we can't just buy a data
capture card. We may consider a capturing card to interface with the
FPGA digitally.

So my question is: What's your recommendation for the PC-FPGA
communication? Given a fairly skilled engineering team and a
management that understands this is not a cheap quickie (but still
wants to keep costs and efforts at a minimum, of course) what would
you suggest? USB? PCIe? Ethernet? Capture data from debug pins?
Something else?

And: Can anyone give me an idea about what we're up against (costs and
time) based upon experience?

Purchasing equipment and IP cores is fine as long as the costs can be
justified in terms of saved engineering time. It's our own salaries
weighted against spending the money on products (with due risk
calculations and stuff).

Thanks in advance,
Bill

I've done this three different ways but not quite at your speed:

FTDI chip and USB - least effort but I only went up to perhaps 4 Mbyte/s
- I always worry about USB.

Ethernet - FPGA -> uP with the FPGA mapped into uP memory - can sustain
wirespeed with 100Mbit Ethernet but that isn't fast enough for you. The
approach would work with a processor with a Gbit Ethernet interface. We
use these in numbers (up to 8) with one PC and going in both directions
- total IO about 40 Mbyte/s

FPGA -> PCI // IO card in PC. This could sustain 20Mbyte/s to disk on a
reasonable PC (Windows XP and (don't laugh) VB6).
The IO card we used was Adlink PCI 7300A (or something like). They
probably do a better one now. This system all worked quite well and
happily fills up Terrabyte hard drives.

I just noticed that you need both directions - that gets harder because
when data goes from PC to FPGA you either need a big buffer in the FPGA
or real time data from the PC.

If you use USB and standard drivers you should allow for at least 0.5
seconds of buffer on the FPGA (either direction).

The Adlink driver didn't need any FPGA side buffering for data into the
PC but we never used it the other way round.

PC's are quite good at buffering incoming Ethernet data but you'll need
to do the work on the FPGA side for the other direction. We like to have
at least 1 second of buffer !

This has all got a bit rambly - hope you get some ideas you can use.

Michael Kellett

 

[Uwe Bonnes]

scrts <hidden@email.com> wrote:

It's indeed true that using UDP eliminates the need to develop a
driver for Windows. Not that I'm 100% sure how to make the computer
link between the Ethernet address and the FPGA's IP address (implement
ARP on the FPGA as well). This way or another, data has to be stored
on some very large memory to allow retransmissions. Yet another option
not ruled out, but not a clear winner either.

Well, I've made UDP communication from FPGA to PC and it runs at almost
100MB/s without any issues. The ARP/setup/etc stuff is processed by
softcpu+LwIP, all the other data streaming is made in hardware. I'd say
it's really easy to do UDP streaming on FPGA side, but I am not sure
about the PC
software.

FT(2)232H needs only a fifo and a not to complex state machine. For the host
side, look into libftdi

http://www.intra2net.com/en/developer/libftdi/examples/stream_test.c

for a sample implementation.
--
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

 

[Tim Wescott]

On Wed, 28 Mar 2012 08:51:16 +0300, scrts wrote:

Another thing that I would look into, without really expecting to
actually use it, would be SATA. Yes, a disk-drive interface. I've
seen it suggested, and the reasons given sounded compelling -- but I
haven't done it, and it is most certainly an oddball approach. My
understanding is that the hardware is easy, but you'd have to write
Windows drivers.

I'd say SATA is not so easy as it could sound. Plus the FPGA will have
to have transceivers afaik. Anyway, is there any useful information
about implementing SATA in FPGA except a simple SATA standard?

You could be quite right -- if you look at my wording, you'll see that I
had that thought in mind.

The article that I was going from was pushing it as a good way to get
real-time comms in and out of a PC; it may not be worth the hassle if all
you want is throughput but don't care as much about latency. Or, it may
not be worth the hassle at all.

(I think that the best way to use a PC in a real-time system is as a
serial terminal, to talk to the processor that's actually doing the
work. But then, I lost patience with PCs a long, long time ago).

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

 

[Tim Wescott]

On Wed, 28 Mar 2012 17:23:29 +0100, MK wrote:

On 27/03/2012 12:10, Bill Valores wrote:
Hello all,

My team needs to design our own piece of testing equipment for our
project. I'll spare you the gory details, and just say that we will
need to collect data at some 20 Mbyte/sec (possibly continuously) and
somehow get it to a PC computer running Windows. A fancy GUI
application will then present this to the operator. A similar link is
necessary in the other direction for signal injection.

The FPGA does some data processing, so we can't just buy a data capture
card. We may consider a capturing card to interface with the FPGA
digitally.

So my question is: What's your recommendation for the PC-FPGA
communication? Given a fairly skilled engineering team and a management
that understands this is not a cheap quickie (but still wants to keep
costs and efforts at a minimum, of course) what would you suggest? USB?
PCIe? Ethernet? Capture data from debug pins? Something else?

And: Can anyone give me an idea about what we're up against (costs and
time) based upon experience?

Purchasing equipment and IP cores is fine as long as the costs can be
justified in terms of saved engineering time. It's our own salaries
weighted against spending the money on products (with due risk
calculations and stuff).

Thanks in advance,
Bill

I've done this three different ways but not quite at your speed:

FTDI chip and USB - least effort but I only went up to perhaps 4 Mbyte/s
- I always worry about USB.

Ethernet - FPGA -> uP with the FPGA mapped into uP memory - can sustain
wirespeed with 100Mbit Ethernet but that isn't fast enough for you. The
approach would work with a processor with a Gbit Ethernet interface. We
use these in numbers (up to 8) with one PC and going in both directions
- total IO about 40 Mbyte/s

FPGA -> PCI // IO card in PC. This could sustain 20Mbyte/s to disk on a
reasonable PC (Windows XP and (don't laugh) VB6). The IO card we used
was Adlink PCI 7300A (or something like). They probably do a better one
now. This system all worked quite well and happily fills up Terrabyte
hard drives.

I just noticed that you need both directions - that gets harder because
when data goes from PC to FPGA you either need a big buffer in the FPGA
or real time data from the PC.

FPGA -> PCI -> PC should let the PC shove data into buffers in RAM, then
have the FPGA extract it via DMA -- but that'll complicate your PCI
interface.

If you use USB and standard drivers you should allow for at least 0.5
seconds of buffer on the FPGA (either direction).

Is that still the case if you're using isochronous transfers, and making
sure that the PC is tuned for feeding your app?

The Adlink driver didn't need any FPGA side buffering for data into the
PC but we never used it the other way round.

PC's are quite good at buffering incoming Ethernet data but you'll need
to do the work on the FPGA side for the other direction. We like to have
at least 1 second of buffer !

This has all got a bit rambly - hope you get some ideas you can use.

Michael Kellett

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

 

[Jon Elson]

As for USB: It's a generic name. The only solution we're aware of is
Cypress' EZUSB. Whether it fits the data rates is considered a
"maybe".

I got 30+ MB/sec both in and out (not simultaneously) with a Cypress

EZUSB (CY7C68013A) chip on a Dell desktop with a core2 Duo CPU.
It was very impressive.

Jon

 

[Uwe Bonnes]

MK <mk@nospam.co.uk> wrote:

FTDI chip and USB - least effort but I only went up to perhaps 4 Mbyte/s
- I always worry about USB.

We use it at > 16 MiByte/s ...

--
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

 

[Thomas Heller]

Am 27.03.2012 13:10, schrieb Bill Valores:

Hello all,

My team needs to design our own piece of testing equipment for our
project. I'll spare you the gory details, and just say that we will
need to collect data at some 20 Mbyte/sec (possibly continuously) and
somehow get it to a PC computer running Windows. A fancy GUI
application will then present this to the operator. A similar link is
necessary in the other direction for signal injection.

The FPGA does some data processing, so we can't just buy a data
capture card. We may consider a capturing card to interface with the
FPGA digitally.

So my question is: What's your recommendation for the PC-FPGA
communication? Given a fairly skilled engineering team and a
management that understands this is not a cheap quickie (but still
wants to keep costs and efforts at a minimum, of course) what would
you suggest? USB? PCIe? Ethernet? Capture data from debug pins?
Something else?

I can recommend the FPGA modules from opal kelly. IMO they have a nice
interface both on the HDL side and on the PC-side. They allow to easily
upgrade from a USB connection to a PCIe connection, without too much
changes. Personally I have only needed USB so far...

Thomas (happy customer)

 

[MK]

If you use USB and standard drivers you should allow for at least 0.5
seconds of buffer on the FPGA (either direction).

Is that still the case if you're using isochronous transfers, and making
sure that the PC is tuned for feeding your app?

The problem is in tuning the (Windows) PC - you might ship the system
running fine and then you get a call from the customer and the PC turns
out to be running a load of other stuff that their IT department refuses
to remove. It shouldn't happen but it does. We found the men with the
cheque books usually sided with the IT department so it was better just
to make it work whatever.

Never got any joy at all with isochronous transfers - if the FTDI
drivers support them it might be worth a go.

Michael Kellett

 

[Tim Wescott]

On Thu, 29 Mar 2012 15:30:59 +0100, MK wrote:

If you use USB and standard drivers you should allow for at least 0.5
seconds of buffer on the FPGA (either direction).

Is that still the case if you're using isochronous transfers, and
making sure that the PC is tuned for feeding your app?

The problem is in tuning the (Windows) PC - you might ship the system
running fine and then you get a call from the customer and the PC turns
out to be running a load of other stuff that their IT department refuses
to remove. It shouldn't happen but it does. We found the men with the
cheque books usually sided with the IT department so it was better just
to make it work whatever.

Never got any joy at all with isochronous transfers - if the FTDI
drivers support them it might be worth a go.

Michael Kellett

It depends on what the environment is, of course -- if the "PC" is
embedded in an instrument or a machine, then you've got a much better
chance of fending off a hypothetical IT department.

I suppose that an overactive IT gnome might attempt to upgrade the
Windows installation on a $50000 oscilloscope -- but I don't know if
they'd try it a second time.

--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com

 

[John Miles]

On Mar 29, 4:02 am, Thomas Heller <thel...@ctypes.org> wrote:

I can recommend the FPGA modules from opal kelly.  IMO they have a nice
interface both on the HDL side and on the PC-side.  They allow to easily
upgrade from a USB connection to a PCIe connection, without too much
changes.  Personally I have only needed USB so far...

Thomas (happy customer)

Agreed with recommendation for Opal Kelly. I've recently started
shipping an instrument that sends about 16 MB/sec to the PC via their
XEM3005 board, and have no complaints. Their hardware quality has
been solid so far, and tech support is more or less instant.

I wrote my own firmware so I can't say much about FrontPanel. I
suspect it's among the best general-purpose API+host interface
packages available, though. Jake's pretty hardcore.

-- john

 

[ralph]

From my experience Ethernet is definitely a good way to do it (1000BASE-T)
I have written a simple MAC layer on SP605 board (with PHY) which onl
deals with ARP, ICMP (for ping), and UDP protocols.

I got approx. 50MBytes downloading speed(from PC to FPGA) with UD
(1024bytes payload). Uploading speed not measured though. But I think i
should meet 20MBps requriement if software can catch and store the dat
quicker enough.



---------------------------------------
Posted through http://www.FPGARelated.com

 

[Dr. Beau Webber]

On Tuesday, 27 March 2012 12:10:18 UTC+1, Bill Valores wrote:

Hello all,

My team needs to design our own piece of testing equipment for our
project. I'll spare you the gory details, and just say that we will
need to collect data at some 20 Mbyte/sec (possibly continuously) and
somehow get it to a PC computer running Windows.

Hi Bill,
See my post of the 28 May, or, to see it with embedded example YouTube videos, go see :
FPGA Modular Firmware Skeleton for multiple instruments - Morph-IC-II, YouTube videos.
http://www.element14.com/community/groups/fpga-group/blog/2012/04/28/fpga-modular-firmware-skeleton-for-multiple-instruments--morph-ic-ii-youtube-videos

This does just what you want - 60MB.s-1 burst, (how much you get continuous depends on the PC and what else you are doing on the USB bus).

It provides the USB interface to a group of instrument interfaces - what you build into each interface is up to you.
Not free - very low price for individual use, a good value price for commercial use, would cost you much more to develop.
You just need to talk to a .dll to drive it - example code for testing provided - See videos for example use.
cheers, Dr. Beau Webber