From: staylor@bnr.ca (Stephen Taylor)
Subject: Loaded Questions on Synopsys Surveys
John, I saw this question on the SolvIt survey (and I quote):
"Who is the Vendor with the best Automated Problem Resolution System?"
and I couldn't help but think: "What is the obvious answer they're looking
for on this?" [ It sounded a little like mirror mirror on the wall....
"Why yes!, Synopsys, SolvIt is the fairest of them all." ;^) ]
Joking aside, I do think that SolvIt works pretty well.
- Steve Taylor
Northern Telecom
( ESNUG 202 Item 1 ) ---------------------------------------------- [11/94]
From: ggrover@procy.gi.com (glen grover)
Subject: A Smattering Of Workarounds Useful In Converting To 3.1
John,
Here's a list of the myriad workarounds that I have had the pleasure :^) of
using while trying to convert to version 3.1:
1) compile_implementation_selection = false
Turns off re-eval of synthetic library implementation selections during the
compile.
2) compile_use_low_timing_effort = true
Causes optimization to use estimated output transitions rather than precise
calculations based on input slew rate. This could cause small violations
in edge rate. (This will only affect compile time if the target library
specifies this relation between input slew and output transition time.)
3) new_seqmap_effort = 1
Lowers the effort of the new sequential mapping algorithm.
4) hdlin_force_use_ffgen = true (or hdlin_seq_device_v30_mode = true)
improved_seqmap = 0
disable_sequential_degeneration = 0
These turn off new sequential mapping algorithms completely (!?!).
Compile times do increase, but not to level of version 3.0c.
5) hlo_minimize_tree_delay = false
Disables algorithm which tries to rearrange associative and commutative
operations in order to shorten critical paths. (This was used to eliminate
a fatal crash for a particular module).
6) hdlin_ff_always_sync_set_reset = true
I used this switch on modules which had no asynchronous sets or resets.
This tells synopsys to treat any =0 or =1 assignments within clocked blocks
as synchronous resets or sets. (I think version 3.0c did this by default).
Anyways, this improved compile time in modules that had significant numbers
of sequential logic.
Regarding (ESNUG 200 #6): Synopsys version 3.1a/b dramatically increased
compile times for the CMOS2 delay model and the suggested workaround of:
set_attribute find(library, your_library) delay_model "generic_cmos"
This workaround does not revert to 3.0 mapping and thus retains the advantages
gained by the new sequential algorithms. Not every library uses the CMOS2
delay models, so this workaround may not help in your case... check your
library.
- Glen Grover
General Instrument, San Diego
( ESNUG 202 Item 2 ) ---------------------------------------------- [11/94]
Subject: ( ESNUG 201 Item 5 ) Can't Get Rid Of "_architecture" !
> Does anyone know how to get Synopsys to not append
> _architecture, architecture_2, architecture_3, etc.
>
> I have changed the variable:
> vhdlout_architecture_name to "structural_view"
> but Synopsys appends _architecture, etc. to the architecture names.
From: jco@egnetz.uebemc.siemens.de (Herr Jon Connell)
Here's what the manual page says:
The generated name is checked to verify that it is
--> unique and is a legal VHDL identifier. If not, it will
be modified so that it is unique and legal. For
example, setting vhdlout_architecture_name = "A" does
not cause all architectures to be written out with the
same name "A". Instead, to make each name unique, the
tool gives the first architecture the name of "A", and
appends subsequent architecture names, as follows:
A
A_architecture
A_architecture_2
Why the name has to be unique is a mystery, but Synopsys is still doing it
with version 3.2a so I guess only a STAR will get you any further!
- Jon Connell
Siemens AG
( ESNUG 202 Item 3 ) ---------------------------------------------- [11/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: M.A.Wilds@bnr.co.uk (Mark Wilds)
John, we had exactly the same problem with overdriven nets in our
design which was targetted at an LSI netlist. When Synopsys is given a
"real" delay/load file to use from LSI's CMDE program (instead of using
it's own wire length estimates) it can correct any ramp time warnings
from under driven nets, but doesn't fix any warnings to do with
overdriven nets. (This is despite the fact that replacing the cell
driving the net with a lower power version has negligible effect on the
timing, which isn't critical anyway.) The compile time of our device is
far too large to do any iterative compilations, and as you found out
that doesn't necessarily get around the problem. As far as we could see
there is no mechanism in Synopsys for persuading it to downsize any
oversized drivers.
In the end we had to resort to a solution outside of Synopsys, which
involved writing a program which reads in the LSI netlist, the seglen
file (LSI's delay/loading file) and the LSI file containing the
warnings about overdriven nets. This program then finds the offending
cells in the netlist, maps them onto lower power versions (which may
have different port names) and adjusts any references to these cells in
the seglen file. These modified netlist and seglen files are then read
back into CMDE which then produces new seglen and warning files. This
process has to be repeated 2-3 times because downsizing one driver
quite often reduced the loading on the previous driver, causing it be
an overdriving cell! Obviously you don't want to have to write a new
program for every different vendor and their associated technologies,
but apart from hand editing the net (not practical with 400+
overdriven nets!) we could see no alternative.
We'd appreciate any other workarounds that people may have found.
- Mark Wilds
BNR Europe Ltd.
( ESNUG 202 Item 4 ) ---------------------------------------------- [11/94]
From: sawinska@ralvm29.vnet.ibm.com (Tim Sawinska)
Subject: New hdlin_translate_off_skip_text Variable in V3.1b
John,
Synopsys has a new variable in v3.1b, called hdlin_translate_off_skip_text.
It may affect you if you use in Verilog:
// synopsys translate_off
// synopsys translate_on
or in VHDL:
-- pragma translate_off
-- pragma translate_on
Version 3.1b defaults the variable to false in the .synopsys_dc.setup file
that it ships. But with that false setting, the translate directives listed
above do not work as they did in previous releases. For that to happen, the
variable must be set to true. (So Synopsys, please default new variables
that you decide to add, so that they don't affect current users.) We don't
appreciate being forced to learn about new variables to get the same results.
- Tim Sawinska
IBM, RTP NC
( ESNUG 202 Item 5 ) ---------------------------------------------- [11/94]
From: jand@easics.be (Jan Decaluwe)
Subject: Synthesizable Yet Unsimulateble Verilog Code (!?)
VHDL/Verilog designers know the concept of non-synthesizable code: code
which is valid for the simulator but not for the synthesis tool. The
opposite should "by definition" not happen.
However, in a current 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". (It is still
documented as such in the HDL Compiler manual. A similar restriction is not
present in VHDL. Therefore, I guess this kind of code is synthesizable
because making it non-synthesizable would have been more work.) Anyway, my
conclusion is that this Verilog restriction is unnecessary & should be lifted.
Another possibility is that this restriction has already been lifted, but
that the enhancement has not found its way yet to the HDL Compiler
documentation and to my specific simulator. Anyone care to comment?
- Jan Decaluwe
Easics, BELGIUM
( ESNUG 202 Networking Section ) ---------------------------------- [11/94]
Austin, TX: AMD seeking IC designers w/exper. in HDL, SYN, F/P, APR or custom
for K86 projects (K5,...). Principals ONLY. Email: Robert.Jones@amd.com
|
|
