( ESNUG 404 Item 6 ) --------------------------------------------- [01/08/03]
Subject: ( ESNUG 400 #7 ) Why DC 2002.05 Differs On HPUX vs. Linux/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 .
When I enquired for the cause of that behavior I was first answered that it
was due to the synopsys cache. During the optimization DC stores
information about the DW modules that it compiles to optimize the design.
In subsequent runs it reuses these results that have been stored in the
cache saving the compilation time needed to generate the DW technology
specific view. These slightly different processes may supposedly cause the
differences. Still I was not pleased with that explanation because I
believe that in any case identical optimization should give identical
results. I kept on experimenting starting with an empty cache. The area
results were again different. I submitted the test case at the local
support and they could not reproduce the problem at the beginning. I
finally found a configuration where I first optimized targeting the slow
asic lib, followed by the same optimization targeting the fast asic lib,
followed by the same optimization targeting the slow asic lib. This
sequence appears to always lend to different area results for the 2
optimizations targeting slow lib. This has been recognized as an issue
and will be fixed in a coming release of DC.
I havent got any explanation regarding the actual cause, but I can think
of some possibilities:
- unitialized variables
- read outside data structures boundaries
Other possible causes that did not apply to my specific case:
- multi-threading execution
- program that rely on seed value to initialize some algorithm
Hope this helps your readers.
- Pierre Ragon
Lucent
[ Editor's Note: Pierre what you describe here is what I called the
white space bug waaaaay back in ESNUG 135 #1. Basically it boils down
to the fact that DC relies on OS specfic seeds for its algorthms;
which means each OS can give you slightly different results. - John ]
|
|
