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
glen herrmannsfeldt wrote: > 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.) Yes, this is part of the design. I guess one needs to make a constraint so that the counter latches get a coherent sample. I'm thinking I should synchronize the external clock for each counter to a 150 MHz internal clock, and use a clock edge detector in the external clock domain to activate the clock enable of the counter on the internal clock. Thanks JonArticle: 153576
Jon Elson <jmelson@wustl.edu> wrote: (snip, I wrote) >> 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.) > Yes, this is part of the design. I guess one needs to make a > constraint so that the counter latches get a coherent sample. Without that constraint, you might get to 300MHz or so. If S3A isn't so different from S3E, 100MHz shouldn't be so hard with the latch. > I'm thinking I should synchronize the external clock for each > counter to a 150 MHz internal clock, and use a clock edge > detector in the external clock domain to activate the clock > enable of the counter on the internal clock. I think that sounds right. You have to meet the setup and hold times for the latch. -- glenArticle: 153577
Rob Gaddi <rgaddi@technologyhighland.invalid> 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. Maybe but you could divide the counter in two (or more) parts. Have the second counter run on a delayed carry chain. By using registers to delay the output of the first counter you can align the output results of the counters. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------Article: 153578
Hi, I get the following data from a on-line slide on MAP decoder. I think "Speed" is about the max clock rate. How about the "Fastest Implementation"? Could you explain it to me? Thanks. ............ Synthesis =95Synopsys =95Area: 0.96 mm2 =95Speed: 150 MHz =95Fastest Implementation: 110MHzArticle: 153579
Hello, I am looking to use FPGA's as specialized coprocessors to increase performance on different applications. I would like the lowest latency possible to memory. I have only found options with PCIE and HyperTransport, but I was hoping to find something similar to this which I assume would have lower latency than PCIE or HyperTransport: ( http://www.nallatech.com/intel-xeon-fsb-fpga-socket-fillers.html ). However it seems that product is no longer in production. Are there any similar products to the above link? I suppose a related question is, how much lower latency would there be for an FPGA on the FSB instead of PCIE or HyperTransport? Thanks, JordanArticle: 153580
On Mar 27, 12:19=A0am, Rob Gaddi <rga...@technologyhighland.invalid> wrote: > Does anyone have any experience connecting an FPGA to a serious mess of > DRAM? =A0I'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. =A0For sheer density I'm thinking DDR2. =A0I'd like to avoid DDR3 i= f > 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. =A0Maybe 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. =A0See above to fix. I don't believe that you will find low end FPGA that officially supports such amount of RAM. May be, mid range, like Arria GZ, but even then, it seems to support ether 1 DDR3 DIMM per channel or 2 DDR2 DIMMs, so hitting 16 GB wouldn't be easy. On the other hand you can relatively easily connect 2x8GB DDR3 DIMMs to smallest Stratix3 or Stratix4. There is another interesting option - do it backward! I mean, build PCIe board around Cyclone-4 GX and let host PC to serve as your memory controller. Plugging 24 GB into PC nowadays is cheap, easy and reliable. The latency over PCIe will be ~5 times higher than via direct connection, but you will get plenty of bandwidth, something around 150 MB/s for x1 gen1 link.Article: 153581
Jordan There were 2 or 3 companies manufacturing accelerators that were aimed at sitting in a second processor socket. For companies that have used this technique the problems of keeping up with socket changes was always going to be a problem. The other problem is that the second socket on most motherboards, and maybe all, has dissappeared. Main reason for that is multi-core processors that don't need 2+ sockets. PCIe latency can be a big factor if you doing a HPC system that only does "small" commands, instructions or functions because the PCIe latency costs you much more than you gain. "Big" commands, instructions, or functions are usually ok. Chained systems or systems where the processor is only a manager usually work well. That's why in our HPC systems, using our Merrick and Broaddown family boards, we make features like 1G and 10G Ethernet directly available to these boards that cuts out the PCIe structure.Similarly we now do real world sensor interfacing for these systems through our Lamachan2 board so there is minimal latency. There are usually other ways to tackle most problems but it depends on what you need to achieve. Here we do a lot of different things depending on a customer system requirements and rarely is the same approach used for any 2 customers. John Adair Enterpoint Ltd. - Home of FPGA HPC systems. On Apr 1, 7:14=A0am, Jordan Fix <jfi...@gmail.com> wrote: > Hello, > > I am looking to use FPGA's as specialized coprocessors to increase > performance on different applications. I would like the lowest latency > possible to memory. I have only found options with PCIE and > HyperTransport, but I was hoping to find something similar to this > which I assume would have lower latency than PCIE or HyperTransport: > (http://www.nallatech.com/intel-xeon-fsb-fpga-socket-fillers.html). > However it seems that product is no longer in production. > > Are there any similar products to the above link? I suppose a related > question is, how much lower latency would there be for an FPGA on the > FSB instead of PCIE or HyperTransport? > > Thanks, > JordanArticle: 153582
On Apr 1, 9:14=A0am, Jordan Fix <jfi...@gmail.com> wrote: > Hello, > > I am looking to use FPGA's as specialized coprocessors to increase > performance on different applications. I would like the lowest latency > possible to memory. I have only found options with PCIE and > HyperTransport, but I was hoping to find something similar to this > which I assume would have lower latency than PCIE or HyperTransport: > (http://www.nallatech.com/intel-xeon-fsb-fpga-socket-fillers.html). > However it seems that product is no longer in production. > > Are there any similar products to the above link? I suppose a related > question is, how much lower latency would there be for an FPGA on the > FSB instead of PCIE or HyperTransport? > > Thanks, > Jordan Intel AGTL+ FSB is dead and buried. Also, I am not sure that even when it was alive the latency was really lower than HyperTransport. AMD HTX slots also close to non-existent. Intel QPI made short appearance in the desktops but was quickly killed by more integrated solutions and, by now, exists only in servers. Besides, QPI is not very narrow source synchronous parallel bus that, in its latest incarnation, runs at 6.4-8.0 GT/s. I.e. even the most modern FPGA will have very hard time talking to it :( Overall, low latency off-chip co-processors look like technological dead end. Sorry. You better start looking for a way to live with relatively high latency of PCIe interface.Article: 153583
On Mar 31, 10:19=A0pm, fl <rxjw...@gmail.com> wrote: > Hi, > I get the following data from a on-line slide on MAP decoder. I think > "Speed" is about the max clock rate. How about the "Fastest > Implementation"? Could you explain it to me? > > Thanks. > > ............ > Synthesis > =95Synopsys > =95Area: 0.96 mm2 > =95Speed: 150 MHz > =95Fastest Implementation: 110MHz Sound like a local route from A to B allows you to do 150 mph, but the highway system would limit to 110 mph So 110 is the number to take into your calculation... while 150 is just for fun !? or at least it tells you go to fix your highway if you want faster speed, and do not dig up you local routesArticle: 153584
Elam <elampooranan@gmail.com> wrote: > I understand that the price depends on the volume etc > but I would like to know the per unit price of Virtex 7 FPGA.. > Any guesses.. Search for XC7V on www.findchips.com. And better sit down before checking... Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 153585
Jordan Fix <jfix71@gmail.com> wrote: > I am looking to use FPGA's as specialized coprocessors to increase > performance on different applications. I would like the lowest latency > possible to memory. Sometimes you can't live without low latency, but reasonably often you can do it pipelined. That might mean doing two or three of whatever you are doing instead of one, using separate data streams. -- glenArticle: 153586
On Mar 28, 10:31=A0am, Elam <elampoora...@gmail.com> wrote: > I understand that the price depends on the volume etc > but I would like to know the per unit price of Virtex 7 FPGA.. > > Any guesses.. > > Thanks > Elam. There are too many variables (device, package, speed grade, volume, delivery date, etc..) involved in pricing for any simple answer. Contact your local Xilinx sales rep and they would be happy to sit down and discuss your needs and come up with the right pricing that matches your situation. http://www.xilinx.com/company/contact/sales-reps.htm Using online pricing data for 1-10 parts today will not be reflective of 1K-10K pricing 18 months from now. Ed McGettigan -- Xilinx Inc.Article: 153587
Fellas, I work in a historically software only industry, but have a project on my desk that would likely benefit from implementation on recent generation FPGA. My HDL skills are scant and ancient, and it's almost certain any recent BsEE can do a better, faster job of it than I can. The problem is relatively simple: read messages off a UDP or TCP socket; identify the key message fields; discard or process the message based on the field contents; generate and push one or more TCP messages out another network. The performance goal is to reduce latency from receipt to transmission. What level of knowledge and expertise can I expect from recent graduates on their first job? How much, or little, on job experience would you expect to be minimal to complete this project successfully? How much project responsibility can I reasonably assign them? How much specific technical knowledge will I need to run this project successfully? Thanks.Article: 153588
On 03/04/2012 07:24, MikeWhy wrote:
> Fellas, I work in a historically software only industry, but have a
> project on my desk that would likely benefit from implementation on
> recent generation FPGA. My HDL skills are scant and ancient, and it's
> almost certain any recent BsEE can do a better, faster job of it than I
> can. The problem is relatively simple: read messages off a UDP or TCP
> socket; identify the key message fields; discard or process the message
> based on the field contents; generate and push one or more TCP messages
> out another network. The performance goal is to reduce latency from
> receipt to transmission.
>
> What level of knowledge and expertise can I expect from recent graduates
> on their first job? How much, or little, on job experience would you
> expect to be minimal to complete this project successfully? How much
> project responsibility can I reasonably assign them? How much specific
> technical knowledge will I need to run this project successfully?
>
> Thanks.
>
The task you describe would normally be coded on some kind of processor,
which could be implemented in FPGA although you don't give quite enough
info. to be sure ("reduce latency" needs numbers !)
If there are some constraints of performance which require that the
TCP/IP stack should be implemented in the FPGA as logic described in an
HDL then you'll need a damn good recent graduate.
You would do far better to get someone in on contract with some
proveable experience.
I've done soem fairly slick (although I say it myself) UDP handling in
VHDL and its hard work.
Michael Kellett
Article: 153589Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de> wrote: > Elam <elampooranan@gmail.com> wrote: > > I understand that the price depends on the volume etc > > but I would like to know the per unit price of Virtex 7 FPGA.. > > Any guesses.. > Search for XC7V on www.findchips.com. No online availability for now. Prices last time I checked was up to 50 k$... Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 153590
"MK" <mk@nospam.co.uk> wrote in message
news:ScCdnWNgw4kCOufSnZ2dnUVZ8tadnZ2d@bt.com...
> On 03/04/2012 07:24, MikeWhy wrote:
>> Fellas, I work in a historically software only industry, but have a
>> project on my desk that would likely benefit from implementation on
>> recent generation FPGA. My HDL skills are scant and ancient, and it's
>> almost certain any recent BsEE can do a better, faster job of it than I
>> can. The problem is relatively simple: read messages off a UDP or TCP
>> socket; identify the key message fields; discard or process the message
>> based on the field contents; generate and push one or more TCP messages
>> out another network. The performance goal is to reduce latency from
>> receipt to transmission.
>>
>> What level of knowledge and expertise can I expect from recent graduates
>> on their first job? How much, or little, on job experience would you
>> expect to be minimal to complete this project successfully? How much
>> project responsibility can I reasonably assign them? How much specific
>> technical knowledge will I need to run this project successfully?
>>
>> Thanks.
>>
> The task you describe would normally be coded on some kind of processor,
> which could be implemented in FPGA although you don't give quite enough
> info. to be sure ("reduce latency" needs numbers !)
> If there are some constraints of performance which require that the TCP/IP
> stack should be implemented in the FPGA as logic described in an HDL then
> you'll need a damn good recent graduate.
> You would do far better to get someone in on contract with some proveable
> experience.
> I've done soem fairly slick (although I say it myself) UDP handling in
> VHDL and its hard work.
Thanks, Michael.
The desired latency is as close to 0 as possible. No smiley. Software
implementations exist. The goal is to put them out of business, soundly and
convincingly. It doesn't need to "win" by a big margin, but it needs to win
100% of the time. Is 100 ns big or small in your world?
Yes, I see the problem with implementing the TCP stack in HDL. Are there
commercial IP that do this in FPGA logic? I know it can be done in soft- or
onboard processors. I think this can be set aside for the moment as an
integration exercise. Say the bytes magically appaer in block ram, and
then...
Getting back to reasonable expectations of competency. Can I expect a EE,
having studied diligently and earned his bachelors, to already know how to
efficiently find a fixed byte pattern in the first N bytes in a message? Can
he implement a hash table in FPGA logic? Can he take a file containing
sample data and create simulation scripts and validate his designs?
Again, my basis for asking is I think I can almost hack my way through this,
but I know I wouldn't want to hire myself to build this.
Article: 153591MikeWhy <boat042-nospam@yahoo.com> wrote: > Fellas, I work in a historically software only industry, but have > a project on my desk that would likely benefit from implementation > on recent generation FPGA. My HDL skills are scant and ancient, > and it's almost certain any recent BsEE can do a better, faster > job of it than I can. > The problem is relatively simple: read messages off a UDP or > TCP socket; identify the key message fields; discard or process > the message based on the field contents; generate and push one > or more TCP messages out another network. As far as I know, this isn't commonly taught to recent BsEE, but also isn't so far from what one might know. Generating UDP packets with a relatively simple state machine in an FPGA shouldn't be so hard. Accepting them as input just a little harder. Probably a soft processor (in the FPGA) would be used to handle ARP. TCP is a lot harder than UDP, with many more cases to be considered. It is certainly possible that it has been done without a processor, but I haven't heard about it being done. > The performance goal is to reduce latency from receipt to > transmission. That pretty much means UDP. Note that TCP is a stream protocol. While you can add record marks (there is even an RFC on how to do it) you usually wouldn't want that if latency was important. > What level of knowledge and expertise can I expect from recent > graduates on their first job? How much, or little, on job > experience would you expect to be minimal to complete this > project successfully? How much project responsibility can > I reasonably assign them? How much specific technical > knowledge will I need to run this project successfully? It is a little complicated by the fact that HDL design and network protocols are often considered separately. It would be much easier to find two people, one to do the HDL design and the other the network protocols. The rest would be much easier to answer with a little more detail on the requirements. -- glenArticle: 153592
MikeWhy <boat042-nospam@yahoo.com> wrote: (snip) > The desired latency is as close to 0 as possible. No smiley. Software > implementations exist. The goal is to put them out of business, soundly and > convincingly. It doesn't need to "win" by a big margin, but it needs to win > 100% of the time. Is 100 ns big or small in your world? How are you measuring latency? For gigabit ethernet, 100ns is 100 bits, or about 12 bytes. I would normally measure from the beginning of the request coming in to the end of the reply. 10G ethernet exists, but isn't common, and will be much more difficult to do in an FPGA. In that case, you get 125 bytes, enough for the ethernet, IP, UDP header and a small amount of data. > Yes, I see the problem with implementing the TCP stack in HDL. > Are there commercial IP that do this in FPGA logic? > I know it can be done in soft- or onboard processors. > I think this can be set aside for the moment as an > integration exercise. Say the bytes magically appaer in > block ram, and then... You wand UDP. Note that TCP includes acknowledge and retransmit after a time expires. That, in addition to it being a stream protocol, make is all wrong for this problem. > Getting back to reasonable expectations of competency. > Can I expect a EE, having studied diligently and earned his > bachelors, to already know how to efficiently find a fixed > byte pattern in the first N bytes in a message? Hmm, I suppose a good chance on that one. > Can he implement a hash table in FPGA logic? Can he take > a file containing sample data and create simulation scripts > and validate his designs? Just for lookups, or does it have to add new entries to the table from the input? > Again, my basis for asking is I think I can almost hack my > way through this, but I know I wouldn't want to hire > myself to build this. In that case, you should be able to supervise and keep on track a good BSEE. You will both learn some as the project progresses, but it should work. -- glenArticle: 153593
On Tue, 03 Apr 2012 01:24:33 -0500, MikeWhy wrote: > Fellas, I work in a historically software only industry, but have a > project on my desk that would likely benefit from implementation on > recent generation FPGA. My HDL skills are scant and ancient, and it's > almost certain any recent BsEE can do a better, faster job of it than I > can. The problem is relatively simple: read messages off a UDP or TCP > socket; identify the key message fields; discard or process the message > based on the field contents; generate and push one or more TCP messages > out another network. The performance goal is to reduce latency from > receipt to transmission. > > What level of knowledge and expertise can I expect from recent graduates > on their first job? How much, or little, on job experience would you > expect to be minimal to complete this project successfully? How much > project responsibility can I reasonably assign them? How much specific > technical knowledge will I need to run this project successfully? Universities don't teach kids how to _do_ -- they build a foundation, on which one builds a house by one's own efforts. So the amount of practical ability that a kid will have coming out of college will vary dramatically from kid to kid. Worse, it won't necessarily correlate well with grades. A straight-A student may be completely worthless at practical stuff, while a C student may have gotten that way because he was spending too much time building working robots (or running a business) to keep his grades up. Hand it off and expect it to get done, to a new EE: maybe a 5% chance of success. Put your heads together with said EE, prop him/her up where they're weak: 15-35% chance of success. Given an EE with the proverbial 5 years of experience or equivalent: 70% chance of success. Above, only the experience is at a company that does routers: 95% A 5-year EE + you: 95% If you feel you must hire straight out of a University, pay careful attention not just to the classes taken, but also to the kid's extracurricular activities. You're looking for someone who's self- motivated and has done something real. The ideal candidate (and there are a few out there) will have worked as a technician before or during college, or will have been an electronics (or robitics) hobbyist, or will have done a senior project that actually worked in the end, etc. By looking for the above, you're going to cut out 90% of the candidates. Fortunately, HR people, and even many EE managers, don't understand the value of practical application, so you'll be presented with a resource that hasn't been picked over yet -- think of it as going prospecting for gold with a bunch of people who don't recognize ore, only the native material. Having said that, getting an EE who's already been in the working world and done some circuit design of some sort will winnow out all the candidates that got through school then found out that they really wanted to be in Marketing, or lack necessary working-world skills, etc. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.comArticle: 153594
Hi, implemented the Mandelbrot set on Digilent's Starter Kit for Spartan 3. http://www.youtube.com/watch?v=nohaJJLdfZQ Is anyone interested in the .bit-file ? Regards ThorstenArticle: 153595
On Tue, 3 Apr 2012 05:19:43 -0500 "MikeWhy" <boat042-nospam@yahoo.com> wrote: > The desired latency is as close to 0 as possible. No smiley. Software > implementations exist. The goal is to put them out of business, soundly and > convincingly. It doesn't need to "win" by a big margin, but it needs to win > 100% of the time. Is 100 ns big or small in your world? > > Yes, I see the problem with implementing the TCP stack in HDL. Are there > commercial IP that do this in FPGA logic? I know it can be done in soft- or > onboard processors. I think this can be set aside for the moment as an > integration exercise. Say the bytes magically appaer in block ram, and > then... > I've seen one somewhere, but can't recall where. The other problem with TCP is that the latency is pretty unpredictable based on network conditions. You might be better off seeing whether you can do everything UDP, which is much more predictable. > Getting back to reasonable expectations of competency. Can I expect a EE, > having studied diligently and earned his bachelors, to already know how to > efficiently find a fixed byte pattern in the first N bytes in a message? Can > he implement a hash table in FPGA logic? Can he take a file containing > sample data and create simulation scripts and validate his designs? > In my experience, you can expect a newly minted EE to be able to beat you at beer pong, and tie his shoes correctly 4 days out of 5. Anything past that he's going to have to learn. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.Article: 153596
On Tue, 03 Apr 2012 11:04:56 +0000, glen herrmannsfeldt wrote: > MikeWhy <boat042-nospam@yahoo.com> wrote: > > (snip) >> The desired latency is as close to 0 as possible. No smiley. Software >> implementations exist. The goal is to put them out of business, soundly >> and convincingly. It doesn't need to "win" by a big margin, but it >> needs to win 100% of the time. Is 100 ns big or small in your world? > > How are you measuring latency? For gigabit ethernet, 100ns is 100 bits, > or about 12 bytes. I would normally measure from the beginning of the > request coming in to the end of the reply. > > 10G ethernet exists, but isn't common, and will be much more difficult > to do in an FPGA. In that case, you get 125 bytes, enough for the > ethernet, IP, UDP header and a small amount of data. > Actually, 10G is popping up in more and more places, especially in the big data centers. Having multiple 10G links on a single device is is here today. 40G is on the close horizon. I've seen the design for a 40G interface card. >> Yes, I see the problem with implementing the TCP stack in HDL. Are >> there commercial IP that do this in FPGA logic? I know it can be done >> in soft- or onboard processors. I think this can be set aside for the >> moment as an integration exercise. Say the bytes magically appaer in >> block ram, and then... > > You wand UDP. Note that TCP includes acknowledge and retransmit after a > time expires. That, in addition to it being a stream protocol, make is > all wrong for this problem. > <snip> The OP should look into a network processor, especially if you are trying to do any kind of deep packet inspection. NPs are built to do this kind of work. -- Chisolm Republic Of TexasArticle: 153597
"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message news:jlelgn$av7$1@speranza.aioe.org... > MikeWhy <boat042-nospam@yahoo.com> wrote: > > (snip) >> The desired latency is as close to 0 as possible. No smiley. Software >> implementations exist. The goal is to put them out of business, soundly >> and >> convincingly. It doesn't need to "win" by a big margin, but it needs to >> win >> 100% of the time. Is 100 ns big or small in your world? > > How are you measuring latency? For gigabit ethernet, 100ns > is 100 bits, or about 12 bytes. I would normally measure from > the beginning of the request coming in to the end of the reply. > > 10G ethernet exists, but isn't common, and will be much more > difficult to do in an FPGA. In that case, you get 125 bytes, > enough for the ethernet, IP, UDP header and a small amount > of data. Message rate is relatively low. Response time is the important measure. Latency will be measured externally with a network protocol analyzer. Run side by side with a software solution, its packets must appear first in the sniffer trace. The competition is an overclocked multi-core Intel, running Linux with RT extensions and optimized stacks. > >> Yes, I see the problem with implementing the TCP stack in HDL. >> Are there commercial IP that do this in FPGA logic? >> I know it can be done in soft- or onboard processors. >> I think this can be set aside for the moment as an >> integration exercise. Say the bytes magically appaer in >> block ram, and then... > > You wand UDP. Note that TCP includes acknowledge and > retransmit after a time expires. That, in addition to it > being a stream protocol, make is all wrong for this problem. Agreed. The network stack will go on an onboard processor. It needs ARP, IGMP, and the whole mess anyway. > >> Getting back to reasonable expectations of competency. >> Can I expect a EE, having studied diligently and earned his >> bachelors, to already know how to efficiently find a fixed >> byte pattern in the first N bytes in a message? > > Hmm, I suppose a good chance on that one. > >> Can he implement a hash table in FPGA logic? Can he take >> a file containing sample data and create simulation scripts >> and validate his designs? > > Just for lookups, or does it have to add new entries > to the table from the input? No new entries from the realtime stream, but added to or modified periodically elsewise. What are the problems?Article: 153598
Tim Wescott wrote: > Universities don't teach kids how to _do_ -- they build a foundation, > on which one builds a house by one's own efforts. So the amount of > practical ability that a kid will have coming out of college will vary <snip> > Having said that, getting an EE who's already been in the working > world and done some circuit design of some sort will winnow out all > the candidates that got through school then found out that they > really wanted to be in Marketing, or lack necessary working-world > skills, etc. Unsurprisingly not very different from software. I have been rather impressed lately with recent CS grads. They seemed head and shoulders above what we were seeing ten years ago. But that might have more to do with the hiring process before they reached me. I actually felt that maybe academia had finally caught up to industry. I wondered if the same might be true of EE.Article: 153599
MikeWhy <boat042-nospam@yahoo.com> wrote: (snip) >>> It doesn't need to "win" by a big margin, but it needs to win >>> 100% of the time. Is 100 ns big or small in your world? 100% of the packets? There is some statistical nature to this, such as an ARP request might come through once in a while, and maybe not at the same time as the competition system. Not very often, so maybe only 99.9%. Also, any broadcast traffic on the net will be received by all hosts, which must then ignore it if not needed. >> How are you measuring latency? For gigabit ethernet, 100ns >> is 100 bits, or about 12 bytes. I would normally measure from >> the beginning of the request coming in to the end of the reply. >> 10G ethernet exists, but isn't common, and will be much more >> difficult to do in an FPGA. In that case, you get 125 bytes, >> enough for the ethernet, IP, UDP header and a small amount >> of data. > Message rate is relatively low. Response time is the important measure. > Latency will be measured externally with a network protocol analyzer. > Run side by side with a software solution, its packets must appear > first in the sniffer trace. The competition is an overclocked > multi-core Intel, running Linux with RT extensions and optimized > stacks. In the more usual FPGA based hardware accelerator, the total time is what is measured. Not that it shouldn't win per packet. So, I will guess that UDP packets are sent multicast such that each system sees it at the same time. (There is no multicast for TCP.) (snip, I wrote) >> You wand UDP. Note that TCP includes acknowledge and >> retransmit after a time expires. That, in addition to it >> being a stream protocol, make is all wrong for this problem. > Agreed. The network stack will go on an onboard processor. > It needs ARP, IGMP, and the whole mess anyway. I soft (or hard) processor should take care of all that, with only the specific request packets handled by a (relatively) simple state machine. >>> Getting back to reasonable expectations of competency. >>> Can I expect a EE, having studied diligently and earned his >>> bachelors, to already know how to efficiently find a fixed >>> byte pattern in the first N bytes in a message? >> Hmm, I suppose a good chance on that one. Problems like that are common homework problems in some EE/CS classes. >>> Can he implement a hash table in FPGA logic? Can he take >>> a file containing sample data and create simulation scripts >>> and validate his designs? >> Just for lookups, or does it have to add new entries >> to the table from the input? > No new entries from the realtime stream, but added to or > modified periodically elsewise. What are the problems? No problem if it is just for lookups. I will guess that you should be able to run a 100MHz clock, but maybe a little slower with more done on each cycle. The state machine has to recognize incoming data, send other data to the processor, extract the appropriate fields from requests, process and generate the data to return, and clock out the return packet. You might have a BSEE do the state machine and BSCS do the code to run the rest of the IP stack (ARP and routing) and updating the hash table. -- glen
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