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?
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.
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.
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.
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.
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.
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.
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.
Hmm, I suppose a good chance on that one.
Just for lookups, or does it have to add new entries to the table from the input?
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.
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.com
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.
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.
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.
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.
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.
Agreed. The network stack will go on an onboard processor. It needs ARP, IGMP, and the whole mess anyway.
No new entries from the realtime stream, but added to or modified periodically elsewise. What are the problems?
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.
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.
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)
I soft (or hard) processor should take care of all that, with only the specific request packets handled by a (relatively) simple state machine.
Problems like that are common homework problems in some EE/CS classes.
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.
For this problem, you need things that come from both EE and CS.
Within CS, there are some who are more theoretical, and some who are more practical. (The latter might be CSE, Computer Science and Engineering, from the Engineering side of the school.)
State machines are commonly taught for CS, less common for EE, but many FPGA designs are state machine based. You need someone who can both get the logic right and build an actual PC board with the appropriate decoupling capacitors and termination on high speed signals.
Try asking your CS grads about the need for decoupling capacitors and see what kind of answer you get.
The last hiring effort that I was involved with was a couple of years ago, and we were looking for newly-minted MS or PhD candidates: we did see quite a few kids that had done real stuff -- but we also saw a number of them that had never done anything but shuffle math around on a white board.
So I do think that universities are doing better than when I graduated (in 1988, with the bulk of my practical experience coming from being an electronics hobbyist, but a not-insignificant amount coming as a consequence of attending WPI in Massachusetts, which did the 'practical project' as a requirement for graduation long before anyone else did).
--
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
We won't be building the hardware. I should be careful to say EE with coursework in FPGA and has completed related projects. I need someone to rationally express the design to take advantage of potential parallelism and features of the FPGA, write and maintain the HDL, and configure the device so it functions as designed, including the embedded processor and its peripheral bus or bare metal interfaces. Driver level coding would be a big plus.
OK, try asking the EE grads what ethertype X'0806' is. If one knows without looking it up, and also knows either VHDL or Verilog, hire him.
Around here, I believe it is called CSE, Computer Science Engineering, but it is pretty close to EE, and not so close to CS. (CS are the people who work out more efficient sort algorithms, and can prove that one is faster than another, but might not ever try running one on an actual computer.)
HDL looks like software, but programs like hardware, and ordinary CS people aren't very good at it. If you find people who were around in the TTL days, then they are usually used to thinking about logic and gates and wires connecting them.
They can prove that one sort algorithm is faster than another on the hypothetical computer that they're counting operations on -- not necessarily on anything that exists in real life.
Absolutely. When I write C, I have assembly code running through my head. When I write HDL, I have flip-flops and gates and little LUTs running through my head -- and curses because I can't remember the details of whichever HDL it is that I'm writing in at the moment.
--
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
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.