Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
[This followup was posted to comp.arch.fpga and a copy was sent to the cited author.] In article <XtKdnbZLV6lQVPHSnZ2dnUVZ_oadnZ2d@giganews.com>, jmelson@wustl.edu says... > > Hello, > > Does anybody have a very rough estimate of how fast > you can run a 32-bit counter in a Spartan 3AN FPGA? > > Thanks, > > Jon The answer to your question will be had by reading the Xilinx Product Data Sheets for the basic information which comes in a modular format including timing for I/O, logic cells, routing and globally distributed networks. The actual timing achievable will be determined by the specific design of the counter and how that design is instantiated in the part. -- Michael Karas Carousel Design Solutions http://www.carousel-design.comArticle: 153526
On Mar 9, 10:26=A0am, Gabor <ga...@szakacs.invalid> wrote: > Berti Schueler wrote: > > Hi > > > in a project I am using a Virtex-6 with GTXRocketIOtransceivers which I > > want to interface with a 4x 6.5 Gb/s interface on the RX side. One proj= ect > > contraint is not to use any channel coding, i.e. only 8B data. So I hav= e 4x > > 6.5Gb/s that I have to synchronize on the RX path. That gives me two ma= jor > > challanges: > > > a) Somehow achieve a clock recovery > > b) Synchronize the incoming data > > > Due to the fact that I am not allowed to use a specific channel coding,= I > > cannot get the clock signal extracted from my data. So my idea is to us= e one > > additional channel to send a 1-0-pattern to get a clock reference for t= he > > whole interface. Use this as RXRECCLK (RX recovered clock) to clock the > > other RocketIOs. Is this possible? If so, done! Then use a training pat= tern > > on the other channels to be able to shift and deskew the data (given th= at > > the skew does not change over time). Thereafter transmit the data over = the 4 > > parallel channels. > > > So what do you think of this concept? Is it feasible? Any other suggest= ions? > > > Thanks, > > Berti > > Your solution sounds remarkably like Channel-Link, and it's not likely > to work at 6.5 Gbps. =A0The problem (even if it were possible to wire the > bit clocks together inside the V6) is that you're looking at a daunting > task to match the prop delays between data and clock channels. =A0You > have a much better chance of success using 8B-10B encoding and > increasing the clock rate to allow the required throughput. =A0Is > the Rx side also implemented in V6? > > -- Gabor I may have a similar problem so just brainstorming here: is it possible to use the recovered clock from the clock channel channel to a PLL to have better clock performance?Article: 153527
On Fri, 23 Mar 2012 14:02:54 -0700, aleksazr wrote: > Damn it, I've found the error, the wire is badly soldered. And fixing one wire is worse than having to replace a whole FPGA? -- 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.comArticle: 153528
Hi, I have this project where I have to design a tachometer using VHDL. The thing is I m pretty new to the field of electronic projects and I m very new to VHDL. The project asks me to count the Rotations/per Minute from a motor. It has to be in the range 19-98 RPM, the measurement time is 1.1s, and the display resolution is 0.1 . The good part is that I dont have to create a system to get this rotations, they are given to me thru a generator. I just have to count the pulses and display the result. [url]http://imageshack.us/photo/my-images/546/blockvk.jpg[/url] So, I tought I'll use an AND gate with the signal from the general as one input and the clock divided so I'll obtain the period of 1.1s . [url]http://imageshack.us/photo/my-images/839/clockbg.jpg/[/url] What I have to do next is when i press a button it will count the pulses for 1.1s and then display the result. [During counting the display will be OFF]. Sorry for the long post but the first problem resumes to this. How do i design a clock divider so I can get a period of 1.1s. I have a basic clock divider code where i count the rising edges and then i change the state of clock. But how many edges i have to count? So : How do i get a clock with 0.909 freqvency from 50 MHZ internal clock of fpga? [code]ENTITY CLKDIV IS PORT( CLK: IN STD_LOGIC; CLKOUT: OUT STD_LOGIC ); END CLKDIV; ARCHITECTURE DIV OF CLKDIV IS BEGIN PROCESS (CLK) VARIABLE COUNT: INTEGER RANGE 0 TO ???? :=0; VARIABLE STATE: STD_LOGIC := '1'; BEGIN IF(RISING_EDGE (CLK)) THEN IF(COUNT= )THEN COUNT:=0; STATE:= '1'; ELSE COUNT := COUNT+1; END IF; IF(COUNT=) STATE:= NOT STATE; END IF; END IF; CLKOUT <= STATE; END PROCESS; END DIV; [/code] --------------------------------------- Posted through http://www.FPGARelated.comArticle: 153529
On Sun, 25 Mar 2012 07:25:21 -0500, tachometer wrote: > Hi, > > I have this project where I have to design a tachometer using VHDL. The > thing is I m pretty new to the field of electronic projects and I m very > new to VHDL. > The project asks me to count the Rotations/per Minute from a motor. It > has to be in the range 19-98 RPM, the measurement time is 1.1s, and the > display resolution is 0.1 . > > The good part is that I dont have to create a system to get this > rotations, they are given to me thru a generator. I just have to count > the pulses and display the result. > [url]http://imageshack.us/photo/my-images/546/blockvk.jpg[/url] So, I > tought I'll use an AND gate with the signal from the general as one > input and the clock divided so I'll obtain the period of 1.1s . > [url]http://imageshack.us/photo/my-images/839/clockbg.jpg/[/url] > > What I have to do next is when i press a button it will count the pulses > for 1.1s and then display the result. [During counting the display will > be OFF]. > > Sorry for the long post but the first problem resumes to this. How do i > design a clock divider so I can get a period of 1.1s. I have a basic > clock divider code where i count the rising edges and then i change the > state of clock. But how many edges i have to count? > > So : How do i get a clock with 0.909 freqvency from 50 MHZ internal > clock of fpga? First: If it's a halfway decent university that you go to, you can always ask the teaching assistant or your prof. Second: Or a fellow student. Third: You have reduced this down to a question that you might have seen in an exam or as a homework problem in a digital logic class -- how did you answer it then? (Hint: how many pulses of a 50MHz clock happen in 1.1 seconds?) Fourth: Do you have sufficient information to get a resolution of 0.1 RPM by counting pulses for 1.1 seconds, or is your prof trying to herd you into a different approach? -- Tim Wescott Control system and signal processing consulting www.wescottdesign.comArticle: 153530
tachometer <bine.bai@n_o_s_p_a_m.yahoo.com> wrote: > I have this project where I have to design a tachometer using VHDL. The > thing is I m pretty new to the field of electronic projects and I m very > new to VHDL. Many years ago (in the TTL days, likely before microprocessors) there was a digital tachometer design in an electronics magazine. To get a reasonable update rate, they used a PLL frequency multiplier. If you want 1RPM resolution, you would otherwise have to count for one minute, and for 0.1RMS for 10 minutes. That is a little slow if someone wants to use it to adjust the speed. With a PLL frequency multiplier, if it can lock you can get an accurate RPM much sooner. -- glenArticle: 153531
glen herrmannsfeldt wrote: > > If you want 1RPM resolution, you would otherwise have to count for > one minute, and for 0.1RMS for 10 minutes. That is a little slow > if someone wants to use it to adjust the speed. I won't tell the solution, because it might be part of the homework, but assuming no jitter on the input signal and a 50 MHz clock in the FPGA, it is no problem at all to measure it with 0.1 RPM resolution, and even better. Of course, measuring 19 RPM in 1.1 second is impossible with a single measurement cycle, if the motor gives one impulse per rotation. Maybe it should be the update rate of the display? -- Frank Buss, http://www.frank-buss.de electronics and more: http://www.youtube.com/user/frankbussArticle: 153532
On Sun, 25 Mar 2012 19:30:39 +0000, glen herrmannsfeldt wrote: > tachometer <bine.bai@n_o_s_p_a_m.yahoo.com> wrote: > >> I have this project where I have to design a tachometer using VHDL. The >> thing is I m pretty new to the field of electronic projects and I m >> very new to VHDL. > > Many years ago (in the TTL days, likely before microprocessors) there > was a digital tachometer design in an electronics magazine. > > To get a reasonable update rate, they used a PLL frequency multiplier. > > If you want 1RPM resolution, you would otherwise have to count for one > minute, and for 0.1RMS for 10 minutes. That is a little slow if someone > wants to use it to adjust the speed. > > With a PLL frequency multiplier, if it can lock you can get an accurate > RPM much sooner. So think about what you've just said -- if there's sufficient information to do it with a PLL, doesn't that mean there's sufficient information in the incoming signal? And what might that sufficient information be? (Sorry about being so mystical -- this has _got_ to be a student project, and while I'm perfectly willing to help, I'm not going to just throw answers away. Hence, Socrates). -- Tim Wescott Control system and signal processing consulting www.wescottdesign.comArticle: 153533
On Mar 25, 5:15=A0pm, Tim Wescott <t...@seemywebsite.please> wrote: > On Sun, 25 Mar 2012 19:30:39 +0000, glen herrmannsfeldt wrote: > > tachometer <bine.bai@n_o_s_p_a_m.yahoo.com> wrote: > > >> I have this project where I have to design a tachometer using VHDL. Th= e > >> thing is I m pretty new to the field of electronic projects and I m > >> very new to VHDL. > > > Many years ago (in the TTL days, likely before microprocessors) there > > was a digital tachometer design in an electronics magazine. > > > To get a reasonable update rate, they used a PLL frequency multiplier. > > > If you want 1RPM resolution, you would otherwise have to count for one > > minute, and for 0.1RMS for 10 minutes. That is a little slow if someone > > wants to use it to adjust the speed. > > > With a PLL frequency multiplier, if it can lock you can get an accurate > > RPM much sooner. > > So think about what you've just said -- if there's sufficient information > to do it with a PLL, doesn't that mean there's sufficient information in > the incoming signal? =A0And what might that sufficient information be? > > (Sorry about being so mystical -- this has _got_ to be a student project, > and while I'm perfectly willing to help, I'm not going to just throw > answers away. =A0Hence, Socrates). > > -- > Tim Wescott > Control system and signal processing consultingwww.wescottdesign.com I don't mind giving more obvious hints... period =3D 1/freq RickArticle: 153534
Michael Karas wrote: > [This followup was posted to comp.arch.fpga and a copy was sent to the > cited author.] > > In article <XtKdnbZLV6lQVPHSnZ2dnUVZ_oadnZ2d@giganews.com>, > jmelson@wustl.edu says... >> >> Hello, >> >> Does anybody have a very rough estimate of how fast >> you can run a 32-bit counter in a Spartan 3AN FPGA? >> >> Thanks, >> >> Jon > > The answer to your question will be had by reading the Xilinx Product > Data Sheets for the basic information which comes in a modular format > including timing for I/O, logic cells, routing and globally distributed > networks. The actual timing achievable will be determined by the > specific design of the counter and how that design is instantiated in > the part. > Thanks, that's as close to a non-answer as you can get. The tricky part is the carry chain for long counters, and they really don't give you much info there, unless there's a secret manual I have not been able to find. JonArticle: 153535
On Mon, 26 Mar 2012 14:33:33 -0500 Jon Elson <jmelson@wustl.edu> wrote: > Thanks, that's as close to a non-answer as you can get. The tricky > part is the carry chain for long counters, and they really don't > give you much info there, unless there's a secret manual I have > not been able to find. > > Jon If I recall correctly, carry chain propagation was on the order of 700 ps/2 bits, but don't quote me on that. Part of the problem is that I don't think your question is answerable in the general case of "Spartan 3A". Different device sizes may or may not allow you to run 32-bits all on one carry chain. If you have to use two columns instead of just one, the additional performance hit of that next bit would be substantial. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.Article: 153536
Jon Elson <jmelson@wustl.edu> wrote: (snip) >> The answer to your question will be had by reading the Xilinx Product >> Data Sheets for the basic information which comes in a modular format >> including timing for I/O, logic cells, routing and globally distributed >> networks. The actual timing achievable will be determined by the >> specific design of the counter and how that design is instantiated in >> the part. > Thanks, that's as close to a non-answer as you can get. The tricky > part is the carry chain for long counters, and they really don't > give you much info there, unless there's a secret manual I have > not been able to find. Well, also it depends on how you use the counter. If you need to be able to latch the bits from the counter, then the timing might depend on that, and not the counter itself. (In race terms, to be able to get lap times while the counter continues to run.) -- glenArticle: 153537
Does anyone have any experience connecting an FPGA to a serious mess of DRAM? I'm thinking of something on the order of 16GB, possibly just by buying/socketing 4x4GB standard DIMMs. I don't need tremendous throughput; if I could average 50 MB/s I'd be fine. For sheer density I'm thinking DDR2. I'd like to avoid DDR3 if I can, simply because of the lack of support on low-end FPGAs. I could certainly go slower, say DDR1 or even SDR, but that seems to imply buying chips by the bucketload per board, and my assembly people will shoot me. Ideally this would be a Cyclone 3/4 project. Maybe Spartan 6 instead. The actual signal processing requirements are low, so I don't need that much crunching horsepower. Anyone manage to do something like this? -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.Article: 153538
Rob Gaddi wrote: > Does anyone have any experience connecting an FPGA to a serious mess of > DRAM? I'm thinking of something on the order of 16GB, possibly > just by buying/socketing 4x4GB standard DIMMs. > > I don't need tremendous throughput; if I could average 50 MB/s I'd be > fine. For sheer density I'm thinking DDR2. I'd like to avoid DDR3 if > I can, simply because of the lack of support on low-end FPGAs. I could > certainly go slower, say DDR1 or even SDR, but that seems to imply > buying chips by the bucketload per board, and my assembly people will > shoot me. > > Ideally this would be a Cyclone 3/4 project. Maybe Spartan 6 instead. > The actual signal processing requirements are low, so I don't need that > much crunching horsepower. > > Anyone manage to do something like this? > I don't recommend Spartan 6 for this application. Its internal memory controllers only handle single chips - not DIMMs. So even with a large S6 and multiple MCB's you can't get up to 16GB. And S6 is sufficiently slow without the MCB to make DDR2 a nightmare. If you want to run really slow, you might want to look into LPDDR memory, which can run with a much lower clock speed making the extra net lengths, loads, etc. more manageable. -- GaborArticle: 153539
Rob Gaddi wrote: > On Mon, 26 Mar 2012 14:33:33 -0500 > Jon Elson <jmelson@wustl.edu> wrote: > >> Thanks, that's as close to a non-answer as you can get. The tricky >> part is the carry chain for long counters, and they really don't >> give you much info there, unless there's a secret manual I have >> not been able to find. >> >> Jon > > If I recall correctly, carry chain propagation was on the order of 700 > ps/2 bits, but don't quote me on that. > > Part of the problem is that I don't think your question is answerable > in the general case of "Spartan 3A". Different device sizes may or may > not allow you to run 32-bits all on one carry chain. If you have to > use two columns instead of just one, the additional performance hit of > that next bit would be substantial. > 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. YMMV -- GaborArticle: 153540
Gabor wrote:
> Rob Gaddi wrote:
>> On Mon, 26 Mar 2012 14:33:33 -0500
>> Jon Elson <jmelson@wustl.edu> wrote:
>>
>>> Thanks, that's as close to a non-answer as you can get. The tricky
>>> part is the carry chain for long counters, and they really don't
>>> give you much info there, unless there's a secret manual I have
>>> not been able to find.
>>>
>>> Jon
>>
>> If I recall correctly, carry chain propagation was on the order of 700
>> ps/2 bits, but don't quote me on that.
>>
>> Part of the problem is that I don't think your question is answerable
>> in the general case of "Spartan 3A". Different device sizes may or may
>> not allow you to run 32-bits all on one carry chain. If you have to
>> use two columns instead of just one, the additional performance hit of
>> that next bit would be substantial.
>>
>
> 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.
>
> YMMV
>
> -- Gabor
Timing constraint: TS_clk = PERIOD TIMEGRP "clk" 4.4 ns HIGH 50%;
For more information, see Period Analysis in the Timing Closure User
Guide (UG612).
574 paths analyzed, 124 endpoints analyzed, 1 failing endpoint
1 timing error detected. (1 setup error, 0 hold errors, 0 component
switching limit errors)
Minimum period is 4.402ns.
--------------------------------------------------------------------------------
Paths for end point count_31 (SLICE_X11Y23.CIN), 30 paths
--------------------------------------------------------------------------------
Slack (setup path): -0.002ns (requirement - (data path - clock
path skew + uncertainty))
Source: count_0 (FF)
Destination: count_31 (FF)
Requirement: 4.400ns
Data Path Delay: 4.363ns (Levels of Logic = 16)
Clock Path Skew: -0.039ns (0.230 - 0.269)
Source Clock: clk_BUFGP rising at 0.000ns
Destination Clock: clk_BUFGP rising at 4.400ns
Clock Uncertainty: 0.000ns
Maximum Data Path: count_0 to count_31
Location Delay type Delay(ns) Physical Resource
Logical
Resource(s)
-------------------------------------------------
-------------------
SLICE_X11Y8.XQ Tcko 0.495 count<0>
count_0
SLICE_X11Y8.F3 net (fanout=1) 0.318 count<0>
SLICE_X11Y8.COUT Topcyf 1.026 count<0>
Mcount_count_lut<0>_INV_0
Mcount_count_cy<0>
Mcount_count_cy<1>
SLICE_X11Y9.CIN net (fanout=1) 0.000 Mcount_count_cy<1>
SLICE_X11Y9.COUT Tbyp 0.130 count<2>
Mcount_count_cy<2>
Mcount_count_cy<3>
SLICE_X11Y10.CIN net (fanout=1) 0.000 Mcount_count_cy<3>
SLICE_X11Y10.COUT Tbyp 0.130 count<4>
Mcount_count_cy<4>
Mcount_count_cy<5>
SLICE_X11Y11.CIN net (fanout=1) 0.000 Mcount_count_cy<5>
SLICE_X11Y11.COUT Tbyp 0.130 count<6>
Mcount_count_cy<6>
Mcount_count_cy<7>
SLICE_X11Y12.CIN net (fanout=1) 0.000 Mcount_count_cy<7>
SLICE_X11Y12.COUT Tbyp 0.130 count<8>
Mcount_count_cy<8>
Mcount_count_cy<9>
SLICE_X11Y13.CIN net (fanout=1) 0.000 Mcount_count_cy<9>
SLICE_X11Y13.COUT Tbyp 0.130 count<10>
Mcount_count_cy<10>
Mcount_count_cy<11>
SLICE_X11Y14.CIN net (fanout=1) 0.000
Mcount_count_cy<11>
SLICE_X11Y14.COUT Tbyp 0.130 count<12>
Mcount_count_cy<12>
Mcount_count_cy<13>
SLICE_X11Y15.CIN net (fanout=1) 0.000
Mcount_count_cy<13>
SLICE_X11Y15.COUT Tbyp 0.130 count<14>
Mcount_count_cy<14>
Mcount_count_cy<15>
SLICE_X11Y16.CIN net (fanout=1) 0.000
Mcount_count_cy<15>
SLICE_X11Y16.COUT Tbyp 0.130 count<16>
Mcount_count_cy<16>
Mcount_count_cy<17>
SLICE_X11Y17.CIN net (fanout=1) 0.000
Mcount_count_cy<17>
SLICE_X11Y17.COUT Tbyp 0.130 count<18>
Mcount_count_cy<18>
Mcount_count_cy<19>
SLICE_X11Y18.CIN net (fanout=1) 0.000
Mcount_count_cy<19>
SLICE_X11Y18.COUT Tbyp 0.130 count<20>
Mcount_count_cy<20>
Mcount_count_cy<21>
SLICE_X11Y19.CIN net (fanout=1) 0.000
Mcount_count_cy<21>
SLICE_X11Y19.COUT Tbyp 0.130 count<22>
Mcount_count_cy<22>
Mcount_count_cy<23>
SLICE_X11Y20.CIN net (fanout=1) 0.000
Mcount_count_cy<23>
SLICE_X11Y20.COUT Tbyp 0.130 count<24>
Mcount_count_cy<24>
Mcount_count_cy<25>
SLICE_X11Y21.CIN net (fanout=1) 0.000
Mcount_count_cy<25>
SLICE_X11Y21.COUT Tbyp 0.130 count<26>
Mcount_count_cy<26>
Mcount_count_cy<27>
SLICE_X11Y22.CIN net (fanout=1) 0.000
Mcount_count_cy<27>
SLICE_X11Y22.COUT Tbyp 0.130 count<28>
Mcount_count_cy<28>
Mcount_count_cy<29>
SLICE_X11Y23.CIN net (fanout=1) 0.000
Mcount_count_cy<29>
SLICE_X11Y23.CLK Tcinck 0.704 count<30>
Mcount_count_cy<30>
Mcount_count_xor<31>
count_31
-------------------------------------------------
---------------------------
Total 4.363ns (4.045ns logic,
0.318ns route)
(92.7% logic,
7.3% route)
That's the worst-case path in the timing report after adding a period
constraint of 4.4 ns. Same achievable period of 4.402...
-- Gabor
Article: 153541In article <48354533-874d-4538-bf69-c4a8c43bda80 @l14g2000vbe.googlegroups.com>, gnuarm@gmail.com says... > > > > I don't mind giving more obvious hints... > > period = 1/freq > > Rick Hmmm... Measuring period within 1.1 seconds limits us to a minimum RPM of 54.5454 assuming one pulse per revolution from the motor. That can give a clue as to how many PPR - pulses per revoultion - would be needed to resolve to the minimum RPM stated. -- Michael Karas Carousel Design Solutions http://www.carousel-design.comArticle: 153542
Rob Gaddi <rgaddi@technologyhighland.invalid> wrote: >Does anyone have any experience connecting an FPGA to a serious mess of >DRAM? I'm thinking of something on the order of 16GB, possibly >just by buying/socketing 4x4GB standard DIMMs. > >I don't need tremendous throughput; if I could average 50 MB/s I'd be >fine. For sheer density I'm thinking DDR2. I'd like to avoid DDR3 if >I can, simply because of the lack of support on low-end FPGAs. I could >certainly go slower, say DDR1 or even SDR, but that seems to imply >buying chips by the bucketload per board, and my assembly people will >shoot me. > >Ideally this would be a Cyclone 3/4 project. Maybe Spartan 6 instead. >The actual signal processing requirements are low, so I don't need that >much crunching horsepower. > >Anyone manage to do something like this? Many years ago I've created a design which used a standard DDR module at 100MHz on a Spartan2 (lowest speed grade). Actually the memory was shared between 2 FPGAs due to lack of pins. I did roll my own DDR controller because the MIG tool produced an overcomplicated interface and didn't even allow for 32 data lines. Most FPGA vendor solutions aim at achieving the highest memory bandwidth. Usually at the costs of enormous amounts of logic. At lower speeds things get much easier. IIRC DDR2 has a lower speed limit of 133MHz which shouldn't be a problem. I think my old design would also be able to use DDR2 if I used a higher speed grade FPGA. I used a 90 degrees shifted clock to capture the data read from the memory. It took some arm wrestling with the tools to get worst case setup and hold timings which I needed to calculate/determine if there was a window in which the data was valid. This is much easier than trying to use the DQS signal as a clock for a FIFO. More logic adds more timing uncertainty when dealing with external signals. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 153543
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, BillArticle: 153544
"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.Article: 153545
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 McCArticle: 153546
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 20 MB/sec going back up to the FPGA as well? Or simply a link that control= s 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? >=20 For a data point, 30-35 MB/sec is achievable via USB on a PC. At that poin= t, 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 dat= a 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 communi= cates with the PC or whether it would be better to put the FPGA on a card i= nside the PC. Based on what you wrote, I'm guessing that you're envisionin= g an external box of some sort, but you should clarify. Kevin JenningsArticle: 153547
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".Article: 153548
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 ----------Article: 153549
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.
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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