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").
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
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.
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?
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.
and
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).
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.
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."
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.
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.
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.
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)
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.
IMHO it depends on the complexity of what you are doing. If you can divide a design in many small pieces then you can test each piece and put it together later on. I've worked on mid range FPGA designs which where a piece of cake and small CPLD designs which where hard to get right.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
The big thing that has changed in the last 10 years: While with a Spartan XL I really had trouble fitting my few stepper drivers, PWMs and preripheral interfacing in, With Spartan 3 (which we still use for most products) I drag more and more functionality from firmware down into the FPGA to make use of all the logic cells I get after picking the smallest device with sufficient IO count.
So, your mileage may vary with the team, project and device size.
- Philip
--
Democracy: Three wolves and a sheep voting on what's
for dinner.
Making an asic design scan testable affects how you do all your asynchronous logic. Fpgas come pretested and you don't need to do a parts test with your logic.
2) Clocking
Asics can easily have 20-30 clock domains and you have the tools to manage
them. Fpgas have a finite number of global clock routing resources and you
really want to keep your design under that number.
Both asics and fpgas work with clock enables and you should use them as much as you can. Fpgas have clock enabled flops and asics will use power
compiler to turn them into separate clock domains.
3) Flexibility
Asics can do anything. Want a and/or gate or invertor feeding your flop?
An asic can do it. So can a fpga but it will cost you 1 LUT. Fpga designs
work best if you have a consistent amount of logic between each stage. To
much and you have to use 2 LUT's and the speed goes down. To little and
you have unused resources and your gate count goes down.
4) Performance
Asics will always win. Hard coded paths beat switched paths any day. We
would use fpgas to prototype all of our asics and we:
a) Target the system clock to well under the asic process maximums
b) Design the prototype for 1/4 the actual system clock.
If you can show that your embedded system can perform each task @ 1/4 clock speed then you buy yourself a nice safety margin for the product.
John Eaton
--------------------------------------- Posted through
I've done both FPGA and ASIC design (front-end and back-end). I prefer FPGA design because I can spend a greater part of my time doing the interesting architecture and design work. During ASIC development, so much time is spent slogging through the less interesting tasks of corner-case verification, DFT, DFM, DRC, RC back-annotation, etc.
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.