( ESNUG 348 Item 6 ) --------------------------------------------- [3/30/00]
From: [ Born To Run ]
Subject: Cadence's Silicon Ensemble Useless At 0.18um On Cross-Capacitance
Hey John, very anon please.
I like how ESNUG is adding physical design issues and wanted to add to the
discussion. I wanted to give people designing 0.18um ASICs a heads up on
cross-capacitance. I'm seeing 2 problems here: ASIC suppliers seem to be
pretty clueless about it, and the advertised Cadence Silicon Ensemble flow
can't handle it for beans.
Here's the deal: I'm working on a 0.18um ASIC with a Japanese foundry.
Good guys. They're working their butts off and closing timing without
a problem. Not a word that we need to worry about cross-capacitance. Then
I get to talking to some of my friends working on processors, and I start
to get a bad feeling. For one thing, cross-capacitance isn't proportional
to clock speed, its proportional to metal pitch. You can be running 83 MHz
in 0.18um and still have cross-capacitance bite you in the butt. Sure,
maybe you can leave some margin on the table to cover additional delay due
to cross-capacitance, but you can't margin noise. Get a glitch far enough
down your logic cone, clock it into a flop, and suddenly you get to debug
a frequency band where the part fails. Lovely.
So when I press my foundry, I get this cheesey answer that they're going to
insert buffers every couple of millimeters to prevent cross-talk. Sounds
good, right?
Not once you run the simulations. For most nets, a 1-2 mm buffering
distance would be fine, but if you have a very high drive cell aggressing
on a very low drive cell, it can increase your delay 50% at less than
1/2 mm of adjacency, even on wide-pitched metal. 50%. That's no small
potatoes. I mean, how much margin do you have?
So warning #1: If somebody tells you you don't have a cross-capacitance
problem in 0.18um, or that they can handle it with blind buffering, check
to see if they've simulated it or if they're just pulling this methodology
out of their butts based on how they think cross-capacitance works.
But it gets worse from there...
So now we know we've got a cross-capacitance problem, and we know we can't
just blindly jam buffers in to fix it, so what do we do? We go check out
the signal integrity option on Cadence Silicon Ensemble.
The best thing I can say for SE is that it runs without crashing.
Here are the problems we've found:
1. The parasitics coming from HyperExtract are up to 200% off compared
to 3D field solution. A chimpanzee throwing darts at a diagram
of parasitics could do better.
2. Its flagging over 1000 noise violations in a few hundred K gates
of logic. Over 1K noise violations in < 9mm^^2 of randomly
routed die? Gimme a break! Simulation showed that SE was
over-estimating noise by > 100%. It was using a slew rate
less than half of the actual slew rate. Its hard to say how many
real noise violations are in there, but my simulations are saying
my usual layout topologies ought to give me < 10 noise violations
per 100K gates *usually*. Not 1000!
3. The repair file isn't. I'm still playing around with this to see
if other PBopt options might get me a better repair rate, but so
far I'm still left with ALOT of xcap timing and noise violations
reported even after I run through the check/repair flow a couple
of times. Given that these results are based on the HyperExtract
parasitics that I know to be bogus, I'm not really motivated to
run this into the ground. To me, the whole solution has the feel
of something that isn't going to gel.
Lesson learned: Just because your EDA or ASIC vendor showes you a pretty
drawing of a flow, don't buy it until you see the parasitic, noise, and
delay modeling correlation. Cross-capacitance isn't like bringing a
router up where the right values for metal pitch go a long ways towards
getting you something reasonably DRC clean. Cross-cap and noise really
require some tuning before you get back something clean.
Part of the trouble with all of this is the incredible lack of data in
the industry on what to expect in real live designs. Virtually all the
data I've come across is from contrived layout topologies on test chips
or from microprocessors with manual or heavily programmed routing. That
just isn't an option in ASIC design. I haven't found anybody who can
knowledgably tell me what kind of cross-capacitance issues to expect in
automatically routed logic. It gets down to religion. Some people say
that because this type of routing results in large numbers of extremely
small aggressors, the cross-capacitance can be neglected (the aggressors
will never all aggress at the same time). Sounds good. But I sit here
and look at the routing fanning in and out of some of my memories and
MUXes, and there are long stretches of massive adjacency. I think the
large-#-of-small-aggressors argument just doesn't hold up across the die.
Even in this random routing, there are instances of great regularity. The
second argument I've come across is that odds are against all these lines
having the appropriate phase relationship to clobber each other. But I
can't guarantee that for all signals entering and leaving memories and
muxes. What do I look like, someone who wants to run vectors for the
rest of my freakin' career?
All in all, I feel a lot of bad silicon coming on...
- [ Born To Run ]
|
|
