Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 153550

Article: 153550
Subject: Re: FPGA communication with a PC (Windows)
From: "RCIngham" <robert.ingham@n_o_s_p_a_m.n_o_s_p_a_m.gmail.com>
Date: Tue, 27 Mar 2012 10:09:46 -0500
Links: << >>  << T >>  << A >>
[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

Article: 153551
Subject: Re: FPGA communication with a PC (Windows)
From: nico@puntnl.niks (Nico Coesel)
Date: Tue, 27 Mar 2012 16:19:32 GMT
Links: << >>  << T >>  << A >>
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=.)
--------------------------------------------------------------

Article: 153552
Subject: Re: FPGA communication with a PC (Windows)
From: nico@puntnl.niks (Nico Coesel)
Date: Tue, 27 Mar 2012 16:36:20 GMT
Links: << >>  << T >>  << A >>
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=.)
--------------------------------------------------------------

Article: 153553
Subject: Re: FPGA communication with a PC (Windows)
From: Arlet Ottens <usenet+5@c-scape.nl>
Date: Tue, 27 Mar 2012 19:22:10 +0200
Links: << >>  << T >>  << A >>
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.





Article: 153554
Subject: Re: FPGA communication with a PC (Windows)
From: Bill Valores <bill.valores@gmail.com>
Date: Tue, 27 Mar 2012 10:26:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Mar 27, 5:09=A0pm, "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 wil=
l
> 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-acquis=
ition/

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.

Article: 153555
Subject: Re: FPGA communication with a PC (Windows)
From: Bill Valores <bill.valores@gmail.com>
Date: Tue, 27 Mar 2012 10:35:00 -0700 (PDT)
Links: << >>  << T >>  << A >>

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

Article: 153556
Subject: Re: FPGA communication with a PC (Windows)
From: Arlet Ottens <usenet+5@c-scape.nl>
Date: Tue, 27 Mar 2012 19:39:10 +0200
Links: << >>  << T >>  << A >>
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.

Article: 153557
Subject: Re: FPGA communication with a PC (Windows)
From: Nicolas Matringe <nicolas.matringe@fre.fre>
Date: Tue, 27 Mar 2012 19:44:11 +0200
Links: << >>  << T >>  << A >>
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

Article: 153558
Subject: Re: FPGA communication with a PC (Windows)
From: Tim Wescott <tim@seemywebsite.com>
Date: Tue, 27 Mar 2012 12:50:22 -0500
Links: << >>  << T >>  << A >>
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

Article: 153559
Subject: Re: FPGA communication with a PC (Windows)
From: Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid>
Date: Tue, 27 Mar 2012 21:23:52 +0200
Links: << >>  << T >>  << A >>
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

Article: 153560
Subject: Re: FPGA communication with a PC (Windows)
From: nico@puntnl.niks (Nico Coesel)
Date: Tue, 27 Mar 2012 20:16:03 GMT
Links: << >>  << T >>  << A >>
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=.)
--------------------------------------------------------------

Article: 153561
Subject: Re: FPGA communication with a PC (Windows)
From: "scrts" <hidden@email.com>
Date: Wed, 28 Mar 2012 08:51:16 +0300
Links: << >>  << T >>  << A >>
> 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.



Article: 153562
Subject: Re: FPGA communication with a PC (Windows)
From: "scrts" <hidden@email.com>
Date: Wed, 28 Mar 2012 08:56:14 +0300
Links: << >>  << T >>  << A >>
> 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. 



Article: 153563
Subject: Re: FPGA communication with a PC (Windows)
From: David Brown <david@westcontrol.removethisbit.com>
Date: Wed, 28 Mar 2012 09:37:55 +0200
Links: << >>  << T >>  << A >>
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...


Article: 153564
Subject: Re: FPGA communication with a PC (Windows)
From: "Morten Leikvoll" <mleikvol@yahoo.nospam>
Date: Wed, 28 Mar 2012 14:00:14 +0200
Links: << >>  << T >>  << A >>
"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



Article: 153565
Subject: Re: FPGA communication with a PC (Windows)
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Wed, 28 Mar 2012 14:27:43 +0000 (UTC)
Links: << >>  << T >>  << A >>
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 ----------

Article: 153566
Subject: Re: FPGA communication with a PC (Windows)
From: MK <mk@nospam.co.uk>
Date: Wed, 28 Mar 2012 17:23:29 +0100
Links: << >>  << T >>  << A >>
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





Article: 153567
Subject: Re: FPGA communication with a PC (Windows)
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Wed, 28 Mar 2012 17:18:25 +0000 (UTC)
Links: << >>  << T >>  << A >>
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 ----------

Article: 153568
Subject: Re: FPGA communication with a PC (Windows)
From: Tim Wescott <tim@seemywebsite.com>
Date: Wed, 28 Mar 2012 12:23:54 -0500
Links: << >>  << T >>  << A >>
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

Article: 153569
Subject: Re: FPGA communication with a PC (Windows)
From: Tim Wescott <tim@seemywebsite.com>
Date: Wed, 28 Mar 2012 12:27:40 -0500
Links: << >>  << T >>  << A >>
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

Article: 153570
Subject: Re: FPGA communication with a PC (Windows)
From: Jon Elson <jmelson@wustl.edu>
Date: Wed, 28 Mar 2012 14:04:01 -0500
Links: << >>  << T >>  << A >>


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

Article: 153571
Subject: Re: FPGA communication with a PC (Windows)
From: Thomas Heller <theller@ctypes.org>
Date: Thu, 29 Mar 2012 13:02:51 +0200
Links: << >>  << T >>  << A >>
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)

Article: 153572
Subject: Re: FPGA communication with a PC (Windows)
From: MK <mk@nospam.co.uk>
Date: Thu, 29 Mar 2012 15:30:59 +0100
Links: << >>  << T >>  << A >>
>
>> 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

Article: 153573
Subject: Re: FPGA communication with a PC (Windows)
From: Tim Wescott <tim@seemywebsite.please>
Date: Thu, 29 Mar 2012 10:20:06 -0500
Links: << >>  << T >>  << A >>
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

Article: 153574
Subject: Re: Spartan 3A counter speed ?
From: Jon Elson <jmelson@wustl.edu>
Date: Fri, 30 Mar 2012 14:11:08 -0500
Links: << >>  << T >>  << A >>
Gabor wrote:


> Well, it took me about 5 minutes to code up a simple project with
> a 32-bit counter and enough registers to prevent other logic from
> being the worst-case path.  In a XC3S50AN-5 there are enough rows
> to keep 32-bits in a single carry chain.  With no constraints, the
> design built and reported 4.402 ns minimum clock period (after
> place & route) or about 227 MHz.
OK, thanks very much.  The request was to run a counter at 100 MHz,
and it sounds like this is doable.  There are some concerns about crossing
clock boundaries that need to be figured out, but it looks like
it can be done.  Thanks VERY much for doing the leg work on this!

I've been learning how to set up a GUI for the project, the one area
I really didn't know enough about.  The FPGA part seemed simple except
for the performance.

Jon



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search