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]

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]

[djacobow]

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

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.

[coppice]

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.

FPGA simulation can be a huge benefit when developing a new chip. It lets you test out the functionality of the design at high speed. Done right, it may let you get a working model of the new chip to key customers at an early stage, so they can verify that the logic of the final chip (although not its power consumption, and other factors) will correctly serve their needs.

The VHDL or Verilog that maps to the FPGA is the same as that which maps to the final silicon. Therefore an FPGA simulation lets you test the logic thoroughly. However it won't tell you anything about issues like timing, power, and so on. Those need to be evaluated for the process being used. If you find things like timing constraint cannot be met, you may need to change the VHDL/Verilog to do things differently (e.g. change pipelining). The new code can be tried on an FPGA, just like the original code, so you can check that your new code is still functionally correct in a simulator environment.

Does your anecdote about the verilog and the hardware drawing mean the tools for translating the verilog to silicon were buggy?

[langwadt]

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.

FPGA simulation can be a huge benefit when developing a new chip. It lets you test out the functionality of the design at high speed. Done right, it may let you get a working model of the new chip to key customers at an early stage, so they can verify that the logic of the final chip (although not its power consumption, and other factors) will correctly serve their needs.

The VHDL or Verilog that maps to the FPGA is the same as that which maps to the final silicon. Therefore an FPGA simulation lets you test the logic thoroughly. However it won't tell you anything about issues like timing, power, and so on. Those need to be evaluated for the process being used. If you find things like timing constraint cannot be met, you may need to change the VHDL/Verilog to do things differently (e.g. change pipelining). The new code can be tried on an FPGA, just like the original code, so you can check that your new code is still functionally correct in a simulator environment.

Does your anecdote about the verilog and the hardware drawing mean the tools for translating the verilog to silicon were buggy?

some 15-20 years ago I did some FPGA prototyping of some SOCs with arm7tdmi-s + RF, I replaced the RF with a wired "simulation"       
It gave the software team a chance to weed out any functional issues using something running in real time and develop the code that had to go into ROM

even though it needed some big expensive FPGAs it was well worth it if it could avoid a respin, I think the time a 90nm mask set was $1mill

[djacobow]

Does your anecdote about the verilog and the hardware drawing mean the tools for translating the verilog to silicon were buggy?

In this case, the cell library had been assembled by hand. Consider a cell library as consisting of four things for each cell:
  - a name
  - a symbol drawing
  - a logical description (truth table, verilog, whatever)
  - a physical drawing of the transistors

In this case, the first three agreed, and so when you simulated it in verilog or in an FPGA, things were fine. However, the fourth thing, the drawing, which had been done by a human being and validated by a human being, had an error.

I think more modern workflows can actually verify cells match their descriptions by extracting transistors from the physical layout and then mathematically applying them. (This does not have to be an analog sim; you can just think of P devices as being able to pull to a 1 or a Z, n devices able to pull a 0 or a Z, then given the inputs you can determine what each node would be at 1,0, or X from contention or X from being undriven, etc.)

This was late 90's early 00's and we did not have such a workflow.

[magic]

How many man-hours went into figuring that one out?

[djacobow]

How many man-hours went into figuring that one out?

There was a lot of head-scratching and consternation for days. We were lucky. The problem was in a multiplier, which just gave wrong answers and the rest of the chip worked. With some detective work we could limit it to a section of the multiplier design. I worked on it for a few days until I had an "a ha" moment when I decided to examine the cells. Since this was a multi-million gate chip that seemed to otherwise work, I could start by eliminating cells that were used elsewhere. Of the remainder, there was one cell, kind of doozy like 5 input and-or-invert gate. We looked at it and bam, that was the one.

We were lucky that it wasn't really *that* expensive because this was a test chip done on a "shuttle run". That is when a fab aggregates a bunch of different companies' designs onto one mask set for a very limited production of prototypes. Typically, the fab delivers unpassivated parts, so they tend to self-destruct after a few months. It's a great way for a fabless company, particularly a startup, to get going, perhaps given today's costs, the only way.