( ESNUG 407 Item 6 ) -------------------------------------------- [02/26/03]
Subject: ( ESNUG 405 #5 ) PrimeTime & DC Results Are Machine Dependant??!
> Wait a minute. The original question was about PrimeTime, not DC. DC's
> optimization algorithms are pretty complex, and seem to include a "wall
> clock" element. Running the same scripts on the same machine with the
> same loading will usually produce the same results. But change the
> machine to a faster or slower model, even with the same OS, and you may
> well get different results. I have seen this. Switch architectures and
> all bets are off.
>
> PrimeTime is a different animal. It's just a big spreadsheet (sorry, PT
> developers - you know what I mean). You should get the same results no
> matter what machine you run it on. Take one of the failing traces from
> one of the runs, and report that exact path on the other machine with
> -input_pins, etc. turned on. If you're running with SDF, you can easily
> track down the culprit because all the numbers should have "*" and you can
> go look the numbers up in the SDF file to see who's right! If you're
> running with parasitics, first verify that the LIBRARY models are the same
> (the .db files). If so, you may have to call up Synopsys.
>
> - Paul Zimmer
> Cisco
From: Jay Pragasam <cow=jlk herd=brecis brought prawn>
Hi John,
I also have some experience with DC/PhysOpt results being machine dependent.
I faced this long time back and checked it up with Synopsys. This is the
response that I got from them:
Hi Jay,
This is regarding your question on "Optimization based on machine
speed". The PhysOpt QOR (quality of results) is not machine-speed
based! If that is what you are seeing, then it is a bug that needs
to be reported. Let me know and I can try it out on a testcase here.
The quality of results (i.e timing, area, wns, tns) depends largely
on the options you use with the "physopt/compile_physical" commands
and of course, the constraints set on the design. Bad or unreasonable
constraints can give bad results. Regarding the number of passes; the
default PhysOpt run, which is timing-based, will execute coarse
placement, and 4 runs of detailed placement (apart from the
optimization steps). A "physopt -congestion" will execute several
passes of placement, based on the hotspots in the design. (You would
see phrases like "Adjusting PLacement..." in the log, for congestion-
based PhysOpt runs).
Of course, if you relax the constraints for the "x" paths you
mentioned, that will affect the optimization results, as the design
"cost" gets changed (same as compile cost in DC).
The runs and qor should not be machine-dependent. Let me know if
this answers your question, or you need more details.
Paul Zimmer suggests that DC/PhysOpt results could be machine dependent,
but not PrimeTime results. I hear from Synopsys that even DC/PhysOpt
results can not be machine dependent though they certainly are architecture
dependent, but I've seen consistently better results on Linux machines than
Solaris machines.
- Jay Pragasam
Brecis Communications San Jose, CA
---- ---- ---- ---- ---- ---- ----
From: [ The Winchester History Mouse ]
Subject: RE: ESNUG Post 400, Item 7
Hi, John,
We have seen similar issues in the past, specifically with differences in
results not only across platform but also between 32 and 64 bit versions
in PrimeTime 2000.11. The following is the response from Synopsys R&D when
we reported the 2000.11 issue and also acknowledges (I think!) issues with
2001.08. I quote:
"Regarding this problem, hp32 system result is correct.
This is quite interesting case. As you said, there is no difference
in the result except 2000.11-SP1. But as you can see in the
directory 2001.08HP (32 and 64) result are same with HP64 of
2000.11-SP1 and 2002.03 HP(32 and 64) are same with HP32
of 2000.11-SP1. So even though there is no difference in one version,
2001.08 and 2002.03 are different with each other. Actually this
difference comes from the get_timing_path.
Some paths are missing when this command is used in 2000.11-SP1
HP64 and 2001.08 HP32/HP64.
These paths can be verified it's existence using report_timing command.
This problem is not happened in case of SUN platform though all
versions and HP platform no longer from 2002.03."
We have just migrated to PrimeTime 2002.09 and our in-house QA shows it's
now consistent across Sun & HP, and 32 & 64 bit.
Please keep me anon.
- [ The Winchester History Mouse ]
|
|
