Electronics > Beginners
Day in the life of IC designer and prototyping ICs
Dmeads:
Hi! Not sure if this is the correct place on the forum to put this question, but I have been wondering if anyone could give me insight on a day in the workplace of an IC designer. Either analog or digital is fine.
Also another question:
I know it's possible to prototype Asics on FPGAs, but I think that is mostly digital stuff. Can you use HDL for analog stuff too?
What is a popular method for prototyping analog integrated circuits?
Thanks!
djacobow:
Ah, it's nice to see the occasional question that I can answer authoritatively.
From an occupational health perspective, an ASIC designer's life is not that much different from that of a software engineer: they sit in front of a computer and type stuff.
To understand how an ASIC designer's life goes, you need to understand a bit about the lifecycle of a chip design process. The steps are (very roughly)
1. generation and settling on the required specifications
This period in an ASIC designer's life involves meeting with customers (maybe) meeting with marketing (definitely) and probably also suppliers (your foundry, IP providers, etc). This is a rather fun time when you can blue-sky ideas to meet marketing's requirements, think about what you design team can pull off in the allotted time and budget, and come up with a proposed design. It involves some slideware and whiteboarding and diagrams.
2. formalizing the specification, perhaps into a high-level model
This is the process of taking the slideware and converting it to something specific and clear enough to implement. This can be done formally or hahazardly. The first way is better. If you are lucky, you get a runnable model, maybe written in SystemVerilog or even just C++ that emulates the functions of the chip at a high level. You can write tests and run them against this model to see that it meets the spec.
3. implementation phase, where you either write synthesizable HDL or you draw schematics to realize the spec
For digital stuff, this means writing verilog or VHDL or what have you that implements the same functionality as the high level model. This code is meant to be synthesizable (meaning a tool can turn it into gates). You can also run/simulate it, to compare to the output of the high level model. In modern flows, it is possible for formally (mathematically) show that the implementation matches the high-level model, obviating the need to simulate.
4. verification. Writing tests and using formal methods to gain confidence that the implementation meets the specification
This is really done in parallel with earlier steps, and often by different folks. But basically, someone needs to write a crap-ton of tests. Tests to test out every corner of functionality and to exercise every line of code. Running these tests can take a long time in a simulator, so folks have resorted to more efficient means, like using an FPGA, or an emulation system (basically a box of FPGAs) or some kind of simulation acceleration. (Disclosure: I've worked in this business for Cadence).
5. synthesis, place and route, design rule checking, timing closure
Tools the Synopsys Design Compiler and Physical Compiler convert your HDL code into gates, and then place and route them. Placing and routing is a different kind of activity if you are doing full-customer vs using a gate array, but basically, they are conceptually the same. Design rule checking makes sure that the design is compatible with the foundry's manufacturing process, and timing closure is the process of making sure that every signal path can propagate through in the required time for the clock frequency desired. Today it is very common for most flip-flops in a design to have "scan", so automated tools can write tests that will get good coverage of every node. This is more useful for test (later on) than it is for (verification). It is now standard to use formal methods to prove mathematically that the synthesized netlist matches the RTL design, so there is no need to run the same tests on the netlist that were run on the verilog -- save's a lot of time.
6. tapeout.
This is where you spend megabucks to generate a mask set which the foundry uses to make the chip. Management gives you this very serious look and asks you if this is going to work, and you have to pretend to be very confident that it will, because tapeout costs A LOT OF MONEY. So much so, in fact, that the number of ASICs being designed as gone way down from even a decade ago. If you discover a mistake in the silicon and have to tape out again, it's going to cost millions. Don't fork it up.
Sometimes after tapeout, there is cake.
7. wait
This would be a good time to go on vacation. Or you can use the time to write more tests.
8. validation and bringup
Chip is back. See if it works. You *may* be able to repurpose some of the tests you wrote for verification. This is time you will spend away from your desk, going into the lab, where you chip may be on a board for testing, or if you have the resources, the chip can be probed using techniques like e-beam, that let you see any node that is exposed on the top layer. Validation also makes sure the chip will run correctly and at speed under the worst conditions of voltage, temperature, and "process corner" (foundry processes have their own variation and you need to plan for that, too). It's also important to make sure that the chip draws the expected power, etc, especially for analog and mixed signal chips.
9. production.
Chip looks good, so now is time to make money. Repurpose tests again and write some new ones to get good, and quick test coverage for production tests. Most chips today use flip-flops with scan, which allow you to get complete coverage of all the nodes of the chip directly without having to write tests, but tests run at full speed can still be faster, which is important since time on the test fixture is money.
I've given you a digital-centric view. There are analog analogs (ha!) for all these steps. For example, instead of running an HDL simulator, an analog engineering will run a SPICE simulator, etc. But they still need to do the same stuff: determine correctness, robustness, etc.
In real companies, the same people do not do all these steps, these often happen in parallel and overlap, and there are usually iteration inside these steps, but overall, this is the general gist.
In my experience, this process takes anywhere from 6-24 months, and has varying periods of intensity and chill time. Sometimes after the chip is in production, the design team is laid off.
Dmeads:
Wow thank you so much for the great answer haha!
One more question:
When you prototype on an fpga, how do you separate the unused logic cells from the ones you need for the masking process? Is there like a place and route file that does it for you?
Again thanks so much for the previous answer!!
Dmeads:
--- Quote from: djacobow on August 30, 2019, 03:31:03 pm --- Management gives you this very serious look and asks you if this is going to work, and you have to pretend to be very confident that it will...
Sometimes after tapeout, there is cake.
/quote]
:) :) :)
--- End quote ---
djacobow:
--- Quote from: Dmeads on August 30, 2019, 06:00:04 pm ---Wow thank you so much for the great answer haha!
One more question:
When you prototype on an fpga, how do you separate the unused logic cells from the ones you need for the masking process? Is there like a place and route file that does it for you?
Again thanks so much for the previous answer!!
--- End quote ---
When you prototype in FPGA, you are doing so to be able to "simulate" the logic at high speed. The fitting of the logic to the FPGA will have no relation to the logic as you would fit it to a gate array or full-custom place and route. So, really, there is nothing to be learned from the FPGA process that will help the physical design of the chip. The FPGA is just telling you that it will work.
Actually, it's not even quite that, because you have to believe that the gates in your design work the same as those in the FPGA. This should be the case, but I worked on a chip once where one strange and-or-invert combo gate in the design had the correct logic function in verilog but the wrong drawing in hardware. In FPGA, everything worked well, but the real chip didn't work properly.
Navigation
[0] Message Index
[#] Next page
Go to full version