Expectations from newly minted EE?

[MikeWhy]

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.

 

[MK]

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

 

[MikeWhy]

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

 

[glen herrmannsfeldt]

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

-- glen

 

[glen herrmannsfeldt]

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.

-- glen

 

[Tim Wescott]

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

 

[Rob Gaddi]

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.

 

[Joe Chisolm]

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 Texas

 

[MikeWhy]

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

 

[MikeWhy]

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.

 

[Tim Wescott]

On Tue, 03 Apr 2012 12:22:02 -0500, MikeWhy wrote:

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.

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

 

[glen herrmannsfeldt]

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

 

[glen herrmannsfeldt]

MikeWhy <boat042-nospam@yahoo.com> wrote:

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)

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.

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.

I wondered if the same might be true of EE.

-- glen

 

[MikeWhy]

glen herrmannsfeldt wrote:

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.

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.

Is this some other specialty?

 

[glen herrmannsfeldt]

MikeWhy <boat042-nospam@yahoo.com> wrote:

(snip, I wrote)

Try asking your CS grads about the need for decoupling
capacitors and see what kind of answer you get.

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.

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.

Is this some other specialty?

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.

-- glen

 

[Tim Wescott]

On Tue, 03 Apr 2012 23:14:15 +0000, glen herrmannsfeldt wrote:

MikeWhy <boat042-nospam@yahoo.com> wrote:

(snip, I wrote)
Try asking your CS grads about the need for decoupling capacitors and
see what kind of answer you get.

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.

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.

Is this some other specialty?

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

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.

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.

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