( ESNUG 405 Item 5 ) --------------------------------------------- [01/29/03]
Subject: ( ESNUG 404 #6 ) Both DC & PrimeTime Runs Differ On HPUX & Solaris
>> Our team is trying to close on timing analysis (using PrimeTime) with our
>> ASIC vendor on our post-route netlist. We are using PrimeTime
>> 2001.08-SP1. Our vendor is running Linux and Solaris and gettings the
>> same results on either platform. Here running on HPUX we get different
>> violators from the vendor using the same constraints and scripts. We
>> also checked the violators using the following commands:
>>
>> 1. report_analysis_coverage ......
>> 2. report_timing -delay_type min ......
>> 3. report_constraints -all_violators -verbose ....
>>
>> All commands show that we have 34 hold violations and they are all the
>> same. But our ASIC vendor running the same scripts reports zero hold
>> time violations running under Linux and Solaris. Does anyone know of
>> any reason why there would be discreprencies across platforms?
>>
>> - Craig Taniguchi
>> TRW
>
> From: Pierre Ragon <bullbullbull pprraaggoonn from lucent cot balm>
>
> Hi, John,
>
> I had a similar experience using Design Compiler 2002.05 on a Sun-Solaris
> workstation. What is even more puzzling is that running on same OS and
> workstation the same optimization of the same design gave different
> results. I start noticing it when we ran optimization of quite large
> partitions (20 to 25 k flops) of the design. Then the final area would
> differ. A test case for this has been submitted.
>
> - Pierre Ragon
> Lucent
From: Paul Zimmer <preacher=pzimmer church=cisco sought yawn>
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: Gzim Derti <derti|itred shouting from agere/agere wrought con>
To: Pierre Ragon <pprraaggoonn of lluucceenntt clot von>
Morning John and Pierre...
John, you mention the "white space bug" that's been around forever with DC,
but I'd like to find out from Pierre what OTHER jobs were possibly running
at the same time on the system that he compiled his design on??
Back a couple of jobs ago, I was running into an issue where the same code
was running overnight and giving me one result, but when I'd run it during
the day (while I was working and doing things on the same box) I'd get
a different area. The only thing I could attribute the differences to were
the amount of "wall clock" time elapsed during the compile.
As we all know, DC uses a diminishing returns concept to tell it how long
to "churn" on a section of gates. According to everyone at Synopsys that
I talked to at the time they told me that their "clock" was the number of
"cpu clocks" spent on the design. My contention was that it was actually
using "wall clock" time and if the system were loaded with other things
"wall clock" time would pass while less actual "cpu clock" time was applied
to the synthesis run... and as such, DC would stop "churning" with fewer
optimization trys.
I've been called crazy concerning this (not to mention other things that
aren't relevent to the current discussion) by more than one person over
the years, but since the topic has come up angain, I figured I'd put it
out there and see what happens.
Anyway, thanks for listening.
- Gzim Derti
Agere Systems
---- ---- ---- ---- ---- ---- ----
From: Pierre Ragon <pragon|nogarp near l*u*c*e*n*t fiat yon>
To: Gzim Derti <ddeerrttii by agere|erega scott guam>
Hi Gzim, John
In my case it was not a matter of the white space bug. I read ESNUG 135 and
I believe that it covers a different issue. Everything was identical from
one run to the other. Machine, OS, source code, script etc. Now regarding
what else could have been running. Difficult to say. It is likely that
some light foreground activity was taking place like writing mails or
editing files. No other jobs were running in the background except for of
course some system activity. One thing that I can mention is that I have
logged a test case to Synopsys support. According to their support people a
job must produce always the same result when it is run in the same
environment. No one argued about the results could depend on the load of
the computer. This is why I am also very keen on understanding what could
cause that. Thanks for your interest,
- Pierre Ragon
Lucent
|
|
