( ESNUG 358 Item 8 ) --------------------------------------------- [8/23/00]
Subject: ( ESNUG 353 #5 ) A Characterization Guy Sells Characterization
> Another key area is in achieving concurrent timing/noise closure. While
> we hear stories of success in correlation between the Synopsys frontend
> and backend Avanti tools the bottom line is different estimation, timing,
> and routing engines never will correlate unless they are the same piece
> of code. Sure we will hear of the few cases where it was "close enough".
> Trust me on this one _your_ design will not be one of them.
>
> - [ Tall Thin Dude ]
From: [ "A Small EDA Vendor" ]
John,
Please make me anon.
It should be intuitively obvious that, even if you apply the same .lib or
.tlf source to the end applications, with different delay calculators and
unique interpretations of the data, results will be different. Isn't this
one of the reasons why we're currently seeing sub-180nm closure becoming
increasingly difficult? Do I hear a collective ESNUG "well, du-uhhhh"?
Hence the rush to merged logical/physical construction. My concern about
this head-long rush to yet one more "holy grail" is that timing analysis is
still being performed with simple static abstractions of cell behaviours;
sure, you should get consistent timing results, and you might have fewer
iterations and get to tape-out sooner. But if your library has guardbands
on top of conservatism on top of fudge-factors on top of some arbitrarily
applied bench constant you're leaving ~25% performance on the table. And
yet still paying for it...
> Oh, and that over-constraining you end up doing? Bigger designs? Ever
> thought about the impact on yield? And do you ever have any hold-time
> problems?
And when VDD drops to around 1.2V, IR drop becomes critical (200mV is now
16%), while the input switching/linear region is rarely more than 40-60%
(where we've been using 20-80% for a decade or more). Couple that with an
increase in other non-linearities (driver admittance for one; resistive
shielding for another), and it's clear the consistency and correlation of
different timing calculators is about as likely as Gerry Hsu offering his
wrists to the San Jose D.A. with the words "he's a fair cop, guv, it was
me what done the deed".
Now (and here's my caveat and disclosure) I'm a long-time characterization
guy, working for a company with the very strong belief that these dynamic,
instance-specific behaviours force the requirement that timing calculation
be performed within the model itself.
In short, merged logical/physical tools are good. Feeding them with simple
static pre-defined operating point data is bad. And getting worse.
- [ "A Small EDA Vendor" ]
|
|
