ASIC design job vs FPGA design job

Hi folks,

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.

Thanks!

On Wed, 09 Nov 2011 20:54:19 -0800, googler wrote:

> Hi folks,
> 
> 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.

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.

-- 
www.wescottdesign.com

googler <pinaki_m77@yahoo.com> wrote:

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

Do you mean a job designing using FPGAs, or designing FPGAs?

The latter is pretty much a specialized version of ASIC design,
though it is probably good to know a lot about designing using
FPGAs first.

Otherwise, as I understand it with mask costs going up, more and
more that previously would have been ASIC are going to FPGA.

-- glen

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

This advice is a couple of years old and outdated.

Todays larger fpgas are forcing fpgas designers to adopt asic design
methods
if you ever hope to get your design working. The best plan combines the
two
so that you create a robust simulation suite to ensure that it should work
and use real hardware to run the bench tests needed for the corner cases.
Two minutes on a fpga breadboard tests as much as a month of simulation.

Got a repeatable hardware failure that your sims say should work? Use scan
assisted debug. Run the hardware and freeze the state sometime before the
error appears. Then use the scan chain to extract the state of all the flip
flops and load that into your simulation. Run it to see if it fails. You
can
use a binary search to narrow it down to the exact clock cycle where the
hardware gets a bad state.


John Eaton

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

In article <oP6dneyod_9EnCHTnZ2dnUVZ_vKdnZ2d@web-ster.com>,
Tim Wescott  <tim@seemywebsite.com> wrote:
>On Wed, 09 Nov 2011 20:54:19 -0800, googler wrote:
>
>> Hi folks,
>> 
>> 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.
>
>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.

<snip>

I made the jump to FPGAs about 6 years ago, after doing ASICs for around 11 years.
I prefer FPGAs for many of the reasons that Tim mentioned - you get
to actually touch and fiddle with the hardware - often!  In all those
year of ASIC design it was just rush to tapeout, the on to the next rush.
Others handled the actual bringup.  Not satisfying.  I never touched
the finished products.

Lab debug is very satisfying (well can be frustrating too!).  And a good
skill to have.  You gotta want to do it though.   

From a design point of view, yeah FPGA's are different than ASICs.  But
they're 90% the same.  You can pickup the 10% on the job.  Plus,
as others in the thread have pointed out, FPGAs because of their size, are
starting to need some of the same flows that ASICs need.  So your
experience there is a benefit.  

Stick next to an experienced FPGA guy. 
You'll learn from him why 'we do things this way in FPGAs'.  

He'll learn from you some of the ASIC methodologies that can be applied
to his flows.

Less Work / Less Stress?  That's a more company culture question IMHO, and
unrelated.  

Going back to ASIC after years in FPGA - well, I'm not interested.  But I think
it'd be doable too.  

My 2 cents...

--Mark

Mark Curry <gtwrek@sonic.net> wrote:

(snip, someone wrote)
>>> I am an ASIC design engineer with over 6 years experience. 

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

> I made the jump to FPGAs about 6 years ago, after doing ASICs for 
> around 11 years.   I prefer FPGAs for many of the reasons that 
> Tim mentioned - you get to actually touch and fiddle with the 
> hardware - often!  In all those year of ASIC design it was just 
> rush to tapeout, the on to the next rush.

This reminds me, some years ago I was told (in one of these
newsgroups) that ASIC designers prefered verilog and FPGA people
liked VHDL.  It seems that the FPGA tools now support both equally,
so maybe things have changed.  Without starting a flame war, 
is it still true that verilog is more popular in the ASIC world,
and VHDL in the FPGA world?

-- glen

On Nov 10, 12:31=A0pm, gtw...@sonic.net (Mark Curry) wrote:
>
> I made the jump to FPGAs about 6 years ago, after doing ASICs for around =
11 years.
> I prefer FPGAs for many of the reasons that Tim mentioned - you get
> to actually touch and fiddle with the hardware - often! =A0In all those
> year of ASIC design it was just rush to tapeout, the on to the next rush.
> Others handled the actual bringup. =A0Not satisfying. =A0I never touched
> the finished products.

Thanks for your comments!

>
> Lab debug is very satisfying (well can be frustrating too!). =A0And a goo=
d
> skill to have. =A0You gotta want to do it though.

Yes, I agree.

>
> From a design point of view, yeah FPGA's are different than ASICs. =A0But
> they're 90% the same. =A0You can pickup the 10% on the job. =A0Plus,
> as others in the thread have pointed out, FPGAs because of their size, ar=
e
> starting to need some of the same flows that ASICs need. =A0So your
> experience there is a benefit.

But most of the tools are different, aren't they? I understand that
the essential/basic knowledge applies to both more or less the same,
but learning different tools can take time sometimes. Anyway, my
bigger concern in switching to FPGA is - AFAIK the scope of FPGA
designs are smaller than ASIC and many of the stages/features that
exit in ASIC do not apply to FPGA (or are significantly simpler). Is
that right? For example, I heard that FPGAs cannot support clock
gating, whereas for ASICs, it is almost essential these days. Other
examples may be scan, formal verification, etc So my point is, if I am
not using some of the knowledges/skills on a daily basis (because they
do not apply to FPGA), I may lose them. I don't know how much of this
concern is actually true, since I have very limited FPGA experience.

>
> Stick next to an experienced FPGA guy.
> You'll learn from him why 'we do things this way in FPGAs'.
>
> He'll learn from you some of the ASIC methodologies that can be applied
> to his flows.
>
> Less Work / Less Stress? =A0That's a more company culture question IMHO, =
and
> unrelated.

You mention "rushing to tapeouts" with ASICs. That's exactly how my
experience have been with ASICs too. It can get very stressful these
days especially with such a huge competition among companies for time-
to-market. That's why I asked if working in FPGAs is better in this
respect (although I understand the company culture does have a big
part to play).

>
> Going back to ASIC after years in FPGA - well, I'm not interested. =A0But=
 I think
> it'd be doable too.
>
> My 2 cents...
>
> --Mark- Hide quoted text -
>
> - Show quoted text -

In article <j9hed3$8m4$1@speranza.aioe.org>,
glen herrmannsfeldt  <gah@ugcs.caltech.edu> wrote:
>Mark Curry <gtwrek@sonic.net> wrote:
>
>(snip, someone wrote)
>>>> I am an ASIC design engineer with over 6 years experience. 
>
>(snip)
>>>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.
>
>> I made the jump to FPGAs about 6 years ago, after doing ASICs for 
>> around 11 years.   I prefer FPGAs for many of the reasons that 
>> Tim mentioned - you get to actually touch and fiddle with the 
>> hardware - often!  In all those year of ASIC design it was just 
>> rush to tapeout, the on to the next rush.
>
>This reminds me, some years ago I was told (in one of these
>newsgroups) that ASIC designers prefered verilog and FPGA people
>liked VHDL.  It seems that the FPGA tools now support both equally,
>so maybe things have changed.  Without starting a flame war, 
>is it still true that verilog is more popular in the ASIC world,
>and VHDL in the FPGA world?

I don't really know what's more popular.  I've worked at two places
with FPGAs.  Both were verilog houses.  Before that, two ASIC houses - both
verilog.  But at all we had to deal with VHDL too.  In one way or another, we 
were forced to mixed language flows.  IP from one place or another 
came in the other language.  IMHO, one will have his or her prefered 
language, but you'd better be able to do the basics in the other too.  

--Mark

googler <pinaki_m77@yahoo.com> wrote:

(snip)
> But most of the tools are different, aren't they? I understand that
> the essential/basic knowledge applies to both more or less the same,
> but learning different tools can take time sometimes. Anyway, my
> bigger concern in switching to FPGA is - AFAIK the scope of FPGA
> designs are smaller than ASIC 

FPGAs are getting big amazingly fast.  (Though the really big
ones are expensive.)  As far as I know, they are big enough
that you still need to "think big."

> and many of the stages/features that
> exit in ASIC do not apply to FPGA (or are significantly simpler). Is
> that right? For example, I heard that FPGAs cannot support clock
> gating, whereas for ASICs, it is almost essential these days. 

As far as I know, you can do it for very slow clocks.  But it
is usual to have FF's with a clock enable.  That changes the
design a little bit, but, it seems to be, not a lot.

> Other examples may be scan, formal verification, etc So my point 
> is, if I am not using some of the knowledges/skills on a daily 
> basis (because they do not apply to FPGA), I may lose them. 

Maybe, but you would probably get them back pretty fast
if needed.  Like the old story about never forgetting
about how to ride a bicycle.

> I don't know how much of this concern is actually true, 
> since I have very limited FPGA experience.

It seems to me that the big difference is in the cost
of a redo.  That shifts the testing and verification needed.
You still have to design to avoid rare timing errors, though,
but many more obvious failures can be found in actual
testing instead of verification.

>> Stick next to an experienced FPGA guy.
>> You'll learn from him why 'we do things this way in FPGAs'.

-- glen

In article <770abbbe-86b6-4d1e-8eb5-4f47fac0679f@h31g2000prl.googlegroups.com>,
googler  <pinaki_m77@yahoo.com> wrote:

><gtwrek@sonic.net wrote> 
>>
>> From a design point of view, yeah FPGA's are different than ASICs. &#4294967295;But
>> they're 90% the same. &#4294967295;You can pickup the 10% on the job. &#4294967295;Plus,
>> as others in the thread have pointed out, FPGAs because of their size, are
>> starting to need some of the same flows that ASICs need. &#4294967295;So your
>> experience there is a benefit.
>
>But most of the tools are different, aren't they? I understand that
>the essential/basic knowledge applies to both more or less the same,
>but learning different tools can take time sometimes. Anyway, my
>bigger concern in switching to FPGA is - AFAIK the scope of FPGA
>designs are smaller than ASIC and many of the stages/features that
>exit in ASIC do not apply to FPGA (or are significantly simpler). Is
>that right? For example, I heard that FPGAs cannot support clock
>gating, whereas for ASICs, it is almost essential these days. Other
>examples may be scan, formal verification, etc So my point is, if I am
>not using some of the knowledges/skills on a daily basis (because they
>do not apply to FPGA), I may lose them. I don't know how much of this
>concern is actually true, since I have very limited FPGA experience.

Tools are just tools.  From 10,000 ft they look the same.  A tool
takes your RTL and synthesizes it.  Another maps to the technology.
Another does Place and Route.  Sure there's details, but that's
constantly changing for all of them.  As long as you understand
the "goes intos" and the "goes outtas" you're most of the way
there. 

As to scope issues of FPGAs vs ASICs.  Well, as I said, I left
ASICs around 6 years ago.  One of the current FPGA I'm working
on is getting pretty darned close to the abilities
of that last ASIC I worked on.  The FPGA's today are big - you're
"big ASIC" experience is a benefit. (What's the current marketing term
for "big ASIC" anyway? - "SOC" seems to be falling out) 

>> Less Work / Less Stress? &#4294967295;That's a more company culture question IMHO, and
>> unrelated.
>
>You mention "rushing to tapeouts" with ASICs. That's exactly how my
>experience have been with ASICs too. It can get very stressful these
>days especially with such a huge competition among companies for time-
>to-market. That's why I asked if working in FPGAs is better in this
>respect (although I understand the company culture does have a big
>part to play).

It can get quite stressful when that end-of-quarter demo to the VP isn't 
working at the 11th hour.  Is the problem software, firmware, hardware, 
mechanical, etc., etc.  To steal an overused line, 
"Meet the new boss, same as the old boss..."

I find that just about anywhere I've worked, there's peaks and valleys
of work-load, stress, and accomplishments.
Deal with them how you can.

--Mark