( ESNUG 417 Item 1 ) -------------------------------------------- [09/08/03]
Subject: ( ESNUG 416 #8 ) Another User Sees Bad PhysOpt Quality Of Results
> We found that we have a 5-10% path delay difference with 2002.05-SP2 to
> 2003.03-1 & 2003.06-1 versions of PhysOpt using the exact same compile
> scripts! We saw that the results at the end of Design Compiler runs are
> very close between the 3 versions -- but the starting point of the
> PhysOpt, after the create placement is showing a 10-15% degradation
> in WNS.
>
> - [ A Little Bird ]
From: Chandra Moturu <chandra.moturu=user company=hp not palm>
Hi, John,
Our testing so far concurs with the above as well and the case was reported
to Synopsys. I noticed a change in mapping optimizations between 2003.06-x
Beta versus the production version and this may be the culprit.
- Chandra Moturu
Hewlett-Packard
---- ---- ---- ---- ---- ---- ----
From: [ The Cheshire Cat ]
Hi, John,
Please keep me anon.
ESNUG 416 #8 was an interesting albeit disturbing read.
Off the top of my head, I can think of two possible causes for the WNS
degradation that Little Bird is seeing:
A) Via resistance calculation (and technology file handling in general)
was overhauled in the PhysOpt 2003 codebase. For 90nm processes, via
resistance is becoming much more of a factor, but a 5-10% hit on path
delay seems borderline suspicious.
One thing for Little Bird to check on are the RC coefficients that
PhysOpt reports at the start of the physopt/compile_physical run.
In PhysOpt releases up to 2002.05, you could grep for GR-1 info
messages in the transcript. Starting with PhysOpt 2003.03, you now
need to grep for RCEX- info messages.
There is a even more direct method of determining if the updates to
the technology file handling are responsible for the path delay hit:
1) read a placed & optimized DB from PhysOpt 2002.05 into PhysOpt
2003.03/2003.06
2) run standard set of reports (report_timing/_qor etc)
3) now invoke the 'run_router' command
4) now rerun set of reports
5) compare path delays
B) The 2nd error guess doesn't fit with the facts, but I'll throw it
out anyway. Starting with 2003.03, Synopsys changed the code for the
following physopt/compile_physical commands:
compile_physical/physopt -effort high
compile_physical/physopt -effort high -timing_driven_congestion
One possible explanation for Little Bird's QoR degradation is that
he's uncovered bug(s) in this new optimization code. Thankfully,
Synopsys has provided yet another variable to disable the
new optimizations:
set physopt_disable_new_high_ effort_flows true
Either way, I'd strongly recommend that Little Bird send one (or even
better, all) of his testcases to Synopsys R&D -- yeah, easier said than
done when you have to worry about your company's IP, not to mention 3rd
party IP, but it ultimately helps Synopsys build a better product.
- [ The Cheshire Cat ]
|
|
