PRESS CALL: I just got a call from a reporter looking for people with
experiences dealing with large 100K to very large 300K+ designs using
Synopsys for an upcoming article. Questions the reporter wants to ask
are things like: "Does your design choke in Synopsys and what do you do
to overcome this?" "Are links-to-layout there yet?" etc. If you
want to be interviewed by this reporter, e-mail me your name, company name
phone number, gate array size & technology, what this ASIC's designed to
do, how you use Synopsys, etc. in a 55 line (at most) e-mail to me. I'll
forward this on to the reporter to sort out.
- John Cooley
the ESNUG guy
( ESNUG 147 Item 1 ) ---------------------------------------------- [9/2/93]
Subject: ( ESNUG 146 # 3 ) "I'll Trade You This Script For Help!"
> [ a dc script to remove hierarchy deleted ]
>
>Quid pro quo, well, here's my question. In the same hierarchial design, I
>no longer need to use some of the functionality so many outputs are no
>connected. Going through the hierarchy, if all the gates that drive the
>unconnected outputs were removed it would save me about 30% of the size. I
>wish to keep the design in a hierarchial form and cannot figure how to get
>Synopsys to remove gates that don't drive any nets across a hierarchial
>boundry. Is there a way?
--- --- ---
From: [The ESNUG Addict]
After offering the script, I just had to respond to this user's question.
I'd try the "set_unconnected" command. It should do the job. You'll have to
run a hierarchical compile with boundary optimization (try "compile
-incremental_mapping -boundary_optimization"), or use "characterize
-connections" on the sub-blocks and then compile them, in order to propagate
the unconnected attribute across the hierarchical boundaries and remove the
unused gates. I've never tried it with the unconnected attribute but I know
it works for the "set_equal" on inputs. I hope this helps. Good luck!
- The ESNUG Addict
--- --- ---
From: Ken Lawrence <ken@inmos.co.uk>
Here's a couple of "pointers". The problem is that with a hierarchical
design the ports of sub-hierarchies are "sacrosanct". If however, you
are able to identify the ports of the sub-hierarchy which connect to
the redundant logic (and that may be a problem) there is a command
called "remove_port" (available only since v3.0a, I think).
If you don't know which sub-hierarchy ports are redundant you can get
some help AFTER compilation; Design-Compiler can spot ports with no
logic driving them by using the command "all_connected". Unfortunately
if your design is complicated this may end up being a recursive
procedure which you, perhaps, want to avoid. We are currently trying to
address this by writing an in-house tool which determines ALL
redundancy and associated ports by analysing a `flattened
representation' of the design. The information reported by the tool
will be used to create a "remove_port" script so that all redundancy
can be removed in a single pass of the compiler.
Hope this may be of some help.
- Ken Lawrence
Inmos, UK
--- --- ---
From: Al Porter <alpo@sun1.atitech.ca>
Hi John
We have experienced simular problems when extracting sub-functions from an
existing design. Most of our experience has been with V2.2b and it hasn't
yet been duplicated on 3.0a.
If the logic was purely combinational, the set_unconnected (outputs) and
set_logic_one or set_logic_zero (inputs) worked quite well. The thing to
watch out for was placing a dont_touch on an instance that is intended
to be removed (Maybe also beware the removable library attribute). When
this happened you would end up with an instance with nothing connected to
it's output.
If the logic had storage elements things were trickier, especially if there
was a feedback path from the output of the storage element to it's input
(chicken / egg syndrome). In several places we had to group the guilty
storage elements (no combinational logic). The outputs from this block
were then forced to unconnected and the block compiled. This should leave
a module that has no logic in it. This was then ungrouped at the original
level, and this was recompiled. Then synopsys was then able to remove the
required logic. Yes it's messy, but it worked.
The other main problem we say was the propagation of constants through the
design. Due to the functionality being stripped out, VDD and GND connections
and feed throughs were introduced in low level modules. Although synopsys
can propagate a constant into a level of hierarchy, it seemed that it had
trouble propagating it out of a level of hierarchy. To work around this, we
successively ungrouped (with a prefix) hierarchy, filtered out the VDD/GND
instances (fgrep -v) and regrouped (using prefix). This also removed any
feed-throughs which had been left behind. Finally a recompile was done to
propagate the constants down into other modules. Unfortunately this becomes
a loop until all the tie points are removed or you're happy with the results
(or fed up enough to quit). Beware of doing this at a level of hierarchy
that is not purely interconnect or your resulting port names will become
n<XXXX>. Also say goodbye to a nice bussed schematic (the result is
bit-blasted) and be prepared to live with the new port names which result
(they inherent the name of the attached net at the parent level). Life's
never simple. I hope this is of some use.
- Al Porter
ATI Technologies Inc
( ESNUG 147 Item 2 ) ---------------------------------------------- [9/2/93]
Subject: (ESNUG 144 #2, 145 #1) "Synopsys/Mentor Falcon Framework Integrator"
>> I just returned from one of my customers who just installed Synopsys v3.0b
>> with the Falcon Framework integraror. Everything seems to be okay with
>> exception of actually invoking the Synopsys application from the Mentor
>> Design Manager application...
>
>Following up on this issue the problem was that "install_dc" was never
>run! We (myself and the customer) were under the impression that when
>the Synopsys applications were installed off the CD the installation was
>complete. Not so ... RTFM ;-)
From: Synopsys Applications Engineering
PROBLEM SYMPTOM: When I try to bring up dc_shell from within Mentor's
Design Manager, I get an error saying that the dmgr_dc_shell script does
not exist.
BACKGROUND: The script that the Design Manager is trying to execute is
located in $SYNOPSYS/<arch>/syn/interfaces/mentor8.2/bin (<arch> is the name
of the directory containing the hardware architecture specific files for your
particular server workstation). These scripts are not in this directory when
the software is copied from the CD ROM, but are built on-the-fly with
install_siff.
SOLUTION: Check the $SYNOPSYS/<arch>/syn/interfaces/mentor8.2/bin directory
to see if it is empty. If there are no script files in the directory, run
the $SYNOPSYS/admin/install/syn/bin/install_siff script as shown in the
Inst. and Config. Guide on page 1-28. If the dmgr_* files do exist, you
might want to take a look at them to see what path names they reference.
Re-run install_siff to update the path names in the scripts.
- Synopsys Applications Engineering
( ESNUG 147 Item 3 ) ---------------------------------------------- [9/2/93]
From: bill@txc.com (Bill Rubin)
Subject: How To Fix One Known Synopsys DC EDIF Output Problem
John -
We were having a problem with the Synopsys DC EDIF output. It seems that
the EDIF reverses all our busses that counted 7 DOWNTO 0. It took us a while
to find the problem, and I thought I should warn others. Our Synopsys AE
gave us a hint about the DC variable.
There is a new variable in DC 3.0: edifout_numerical_array_members.
According to "help edif_variables":
edifout_numerical_array_members -- When edifout_netlist_only
is false or this variable is false, in member constructs,
the integerValue that is the index into an array is 0 for
the first member of the array and increases by 1 for each
succeeding member of the array, regardless of whether the
bus is ascending or descending.
The defaults in ~synopsys3.0b/admin/setup/.synopsys_dc.setup are:
edifout_netlist_only = "false";
edifout_numerical_array_members = "false";
We set both variables to "true" in the .synopsys_dc.setup file and
our problem went away. I have no idea why the default is "false" except
maybe for consistency with V2.2b.
- Bill Rubin
TXC
( ESNUG 147 Item 4 ) ---------------------------------------------- [9/2/93]
From: vaseem@berlioz.nsc.com (Vaseem Anjum)
Subject: Translating Designs From C to Verilog
Hi John,
I was wondering if anyone has translated designs from C to Verilog. The
design should be synthesizable by Synopsys. Any pointers greatly appreciated.
- Vaseem Anjum
National Semiconductor
( ESNUG 147 Item 5 ) ---------------------------------------------- [9/2/93]
From: rachak@birch.ee.vt.edu (Ramana V Rachakonda)
Subject: ViewLogic/Synopsys Problem
I am working on a project in virginia tech. We write vhdl code and
synthsize it to xnf(Xilinx Netlist Format) through a variety of steps that
make use of both viewlogic and xilinx tools excluding the initial compilation
to edif with the help of synopsys synthesizer. One of my programs makes it
smoothly through the synopsys tools and some parts of the viewlogic tools but
crashes with a program called wir2xnf (Viewlogic). The error it gives is
"Illegal PIN to PIN Connection (OUT to OUT) : Net look_up110"
When I tried searching the edif file created by viewlogic it I could not find
the corresponding net. But brousing through edif file gives me a feeling that
there has been some misinterpretation of my code by the synopsys synthesizer.
I declared an array of Bit_Vector which I am using as a look_up table.
If somebody knows anything about this, I would like to know. Any help on the
issue will be appretiated. Thanks in advance.
- Ramana V Rachakonda
Virginia Tech
|
|
