Electronics > Beginners
Day in the life of IC designer and prototyping ICs
<< < (2/2)
coppice:

--- Quote from: djacobow on August 30, 2019, 11:47:03 pm ---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.

--- End quote ---
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:

--- Quote from: coppice on August 31, 2019, 12:09:10 am ---
--- Quote from: djacobow on August 30, 2019, 11:47:03 pm ---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.

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

--- End quote ---

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:

--- Quote from: coppice on August 31, 2019, 12:09:10 am ---Does your anecdote about the verilog and the hardware drawing mean the tools for translating the verilog to silicon were buggy?

--- End quote ---

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? :D
djacobow:

--- Quote from: magic on August 31, 2019, 06:08:53 am ---How many man-hours went into figuring that one out? :D

--- End quote ---

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.
Navigation
Message Index
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod