Well, we just fed our last remaining Christmas tree to Aart & Harvey (the
goats; not the Synopsys bigwigs) and they munched it up with seeming glee.
Afterwards, my girlfriend and I went for a walk out in the back pasture.
Unlike sheep, the goats followed us. They were like vegetarian dogs,
stopping every here and there to sniff or nibble something. Then suddenly
they'd run/jump to catch up to us like pudgy, overweight gazelles when we
got more than 15 meters from them. As we were walking, my girlfriend and I
discussed what I couldn't eat on my three week old low fat diet. No bacon,
no cheese, no butter, no pork, no cream based soups, no Big Macs, no peanut
butter, no ice cream, nothing that had flavor was allowed... It was then
I realized I now get to eat what my goats eat: lots of hay, some grain, and
the occassional leftover Christmas tree!
- John Cooley
the ESNUG guy
( ESNUG 207 Item 1 ) ---------------------------------------------- [1/95]
From: sherman@netcad.enet.dec.com (Steve Sherman)
Subject: When VSS Faults On DEC AXP Workstations
John,
When running VSS on AXP platforms, we've found that if our path lengths to
simulation object files are too long the VHDL simulator will fault at
elaboration. This is apparently because it bumps against the ARG_MAX
parameter (which limits the bytes you are allowed for environment variables
and exec arguments). This parameter can be altered during a system build, or
you can take steps to reduce the number of object files, or you can shorten
the path lengths to the object files to avoid this problem.
- Steve Sherman
Digital Equipment Corporation
( ESNUG 207 Item 2 ) ---------------------------------------------- [1/95]
Subject: (ESNUG 206 #1) Same Code & Scripts, Results Drop 3.0b->3.1b (& 3.2a?)
>We used design compiler v3.0b... we received version 3.1a. With the
>same scripts and the same VHDL code ... I was not too thrilled when the
>results gave me a larger design (area) and a MUCH slower design (slack)...
>I've made the switch to version 3.1b and the results were better, but not as
>good as version 3.0b. In the meantime, I've been trying a lot of different
>things in version 3.1b, but I can never seem to get the design as good as
>version 3.0b. And now they want me to switch to version 3.2a.... I'm just
>curious to know if other users have seen this problem & what they did?
From: brien@acuson.com (Brien Anderson)
Hello John,
With regards to Esnug 206 item 1, Yes, we have seen those types of problems
using Verilog. We had to put a stake in the ground and say that we could not
keep recompiling designs no matter how many times Synopsys changed versions.
We found 3.0b to be lesser of many evils (gee, why could not we not just keep
on using 2.2b forever? oh yeah -- ASIC vendor library changes). The 3.1
series was tried and rejected, so we continued to tape out using 3.0b. This
is similar to Cadence releasing tools each and every quarter. I think that
each designer must make decisions on what tools and tool versions to use
based on design cycle time and what bugs and features are present in any
version. The caveat applies of "If you don't need to change, then don't."
The good news is that the 3.2a is working fine so far (yes, the 3.2b
is coming out Feb.).
- Brien Anderson
Acuson
---- ---- ---- ----
From: [ The Man With No Name ]
Hi John, please keep me anonymous on this.
Using Synopsys VHDL I have experienced similar problems for my particular
design:
3.0a gives me a good circuit and good speed characteristics.
3.0b worst in terms of area and speed.
3.0c similar to 3.0a results.
3.1a worst than 3.0b (!). I have made several tries and found that the
problem appears during elaboration. When an operation is done on
a bus in a "for" loop all bits are affected the same way even if
they shouldn't. This problem was not easy to identify because the
compiler is able to hide it very frequently even on a design small
enough to be understood. According to Synopsys it should be solved
in 3.2a. Because of several administration problems (Synopsys & us)
I have not received 3.2a yet.
Generally speaking, I have better results using 3.0a or 3.0c. The release
3.0b was bad news. Most of the time, 3.1a and 3.1b weren't any better.
(However, I should mention that on some very big design, I sometimes got
better results with 3.1b than with all other releases.) Unfortunately, I
consider that these designs are poorly coded and should be smaller to ease
their maintenance.
The workarounds I am using are simply:
1) Compilation Script Modification. It may make a script twice as big to
obtain a comparable result but I am applying this techniques to every
design because I'm assuming there's *always* a better undiscovered way.
2) HDL Coding variation. Different coding styles get different results
depending on the revision of Design Compiler.
3) When a design contains an asynchronous condition (set or reset),
I declare explicitly all other signals (and registered variables)
and assign them to '-';
4) In a synchronous process, just after the
wait until CLOCK'event and CLOCK = '1'
or
if ( CLOCK'event and CLOCK = '1' ) then
I dress a list of all registered variables and assign them to a default
value. If the default is to keep the current value I sometimes get good
results by explicitly write it.
I've send several e-mails and phone calls to Synopsys about this fact and I
am still waiting. I'm interested in what users can share on their working
methodology with us on ESNUG.
- [ The Man With No Name ]
( ESNUG 207 Item 3 ) ---------------------------------------------- [1/95]
Subject: (ESNUG 206 #3) If Reading Flat Verilog Chokes, Try Reading In EDIF!
>John, we've discovered a problem in Synopsys when trying to read in large
>flat Verilog files. In a nutshell, Design Compiler hangs, creates a extra
>large core dump, then exits with a segmentation error or fills the disk up
>while dieing un-gracefully. The problem appears to only happen when
>reading in a flat Verilog file of a full ASIC design.
From: swanson@romulus.cray.com (Gary Swanson)
John, It looks like some defaults were not set large enough for stack size.
The problem was a fatal segmention error & stack overflow. Change the
limits and our problem went away. In csh, for instance, you can check the
max size of the stack by using the UNIX command "limit":
UNIX PROMPT> limit
cputime unlimited
filesize unlimited
datasize unlimited
stacksize 8192 kbytes
coredumpsize unlimited
memoryuse unlimited
descriptors 64
Our stacksize of 8192 kbytes was not sufficient. The solution (in csh) was
to run the UNIX command "limit stacksize unlimited" (or to be safe)
"limit stacksize 100000".
- Gary Swanson
Cray Research
[ Editor's Note: Gary, thanks for following up on your orginal post. - John ]
( ESNUG 207 Item 4 ) ---------------------------------------------- [1/95]
Subject: (ESNUG 205 #5 206 #2) Headaches w/ Synopsys To Mentor w/ "db2eddm"
>When we asked both Mentor & Synopsys about going from EDIF to EDDM, the
>answer was a definite "NO". We have encountered some problems with the
>db2eddm path (nets crossing bus rippers that were shorted in Mentor and not
>in Synopsys, etc.) Do you have any suggestions from any of your readers?
From: bolling@lds.loral.com (Randy Bolling)
John,
We worked this one into the ground at GTE. The only two solutions we found
that were definitive were to either un-bus the schematics (obvious downturns.)
The other solution is to write a Mentor Ample script that draws schematics
from the read-in edif files of each level of the design. The second task
tends to be too slow to be effective (10-12 hrs. vs. 1 hr. using db2eddm.)
We found shorted nets, shorted bus rippers to net(s), and un-reported net
renaming instances which implied a short by name only. In the latter case,
the use of two signals named "SignalName" and "SignalName_reg" caused the
short after translation through db2eddm; that passed check sheet, only to be
found in simulation as a double-drive situation. This lead to un-bussing
certain portions of the design that were susceptible to the phenomenon, and
avoiding nets names in the code to prevent the accidental connectivity.
- Randy Bolling
Loral Data Systems
---- ---- ---- ----
From: bmoore@space.honeywell.com (Bruce Moore)
John -- We have also experienced the headaches associated with db2eddm
schematic generation for some time now. What we saw includes:
- Nets being accidentally connected to another net at bus rippers
- Nets which cross but don't connect in Synopsys but are shorted in Mentor
- Input side and output side of a buffer being shorted by the same net name
The bus ripper problem can actually be seen prior to the db2eddm conversion
in Synopsys Design Analyzer as two nets laying on top of each other, but
still individually selectable. (It seems like there needs to be some sort of
"keepout zone" specified for the bus ripper which isn't getting done.)
We have also seen problems in eddm2db conversion, especially if these same
schematics are later converted back to EDDM (for example, if you are
inserting scan at the end of the design instead of during initial synthesis.)
Also, Synopsys Design Compiler (which is case-sensitive) might add new nets
by the name of "net_2" because it doesn't see that Mentor has upper-cased a
previously named net to "NET_2". In the return trip back to Mentor EDDM
(which is NOT case-sensitive), these nets are then shorted together!
While we did not find a solution to these problems when converting from
Synopsys to Mentor, we did drive the problem out of the Synopsys schematics
by simply changing the sheet size and re-generating the affected schematic.
(Synopsys solutions did not work for us.) We edited by hand in Mentor Design
Architect (yuck) and went on. Fortunately, the problems are few and far
between, and can quickly and easily be detected in our case by running our
ASIC vendor's Verify tool which looks for design rule violations such as
shorted outputs.
We got around eddm2db problems by using VNET to convert to a Verilog netlist
on our way into Synopsys DC.
- Bruce Moore
Honeywell Space
( ESNUG 207 Item 5 ) ---------------------------------------------- [1/95]
Subject: LMC's Hotline Has Gone Down Hill Since Being Bought By Synopsys
Ed Oswalt <efo@dtc.kodak.com> wrote:
>Is it me or has LMC's hotline went down hill since Synopsys took over?
>Lately more and more users complain about it and I used to remember they
>where one of the best a few years ago. I notice more delays when I do
>use it (which is less frequent than a few years ago).
>
> - Ed Oswalt
> Kodak
From: fredo@newbridge.com (Fred Odendaal)
I agree. A couple of weeks ago, I phoned the hotline three times for one
problem. The first time I was disconnected, the second time my call was
forwarded to somebody's voice-mail that wasn't in the modelling group and the
3rd time I was forwarded to the voice-mail of the call dispatcher. I was
called back the next day to get a log number and the support Engineer phoned
the day after that. Aaaaah, the beauty of a monopoly!!!
- Fred Odendaal
Newbridge
( ESNUG 207 Networking Section) ----------------------------------- [1/95]
San Diego, CA - want perm. engineer for networking ASIC designs w/ Verilog
& Synopsys at XLNT Design, Inc. No headhunters, please. "fazil@xlnt.com"
|
|
