( ESNUG 311 Item 6 ) ---------------------------------------------- [2/18/99]
From: sol@lexra.com (Sol Katzman)
Subject: Yeach! Those Incremental Compiles Are Wrecking My Timing !!!
John,
Yeach! A second compile apparently wrecks timing under certain conditions.
We have found that the area-reduction phase of an incremental compile
either ignores timing violations, or incorrectly calculates timing, IF
there is a design rule violation at the start of the incremental
compile AND the max_area attribute is over constrained.
The result is that a design that met timing before the incremental compile
is turned into a design that is smaller, but no longer meets timing. Not
what you want. (Definitely not what you want.)
Our flow is as follows for module "jpt":
1) read -format verilog jpt
2) set_max_area jpt 2500
3) apply custom wire load model to jpt
4) compile jpt
-- generates designware submodule "DW01"
-- timing met
-- design rules met
-- area 6500
5) apply custom wire load model to DW01
6) compile DW01 with overconstrained timing
7) report constraint -all_violators for jpt
-- timing met
-- area not met (okay)
-- fanout design rule violation (due to step 6)
8) compile -incremental jpt
-- timing *apparently* met (0 delta delay)
-- design rules met
-- area 6200
9) report constraint -all_violators
-- timing NOT met (VERY BAD)
-- area not met (okay)
-- design rules met (good)
Key points:
In step (8) Design Compiler shows DELTA DELAY = 0, but report_timing
(corroborated with primetime) shows beaucoup violating paths.
(NOTE: the fanout violation is not known to the step (6) compile of
DW01, presumably because part of the fanout on the net in jpt is
outside DW01.)
WorkArounds:
Any of the following workarounds eliminate the problem:
(a) omit step (6) -- no fanout design rule violation
(b) loosen fanout design rule after step (6)
(c) loosen max area constraint in step (2)
(d) remove area constraint before step (8) <-- chosen approach
WorseArounds:
If a full compile (not incremental) is used in step (8), then
(c) and (d) don't work because the full compile always tries
to reduce the area, even without a max_area attribute!
My guess as to what's going on:
Due to the design rule violation, the incremental compile sets a
switch to fix it at all costs, including making timing worse. Then
in the area reduction phase, it forgets to turn the switch off.
I don't know why the incremental compile shows 0 delta delay, but
report_timing definitely finds real timing failures in the
resulting design.
This behavior was observed in both 1998.02 and 1998.08 versions
of design compiler.
Conclusion:
Watch out for incremental compiles!
- Sol Katzman
Lexra
|
|
