( ESNUG 207 Item 2 ) ---------------------------------------------- [1/18/95]
Subject: (ESNUG 206 #1) Same Code & Scripts, Results Drop 3.0b->3.1b (& 3.2a?)
>We used design compiler v3.0b... we received version 3.1a. With the
>same scripts and the same VHDL code ... I was not too thrilled when the
>results gave me a larger design (area) and a MUCH slower design (slack)...
>I've made the switch to version 3.1b and the results were better, but not as
>good as version 3.0b. In the meantime, I've been trying a lot of different
>things in version 3.1b, but I can never seem to get the design as good as
>version 3.0b. And now they want me to switch to version 3.2a.... I'm just
>curious to know if other users have seen this problem & what they did?
From: brien@acuson.com (Brien Anderson)
Hello John,
With regards to Esnug 206 item 1, Yes, we have seen those types of problems
using Verilog. We had to put a stake in the ground and say that we could not
keep recompiling designs no matter how many times Synopsys changed versions.
We found 3.0b to be lesser of many evils (gee, why could not we not just keep
on using 2.2b forever? oh yeah -- ASIC vendor library changes). The 3.1
series was tried and rejected, so we continued to tape out using 3.0b. This
is similar to Cadence releasing tools each and every quarter. I think that
each designer must make decisions on what tools and tool versions to use
based on design cycle time and what bugs and features are present in any
version. The caveat applies of "If you don't need to change, then don't."
The good news is that the 3.2a is working fine so far (yes, the 3.2b
is coming out Feb.).
- Brien Anderson
Acuson
---- ---- ---- ----
From: [ The Man With No Name ]
Hi John, please keep me anonymous on this.
Using Synopsys VHDL I have experienced similar problems for my particular
design:
3.0a gives me a good circuit and good speed characteristics.
3.0b worst in terms of area and speed.
3.0c similar to 3.0a results.
3.1a worst than 3.0b (!). I have made several tries and found that the
problem appears during elaboration. When an operation is done on
a bus in a "for" loop all bits are affected the same way even if
they shouldn't. This problem was not easy to identify because the
compiler is able to hide it very frequently even on a design small
enough to be understood. According to Synopsys it should be solved
in 3.2a. Because of several administration problems (Synopsys & us)
I have not received 3.2a yet.
Generally speaking, I have better results using 3.0a or 3.0c. The release
3.0b was bad news. Most of the time, 3.1a and 3.1b weren't any better.
(However, I should mention that on some very big design, I sometimes got
better results with 3.1b than with all other releases.) Unfortunately, I
consider that these designs are poorly coded and should be smaller to ease
their maintenance.
The workarounds I am using are simply:
1) Compilation Script Modification. It may make a script twice as big to
obtain a comparable result but I am applying this techniques to every
design because I'm assuming there's *always* a better undiscovered way.
2) HDL Coding variation. Different coding styles get different results
depending on the revision of Design Compiler.
3) When a design contains an asynchronous condition (set or reset),
I declare explicitly all other signals (and registered variables)
and assign them to '-';
4) In a synchronous process, just after the
wait until CLOCK'event and CLOCK = '1'
or
if ( CLOCK'event and CLOCK = '1' ) then
I dress a list of all registered variables and assign them to a default
value. If the default is to keep the current value I sometimes get good
results by explicitly write it.
I've send several e-mails and phone calls to Synopsys about this fact and I
am still waiting. I'm interested in what users can share on their working
methodology with us on ESNUG.
- [ The Man With No Name ]
|
|
