Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
FPGA communication with a PC (Windows)
878 views
Skip to first unread message
Bill Valores
Mar 27, 2012, 7:10:18 AM3/27/12
to
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
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
Mar 27, 2012, 7:36:04 AM3/27/12
to
"Bill Valores" <bill.v...@gmail.com> wrote in message
news:33dd12b5-c2a4-4dab...@w32g2000vbt.googlegroups.com...
lane gen1 may be just enough, so any other newer gen would do too.
news:33dd12b5-c2a4-4dab...@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
> communication?
lane gen1 may be just enough, so any other newer gen would do too.
andy.mc...@tesco.net
Mar 27, 2012, 7:36:34 AM3/27/12
to
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
Mar 27, 2012, 7:37:07 AM3/27/12
to
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?
> 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.
>
> 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?
>
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
Mar 27, 2012, 8:22:12 AM3/27/12
to
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".
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".
Uwe Bonnes
Mar 27, 2012, 8:49:36 AM3/27/12
to
into the PC.
--
Uwe Bonnes b...@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Arlet Ottens
Mar 27, 2012, 10:41:49 AM3/27/12
to
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.
RCIngham
Mar 27, 2012, 11:09:46 AM3/27/12
to
[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).
You will want a s/w element to accept TCP/IP packets (a stack in HDL is
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
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).
You will want a s/w element to accept TCP/IP packets (a stack in HDL is
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
Mar 27, 2012, 12:19:32 PM3/27/12
to
Bill Valores <bill.v...@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:
>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?
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
Mar 27, 2012, 12:36:20 PM3/27/12
to
Arlet Ottens <usen...@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
>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.
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.
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.
Arlet Ottens
Mar 27, 2012, 1:22:10 PM3/27/12
to
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
>> 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.
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.
Bill Valores
Mar 27, 2012, 1:26:51 PM3/27/12
to
On Mar 27, 5:09 pm, "RCIngham"
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.
<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.
> [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).
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
Mar 27, 2012, 1:35:00 PM3/27/12
to
>
> FTDI has parallel USB interface chips:http://www.ftdichip.com/Products/ICs/FT2232H.htm
>
> USB gives the least hassle to a user.
Arlet Ottens
Mar 27, 2012, 1:39:10 PM3/27/12
to
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
> 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.
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
Mar 27, 2012, 1:44:11 PM3/27/12
to
transfer 20MB/s)
Nicolas
Tim Wescott
Mar 27, 2012, 1:50:22 PM3/27/12
to
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
Mar 27, 2012, 3:23:52 PM3/27/12
to
In comp.arch.fpga,
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
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
Nico Coesel
Mar 27, 2012, 4:16:03 PM3/27/12
to
Tim Wescott <t...@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).
>
>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
>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.
(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.
scrts
Mar 28, 2012, 1:51:16 AM3/28/12
to
> 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
> 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.
have transceivers afaik. Anyway, is there any useful information about
implementing SATA in FPGA except a simple SATA standard?
Regards,
Tomas D.
scrts
Mar 28, 2012, 1:56:14 AM3/28/12
to
> 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
> 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.
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.
David Brown
Mar 28, 2012, 3:37:55 AM3/28/12
to
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...
Bill Valores
Mar 28, 2012, 6:20:08 AM3/28/12
to
Thanks, guys.
Does anyone have experience with this thing? http://xillybus.com/
As for Ethernet and UDP, a soft CPU is probably the solution. And yes,
unfortunately Linux is out of the question.
Or raw Ethernet packets to broadcast address, which sounds simpler to
me + libpcap on the PC. And implement a protocol for retransmits.
SATA is an amusing direction, since the physical interface is just one
of those RocketIO transceivers. The "little problem" is that you then
need to implement the entire SCSI emulation, since the host can use a
disk however it chooses, so anything covered by the SCSI standard can
happen. This makes the PCIe from scratch solution sound like a piece
of cake. :)
Does anyone have experience with this thing? http://xillybus.com/
As for Ethernet and UDP, a soft CPU is probably the solution. And yes,
unfortunately Linux is out of the question.
Or raw Ethernet packets to broadcast address, which sounds simpler to
me + libpcap on the PC. And implement a protocol for retransmits.
SATA is an amusing direction, since the physical interface is just one
of those RocketIO transceivers. The "little problem" is that you then
need to implement the entire SCSI emulation, since the host can use a
disk however it chooses, so anything covered by the SCSI standard can
happen. This makes the PCIe from scratch solution sound like a piece
of cake. :)
Morten Leikvoll
Mar 28, 2012, 8:00:14 AM3/28/12
to
"scrts" <hid...@email.com> wrote in message
news:jku8sg$b46$1...@dont-email.me...
http://www.xilinx.com/support/documentation/application_notes/xapp870.pdf
http://www.altera.com/literature/wp/wp-01093-arria-iv-gx-sata-sas.pdf
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:
> have transceivers afaik. Anyway, is there any useful information about
> implementing SATA in FPGA except a simple SATA standard?
http://www.xilinx.com/support/documentation/application_notes/xapp870.pdf
http://www.altera.com/literature/wp/wp-01093-arria-iv-gx-sata-sas.pdf
Uwe Bonnes
Mar 28, 2012, 10:27:43 AM3/28/12
to
side, look into libftdi
http://www.intra2net.com/en/developer/libftdi/examples/stream_test.c
for a sample implementation.
MK
Mar 28, 2012, 12:23:29 PM3/28/12
to
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
Mar 28, 2012, 1:18:25 PM3/28/12
to
MK <m...@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 ...
> FTDI chip and USB - least effort but I only went up to perhaps 4 Mbyte/s
> - I always worry about USB.
Tim Wescott
Mar 28, 2012, 1:23:54 PM3/28/12
to
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).
Tim Wescott
Mar 28, 2012, 1:27:40 PM3/28/12
to
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).
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
Jon Elson
Mar 28, 2012, 3:04:01 PM3/28/12
to
>
>>> 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".
>>
EZUSB (CY7C68013A) chip on a Dell desktop with a core2 Duo CPU.
It was very impressive.
Jon
John Adair
Mar 28, 2012, 4:22:51 PM3/28/12
to
Bill
There are a range of options but we are running our Raggedstone2 at
200 MB/s for data capture and more. That's a PCIe card. We have other
PCIe and PCI cards as well with more and less performance. We can
supply things like drivers and GUIs. Some of this will be appearing as
standard products but meanwhile if that is of interest contact us
directly. There is a contact page on our website www.enterpoint.co.uk
or email boardsales at our webroot.
We also have some USB solutions that might just meet the rquirement as
well but that is more marginal. When our USB3 products push out these
should be much better in this respect.
John Adair
Enterpoint Ltd.
There are a range of options but we are running our Raggedstone2 at
200 MB/s for data capture and more. That's a PCIe card. We have other
PCIe and PCI cards as well with more and less performance. We can
supply things like drivers and GUIs. Some of this will be appearing as
standard products but meanwhile if that is of interest contact us
directly. There is a contact page on our website www.enterpoint.co.uk
or email boardsales at our webroot.
We also have some USB solutions that might just meet the rquirement as
well but that is more marginal. When our USB3 products push out these
should be much better in this respect.
John Adair
Enterpoint Ltd.
Bill Valores
Mar 28, 2012, 4:38:46 PM3/28/12
to
Thanks again. You rock. :)
I'll try to sum up my top list to this point. There's a lot of
information to mix and match, so I might have missed something.
In no particular order:
* The FTDI chip will get a closer look, despite somewhat contradicting
reports about its performance. (Cypress is out because of my own bad
memories with the EZUSB chip).
* Raw Ethernet with broadcast MAC addresses (to spare myself the soft
CPU), a memory controller to store data for retransmission and libpcap
on the PC. And a protocol for retransmissions, which could be fairly
trivial. The main advantage of this method is that there are no doubts
about the bandwidth. Playing around with a DDR memory controller is
probably the less fun part here.
* PCIe with Xillybus. Since they promise all will be up and running in
no-time, it's either the easiest solution by far or a quick and not so
painful failure. Won't hurt.
* ... or PCIe done manually, if the previous option won't go well. And
custom drivers for Windows. I'm not sure I want to keep this option on
this list.
Thanks again,
Bill
I'll try to sum up my top list to this point. There's a lot of
information to mix and match, so I might have missed something.
In no particular order:
* The FTDI chip will get a closer look, despite somewhat contradicting
reports about its performance. (Cypress is out because of my own bad
memories with the EZUSB chip).
* Raw Ethernet with broadcast MAC addresses (to spare myself the soft
CPU), a memory controller to store data for retransmission and libpcap
on the PC. And a protocol for retransmissions, which could be fairly
trivial. The main advantage of this method is that there are no doubts
about the bandwidth. Playing around with a DDR memory controller is
probably the less fun part here.
* PCIe with Xillybus. Since they promise all will be up and running in
no-time, it's either the easiest solution by far or a quick and not so
painful failure. Won't hurt.
* ... or PCIe done manually, if the previous option won't go well. And
custom drivers for Windows. I'm not sure I want to keep this option on
this list.
Thanks again,
Bill
Thomas Heller
Mar 29, 2012, 7:02:51 AM3/29/12
to
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
> 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?
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
Mar 29, 2012, 10:30:59 AM3/29/12
to
>
>> 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
>> 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?
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
Mar 29, 2012, 11:20:06 AM3/29/12
to
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
Mar 30, 2012, 3:18:24 AM3/30/12
to
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
> 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)
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
May 3, 2012, 3:38:18 PM5/3/12
to
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 only
deals with ARP, ICMP (for ping), and UDP protocols.
I got approx. 50MBytes downloading speed(from PC to FPGA) with UDP
(1024bytes payload). Uploading speed not measured though. But I think it
should meet 20MBps requriement if software can catch and store the data
quicker enough.
---------------------------------------
Posted through http://www.FPGARelated.com
I have written a simple MAC layer on SP605 board (with PHY) which only
deals with ARP, ICMP (for ping), and UDP protocols.
I got approx. 50MBytes downloading speed(from PC to FPGA) with UDP
(1024bytes payload). Uploading speed not measured though. But I think it
should meet 20MBps requriement if software can catch and store the data
quicker enough.
---------------------------------------
Posted through http://www.FPGARelated.com
Dr. Beau Webber
May 4, 2012, 3:04:38 PM5/4/12
to
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,
> 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.
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
0 new messages