( ESNUG 207 Item 4 ) ---------------------------------------------- [1/18/95]
Subject: (ESNUG 205 #5 206 #2) Headaches w/ Synopsys To Mentor w/ "db2eddm"
>When we asked both Mentor & Synopsys about going from EDIF to EDDM, the
>answer was a definite "NO". We have encountered some problems with the
>db2eddm path (nets crossing bus rippers that were shorted in Mentor and not
>in Synopsys, etc.) Do you have any suggestions from any of your readers?
From: bolling@lds.loral.com (Randy Bolling)
John,
We worked this one into the ground at GTE. The only two solutions we found
that were definitive were to either un-bus the schematics (obvious downturns.)
The other solution is to write a Mentor Ample script that draws schematics
from the read-in edif files of each level of the design. The second task
tends to be too slow to be effective (10-12 hrs. vs. 1 hr. using db2eddm.)
We found shorted nets, shorted bus rippers to net(s), and un-reported net
renaming instances which implied a short by name only. In the latter case,
the use of two signals named "SignalName" and "SignalName_reg" caused the
short after translation through db2eddm; that passed check sheet, only to be
found in simulation as a double-drive situation. This lead to un-bussing
certain portions of the design that were susceptible to the phenomenon, and
avoiding nets names in the code to prevent the accidental connectivity.
- Randy Bolling
Loral Data Systems
---- ---- ---- ----
From: bmoore@space.honeywell.com (Bruce Moore)
John -- We have also experienced the headaches associated with db2eddm
schematic generation for some time now. What we saw includes:
- Nets being accidentally connected to another net at bus rippers
- Nets which cross but don't connect in Synopsys but are shorted in Mentor
- Input side and output side of a buffer being shorted by the same net name
The bus ripper problem can actually be seen prior to the db2eddm conversion
in Synopsys Design Analyzer as two nets laying on top of each other, but
still individually selectable. (It seems like there needs to be some sort of
"keepout zone" specified for the bus ripper which isn't getting done.)
We have also seen problems in eddm2db conversion, especially if these same
schematics are later converted back to EDDM (for example, if you are
inserting scan at the end of the design instead of during initial synthesis.)
Also, Synopsys Design Compiler (which is case-sensitive) might add new nets
by the name of "net_2" because it doesn't see that Mentor has upper-cased a
previously named net to "NET_2". In the return trip back to Mentor EDDM
(which is NOT case-sensitive), these nets are then shorted together!
While we did not find a solution to these problems when converting from
Synopsys to Mentor, we did drive the problem out of the Synopsys schematics
by simply changing the sheet size and re-generating the affected schematic.
(Synopsys solutions did not work for us.) We edited by hand in Mentor Design
Architect (yuck) and went on. Fortunately, the problems are few and far
between, and can quickly and easily be detected in our case by running our
ASIC vendor's Verify tool which looks for design rule violations such as
shorted outputs.
We got around eddm2db problems by using VNET to convert to a Verilog netlist
on our way into Synopsys DC.
- Bruce Moore
Honeywell Space
|
|
