![](https://csdnimg.cn/release/download_crawler_static/88607838/bg3.jpg)
Figure 4: High-level comparison of two popular de-
sign methodologies.
rid of them in favor of a few tables or graphs. And
because these graphs are generated using device sim-
ulations in Spice, they are much more acc urate than
the long-channel model could ever hope to be.
It is no stretch to say that most of us cringe a little at
the thought of using a lookup table. With the advent
of cheap and powerful computing, we electrical en-
gineers have lost touch with filter tables, log tables,
trigonometric tables, and the like. But our current
equational exclusivity has been only a brief fad in
our industry. Just as vacuum tube circuit designers
once used (and still use!) tube curves, so we are redis-
covering the value of table-based design for situations
where it is the most e±cient means of ”computation.”
Fig. 4 compares V
ov
-based design and g
m
/I
D
-based
design in a side-by-side summary. In both cases, we
need physical information about the technology tar-
get. After all, the capabilities of the target will ob-
viously aÆect transistor performance greatly. In the
case of the long-channel model, the technology data
must be limited to only the barest of essentials, such
as µ and C
ox
, otherwise hand calculations become in-
tractible. Consequently, initial designs may only get
within an order of magnitude until the designer gets a
”feel” for that process. Meanwhile, the g
m
/I
D
-based
method utilizes complete Spice models from the tech-
nology target and yields initial results that only re-
quire minor twe aking.
0.4 The More-De tailed Picture
Now I want us to start over trying to solve the design
problem, but at a more quantitative level. We will
reach the same conclusion, of course, even though we
are taking a very diÆerent approach.
A First Attempt at Transistor-Level Design
How might an intelligent-but-inexperienced engineer
go about designing a circuit? Of course, I have a
preferred method towards which I am working, but
it is certainly worthwhile to see if we can solve the
design problem without knowing the answer ahead of
time.
To b egin, le t us step back and ask, what will our
finished design look like? Or, what is afinishedde-
sign? In the context of this article, it is a netlist.
Ultimately we just want a file that contains spe cifica-
tions for all the transistors, resistors, capacitors, etc.,
and explains how they are all connected together. Of
course, in the real world, circuits must be fabricated,
and designers must be wary of the limitations of simu-
lation itself, and how well it agrees with actual mea-
sured performance, but those concerns are beyond
our scope here.
If our end goal is a netlist, why not start with the
netlist and work backwards? What kinds of informa-
tion do we need in order to ”fill in the blanks?” For
reference, here is a line that instantiates a transistor
in Hspice:
M1 drn gat src blk nchmodel L=0.18u W=10u
Well, which blanks can we fill in? Put another way,
how do we design a transistor? Obviously, V
T
, µ, C
ox
,
and other familiar transistor quantities are not among
the parameters we get to specify. In fact, apart from
the terminal connections, it looks like we only get to
choose W and L.
Is that all there is to it? Is circuit design just a matter
of deciding how big each transistor is? Well, yes and
no. With the exception of some advanced options
(such as source or drain sharing, or multi-fingered
gates), W and L really are the only transistor charac-
teristics that you get to explicitely specify. You hook
them together, size them correctly, and you almost
have the whole thing. Really!
One p ossible design method, then, might be to just
use W and L directly as design variables. This pro-
cess would be something like the following:
3