From: ton@lvs-emh.lvs.loral.com (cameron ton)
Subject: Synopsys Survey
>Joking aside, I do think that SolvIt works pretty well.
>
> - Steve Taylor
> Northern Telecom
John,
Steve is right about SolvIt. About 98% of the time, the responses
from SolvIt have provided a solution to my problem.
- Cameron Ton
Loral Vought Systems
( ESNUG 203 Item 1 ) ---------------------------------------------- [12/2/94]
Subject: (ESNUG 201 #2) Design Compiler Producing Beaucoup Overdriven Nets
>We have a problem with Synopsys inserting extremely powerful buffers
>to drive nets with small loads (i.e. a buffer designed to drive a fan
>out of 180 or more driving a fanout of 1 or 2). ... The problem is that we
>can't simply not use the strong buffers as we have many cases where they are
>actually required (so we can't just put a dont_use on the strong buffers in
>the library) -- but we end up with literally hundreds of overdriven nets
>(which also costs us significant area). We have developed scripts which
>reduce the number of overdriven nets by iteratively compiling with and
>without a dont_use on the strong buffers -- but we still end up with dozens
>of overdriven nets.
From: aluxs!alsun121!jte (John Emmott)
John,
The root causes of overdriven nets can be summarized into three categories:
1. User DID NOT set max_area to less than achievable.
2. Some cells were inserted in critical paths and at some point in the
synthesis were thought to be required. At a later point like fix design
rules this thought was changed. But, the cell remains. The path
containing the cell never fails and is not looked at in later compiles
that try to remove the large area cells.
3. Marginal Timing ( <<1ns ) improvement to meet user requirements.
Work-Arounds:
1.) Set Max Area to less than achievable and recompile.
2.) set_dont_use "high power cells"
translate
remove_attribute dont_use "high power cells"
compile -incremental
(also works and better/faster than work-around #1.)
3.) when all else fails be brave and use vi or your favorite editor.
4.) Best Design Practice: request from the Synopsys support center a
vendor attribute for libraries of a minimum capacitance a cell that can
drive as a design rule addition to the vendor library. (e-mail:
support_center@synopsys.com) As a vendor we have requested this
feature and with end user support its priority could be raised.
Problems associated with 1 and 2 have achieved acceptable yet reliable
results in a number of cases. Resorting to hand editing is not satisfactory
for the user and/or vendor -- and results in slipping schedules, numerous
retesting runs from the danger that the edit is incorrect.
- John Emmott
AT&T
( ESNUG 203 Item 2 ) ---------------------------------------------- [12/2/94]
Subject: (ESNUG 202 #5) Synthesizable Yet Unsimulateble Verilog Code (!?)
>In a project involving both Verilog and VHDL we stumbled upon Verilog
>code which is synthesizable (Synopsys 3.0c) but that cannot be simulated
>(Veriwell). When trying to do "non-constant valued part-selects", like:
>
> for (i=1; i <= 7; i=i+1) begin
> a[i-1] = {b[7-i:0], zeros[i-1:0]};
> end
>
>the synthesis tool gives you the circuit you would expect, but the simulator
>doesn't accept it! I remember from my pre-VHDL life (3 years ago) that this
>is indeed a Verilog restriction: part-selects should be "constant-valued".
From: prasad@lsil.com (Prasad Paranjpe)
John,
I'd like to verify this problem. (I have been trying to build muxes the way
I do in VHDL as parameterized designs. This way I build ONE mux template and
elaborate any mux I want by changing the parameters. This is not as nice as
using an array of arrays in the port declaration but then again this _is_
Verilog. :^) )
From the Cadence Verilog-XL reference (p 4-17) Section 4.2.1 - Net & Register
Bit Addressing - paragraph 5:
vect[ms_expr:ls_expr]
Both expressions must be constant expressions. The first expression
must address a more significant bit than the second expression.
Compiler errors will result if either of these rules is broken.
I, too, could synthesize this type of code but when I tried to run the source
in Verilog-XL 2.0.5, I got:
Error! Non-constant part-select index [Verilog-NCPSI]
"muxMto1.v", 25: D[ti:bi]
- Prasad Paranjpe
LSI Logic
--- --- --- ---
John,
We sent an enhancement request to Cadence on this matter in 12/92 (PCR 82530).
As of 10/94, it has not yet been changed, to the best of our knowledge.
- Shalom Bresticker
Motorola Semiconductor Israel, Ltd.
( ESNUG 203 Item 3 ) ---------------------------------------------- [12/2/94]
From: mkphilli@netcom.com (Mike Phillips)
Subject: Model Tech & Synopsys VHDL Incompatibilities
John,
I have been back-annotating SDF delays generated by Synopsys into ModelTech's
VHDL simulator. The VHDL simulation library I was using was generated by
Synopsys Library Compiler (3.1a) and was created by the ASIC vendor I was
working with (ChipExpress). In doing this, I had to develop several scripts
in order to get Synopsys and ModelTech on the same wave length. One specific
problem was the names of the generic delay values. An example of a generic
in the VHDL simulation library is:
entity <macrocell> is
generic( <stuff deleted>
tsuD : Time := xx ns;
<stuff deleted> );
port( <stuff deleted> );
end <macrocell>;
Model Technology expects the generic to be "tsetup_d" instead of "tsuD".
(I wrote a script to substitute tsetup_d for tsuD in the simulation library
and everything worked o.k. In retrospect, I probably could have created
an alias, which would probably have worked and would probably would have been
easier to implement.) I'm not sure about is whether the ASIC vendor
was responsible for the generic being named tsuD instead of testup_d.
Maybe a Library Compiler expert out there knows the answer to this.
- Mike Phillips
E-Systems
( ESNUG 203 Item 4 ) ---------------------------------------------- [12/2/94]
From: mark_indovina@pts.mot.com (Mark Indovina)
Subject: DesignWare install.cd Code Error
Hi, John,
There is a minor bug with the Synopsys install.cd script for Designware ver.
3.2a, P/N 2US01-20340. To the install the products I was forced to copy
the install.cd script the /tmp and correct the bugs.
The following code fragment from the script shall highlite the problems,
search for the 'LOOK HERE' (clipped from install.cd):
foreach prod ( $prods )
set readme = "$cddir/$rme.$prod$iso"
# Get the script name from the product readme file
if ( -r "$readme" ) then
set str = ( `awk -F: '/^[ ]*DO_INSTALL/ { print $2 }' "$readme" ` )
set do_install = ( $do_install $str )
endif
endif <<<<<-------- this 'endif' should be an 'end' <<< LOOK HERE >>>
setenv SYNOPSYS "$synopsys"
foreach entry ( $do_install )
set install_prod = "$synopsys/$entry"
if ( -r "$install_prod" && -x "$install_prod" ) then
$install_prod -r "$synopsys" -plat "$plats"
echo "DO_INSTALL $install_prod -r $synopsys -plat '$plats'" >> $logfile
endif
endif <<<<<-------- this 'endif' should be an 'end' <<< LOOK HERE >>>
- Mark A. Indovina
Motorola, Inc.
( ESNUG 203 Item 5 ) ---------------------------------------------- [12/2/94]
Subject: (ESNUG 201 #6) "Seeking User Wisdom On Floorplanning Tools
> I'm trying to decide the best approach to floorplanning, and I've never
> used the Synopsys floorplanner, though I've used vendor floorplanning
> tools before.
>
> Can anyone comment on the relative merits of Synopsys floorplanner vs.
> vendor supplied floorplanners? Which is the better route for timing
> analysis (Synopsys or vendor)? Is a combined approach (both tools) best,
> or are they redundant or incompatible?
From: landman@hal.com (Howard Landman)
There is at least one other alternative in some cases, which is the software
from High Level Design Systems. I haven't actually used their stuff, but
they have floorplanning and placement tools with hooks both into Synopsys
and into several P&R packages, and I liked their demo/presentation at ICCAD.
Their interface works at several levels, from early floorplan -> estimated
loads, to building custom wire load models for each block, to Synopsys
IPO -> P&R ECO.
Even if you don't buy their stuff, it's worth seeing their foils, because
they've thought through a lot of the timing integration issues very carefully.
My sense is that I'll either end up buying it, or reimplementing it. :-)
- Howard A. Landman
HaL Computer Systems
--- --- --- ---
From: matahari@netcom.com (paul chai)
In my some 5 years of painful Synopsys experience, I have found it best to
only rely on Synopsys for what it does best which is synthesis ( even then,
it is rather painful to expect too much from the tool). When it comes to
floorplanning, you are definitely better off using the vendor's tools!!!
- Paul Chai
VLSI/ASIC design Consultant
|
|
