( Post 84 Item 1 ) ------------------------------------------------------
From: kagar@dtc.Kodak.COM (Keith Agar)
Subject: Net Shorts in Synopsys EDIF Outputs
John,
You mean you've found bugs with Synopsys too??
Currently we are running Synopsys v2.2b on a Sparc2. Target system
is Mentor v7.0 on HP400 series boxes. Interfacing is done via EDIF
schematic netlists (the ESIread command on Mentor).
We use Actel, NCR and VLSI technology libraries with VHDL as source
code input on Synopsys.
Our biggest complaint currently is when you re-optimize a design in
Synopsys with a max fanout constraint, it does the buffering okay,
but creates an Edif out file that has net shorts. I sent a test case
to Synopsys last week, they confirmed it and assigned it a STAR #.
The problem is related to our using create_schematic with a "-no_bus"
option. We have to use that option, however, because we have never
got the Synopsys to Mentor interface to work using busses.
The only current workaround is to read in the design to Mentor, create
a vendor netlist, run their netchecking software, find the blocks
with shorts, go back to Synopsys, reoptimize those blocks, write out
a new EDIF, and bring those blocks back to Mentor. Time consuming!
- - - - - - - - - - - - - - - - - - - - - - -
[ Editor's Note: I wrote Keith and asked for more details.
Here's what he sent back. -John ]
- - - - - - - - - - - - - - - - - - - - - - -
As far as more detail concerning the problem it also deals with the
variable:
write_name_nets_same_as_ports = true
As far as I am aware, this variable must be set when using the
Mentor v7.0 interface to ensure that the net driving a hierarchical
port has the same name as the Mentor symbol pin that is created when
an EDIF file is written out of Synopsys. The problem occurs when you
reoptimize with a max fanout constraint and buffers are added to a
net that used to go (for example) directly from a Q pin of a DFF to
a hierarchical portout connector. In the Synopsys environment, the
net that is still attached to the Q pin of the DFF retains the port
name of the old, unbuffered design. The net on the other side of the
buffer (the one now connected to the portout symbol) gets some Synopsys
created nXXX name. The portout symbol name is the SAME as the net
connected to the Q pin of the DFF. This is the problem. When you write
the EDIF file out, the Synopsys named net (nXXX) connected to the
portout symbol gets named the same as the net attached to the Q pin
of the DFF, due to the above variable being set (which I believe has
to be set for correct compiling in the Mentor system). You get a net short.
Apparently, this problem doesn't occur if you don't use the "-no_bus" option
with create_schematic, but I gave up trying to get busses to translate
from Synopsys to Mentor about a year ago :-)!
It also goes away if you re-optimize the problem design blocks with the
max fanout constraint twice. On the second compile, all nets in the design
get some Synopsys nXXX name which don't conflict with the port names
(unless you wrote your source code with nXXX variable names).
Keith Agar
Digital Technology Center
Eastman Kodak Co.
|
|
