( ESNUG 270 Item 7 ) -------------------------------------------- [10/31/97]
Subject: ( ESNUG 267 # 6 268 # 2) Synopsys 1997.08 -- To Use Or Not To Use?
> We are finding that designs that compiled fine with 1997.01-44683 and 3.4b,
> cause those "friendly" FATAL ERROR ENCOUNTERED in 1997.08.
>
> I've been trying to get a pulse from some of the AE's at Synopsys if this
> 1997.08 release is worth progressing to (from 1997.01-44683) or not. At
> least one AE claimed none of his/her other customers had upgraded, yet, so
> he/she had no other feedback but mine.
From: "Tom Harrington" <tharring@ford.com>
John,
As Greg Mann mentioned to you, we've been bitten by fatal errors on
Synopsys 1997.08. I thought ESNUG readers might be interested in the
details of the problem as we're experiencing it.
Our fatal errors with 1997.08 are related to the use of parameterized
sub-modules. If you analyze/elaborate a design that instantiates
a parameterized block, dc_shell croaks just as it tries to build
the sub-module. So far I've observed this on two separate designs.
Since we make heavy use of parameterized blocks, this is a major
roadblock for us.
We're using Verilog, although I'm not sure yet if that's significant.
Unlike Howard Landman, we don't use connection_class at all. For
now, 1997.08 has been declared unfit for human consumption around
here while I try to find a work-around. I've submitted a test case
to Synopsys support, but so far I've only received auto-responses.
Our AE says he hasn't heard of any other problems with this release.
Synopsys 1997.08-12345, anyone?
- Tom Harrington
Ford Microelectronics, Inc.
---- ---- ---- ---- ---- ---- ----
From: landmh@taec.toshiba.com (Howard Landman)
Hi John,
My problems with 1997.08 crashing went away after I:
(1) Removed all connection_class statements from my library
and recompiled the library.
(2) Removed all "set_connection_class" commands from my scripts.
(3) Executed the following on all .db files to remove any stored
connection_classes:
foreach(des,find(design)) {
current_design = des
set_connection_class "default" find(port)
}
So, it looks like the problems *were* connection_class related. However,
some other people reported that they were crashing without having any
connection_class stuff. I'll see if I can find their email and forward
it to you.
I'm still having other problems, most notably long run times. One job just
completed after 11.5 cpu-days, for example. And that was "-incremental"!!!
- Howard A. Landman
Toshiba America Electronic Components
|
|
