ASIC design job vs FPGA design job Options

ASIC design job vs FPGA design 

 THIS IS FROM  comp.arch.fpga group ...... 

question:

I am an ASIC design engineer with over 6 years experience. My experience 
 in ASIC design spans across microarchitecture, RTL coding, synthesis, 
 timing closure and verification. Is it advisable for me if I change to a 
 FPGA design job? I mean, what are the pros and cons? I do not have much 
experience in FPGA other than school projects. How much learning is 
 involved? Will it be difficult to switch back to ASIC design position in 
 the future if I move to a FPGA job? Do FPGA design involve less work and 
 stress than ASIC? Please provide your opinion, experience or any other 
 comment. 

 answer by anonymous author  : I knew a guy who had done really good FPGA designs for years, and for 
years had yearned to do ASIC design with the "big boys".  He lasted a 
year or two -- not because he wasn't up to the job, but because he hadn't 
realized the difference in the design cycle between ASIC and FPGA, and he 
vastly preferred FPGA design. 

Because with FPGA design, you do your system design and have a design 
review, then you do your coding and have a design review, and then you 
pour it all into the PC board that's been underway at the same time that 
you were doing your FPGA design.  You bring it all up with the test 
features in the software whose design has _also_ been underway while you 
were working, and you test the heck out of it. 

At this point, you're far from done: the board will be getting green 
wires, the software will be getting revised (or, if everyone is smart, 
only the critical portions of the software will have been completed), and 
your logic design will probably need revision (or be incomplete). 

So it's not uncommon to spend a month or two tweaking and revising your 
"finished" design after it's finished. 

Tom's experience with ASIC design, on the other hand, was that you get 
the system design done, then you go write a bunch of behavioral code to 
completely embody the system design, and a testbench to completely test 
it.  You churn on that for weeks or months while your colleagues make up 
new tests for corner cases.   

Then, once you've verified the snot out of the system design, you start 
replacing parts of your behavioral system piece-by-piece with the RTL- 
level code for your ASIC, testing all the way. 

So, (in Tom's words), you spend 90% of your time flogging the 
verification. 

This all makes sense:  the cycle time between moving a comma in a Verilog 
file and testing the effect in an FPGA might only take between half an 
hour and several hours.  The cycle time to do the same thing with an ASIC 
is weeks, and $$$, and trash bins full of parts.  So doing the 
verification "live" makes good economic sense with FPGAs, and doing it in 
simulation makes equally good economic sense with ASICs. 

So:  if the design cycle that I'm quoting for ASICs sounds accurate to 
you (I'm just forwarding a long-ago conversation), and the design cycle 
for FPGA work makes you think "ewww!", then FPGA work isn't for you.  If, 
on the other hand, you get no joy from spending 90% of your time 
verifying before you actually get to see your work working -- maybe 
you'll like FPGA work. 

Tom did note barriers to transitioning to ASIC work (in part because he 
has an EET degree, not a "real" EE degree), and may not have found the 
transition back to FPGA work as easy as he did if he did not have a large 
circle of former coworkers who -- to a man -- were impressed by his work 
and willing to tell their bosses.  (Tom's one of those guys that if he's 
applying for work you tell your boss "just hire him, he'll make it work"). 

So, that's what I know.