The Technical Program Committee for Synopsys' March SNUG meetings will
be meeting at DAC on Tuesday. (We're Synopsys users working to make the SNUG
meetings more customer driven; if you're interested in being on this board,
send me e-mail soon.) Anyway, I've been asked to poll the ESNUG readership
for what would they like to see at the next March SNUG meeting in California.
Please send this info to me ASAP so I can bring your ideas to the meeting
next week. If any of you are going to DAC, I'll see you there!
- John Cooley
ESNUG Moderator
( ESNUG 131 #1 ) ---------------------------------------------------- [6/9/93]
Subject: ( ESNUG 130 #3) "Want to Get Rid of Escape Characters in db Files"
> From: bugs@sh.alcbel.be (F. De Meersman)
>
> I am investigating the transfer of a design, from the Synopsys db file via
> a verilog netlist towards Cadence Opus Framework, using Opus verilogIn.
> In my opinion, this way should work efficiently, but I have seen that there
> are serious problems in the verilogIn once your design contains the so-called
> escape characters (like a '\').
>
> These characters need to disappear from the verilog netlist and it is my
> hope to do this within Synopsys.
-- -- -- -- -- --
From: jms@dsbc.icl.co.uk (Jurgen Schulz)
We use the following in a script file:
define_name_rules CADENCE -allowed "a-z A-Z 0-9 _" -first_restricted "_ 0-9"
set_name_rules = CADENCE
compile -map_effort medium
change_names -rules CADENCE
This has the effect of specifying the characters that Synopsys can use to
name the signals.
Regards,
- Jurgen Schulz, ICL, UK
P.S. reading a structural netlist into the framework takes a very long time,
we just read it back in a "structural" view which is still in a netlist
format. Also Synopsys will not connect up all the ports on a primitive,
so if you then let the HDL parser loose on it it will report that some
pins are unconnected. This is fixed in version 4.2.1a.
-- -- -- -- -- --
From: brucel@zulu.sps.mot.com (Bruce A. Loyer H3-451)
I had to get rid of the [] characters and this is what Synopsys told me to do:
First do normal compile at top level. Then:
write -format db design.db
define_name_rules bus_delete -restricted "[]" -replacement_char "_"
report_names -hierarchy -nosplit -rules bus_delete > names
Then exit Synopsys. (This part is not needed with 3.0 and later versions of
Synopsys.) Execute the UNIX command:
egrep "(\[|\])" names > bus_names #only change bus names
This made sure that bus_names only had those changes that were necessary.
The old Synopsys put in some extra. The circuit was not changed, but some
names that shouldn't have been effected were. Now go back into Synopsys and:
read -format db design.db
change_names -hierarchy -names_file bus_names
write -format verilog design.verilog
Hope this helps,
- Bruce A. Loyer
Motorola
-- -- -- -- -- --
From: uunet!uranus!splinter!flieder (Jeff Flieder)
The crux of the problem that Mr. De Meersman is having is that this
flow from Synopsys to OPUS realy stinks, and the escaped names are really
the tip of the iceberg. If you remove the escaped names, then you find
that many of the net names and instance names are illegal. To give a few
examples:
net names: top/multi/net125 *cell*127net22
cell names: count_reg[10]
Also, all of the busses in the original design (like outputs of multi-bit
regs) dissapear in the output netlist.
In addition to these problems, the VerilogIn process in OPUS is iffy at
best. It tends to "give up" sometimes and just forgets to wire up a net.
It turns out that the net is wired electrically, but it is physically
8 million grids away from where it should be (OK, I exaggerate a little).
Our workaround for this problem is a Perl script that repairs the Verilog
netlist output Synopsys. It removes all the escaped names, puts the busses
back together, and fixes any illegal net and instance names. I agree that
this is not the greatest solution to the problem, but Synopsys has assured
me on many occasions that they are not going to fix the problems with
thier Verilog netlister, so we are stuck fixing it ourselves. As far as
the VerilogIn problems are concerned, cross your fingers and hope for the
best.
On the brighter side, CAE's at Synopsys assure me that the EDIF interface
works in CSI2 which will be available with OPUS release 4.2.2 due out
sometime between now and next Christmas...
- Jeff Flieder
Ford Microelectronics, Inc.
[ Jeff, I remember writing an NAWK script that does what you described
for the escape character problem back in rev 1.3 days. (At that time,
I was trying to feed Synopsys netlists to Aida ATPG and it barfed on
escape charaters!) Could you please send me a copy of your Perl
script so I can share it with other ESNUG readers? - John ]
-- -- -- -- -- --
From: John Vogel <RYGK80@waccvm.corp.mot.com>
Just a few comments on the Cadence Framework verilogIn translator.
Behavioral statements in the Synopsys Verilog netlist will force a
functional view to be created instead of the desired schematic view. Two
continuous assignment statements that you can control are the tri and
'b0/'b1. Put the following variable assignments in your .synopsys file:
verilogout_no_tri = true
compile_fix_multiple_port_nets = true
The verilogIn translator converts a hierarchical Verilog netlist
into a hierarchical set of schematics. I have seen problems associated
with the schematic generator; net labels do not get attached to the
correct wire resulting in shorted nets, and long net labels (buses)
not getting connected at all; resulting in check-sheet errors. We got
around the first problem by writing a NAWK script that writes a skill
program to automatically check-sheet on all hierarchical blocks. The
NAWK script extracted all the modules from the source Verilog netlist.
The second problem was solved but, get ready; you better sit down, by
opening the offending schematic, finding the unconnected long wire
label, and moving the wire a little! (I do not know why but the act of
moving the wire caused the net label to be properly attached...)
As far as the escape character on UNCONNECTED nets. Do these nets
matter for backannotation? My guess would be that the layout tools
would not report parasitics on unconnected nets.
- John Vogel
Motorola ASIC
[ What I said for Jeff, ditto for you; Send that NAWK script! - John ]
( ESNUG 131 #2 ) ---------------------------------------------------- [6/9/93]
From: trevor@sheridan.ncd.com (Trevor Pearman)
Subject: (ESNUG 130 #2) "Changing Register Inferencing to Latch Inferencing"
>We have recently created a mass of verilog that uses the flip/flop inference
>of "always @ (posedge clk)". Due to various reasons we have to change to a
>latch based design.
>
>Is there a simple way to have Synopsys map the flip/flop inference to a latch
>without changing the verilog?
You could make a translation lib which maps the inferred flip-flops to
latches.
eg: Your code produces flips flops from your XYZ library which are called
FF1, FF1_set, FF1_reset, FF2, FF2_set, FF3_reset.
Create a translate library (XYZ_TRANS) that defines FF1 to be a latch from
library XYZ, FF1_set to be a latch with a reset etc
Compile the modules you want to change with link library = {"XYZ_TRANS" "XYZ"}
and target library = "XYZ"
Should work. No guarentees :-)
- Trevor Pearman, NCD
|
|
