( ESNUG 314 Item 7 ) ---------------------------------------------- [3/17/99]
Subject: ( ESNUG 311 #6 ) Incremental DC Compiles Wrecks My Timing !!!
> 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)
From: Jeffrey Ebert <ebert@sonicsinc.com>
John,
This doesn't answer Sol directly, but this is another approach that he
could try:
I think that Sol should characterize the DW01 instance between steps 4
and 5. This would provide proper input drive and output load
characteristics for the DW01 pins. He can still overconstrain the timing
without introducing design rule violations.
Of course, if timing is met in step 4, why is he overconstraining DW01?
I used to do things like this in old Synopsys versions, but I have found
it unnecessary lately.
- Jeffrey Ebert
Sonics, Inc.
---- ---- ---- ---- ---- ---- ----
From: Andrew Maccormack <andrewm@bristol.st.com>
John,
When Synopsys had a seminar on their new 98.02 version of DC early last year
I remember them saying that they knew that to get the best out of DC in the
past you had to over-constrain it, but now over-constraining it (especially
in area) was *BAD*. Part of this was probably to sell PrimeTime's timing
budgeting to people, but also it is the "intuitive" approach... we're just
used to rubbish synthesis tools!
I would be interested to know what effect using the "set_critical_range"
command has, especially if you make it large enough to include the amount of
violation you end up with.
- Andrew R MacCormack
STMicroelectronics
|
|
