Editor's Note: Last week the the Software Support Professionals Association
(SSPA), an organization with over 500 member companies, awarded The 1995
STAR Award for the "Best Support for Complex Software" to Synopsys. My
congradulations go to Deirdre Hanford for spending six months at Sun
Microsystems getting the first copy of Design Compiler actually customer
usable so many years ago and, along with Chi-Foon Chan, starting SNUG with a
purely technical, non-marketting orientation (and to Mikael Hakansson and
Ken Nelsen for retaining this outlook as SNUG chairs.) I'd also like to
note Stephan Andres' claundestine help with ESNUG when it wasn't quite so
popular with Synopsys management, Brent Gregory (& others) for going that
extra mile in R&D like improving the cryptic Design Compiler error messages
on their own time on the weekends, and Vito Mazzarino for beating on
Synopsys R&D to cut their average time to find customer workarounds with
the really serious bugs from 28 days down to 8 days.
But, mostly, I'd like to cite Bob Dahlberg for taking all the uncomfortable
political risks, as VP of Customer Support, to change Synopsys from having
a paranoid control-freak culture that hinted at getting litigious if a
customer openly discussed bugs to the current open kimono approach where
we're warned about problems beforehand. Bob heavily pushed many initially
unpopular-within-Synopsys programs such as letting customers get the *same*
technical training Synopsys field engineers get (ACES) & making sure SolvIt
has *all* known bugs listed no matter how embarrassing. Bob also did a lot
of behind-the-scences maneuvers to foster frank, open discussion with
customers and to create a "let's do what it takes to make you successful!"
outlook to replace the burnt out "why are you bothering us with your
problems?" mindset many troubled customers found five years ago. I feel Bob
deserves a good part of the credit for this STAR Award because he took the
risks to create these much needed pro-customer cultural changes. Good job.
- John Cooley
the ESNUG guy
( ESNUG 232 Item 1 ) ---------------------------------------------- [12/95]
Subject: (ESNUG 231 #6) Seeking One Generic Embedded Multiport RAM Array
>We are designing ASICs that include embedded multiport RAM arrays, which
>require using vendors' libraries. The problem is that different vendors
>offer different RAM cells... We are trying to find a common base, so as to
>define a common model of the RAM cells that will yield a design compatible
>with all (or most) vendor libraries, present and future (some sort of an
>"industry-standard" RAM cell).
From: Andy Chomyn <Andy.Chomyn@proteon.com>
John,
What this user is trying to do is somewhere between difficult & impossible:
defining "industry-standard" RAM cells. Although I am not, at present,
working on designs with embedded arrays, in the past on some large designs
(300K+) we looked at embedded arrays from various vendors. As you say they
come in various flavours. The general breakdown in terms of port style are:
1 port R/W.
2 port = 1 Read, 1 Write.
2 port = 1 R/W, 1 Read.
3 port = 2 Read, 1 Write.
WE and OE controls tend to be per word - but I'm sure that now I've said
this, there will be a massive response saying bit controlled ! Also, we
found that building our own RAM design could beat some of the vendors
library designs in terms of gate size. I don't know if it is a good idea
to try to define a common base. Probably better to create a generic
with all combinations.
-- Andy Chomyn
Proteon
( ESNUG 232 Item 2 ) ---------------------------------------------- [12/95]
Subject: (ESNUG 230 #6) "InterHDL's 'Verilint:' Good Stuff Or Trash?"
>We're evaluating "Verilint" which is supposed to flag pre-synthesis warnings
>in Verilog source code. We are told this tool is supposed to guide the user
>to writing better synthesizable code. We are really interested in hearing
>any feedback from people who have used this tool. We are not interested in
>the workings of the tool itself, but we would like to know if it actually
>helps you improve the quality of your code. For example, please don't just
>say "we've been using for N years and we like it". Please tell ESNUG what
>you like/dislike about it.
From: taub@corp.cirrus.com (Ed Taub)
John, I used verilint a few years ago.
Good: 1. Identified "relict" code i.e. variables no longer used, I/O not
connected, etc. 2. Detected subtle style errors like incomplete sensitivity
lists (nice but not critical.)
Bad: When I used it it emitted a storm of warnings, most useless. You could
limit the warnings from particular bugs but the mechanism was clumsy.
Ugly: The cost seemed excessive for the utility, in my case. (We were using
the Cadence synthesizer at the time and it had great synthesis style error
checking anyway. INHO Synopsys is not as great in error reporting either.)
- Ed Taub
Cirrus
---- ---- ---- ---- ---- ---- ----
From: jhollins@eng.adaptec.com (Jack Hollins)
I insist that "Verilint" be run before simulation or synthesis on projects
that I am involved with. I don't believe it is productive to find syntax
errors by tying up an expensive verilog or synopsys license. Some of the
warnings it generates which I find most useful are:
1. sensitivity list omissions as this could result in mismatches between
rtl & synthesized simulations.
2. mismatches between size of arguments used in an assignment.
3. unused variables, macros , etc.
- Jack Hollins
Adaptec
---- ---- ---- ---- ---- ---- ----
ANONYMOUS PLEASE!!!!!!!!!!!!!!
Likes: It finds things that Verilog (XL) doesn't catch and Synopsys may
or may not catch. e.g. a[0] <= #1 b[1:0]; Very quick to run.
Dislikes: InterHDL do not understand the unit-delay non-blocking design
methodology however the heinous warnings generated can be disabled.
---- ---- ---- ---- ---- ---- ----
From: Chuck Gollnick <chuckg@arnet.com>
Verilint will find a lot of mistakes that could bite you later on, but those
reports are often burried amidst reams of trivial messages. You can
configure it to not generate certain messages, but that's kind of like
taking the battery out of the smoke detector because the little red light
keeps you awake.
Overall, I'd recommend using it because I think it will improve the quality
of your code and promote consistency between your various engineers.
- Chuck Gollnick
Digi International
---- ---- ---- ---- ---- ---- ----
From: abdoo@azmda.sps.mot.com (Dave Abdoo)
John, We've had a Verilint license for a year or two now, and I always use
it on any code I've just written or changed. Why? Simple - it finds things
that Verilog won't flag as errors, but cause simulation issues. (And these
issues aren't always easy to find in sim!) Examples: floating nets,
assigning a vector'ed net to another signal of a different width, and (to
make this short) just about anything that can cause a failure that is due
to a brain fart, er, ah, oversight while creating your models. I personally
recommend it. When I changed jobs within my company, I nagged my new boss
into buying a copy for this group.
Note that a single floating Verilint license is plenty for most groups - it
runs so quickly that it's always available.
- Dave Abdoo
---- ---- ---- ---- ---- ---- ----
From: dtozer@telenet.com (David Tozer)
John,
I have been using Verilint for a couple of years now; most recently Version
3.0 during the design of an FPGA. I see Verilint's main advantage as
identifying Verilog code which does not meet the syntax required by Synopsys.
This prevents the need to fix these problems as they are reported ONE AT A
TIME by the HDL Compiler. The source for the FPGA (28200 lines of code)
compiled, with no syntax errors, the first time I ran the HDL Compiler!
However, Verilint is extremely pedantic in its checking and reporting. This
is a good thing for the first couple of modules you write, but after that it
gets tiring to wade through pages of warnings (which you know are not
problems) to find the (hopefully) occasional error which is a problem. For
example, I put all my chip-wide `defines in one file which I include in all
my source modules. Verilint prints a warning for each `define which is not
used in the module.
I did use the Verilint command line options to disable some of the warnings
I was not interested in, but others had to stay because they might be
problems in certain circumstances.
To sum up; I use and like Verilint, its avoids having to debug Synopsys
syntax errors one at a time, but it does not make me write "better"
code - just syntactically correct code.
- Dave Tozer
Alcatel Data Networks
---- ---- ---- ---- ---- ---- ----
From: irwans@videocore.com (Irwan L. Sie)
John,
I used Verilint a few times, around May 95, and my take on it:
- It is generally a good tool and will point out the same kinds
of code pblms that Synopsys would also find.
- If access to Synopsys license is limited, the value of Verilint
of course increases in aiding code development.
- Did I encounter any code pblms that Synopsys found and Verilint
didn't? No. All pblms were found by both.
- Did I encounter any code pblms that Verilint found and Synopsys
didn't? YES, BUT ACTUALLY NO. It was a Verilint BUG. Verilint
reported Timing Loops where there was none. I alerted the person
in contact with InterHDL then about this, they investigated, and
from what I gathered later on, they confirmed it, and I expect
that they have fixed it by now.
I did not use Verilint anymore after that brief evaluation.
- Irwan L. Sie
Videocore
---- ---- ---- ---- ---- ---- ----
From: dblack@apple.com (David C. Black)
I use verilint and have the following comments:
* [POSITIVE] Its saved me many hours of needless compiles and simulations.
Verilint runs much faster than either the Verilog simulator or HDL compiler
for a much lower cost. Most runs take much less than a minute to complete
(see licensing comment below). Imagine a large simulation taking many
minutes to compile and finding a syntax error in the last file.
* [NEGATIVE] I have found that there are some errors missed by Verilint,
but caught by other tools. In other words, the set of errors caught by
Verilint, Verilog and HDL Compiler is an overlapping set, and Verilint is
NOT a superset.
* [POSITIVE] Verilint DOES catch errors missed by both Verilog and
Synopsys. Pays for itself.
* [POSITIVE] InterHDL's staff is extremely responsive to problems, and will
add tests once they are aware of them. You need to provide specific
examples, and there must be some automated method of detection. I have
seen suggestions implemented for the next release in very short order.
* [NEGATIVE] Verilint does not yet fully support Behavioral Compiler
(important if you use this). I am also certain that in general synthesis
checks apply primarily to Synopsys Design Compiler. Never-the-less they do
help.
* [POSITIVE] All warnings may be suppressed in a global or case by case
manner. Embedded comments may be used to suppress warnings that are "OK
for this design".
* [NEGATIVE] Some syntax errors have very little more than a pointer to
where. They could attempt to explain what the error was (missing semi).
Usually these are easy to spot.
* [POSITIVE] Errors and Warnings are succinctly stated on one per line.
* [POSITIVE] Invocation is identical to Cadence Verilog-XL. They use
identical switches (options) where possible.
* [NEGATIVE] Verilint-XL licensing has a poor licensing scheme. The first
time a user accesses Verilint-XL it locks that license to the user for 27
minutes to that user. During the 27 minute time period, the same user may
access verilint multiple times since they exclively own it. At the end of
27 minutes, another user can access it. This is fine if you have one
license per user. Unless you are buying one license per user, you should
definitely purchase Verilint-Turbo.
* [POSTIVE] Verilint-Turbo exists with the licensing restriction removed
(actually I think they reduced the time limit to a very small number). It
costs about twice Verilint-XL, but worth it.
- David C. Black
Apple Computer
( ESNUG 232 Item 3 ) ---------------------------------------------- [12/95]
Subject: (ESNUG 229 #2 230 #2 231 #3) "Is Synopsys Floorplan Manager Worth It?"
> ... // Synopsys Floorplan-Manger exists mode OFF... METRICS: It took about
> five iterations of netlist hand-edits, four quarts of StarBucks coffee, and
> a three all-nighters to coerce the layout to meet timing... // Synopsys
> Floorplan-Manger exists mode ON... METRICS: One iteration. Two cups of
> Starbucks. No all-nighters.
From: [ Intrigued in San Francisco ]
Hi John, Please keep me anon.
Obviously this user had a very good experience with the Floorplan Manager
but the original question asked was:
>For example, does it really do something that I can't do myself by tweaking
>the constaints and process by which I use the dc_shell?
I have also seen some great success stories with the Floorplan Manager but
I'm always left wondering if there's anything else I could do in Design
Compiler... Any comments?
- [ Intrigued in San Francisco ]
( ESNUG 232 Item 4 ) ---------------------------------------------- [12/95]
Subject: (ESNUG 231 #2) Synopsys Killing DA's Source-To-Gates NOT Schematics
>I would like to ask Synopsys users on ESNUG to speak out if anyone has used,
>or desired to use, the schematic cross probing feature of Design Analyzer.
>Or maybe would have used it if it was less buggy. Anyone out there???
From: fitz@pond.sps.mot.com (Michael Fitzsimmons)
I find myself simulating gates and looking at waveforms of gates instead
of the gates themselves. Can't remember the last time I debugged a
gate-level problem by looking at schematics... 1989?
- Michael Fitzsimmons
Motorola
---- ---- ---- ---- ---- ---- ----
From: neuman@lsil.com (Darren Neuman)
John:
I have always used and liked the schematic cross probing feature, and
the schematic tracing features of Synopsys in general. They are EXTREMELY
useful, and removing them would be a fatal marketing mistake. The ability
to examine a schematic in a number of systematic ways (tracing is one of
them) is important to be able to verify synthesis results. I have a room
full of engineers using these features on a daily basis, and don't relish
the idea of purchasing & training them on new software!
- Darren Neuman
LSI Logic
---- ---- ---- ---- ---- ---- ----
From: John_Swan-ACIC00@email.mot.com (John Swan)
John,
I'm sorry my comment about schematics was not taken the way I expected it
to be. I did not mean to imply that Synopsys was intending on removing
schematic capability in Design Analyzer. Indeed, that does not make
sense since the tool is based on interactivity with schematics.
The issue is one of cross probing between schematics and source code. In
Design Analyzer, the TEXT VIEW capability has been removed. It would be
useful to have the TEXT VIEW capability back, but one that could highlight
schematic (yes, even mapped schematics) when your Verilog/VHDL is selected,
or conversely highlight source code when schematic is highlighted. Even
where there is no 1-for-1 comparison between source code and gates, a
generalized highlight would suffice. This would have been very helpful for
me in finding gate simulation problems.
Does it not bother anyone that you pay Synopsys $$$ in maintenance only to
have Synopsys REMOVE capability? Why should TEXT VIEW be removed from a
tool on which customers are paying maintenance only to add similar capability
to a new tool that you have to pay for (HDL Advisor)?
- John Swan
Motorola
( ESNUG 232 Item 5 ) ---------------------------------------------- [12/95]
From: dave@nlc.com (Dave Manley)
Subject: Why Doesn't Design Compiler Support `Ifdef, `Else, & `Endif ?
Can anyone give me one good reason why Synopsys chose to not support `ifdef,
`else, and `endif in the Verilog HDL compiler? I'm using cpp but why should
I have to bother?
- Dave Manley
NLC
( ESNUG 232 Networking Section ) ---------------------------------- [12/95]
So. Portland, Maine -- National Semiconductor seeks 1 exp. CAE appl. engr.
to support full custom to VLSI design. No Agencies. "cliff@spcfs2.nsc.com"
|
|
