How Can a Recent Graduate Break Into the DSP Industry?

[hammertime]

Hi.

I just graduated in December with a B.S. in Electrical Engineering from a prominent Southern California university. For privacy's sake, I won't disclose its name but I will say that its mascot rhymes with "shoo-ins". Anyway, while I was there I took classes on a lot of different topics but the ones I enjoyed the most were the ones on signal processing (DSP, signals and systems, image processing, etc.).

I'd love to get a job in that field but every time I search for DSP related jobs I see several terms in the requirements section that I've never even heard of. When I was in college I studied things like FIR filters, IIR filters, Z-transforms, sampling, etc. But in these job listings I see things like ASIC, FPGA, VHDL, etc.

How can I teach myself these things? I'm taking a few free open courses at MIT on signal processing and I got a few books on college-level DSP exercises for MATLAB, but is that enough? I know I saw a few books on DSP programming in C. Would that do?

In other words, where should I go if I want to get a DSP related job? Do I have to go to grad school?

 

[turin]

WARNING: The following opinion is based on experience from 10 years ago.

Out of those three terms (ASIC, FPGA, VHDL) the thing that you really need to learn is VHDL. The others will largely depend on the particulars of each assignment, and you should learn them as you go. At this point, you should stop reading my post, and go learn VHDL.

There are many different kinds of FPGA, where the variations include speed, size, and even architecture and implementation. If you want to practice on your own, then just choose one that you think you can use for a small project (e.g. the cheapest one), and start there. (I recommend one of Xilinx's.)

As far as the ASIC goes, I don't know what you would be expected to do about that. I'm curious what is the wording in the job requirements regarding ASICs.

EDIT:
Here's how the process basically works, as I remember it:

software stage:
Your company has an "arrangement" with some FPGA manufacturer. So, you get some computer software that "helps" to design (i.e. write VHDL code for) their particular brand of FPGAs. Then, you spend most of your time at your computer, pulling out your hair to find bugs and tweak little details like timing, because the software that is supposed to help you doesn't. Oh, yeah, by the way, all of the fun stuff, like filter design, is "already done", and your manager will tell you to "stop trying to reinvent the wheel - there's a deadline". This is the software stage.

firmware stage:
Meanwhile, someone in your team (possibly you) arranges the prototyping of the board where you need to implement the functionality that you're modelling in VHDL, and manufacturing produces, say, three prototypes with your FPGA on them. However, these boards have bad connections, and faulty components, so you take occassional breaks from your computer desk to visit the lab, where you work with the lab tech trying to narrow down where the problem is. This is the firmware stage, and you will go back and forth between firmware and software many times. I cannot stress enough the issue of nonideal manufacturing. An extremely important part of your job as an engineer may very well be to assume that these issues occur and then work around them with redundancy and robust design. This is what really separates the software stage from the firmware stage.

hardware stage:
Finally, after perhaps months (and certainly after the deadline), you think that you have all of the bugs worked out of your code and out of the prototypes. Your company (possibly you) made an "arrangement" with some ASIC manufacturer. This is where the real "fun" begins: The VHDL gets implemented in hardware. This is the hardware stage. You may have to go back to the firmware stage; if so, your manager will not be happy. If you have to go back to the software stage, you will suffer the wrath.

 

[hammertime]

WARNING: The following opinion is based on experience from 10 years ago.

Out of those three terms (ASIC, FPGA, VHDL) the thing that you really need to learn is VHDL. The others will largely depend on the particulars of each assignment, and you should learn them as you go. At this point, you should stop reading my post, and go learn VHDL.

There are many different kinds of FPGA, where the variations include speed, size, and even architecture and implementation. If you want to practice on your own, then just choose one that you think you can use for a small project (e.g. the cheapest one), and start there. (I recommend one of Xilinx's.)

As far as the ASIC goes, I don't know what you would be expected to do about that. I'm curious what is the wording in the job requirements regarding ASICs.

EDIT:
Here's how the process basically works, as I remember it:

software stage:
Your company has an "arrangement" with some FPGA manufacturer. So, you get some computer software that "helps" to design (i.e. write VHDL code for) their particular brand of FPGAs. Then, you spend most of your time at your computer, pulling out your hair to find bugs and tweak little details like timing, because the software that is supposed to help you doesn't. Oh, yeah, by the way, all of the fun stuff, like filter design, is "already done", and your manager will tell you to "stop trying to reinvent the wheel - there's a deadline". This is the software stage.

firmware stage:
Meanwhile, someone in your team (possibly you) arranges the prototyping of the board where you need to implement the functionality that you're modelling in VHDL, and manufacturing produces, say, three prototypes with your FPGA on them. However, these boards have bad connections, and faulty components, so you take occassional breaks from your computer desk to visit the lab, where you work with the lab tech trying to narrow down where the problem is. This is the firmware stage, and you will go back and forth between firmware and software many times. I cannot stress enough the issue of nonideal manufacturing. An extremely important part of your job as an engineer may very well be to assume that these issues occur and then work around them with redundancy and robust design. This is what really separates the software stage from the firmware stage.

hardware stage:
Finally, after perhaps months (and certainly after the deadline), you think that you have all of the bugs worked out of your code and out of the prototypes. Your company (possibly you) made an "arrangement" with some ASIC manufacturer. This is where the real "fun" begins: The VHDL gets implemented in hardware. This is the hardware stage. You may have to go back to the firmware stage; if so, your manager will not be happy. If you have to go back to the software stage, you will suffer the wrath.

So an FPGA is a pre-existing piece of hardware on which one would practice VHDL? And how hard is it to learn VHDL? Does it take long?

 

[story645]

So an FPGA is a pre-existing piece of hardware on which one would practice VHDL? And how hard is it to learn VHDL? Does it take long?

FPGA stands for Field-programmable gate array, and is basically just programmable hardware. You can simulate costume hardware configurations on an FPGA using different discription languages, VHDL (VHSIC hardware description language) and Verilog included.

VHDL is funky, but it's not very difficult if you've already done lots of programming (especially C/assembly/low level stuff.) If you've only done matlab, then you're probably in a bit of trouble as VHDL is more bit oriented.

 

[hammertime]

FPGA stands for Field-programmable gate array, and is basically just programmable hardware. You can simulate costume hardware configurations on an FPGA using different discription languages, VHDL (VHSIC hardware description language) and Verilog included.

VHDL is funky, but it's not very difficult if you've already done lots of programming (especially C/assembly/low level stuff.) If you've only done matlab, then you're probably in a bit of trouble as VHDL is more bit oriented.

I'm familiar with C/C++ and MATLAB, and I've taken a digital logic design course (on gates, ALU's, etc.). So how long would it take to learn VHDL? Would I have to spend money on software/books, and if so, how much? How much time should I put in every day?

 

[story645]

So how long would it take to learn VHDL? Would I have to spend money on software/books, and if so, how much? How much time should I put in every day?

How good are you? VHDL basically boils down to a 3 credit course and 1 credit lab at my school, or two/three weeks in a 1 credit lab for the EEs. Basically, anywhere from a few hours a week for a couple of months to a few hours a week period.

Would I have to spend money on software/books, and if so, how much?

Start with Modelsim student (it's free), and work through a bunch of projects. As you get better, figure out if you think it's worth it to invest in an FPGA.

 

[turin]

So an FPGA is a pre-existing piece of hardware on which one would practice VHDL?

You could think of it that way at first. However, sometimes a company, group, or individual engineer may even decide to make the FPGA (along with its PROM) a quasi-permanent fixture of the design. This provides one solution for a circuit board that is expected to periodically change in an undetermined way. (Other options include redesigning the circuit module upon each upgrade, designing the circuit module with some kind of program memory, or even having jumpers that are physically soldered in or removed to determine the particular functionality; the choice should be an engineering decision, but it will likely be a managerial decision.) I worked with (inheritted) boards with FPGAs that had already served two years in the field. I suppose the main problem with this approach would be keeping the functionality private, so, perhaps not a good idea if you want to implement hardware-level cryptography.

 

[hammertime]

How good are you? VHDL basically boils down to a 3 credit course and 1 credit lab at my school, or two/three weeks in a 1 credit lab for the EEs. Basically, anywhere from a few hours a week for a couple of months to a few hours a week period.


Start with Modelsim student (it's free), and work through a bunch of projects. As you get better, figure out if you think it's worth it to invest in an FPGA.

Aside from VHDL, what else do I need to learn? I mean, in school I just basically learned about z-transforms, DFT's, DTFT's, DCT's, and a little bit of MATLAB. How hard is it to learn things like statistical signal processing, adaptive filters, array processing, image processing, wavelets, estimation theory, detection theory, information theory, channel coding, source coding, etc.? Can I just learn them from a book or do I have to go to grad school for that?

 

[hammertime]

What about audio engineering? What all would I have to learn for a career in that, and would I need to get a Master's in order to pursue a career in it?

 

[story645]

Can I just learn them from a book or do I have to go to grad school for that?

Sure, you can learn them from a book, maybe even well if you're suited to it, but I doubt anyone will take you seriously when you say that you know how to do something. Grad school is as much about giving you credibility as it as about learning something. That being said, I've done bits and pieces in some of the fields you're interested in learning from books, and they're hard, crazy hard, and require a lot of math you either haven't ever touched or haven't touched in years, on top of all sorts of applied math/statistics you've probably never done and still more outside knowledge. I don't think a book will help you learn what questions you'll need to ask of the techniques, tools, and data, and that's something grad school is very much about.