|
Sept 2009
ASIC Design Flow
Design flow methodology has been with us since the very first ASICs were produced and put into the hands of designers. It became clear, early on, that for a designer to submit a design for implementation by a foundry, there had to be certain things that were done to be sure that the logic worked as expected, and worked in the manner expected.
Those of us present in the early days compiled, compiled and compiled some more, a list of all the steps required.
Over time, entrepreneurs (as many engineers are), developed programs, EDA tools, for the tasks the designers faced. At the same time, the designs themselves were getting bigger and bigger, until they passed the point at which one designer could be responsible for one design, and now teams were assembled to take a design from inception to wafer fab.
Over more time and with bigger, faster arrays, and with deep submicron added to the vocabulary, the design team became specialized as to the task, and the software proliferated, until as many as 42 different products might be used to complete one array design. These days we are so far down in deep-submicron territory, we don't even mention it anymore.
We started with the wildly optimistic 700 gates on one die. 5 micron technology. Two-layer metalization. Bipolar. The old TTL and ECL I/Os. A 3 inch wafer. Around 26 layers in the base. And semi-custom meant the same base would be used over and over for many designs, just the metalization was affected. The words design re-use and IP, never mind hard IP, were not yet coined.
The Q700. Well, 700 equivalent gates is child's play and any self-respecting designer can whip that out. Can't he? (They were, at that time, mostly hes. I know this.) Same with 1000 gates. Same with 5000 gates. By now, however, the task was fast becoming overwhelming. (For 5000 equivalent gates, any self-respecting designer can beat the software.)
When they introduced 20,000 gate-dies, and the new CMOS technology with 200,000 gate dies, the single design concept was over.
First, way back when, we didn't worry about interconnect delays. Not much. 5ns per fan-out, add something for wired-or. Seat-of-the-pants. The biggest delay in the 5 micron technology was the internal delay through the gate.
We looked at operating environment and adjusted for the variations. (We were the foundry, we could do that. Try it today!) Many companies had their own foundries. Thousands of dollars, Millions of dollars were spent on racing these things into existence. Today, we know better, They are horrifically expensive, change constantly, and only a massive operation can keep the trays full. So today, the design house is NOT part of the foundry. Many companies use the same foundry.
We knew what speed we needed, and we even knew what the critical path (of the 10 worst paths) were.
We hand-computed external set-up and hold times.
We chose the package, computed the junction temperature, seleced air flow and heat sinks.
We place the macro on the cell positions on the layout grid.
We distributed the I/O around the I/O ring and placed extra powers and grounds to isolate high-speed signals and to break up the SSO switching effects. Gang-switching could pull on the power bus and cause problems unless dampened.
We hand-selected the macros based on our design criteria, speed requirements, die size, I/O requirements, power requirements, all in the priority that the particular design required.
And when we fit the die, did not violate the utilization, and had satisfied our design criteria in the physical sense, we created the test vectors (by hand - we had algorithms, I invented one) and we ran simulations. We ran functional (no speed), we ran at-speed, we ran test for critical paths and we specified parametric tests.
The die was built and packaged and tested and we even checked on all of that.
Today, we break the design flow into pieces. Something like this.
Design Creation.
First of all, Marketing tells you that you are going to build something. And they tell you what criteria it must meet. These are the Design Criteria. THe marketing spec is then processed by the various engineering departments or gorups and they come back with an engineering spec. Then they hash out what marketing wants, and what engineering says it can currently build.
The end result may be called a "Requirements" specification. This is what they want you to build mixed with what you think you can build.
Then comes the Architecture Specification. This is the step where the engineers, on seeing the final requirements, establish what it is they think they will build. There are probably some compromises. (Mild understatement.)
In a well-run company, there will be a final architecture spec that tells you what was actually built. The two are not identical.
From there, the design blocks are broken down and each of them will have its own specification, first at the high-level (block diagram, the pieces, registers, signals, basic functionality, i.e., what it is supposed to do), and then at the low-level (timing waveforms, issues, gate-level diagrams, etc.).The low-level specification for a module records how it was implemented or built.
From the high-level specification, the design is "created".
First, we used to draw blueprints. By the time ASIC showed up, we were drawing the schematics on a workstation. The macros we could use (the gates, the functions) were pre-defined by the library for the technology. It is still so defined today. The engineer who knows the design library in all its glory is the one who can do the best designs. Experience on another library, another process, etc. counts, but it does not count as much.
|