Sub micron questions
Jerry English
I have a few questions about ASICs done in .18 and below micron. There
is a lot of discussion concerning physical placement synthesis where the
synthesis engine takes into account the placement of the cells I guess
in order to size buffers and adjust timing. Our next project is looking
at
.18 micron and smaller in order to cram more functions for less power in
a cheaper package. Our operating frequency is much less than 100 Mhz and
device latency is not a concern. With all that said I was wondering if
synthesizing
small blocks (say less than 50K gates with wire load models) and over
constraint
clock rates would be sufficient to avoid multiple passes through place
and route to achieve
timing closure?
I know if I approach Synopsys or Cadence I'd get the sales pitch to use
their engineers and
software. One of the ASIC vendors I have contacted wants to do a RTL
hand off.
Handing over our source code makes my gut tighten up. If physical
synthesis is the only
way to achieve timing closure could this be achieved by reading a
verilog netlist into a
physical synthesis engine for additional optimization?
Your comments are welcomed.
Jerry
Lars Rzymianowicz
> I have a few questions about ASICs done in .18 and below micron. There
> is a lot of discussion concerning physical placement synthesis where the
> synthesis engine takes into account the placement of the cells I guess
> in order to size buffers and adjust timing. Our next project is looking
> at .18 micron and smaller in order to cram more functions for less power
> in a cheaper package. Our operating frequency is much less than 100 Mhz
> and device latency is not a concern. With all that said I was wondering
> if synthesizing small blocks (say less than 50K gates with wire load
> models) and over constraint clock rates would be sufficient to avoid
> multiple passes through place and route to achieve timing closure?
Hi Jerry,
physical synthesis is needed for designs with tight timing goals, where
you can't get a signal from one side of the die to the opposite in one
cycle. Then routing plays a major role in timing closure.
But with your moderate timing goal (<100MHz) in 0.18u you might go along
with 'traditional' logic synthesis, if you have a small- to medium-sized
design.
Doing some initial floorplanning and maybe creation of custom WLM's should
be sufficient.
I wouldn't recommend overconstraining your clocks, this might bloat your
logic where it is not needed. And would result in slower paths and more
power.
> If physical synthesis is the only way to achieve timing closure could
> this be achieved by reading a verilog netlist into a physical synthesis
> engine for additional optimization?
Hmm, might give you slightly better results. But starting from RTL with
constraints & custom WLM's should be better.
Would like to see other comments on this from designers already using
Phy.Syn. tools...
Lars
--
Address: University of Mannheim; B6, 26; 68159 Mannheim, Germany
Tel: +(49) 621 181-2716, Fax: -2713
email: larsrzy@{ti.uni-mannheim.de, atoll-net.de, computer.org}
Homepage: http://mufasa.informatik.uni-mannheim.de/lsra/persons/lars/
Jeff Buckles
Here's an opinion from a designer who's seen too many designs
attepemted *without* some kind of physical knowledge in the
synthesis flow.
There are several other factors to consider besides
clock speed when deciding how to synthesis with a DSM
(0.5 um or smaller) technology.
For example, as the geometry shrinks, then unless the
process (Vt, Idsat) are tuned for performance (and consequently
high leakage and crowbar current) then you will likely see
the ability of the transistor to drive wire load shrinking
faster than the average wire length. That is, if the
area of a block decreases by 50 % from 0.25 to 0.18 um,
the length of wire a 1x buffer can drive (with acceptable
transition delay) may decrease by much more than 50%. This
happens in part because of the increased constraints of
electromigration and the increased parasitic capacitance and
increased cross-coupling (assuming your asic vendor models
this in a meaningful way).
Furthermore, as the geometries shrink, the assumption about
what is a good size of synthesizable block continues to increase
(only two years ago, 20k gates was a "good size", now we often
see over 100K blocks). This has the effect of increasing the
spread of the wire-load distribution. That is, for a given
fanout N, the ratio of shortest to longest net in a block may have
been 20::1 in 0.5 um technology, but may be 1000::1 or greater in
0.18 um. Therefore, the use of wire-load models -- even so-called
"custom" wire-load models which I have generated and used quite a
bit -- becomes less and less useful. The statistical outliers
(nets that are greatly exceed the estimated model) exceed the
estimate by increasing proportions. Imagine the gate-bloat and
timing impact of choosing a custom model that exceeds those
statistical outliers!
So, you have wider distribution of post-layout cap,
signal integrity (EM, Hot-E, crosstalk) effects begin
to impose constraints that may be more restrictive than
simply meeting setup times, and (relatively) weaker drive
strength all making the probablitiy of success very small
without some communication between synthesis and layout
that is more sophisticated than custom wire-load models.
There are several alternatives available, depending on
what your asic supplier is able to support.
Given the relatively low clock speed, one option that may
not require a lot of additional support from your asic vendor
is some kind of post-layout optimization (such as Synopsys'
Layout Based Optimization -- I assume Ambit and others have
a similar capability). If you choose this route, don't accept
the vendors' claims that it will work only if you`re within
xx% of meeting timing. The DSM effects -- particularly the
1000:1 cap distribution mentioned above -- means that a lot
of gross violations are easily fixed. Also, don't confuse
IPO (in-place optimization) with LBO. IPO does not consider
the detailed physical information that a tool such as LBO
uses.
And what Lars said with regard to over-constraint is
especially important if you are synthesizing with physical
"awareness" or doing post-layout optimization.
I hope this is helpful.
Let me know how it turns out.
Best Regards,
Jeff Buckles
NEC Electronics Inc.
Portland ASIC Design Center
je...@el.nec.com
In article <39A3DF7C...@ti.uni-mannheim.de>,
Sent via Deja.com http://www.deja.com/
Before you buy.