( ESNUG 133 #1 ) -------------------------------------------------- [7/93]
From: epic!kate!fish@netcom.com (Randy Fish)
Subject: Want Verilog/VHDL to SPICE/HSPICE translator
john,
do you know of any available translators to get my netlist out of
Design Compiler and into HSPICE format? i do not want to generate a
schematic in Cadence/Mentor/Viewlogic in order to accomplish this.
ideally, it would also support hierarchy. possibly an "EDIF 200"
or Verilog to SPICE converter.
- Randy Fish
Epic
( ESNUG 133 #2 ) -------------------------------------------------- [7/93]
From: [ anonymous ]
Subject: A Few Minor DesignWare Bugs & Some Serious Simulation Concerns
John,
Due to politics, please post this as anonymous.
In the two examples of using the GTECH library it appears that the two
multiplexer data inputs d1 and d2 are swapped. From the Designware Databook
the truth table for MUX4 is:
A B Z
0 0 d0
0 1 d2
1 0 d1
1 1 d3
This demonstrates one of the major problems with instantiating "technology
independent components" someone has to build a library of mapping functions
then test them for correctness. This slows down the design process which was
supposed to take advantage of high level behavioral design.
Another issue is that the examples as given are not the most simulation
efficient, in particular the Verilog version does not take advantage of
the XL algorithm which can speed up simulation by 8-10X. Typically in
heavy datapath designs (where you would find MUX's) the XL algorithm
provides a substantial simulation performance increase. In the VHDL version
the use of others selecting d0 is definitely incorrect from the standpoint
of simulation accuracy.
In the drive toward better synthesis results the net effect is to degrade
simulation performance, readability and portability of designs.
- Anonymous
( ESNUG 133 #3 ) -------------------------------------------------- [7/93]
From: kkranen@synopsys.com (Kevin Kranen)
Subject: Cadence / Synopsys Interfaces
Synopsys and Cadence have been cooperating over the past year to deliver
an integration in the form of an updated Cadence EDIF and a new
Cadence product called CSI2 (Cadence Synopsys Interface 2). It is
available concurrent with the Cadence 4.2.2 release and works best with
Synopsys v3.0b and above.
While we cannot guarantee it, since it is not a Synopsys product, several
of the early testers have found it to hit the mark. It contains key
capabilities such as full, automatic, bidirectional transfer of
hierarchical & bussed designs. You can also look forward to using Synopsys
in an interactive fashion.
Even if you are looking at doing your own integration, I would advise using
EDIF for the Synopsys => Cadence path. Our experience has been that this
path is NOW (v4.2.2) much more robust than through Verilog => schematic
generation.
Good Luck
- Kevin Kranen, Synopsys, Inc.
Product Marketing Manager - Interfaces & Integration
-- -- -- -- -- --
From: jws@billy.mlb.semi.harris.com (James W. Swonger)
Subject: Cadence's EDIF Interface
The Cadence EDIF[out,in] seems to be improving. Forget about Edge based stuff
though. Opus 4.2.1 doesn't handle wire bundles. 4.2.2 takes bundles OK but
still gives me cryptic error messages. I have written and read back some
schematics with 4.2.1 (with bundles removed) and 4.2.2. There are still a
few problems.
Problem #1 is that if your library is writable, the read-in will overwrite
existing cells. This wouldn't necessarily be bad except that some of the
property text, etc. get changed to plain text or stripped. Losing things like
value parameters or w,l on MOSFETs is not helpful.
Problem #2 is that the quality of the I/O seems to depend markedly on the
template file. There are a lot of undocumented switches, settings, mappings
from what I've seen and few are set by default, fewer to a really useful
(or correct) value.
If you're trying to read Someone Else's EDIF then you'll definitely need
to do some figuring and poking. There seems to be no convention regarding
naming of layers (FigureGroups) and one company's PIN must be mapped to
Cadence Pwire for anything to work; unrecognized layers do not get brought
in properly. They may give errors, may cause the cell to simply not get
created, or may give you a cell that looks normal but has wrong layers.
Only Pwire figures pass connectivity, so you can get a good-looking
schematic that doesn't work at all if all your pins end up on a default
layer.
Problem #3 is that the use of libraries seems to dramatically affect
EDIFIN/EDIFOUT behavior but without apparent logic. For example, I can
read in a deep schematic if I have a library for it to write over, but
not having a library seems to mess things up, as does having a non-
writable library. There's no way I know of to specify where read-in
libraries ought to go, and I haven't figured out any way to make it
understand that it ought to -reference- an existing library instead
of trying to overwrite it and then get peeved if it can't.
This Cadence tool set needs documentation very badly. No, scratch that,
bad documentation it has already. The following (for benefit of Cadence
insiders) are missing or unusably vague:
- Listing of error messages produced and what, if anything, they might be
trying to say (missing)
- Complete list of variables/switches/settings, their purposes, their ranges
and suggested -useful- defaults (incomplete/vague)
- Description of any and all mapping files and processes (incomplete/vague)
- Clear explanation of how to get the various modes of EDIF write/read
- Full hierarchy schematic with all used library symbols all the way down
- Full hierarchy schematic except for standard reference library symbols
(instance calls only for cells not in path)
- Library symbols only (by path)
- Read in and create new library directories even if cells exist in
path, do not overwrite existing library
James W. Swonger
Harris Semiconductor, Melbourne FL
( ESNUG 133 #4 ) -------------------------------------------------- [7/93]
From: manley@optilink.com (Dave Manley)
Subject: Test Compiler
(Synopsys version: 3.0a-10063)
After running insert_test there is a very high fanout on the
test scan enable (test_se) signal. The Test Compiler manual
recommends running 'compile -incremental' which is a very slow
procedure for a large design. Is there a faster way to do this?
I don't want it to consider every net - it just needs to fix
test_se. (Can I dont_touch everything except this net? How?)
It's interesting to note the Test Compiler manual states: 'If a
design has no design-rule constraint violations before you add
scan-test circuitry, it usually has no design-rule constraint
violations after you add scan-test circuitry.'
Except for on test_se that is....
- Dave Manley
Optilink
|
|
