FPGA communication with a PC (Windows)

[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?

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

 

[Morten Leikvoll]

"Bill Valores" <bill.valores@gmail.com> wrote in message
news:33dd12b5-c2a4-4dab-bfba-8e801b27c37c@w32g2000vbt.googlegroups.com...

So my question is: What's your recommendation for the PC-FPGA
communication?

Buy a FPGA on a PCIe development board, then add your stuff to it. A single
lane gen1 may be just enough, so any other newer gen would do too.

 

On Tuesday, March 27, 2012 12:10:18 PM 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. 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

Hi Bill,

My first thought would be to see if something from National Instruments' extensive range would suit your requirements. http://www.ni.com/fpga-hardware/

Even if you don't find an off-the-shelf solution from them, the website is a good resource for discovering the various comms and bus options.

NI are undoubtedly at the pricier end of such solutions, but they have put a great deal of effort into ease of use, flexibility and support.

You might even find that their Lab-View s/w can be used to create the GUI that you need.

--
Regards,

Andy McC

 

[KJ]

On Tuesday, March 27, 2012 7:10:18 AM UTC-4, Bill Valores wrote:

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.

20 MB/sec going back up to the FPGA as well? Or simply a link that controls the 20 MB/sec data that is going downstream to the PC?

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?

For a data point, 30-35 MB/sec is achievable via USB on a PC. At that point, Windows becomes the bottleneck. Whether you're purchasing or designing your own USB for the FPGA side of things you'll want to exercise simple data transfers to see what you can achieve with whatever you choose.

Also, you don't really mention what is the source for the FPGA data. That would likely affect whether you have an external box with FPGA that communicates with the PC or whether it would be better to put the FPGA on a card inside the PC. Based on what you wrote, I'm guessing that you're envisioning an external box of some sort, but you should clarify.

Kevin Jennings

 

[Bill Valores]

Thanks for your answers so far. I'll address some issues shortly.

Yes, National Instruments was one of the first thoughts. The main
concern about this solution the per unit price in case we want to
duplicate the system. But it's definitely not ruled out.

Buying an PCIe development board is indeed easy. Implementing the
logic for the PCIe interface (I suppose DMA is the only option) and
writing the Windows drivers doesn't sound like a trip in the
rosegarden to me.

As for the form factor: A separate box solution, or a card stuck in
the PC, both go. Data needs to be flowing in both directions
simultaneously at 20 MB/sec in each direction.

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".

 

[Arlet Ottens]

On 03/27/2012 02:22 PM, Bill Valores wrote:

Thanks for your answers so far. I'll address some issues shortly.

Yes, National Instruments was one of the first thoughts. The main
concern about this solution the per unit price in case we want to
duplicate the system. But it's definitely not ruled out.

Buying an PCIe development board is indeed easy. Implementing the
logic for the PCIe interface (I suppose DMA is the only option) and
writing the Windows drivers doesn't sound like a trip in the
rosegarden to me.

As for the form factor: A separate box solution, or a card stuck in
the PC, both go. Data needs to be flowing in both directions
simultaneously at 20 MB/sec in each direction.

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 wouldn't recommend USB. It's too flaky for reliable transfer.

Why not ethernet ? Interfacing with a PHY is simple, and if you use UDP
packets in a controlled environment (fixed IP addresses), the MAC layer
is fairly straightforward too.

Capturing the UDP traffic can be done with simple tool like netcat.

 

[Uwe Bonnes]

Bill Valores <bill.valores@gmail.com> wrote:

Thanks for your answers so far. I'll address some issues shortly.

Yes, National Instruments was one of the first thoughts. The main
concern about this solution the per unit price in case we want to
duplicate the system. But it's definitely not ruled out.

Buying an PCIe development board is indeed easy. Implementing the
logic for the PCIe interface (I suppose DMA is the only option) and
writing the Windows drivers doesn't sound like a trip in the
rosegarden to me.

As for the form factor: A separate box solution, or a card stuck in
the PC, both go. Data needs to be flowing in both directions
simultaneously at 20 MB/sec in each direction.

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".

A FT(2)232H in synchronous FIFO mode should also be able to pump that rate
into the PC.
--
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de

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

 

[RCIngham]

[replying to OP]

Ethernet is definitely a reasonable-risk option. For 20Mbytes/sec you wil
need Gigabit Ethernet, so an FPGA with a hard MAC is a good idea, e.g
Vitex-5 (other vendors' products may be equally suitable).

You will want a s/w element to accept TCP/IP packets (a stack in HDL i
theoretically possible). You can send UDP/IP from HDL.

PCIe might be a better idea, but never done it...


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

 

[Nico Coesel]

Bill Valores <bill.valores@gmail.com> 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?

FTDI has parallel USB interface chips:
http://www.ftdichip.com/Products/ICs/FT2232H.htm

USB gives the least hassle to a user.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

 

[Nico Coesel]

Arlet Ottens <usenet+5@c-scape.nl> wrote:

On 03/27/2012 02:22 PM, Bill Valores wrote:
Thanks for your answers so far. I'll address some issues shortly.

Yes, National Instruments was one of the first thoughts. The main
concern about this solution the per unit price in case we want to
duplicate the system. But it's definitely not ruled out.

Buying an PCIe development board is indeed easy. Implementing the
logic for the PCIe interface (I suppose DMA is the only option) and
writing the Windows drivers doesn't sound like a trip in the
rosegarden to me.

As for the form factor: A separate box solution, or a card stuck in
the PC, both go. Data needs to be flowing in both directions
simultaneously at 20 MB/sec in each direction.

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 wouldn't recommend USB. It's too flaky for reliable transfer.

That depends on the software driver and the EMC/EMI protection applied
to the data lines.

Why not ethernet ? Interfacing with a PHY is simple, and if you use UDP
packets in a controlled environment (fixed IP addresses), the MAC layer
is fairly straightforward too.

Capturing the UDP traffic can be done with simple tool like netcat.

Libpcap is easy to use but don't forget that when using ethernet you
are usually sharing the bandwidth, have to depend on the quality of
network components and the people who maintain it. I wouldn't go that
route unless it s absolutely necessary.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

 

[Arlet Ottens]

On 03/27/2012 06:36 PM, Nico Coesel wrote:

Capturing the UDP traffic can be done with simple tool like netcat.

Libpcap is easy to use but don't forget that when using ethernet you
are usually sharing the bandwidth, have to depend on the quality of
network components and the people who maintain it. I wouldn't go that
route unless it s absolutely necessary.

It sounded like the OP wouldn't object to setting up a dedicated
connection for this project. If not, USB would present a similar
problem, but even less controllable. With USB, bandwidth depends a lot
on efficiency of driver and host implementation, and can vary with the
amount of bit stuffing.

 

[Arlet Ottens]

On 03/27/2012 07:26 PM, Bill Valores 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.

Depends on how you want to use it. Is it strictly used in a controlled
environment ? If so, you could hard code the MAC adress in the FPGA, or
send an initial packet from PC to FPGA. The FPGA could then extract the
addresses from the PC's packet, and swap them in its responses.

 

[Nicolas Matringe]

Le 27/03/2012 19:35, Bill Valores a écrit :

FTDI has parallel USB interface chips:http://www.ftdichip.com/Products/ICs/FT2232H.htm

USB gives the least hassle to a user.

That's an interesting one. Will definitely follow that up.

I am currently using one in a project, works a treat (though I don't
transfer 20MB/s)

Nicolas

 

[Tim Wescott]

On Tue, 27 Mar 2012 04:10:18 -0700, 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).

I was going to just say USB, then I read all the responses. And, I'm
still going to just say "USB"!

I've seen FPGA designers struggling to get PCI working in an FPGA. They
did it, but it wasn't a trivial task and it took a lot of messing
around. Implementing a client-side USB in FPGA should be way easier than
PCI, and if you can get an FTDI chip to work -- go for it.

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.

No matter what you do, though, I think your biggest problem isn't going
to be getting the bits into the PC hardware: I think it's going to be
getting past the Windows software to actually _do_ something with those
bits. I wouldn't even think about trying this unless I had some Windows
driver whizzes to help me out.

--
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

 

[Stef]

In comp.arch.fpga,
Bill Valores <bill.valores@gmail.com> wrote:

On Mar 27, 5:09 pm, "RCIngham"
robert.ingham@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote:
[replying to OP]

Ethernet is definitely a reasonable-risk option. For 20Mbytes/sec you will
need Gigabit Ethernet, so an FPGA with a hard MAC is a good idea, e.g.
Vitex-5 (other vendors' products may be equally suitable).

I think this blog post summarizes the Ethernet option pretty well.
Even though it looks like it was written to promote a certain
solution, the points made appear to be valid.

http://billauer.co.il/blog/2011/11/gigabit-ethernet-fpga-xilinx-data-acquisition/

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.

I'm not sure it does work (need to look it up sometime or just test), but
if you use ethernet as a point-to-point connection, you may be able to
just use the broadcast address and don't even need to use ARP.

--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

Blessed is the man who, having nothing to say, abstains from giving
wordy evidence of the fact.
-- George Eliot

 

[Bill Valores]

On Mar 27, 5:09 pm, "RCIngham"
<robert.ingham@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com> wrote:

Ethernet is definitely a reasonable-risk option. For 20Mbytes/sec you will
need Gigabit Ethernet, so an FPGA with a hard MAC is a good idea, e.g.
Vitex-5 (other vendors' products may be equally suitable).

I think this blog post summarizes the Ethernet option pretty well.
Even though it looks like it was written to promote a certain
solution, the points made appear to be valid.

http://billauer.co.il/blog/2011/11/gigabit-ethernet-fpga-xilinx-data-acquisition/

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.

 

[Bill Valores]

FTDI has parallel USB interface chips:http://www.ftdichip.com/Products/ICs/FT2232H.htm

USB gives the least hassle to a user.

That's an interesting one. Will definitely follow that up.

 

[Nico Coesel]

Tim Wescott <tim@seemywebsite.com> wrote:

On Tue, 27 Mar 2012 04:10:18 -0700, 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).

No matter what you do, though, I think your biggest problem isn't going
to be getting the bits into the PC hardware: I think it's going to be
getting past the Windows software to actually _do_ something with those
bits. I wouldn't even think about trying this unless I had some Windows
driver whizzes to help me out.

It depends. About a decade ago I was involved in developing a PCI card
(I was responsible for the FPGA design). Writing the Windows driver
proved to be the biggest challenge. We didn't even got to the point of
using memory-to-memory transfers.

Nowadays there is a library called libusb which can deal with a lot of
the USB complexities from userspace (application level). It should be
relatively easy to get a self build USB device going.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

 

[scrts]

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?

Regards,
Tomas D.

 

[scrts]

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.

Regards,
Tomas D.