John Cooley <jcooley@world.std.com> on "comp.sys.mentor" wrote:
>It's important to note that ESNUG is not a letterized bitch session;
>opinions on various EDA tools are greatly encouraged on ESNUG but you must
>have some basis. That is, I won't print: "Synopsys sucks!" but I will
>print "Synopsys sucks because of the XYZ, ABC and 123 bugs in rev. 3.1a."
Michael Lodman <jlodman@alumni.caltech.edu> on "comp.sys.mentor" replied:
>Good thing, too, because it's stating the obvious. The only reason
>we all use it is because to date, everything else sucks worse! Look
>out Synopsys if a decent competitor ever appears! I'd jump without
>any remorse at all.
Ironically, Michael, your reply exhibits exactly what I'm not interested
in publishing on ESNUG. Yes, you may understandably vent some frustrations
with using one or more Synopsys tools -- but I and the other readers are stuck
trying to figure out what *exactly* you're having problems with. Without
specifics, this venting is a waste of everyone's time. Did the hotline lose
your bug? Was the training course you took too simple/hard/out-to-lunch?
Did Test Compiler (rev X.X) choke on your design? Did the Synopsys salesman
ignore your existance once he met your boss and the sale was made? Did your
final gate level design come out 15x larger than expected? Saying *exactly*
what your issues are, be they technical, business, sales and/or whatever, (as
long as you're SPECIFIC!) is worth everyone's time & energy to read & think
about... And worth publishing! :^)
- John Cooley
the ESNUG guy
( ESNUG 213 Item 1 ) ---------------------------------------------- [4/5/95]
From: prz@hprnd.rose.hp.com (Paul Zimmer)
Subject: Design Compiler 3.2a vs. 3.0b -- Makes Smaller But Slower Designs?
John,
I've heard rumblings that 3.2a seems to produce larger, slower designs than
3.0b. So, I completely re-synthesized a chip we released with 3.0b and 3.2a.
Except for the Test Compiler stuff, no changes were necessary in any of the
source files. Test Compiler seems to have arbitrarily changed things like
the default number of scan chains (it now creates one per clock?), and the
default test port names. A recent post (ESNUG 213 #3) from "Jan Decaluwe"
indicates that this is an improvement. Still, it took some struggling to
find and fix all these things, but I finally got some results:
Design Compiler 3.0b Design Compiler 3.2a
-------------------- --------------------
Combinational area: 39,936.000 38,893.750
Noncombinational area: 27,637.250 27,714.250
Net Interconnect area: 146,492.625 146,057.188
Total area: 214,065.875 212,665.188
Path Group A's slack: 8.18 8.17
Path Group B's slack: ***? -3.96
Path Group C's slack: -1.58 -2.05
Path Group D's slack: 4.44 7.17
Path Group E's slack: -1.22 -3.34
(Remember that the more positive slack is, the better one's
gate level design is meeting the constraints you give it.)
***? - This path group came up in 3.0b but report_constraint -verbose
wouldn't give me any "slack" information. Same script, source,
and constraint files. Very strange.
It appears that 3.2a produced a slightly smaller, but noticably slower,
design overall. That doesn't give me a warm, fuzzy, feeling. Since
the chip was built in parallel on many machines, I don't have a good feel
for compile times.
The library is VLSI's "vsc450" 0.8u std cell, version v3r1.5. As you can see,
they use heavy net area in their wire load models. Some experiments we did
on this same chip showed this to produce better results than either VLSI's old
wire load tables (not too hard) or our in-house, Lee Bradshaw (ESNUG 143 #3)
versions. But that's another story...
As a final note, I wanted to include the results of "report -constraint"
as a tidy overview of the chip, but 3.2a fatals every time I try this...
- Paul Zimmer
Hewlett Packard, Roseville
( ESNUG 213 Item 2 ) ---------------------------------------------- [4/5/95]
Subject: (ESNUG 211 #7 212 #1) "Synopsys & Cores: Library Wire Model Bugs"
>We had to patch the GATES library to fix some erroneous timing values...
>... we instead released a "patch" library which contained only the fixed
>cells. Then the link_library was set up as: link_library = { "*", PATCH.db,
>GATES.db, MEGA.db } ... Now, update_lib would report that everything was
>still going swimmingly. But somehow, neither I nor the customer "noticed"
>that there was no reference to wire-load in the compile logs or timing
>reports! In fact, the wire load selection table for GATES.db was completely
>ignored! ... To work around it we had the customer "update_lib" all of the
>libraries in the link_library list. update_lib may work on only the first
>library -- I never had a chance to check this out.
From: [ Synopsys R & D ]
John,
Prior to v3.3 - User could only get a wire load selection group from the first
library in the target library list which was actually used in the design.
In v3.3 - User who does nothing will have a wire load selection group picked
from the first used library in the target library list. If none are
available, a selection group will be chosen out of the first library in the
link library list. If none are available there either, auto wire load
selection is not done. In either case, wire loads in the chosen selection
group must be defined in the same library as the selection group. Since
v3.3 now supports named selection groups, the user can get a selection
group out of any library in the link library path by explicitly setting
the selection group and library:
set_wire_load -library <name> -selection_group <name>
- [ Synopsys R & D ]
( ESNUG 213 Item 3 ) ---------------------------------------------- [4/5/95]
From: hill@synnet.com (Shannon Hill)
Subject: A DesignWare & Synopsys Synthesis VHDL Configuration Conspiracy
John:
Does it also occur to other VHDL-based Synopsys users that the only
reason Synopsys doesn't support configurations (for synthesis) is that
they want to keep selling DesignWare licenses? If VHDL configurations were
well supported; DesignWare would make even less sense than it does now...,
but it would certainly be a useful addition. Has anyone else asked
Synopsys about this? Our communication on this issue has yielded a
reply which basically says "there are deep-seated reasons why we can't
(won't?) support configurations for synthesis".
- Shannon Hill
3COM Switching Division
( ESNUG 213 Item 4 ) ---------------------------------------------- [4/5/95]
From: frazer@idtinc.COM (Andrew Frazer)
Subject: Surprized By Model Tech/Synopsys VHDL Simulator Incompatibilities
Has anyone had experience with incompatabilities between VSS (Synopsys)
and VSIM (Model Technology)?
We developed a VHDL model in Model Tech's VSIM and completely debugged it.
When we ran the same model in Synopsys's VSS, we found that 20 out of 96 test
sets had some sort of miscompare. I'm not surprised that different vendors
evaluate the VHDL language differently, but I'm surprised how difficult it is
find references detailing these differences. Any help will be appreciated.
- Andy Frazer
Integrated Device Technology
( ESNUG 213 Item 5 ) ---------------------------------------------- [4/5/95]
From: kbpeh@tmi.com.sg (Boon Peh Keng)
Subject: Changed Timing Models & False Paths in >3.1 Latch Based Designs
Hi! John, I love your first few lines in each of the ESNUG posts!
Need a little bit of help here. I am not very experienced with Synopsys but
I have this problem which I never encountered with 3.1 and below. I think it
has something to do with their changing the Latch timing stuff.
Let say I have two one-bit registers, which can be read onto the data bus,
and written from it as well. The tool now seems to time from writing to one
of the registers, thru' its three-state driver onto the data bus, and back
onto the input of any one of the two registers, and it complained there was
not enough time at the end point. The path is of course a false one because I
do not expect the data to flow like that. How do I control this? Do I have
to define false paths for every one of such data latches? I am sure if
I had only one register, it will time from the point there was a write and
thru' the data bus and back to its own input. (This does not make sense
because I'd now have a feedback combinatorial circuit.) Setting the variable
level_sensitive_startpoint_close_active_edge = 1 seems to work. But is this
the right way? I am not doing "advance" latch-base design; I am just using
latches to hold data. (Incidentally, this two one-bit register exercise took
about 20 minutes to complete (but the library is huge) which is ridiculous.
----------------------
| |
| |----| |
----|D | |\ <------------ three-state driver controlled by rd1
| | QB|---| O-----|
---- | --|E | |/ |
wr1 | |----| | |
| L1 rd1 | 1-bit bus
| |
| |
| |
| |----| |
----|D | |\ |
| QB|---| O-----
---------|E | |/ <----------- three-state driver controlled by rd2
wr2 |----| |
L2 rd2
The path might be from active edge of wr1, plus max_borrow time, thru rd1
(three state driver) onto the bus and ends at D of L2. And complains about
data not valid in time for wr2. Note that wr1, and wr2 are both gated with
CLK. Any help/hint/pointers would be much appreciated.
- Boon Peh Keng
Tritech Microelectronic International, Singapore
( ESNUG 213 Item 6 ) ---------------------------------------------- [4/5/95]
Subject: (ESNUG 211 #5) Use set_max_fanout With Much Caution!
>USE CAUTION WITH SET_MAX_FANOUT ON THE ENTIRE DESIGN! Our methodology used
>to have as part of the process a "set_max_fanout = 10" on the entire design.
>This caused timing problems on our modules which drove the outputs of the
>ASIC. ... Design Compiler correctly used the largest buffers available
>(BUFF3 - which had a fanin of 3 inputs attributed to their inputs). The
>set_max_fanout caused Synopsys to only drive 3 BUFF3's with a single BUFF3,
>and the worst path for these outputs was a string of three BUFF3's in a row.
> ... Design Compiler gave a mish-mash 3 layer buffer tree when it could
>have built a nice balanced 2 layer buffer tree... We later found that
>set_max_transition, used correctly was the command to use instead.
From: [ The Synopsys CAE for Design Compiler ]
This is a frequently encountered design methodology problem. As the user
determined, max_fanout can be a potentially dangerous design rule to apply
to an entire design. If it is desirable for the design to have a
"set_max_fanout = 10" except for the BUFF3 (and similar cells), a two pass
methodology could be used.
On the first pass, apply either no design rule constraints (max_fanout or
max_transition) or a loose design rule constraint and compile the design.
If the synthesis library has design rule constraints on the cells these
will be followed during this pass.
On the second pass, dont_touch all the BUFF3 (and similar cells) that you
don't want the more restrictive "set_max_fanout" or "set_max_transition"
constraint to affect. Compile as before and the tighter design rule
constraint will be applied but leaving the dont_touched cells alone.
- [ The Synopsys CAE for Design Compiler ]
( ESNUG 213 Item 7 ) ---------------------------------------------- [4/5/95]
From: sbkim@rwasic44.aud.alcatel.com (Scott B. Kim)
Subject: Test Compiler & Bidirectional Ports During SCAN
John,
I would like to know if I can make Test Compiler understand that all the
bidirectional pins in my design are configured to be input during the scan
test. Our test control circuit was designed to force all the bidirectional
pins as input during scan mode; however, the Test Compiler treats these
pins as output.
Due to this undesirable circumtance, we are constanly getting miscomparison
during scan check. If anyone on ESNUG has any suggestions, please post them!
- Scott Kim
Alcatel
( ESNUG 213 Networking Section ) ---------------------------------- [4/5/95]
Portland, Oregon - ASIC/FPGA/board-level DSP/neural-net Engineer w/ Xilinx,
Verilog, Synopsys & PC peripheral expr wanted. No Headhunters! dean@asi.com
Colorado Springs, CO - Verilog RTL, Synopsys, static timing, C, UNIX, Perl,
team playing CAE engineer wanted. No Agencies. "fmicos!gulati@uunet.uu.net"
|
|
