Editor's Note: While looking through some old family pictures, it hit me
that my parents were two completely different people in their youth. My
dad was an athletic, outdoorsy type who was a fighter pilot in the U.S.
Air Force. Yet my mom hates exersize and kept a house filled with books,
cats and dainty antiques. I emailed my dad and asked him about this.
His reply:
"What did I gain from the deal when I married your mom? Just for
starters let me itemize a few:
1. A full time and tireless safety officer.
2. A television critic and remote control controller.
3. A travel route/motel authority and chooser.
4. A dress code authority and hair styist.
5. A restaurant picker and menu policewoman.
6. An automobile looks and style expert.
7. A personal friend monitor and advisor.
8. A joint tenant with rights of survivorship.
I could probably come up with more but the word censor might rear
its ugly head. luv dad"
This year they'll be having their 51st wedding anniversary. Here's
to wishing you and your special loved one a Happy Valentine's Day. :)
- John Cooley
the ESNUG guy
( ESNUG 406 Subjects ) ------------------------------------------ [02/12/03]
Item 1: ( ESNUG 403 #3 ) Two Say You Should Avoid Toshiba As ASIC Vendor
Item 2: ( ESNUG 291 #6 ) Steve's Lazy Man (lman) Generic Man Page Script
Item 3: Paul Critiques Zain's Verilog CBT Training CD From McGraw Hill
Item 4: User Website Offers Seven Free But Useful Homebrew ASIC Tools
Item 5: Three Techies Chastise Cooley For Not Respecting Scan Chains
Item 6: A DesignWare, Module Compiler, Design Compiler Licensing Question
Item 7: Mentor, Erach Desai, Magma, Monterey, Get2chips, Synplicity, IKOS
Item 8: Synopsys Warns That You *MUST* Use The change_names Command Now!
Item 9: ( ESNUG 405 #10 ) Using Mentor Fastscan Along With DC-Expert-Plus
Item 10: ( ESNUG 405 #11 ) Tomoo Calls Formality An "Arthur Anderson" Tool
Item 11: ( ESNUG 405 #2 ) Odd Blocks From Floorplan Compiler Choke PhysOpt
Item 12: ( ESNUG 404 #16 ) Better DC/PhysOpt Results With 0 Wireload Models
Item 13: One Cadence Diva Workaround For A Difficult Extract/LVS Problem
Item 14: Two Consultants Report On Last Week's DesignCon 2003 Conference
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 406 Item 1 ) -------------------------------------------- [02/12/03]
Subject: ( ESNUG 403 #3 ) Two Say You Should Avoid Toshiba As ASIC Vendor
> Right now we are looking at the advantages of working with Toshiba vs. IBM
> as an ASIC vendor. We have some experience with IBM, but are being wooed
> by the promises of cheaper pricing and support by Toshiba. Toshiba sure
> sounds attractive (and I bet they have some pretty dense RAMs, too!) but I
> am wondering if it is all smoke and mirrors. The grass always being
> greener on the other side. I am sure Toshiba has skeletons as well! I'd
> like to ask your readers what these Toshibia skeletons are.
>
> - the real Toshiba price points
> - the Toshiba vs. IBM tool issues (standard tools vs. proprietary tools,
> ease of use & integration, etc.)
> - Toshiba capacity (or lack thereof)
> - Toshiba availability (hot lots?)
> - the fab cycle time at Toshiba
> - process maturity (0.18u, 0.13u and below) for both Toshiba & IBM
> - Toshiba handling of testability issues (embedded in the process, or
> you do you do it on your own?)
> - Toshiba level of support (especially for smaller companies)
> - Toshiba vs. IBM issues supporting projects w/ lower production volumes
> - access to Toshiba IP cores (PCI, GbE, processors, etc.)
> - access to Toshiba embedded memory and density (SRAM, DRAM, CAM)
> - Toshiba people issues (Japanese language barriers, coordination,
> "not my job", etc.)
> - quality of local Toshiba support teams
> - access to Toshiba technical experts & decision makers in the company
> - sharing mask charges for protos (i.e., shuttle service) at Toshiba
>
> As I said, I have some experience with IBM, but by no means have I hit
> every boundary condition so I would really like to hear anything that
> anyone has experienced with either Toshiba vs. IBM.
>
> - [ Curious George ]
From: Richard Lowry <user=rich domain=starburstt trot balm>
John,
Here is a true story from an old "leftover submarine sailor". Let me start
by saying that I will never buy ANY Toshiba product. Here is why. Before
the fall of the Soviet Union, the U.S. Navy gave the plans for its SECRET
submarine propeller design to the Japanese government. We gave them the
plans so that they could build quieter Japanese submarines. The Japanese
Submarine propeller manufacturer that received these plans turned around
and sold them to the Soviet Union. That company was Toshiba!
In these hard economic times, stick with IBM as your fab.
- Richard Lowry
Starburst Technologies Orlando, FL
---- ---- ---- ---- ---- ---- ----
From: Jeff Winston <soldier=jwinston army=engim aught bomb>
Hi John,
I read with interest Curious George's questions about IBM vs. Toshiba in
ESNUG 403 #3. Though I can't help with Toshiba per-se, I wonder if he
considered a COT flow. A lot of companies of all sizes seem to be moving
to a COT flow, as it supposedly offers faster turnaround, lower costs, and
more control. (I suspect this tracks with the increase of physical-design-
related discussion in ESNUG). Combine this movement with the general
downturn in design starts, and one wonders -- if even IBM can't drum up
enough designs to avoid laying people off, how long will other turnkey
vendors be able to keep their ASIC businesses viable, and will there be some
consolidation down the road? I have nothing against ASIC flow, and I could
be wrong, but I suspect anyone entering into a contract with an ASIC vendor
today needs to consider these trends.
Just my $.02. I'd love to know what others think.
- Jeff Winston
Engim, Inc. Acton, MA
( ESNUG 406 Item 2 ) -------------------------------------------- [02/12/03]
Subject: ( ESNUG 291 #6 ) Steve's Lazy Man (lman) Generic Man Page Script
> Recently I had the problem that I didn't know exactly what Synopsys
> synthesis command to use. For UNIX commands one could find something
> with the "apropos" command. I have a paper version of the synthesis
> quick reference available, but I thought there must be another way. I
> wrote together a few lines of Perl code (see below) and what I got was
> a kind of "apropos" command for the Synopsys synthesis commands:
> "synapropos". It extracts data from the Synopsys man pages and I think
> it might be useful for many other Synopsys users.
>
> - Peter Kamphuis
> Siemens Semiconductor Group Munich, Germany
From: Steve Ehlers <director=steve.ehlers choir=conexant clot prom>
Hi, John,
I have long enjoyed the use of both Synman (ESNUG 188 #2) and Synapropos
(ESNUG 291 #6) for finding and viewing man pages. Thank you, Larry Fiedler
and Peter Kamphuis. I have two things to offer in return.
As a tidbit, the following bash function allows one to get the man page for
Synopsys warnings like so:
warnman UIO-12
# Find man pages for Synopsys warning messages, e.g.
# "warnman OPT-318"
warnman() {
msg=`echo $1 | perl -pe 's,(.*)-(.*),$1/$1-$2,;'`
less $SYNOPSYS/doc/syn/man/catn/$msg.n
}
Or for the csh folks:
alias warnman 'set msg=`echo \!* | \
perl -pe "s,(.*)-(.*),\1/\1-\2,;"` \
&& less $SYNOPSYS/doc/syn/man/catn/$msg.n'
A bit more involved is the attached Perl script. I've been using Verplex
and had made vman a la "Synman":
alias vman='man -M $VERPLEX_HOME/doc'
But I found it annoying to have to exactly remember the full command and
type "vman report_black_box" for a command that could be abbreviated as
"rep bl b" in the Verplex command shell. Why couldn't "vman rep bl b" work?
So I wrote a Perl script to do that.
Then I realized it could work given *any* man pages path. So now I have
these bash aliases:
alias ptman='lman -M $SYNOPSYS/doc/pt/man'
alias sman='lman -M $SYNOPSYS/doc/snps_tcl/man:$SYNOPSYS/doc/syn/man'
alias vman='lman -M $VERPLEX_HOME/doc'
I can type "sman ins te ma" instead of
"synman insert_test_map_effort_enabled".
Or type "ptman set c" to get a list of all documented PrimeTime commands
that start with "set_c", and then pick from the list. If I'm really
fishing, "vman -l point" will return a list of all Verplex man pages with
"point" anywhere in the command name. It's kind of slow, but by default
lman even searches using the $MANPATH environment variable for system
commands! Type "lman -h" for a help message.
I call it lman, as in Lazy Man. Of course, that's man as in the command,
not me, really. Well, okay, so maybe it's both, but I'm only trying to
live up to one of "the three principal virtues" from the Perl man page!
- Steve Ehlers
Conexant Austin, TX
[ Editor's Note: Steve's script is #38 of DeepChip Downloads - John ]
( ESNUG 406 Item 3 ) -------------------------------------------- [02/12/03]
From: Paul Menchini <dancer=mench stage=mench sought guam>
Subject: Paul Critiques Zain's Verilog CBT Training CD From McGraw Hill
Hi, John,
I thought you'd be interested in my review of Zain Navabi's "Verilog
Computer-Based Training Course (Verilog CBT)". It's a computer-
based training course to introduce Verilog to newbies. The course's use of
modern, web-based technologies, such as Macromedia Flash, is both a
blessing and a hinderance. While the ability to animate the presentation
and correlate descriptions with specific regions of code via highlighting
is often used to good effect, his excessive use of animation sometimes
proved distracting to me.
The course does not rely solely on new methods, however. A booklet
covering the use of the course itself accompanies the CD containing the
course and tools. Unfortunately, the indespensible "Quick Reference Guide"
to the course itself is located at the back of the booklet, rather than at
the front. Being a linear sort of guy, I didn't find it until I was well
into the course.
And, the inclusion of tools is a major strength. One can work the examples
as one proceeds through the course, which is vital to understanding.
Probably the most serious flaw in the course is that the explanations
are generally too brief. In many instances, they present the language
without fully explaining the use and limitations of features. Having
on hand a good book on Verilog as a companion to the course would
remedy this problem.
Additionally, I have some minor nits about the course and its delivery
software:
* The installer put a shortcut on my desktop without asking --
admittedly a pet peeve of mine, but one that becomes more important
the more software one installs.
* Also, the course requires not only that IE 5 or later be installed,
but be set as the default browser when Netscape 7 also displays the
in-line frames used in parts of the course.
* The course itself should display how far along within a particular
section you are at any point. You have a display showing where you
are, down to the slide number, but not how far along you are.
* Quitting and restarting does not return you to the same place, so
you must remember where you were.
* There are a few places where the display is not ipdated properly
with flyovers. The screen overprints rather than refreshing.
* Stream 4, billed as a Language Reference Manual, is really a Quick
Reference to the language, and should be billed as such. It does a
good job of being a quick reference, however.
In spite of these and a few other, even more minor nits, the course is
generally well-written and does its job of presenting Verilog in a
structured and accessible manner well. I would, however, suggest that
users have handy a book that more fully explains the language as one
works the examples. Verilog CBT is ISBN: 0-07-137473-6 from McGraw Hill.
- Paul Menchini
Menchini & Associates Durham, NC
( ESNUG 406 Item 4 ) -------------------------------------------- [02/12/03]
From: Jeff Winston <wolf=jeffw2 wolfpack=kwcpa clot bon>
Subject: User Website Offers Seven Free But Useful Homebrew ASIC Tools
Hi John
I'm writing to tell you about my website which contains some free utilities
I wrote which are useful for ASIC design. They are all distributed under
the GNU GPL License. The URL is http://www.kwcpa.com/tools Here's the
seven tools I have so far:
- PTCMP.C compares two PrimeTime files. It finds all the matching
paths, and flags where the slack differs by more than a user
-selectable amount. This program comes in especially handy if you
have a complete chip for which you have blessed timing, but then
have to make small changes to it. You can "re-bless" timing by
comparing your new Primetime output to the old, filtering out
differences of selectably small numbers of picoseconds.
- IFDEF.C processes all the `ifdefs in a Verilog or C (or C++) file.
The result is what the file looks like with the `ifdefs executed.
It also allows you to control which `ifdefs are processed, and
finds nesting errors.
- MODSPLIT.C reads a file with multiple modules in it and writes out one
file per module (with the filename same as the module name). It also
has some smarts to handle lines outside module definitions, and hooks
to easily process an entire design database.
- DCBUILD.PRL recursively uses the report_reference command in Design
Compiler to generate a bottom-up build script, and a useful top-down
printout of your design's entire module hierarchy.
- BEGEND.C parses a verilog file for begin/end and case/endcase statements,
and produces a report that shows the level of nesting for each type of
nesting at every line. This is useful for debugging nesting errors.
- READER.C is useful for reading very large files over a slow (e.g.
dialup) Internet connection. It loads the file and allows you to move
(or search) through it efficiently. There are some assists for finding
multiple simulation failures quickly.
- IPOFIX.ZIP is a set of 2 programs used to fix post-layout timing
problems in VLSI netlists. It does in-place optimization and hold
buffering using input from a variety of sources, including PrimeTime
output. These tools could be ported to other libs with some effort.
I hope to add more tools to this website over time. All the C programs are
generic ANSI C for easy compile and run.
- Jeff Winston Sudbury, MA
[ Editor's Note: As a backup, I've placed all seven of Jeff's free
tools in one Zip file in #37 of the DeepChip Downloads. - John ]
( ESNUG 406 Item 5 ) -------------------------------------------- [02/12/03]
Subject: Three Techies Chastise Cooley For Not Respecting Scan Chains
> Fixing the hold times on scan chains is like working on the septic
> system of a country house. Nobody praises you for doing it well, but
> people notice when it's not working right. And I don't want to be
> worrying about circuits there just to test my design anyway. Like
> most people, I just like to flush the toilet and forget about it,
> thank you.
>
> - John Cooley, EE Times, 01/06/03
From: Hank Walker <doctor=walker hospital=cs.tamu.edu barkbarkbark>
Hi, John,
Some thoughts on "circuits there just to test my design":
1. Hopefully anyone with a brain will be using their scan logic for
design debug, design characterization and defect diagnosis, in
addition to wafer, package and potentially system test. Most
designers put at least a tiny bit of value on the ability to debug
and characterize their designs. And most fabs do appreciate the
ability to do yield learning without the need for a massive amount
of inspection equipment.
2. Most customers do put some value on test, that is, the difference in
the price they'll pay for tested vs. untested chips. Since this
difference might be the sale price, one can legitimately argue that
test has at least as high a value to the customer as the mission mode
design. In other words, quality is free.
3. Ask any designer if they would rather spend N hours fixing scan logic
or spend K*N hours writing functional vectors on a non-scan design
to achieve poorer coverage, where K is certainly more than 1000 for
large designs. And ask the factory manager if they want to buy all
those big testers to apply functional patterns.
4. The system development manager doesn't want to be worrying about how
to implement the design spec. They just want to flush (a la
Synplicity) and have the design pop out, without paying all those
design engineers.
Of course if its a really old toilet, there's no need to flush. Just throw
a maggoty piece of meat down the hole once in a while to feed the bacteria.
- Hank Walker
Texas A&M University College Station, TX
---- ---- ---- ---- ---- ---- ----
From: Nikhil Dakwala <yodeller=nikhil alps=stridge taut pomme>
Hi John,
I myself have a lot to learn on lots of things, but for now, I want to point
out that you have incomplete understanding on scan chain usage, based on
your following statements:
"And I don't want to be worrying about circuits there just to test my
design anyway. Like most people, I just like to flush the toilet "
Following are few things scan can be used at:
- manufacturing tests
- debug functional fails
- debug functional fails at-speed
- characterization
- yield improvement
Scan helps a designer retrieve their prestige, if by mistake it was flushed
down the toilet. :)
- Nikhil Dakwala
Stridge Austin, TX
---- ---- ---- ---- ---- ---- ----
From: Roger Gregor <stripper=rgregor nightclub=stny.rr swat dawn>
Hi, John,
The easiest way to solve the scan chain problem is to use Level Sensitive
Scan Design (LSSD) methodology, circuitry, and tools; rather than a Scan
Mux Flipflop methodology. Although LSSD requires a small area increase per
latch, it allows separate non-overlapping clocks to the Master and Slave
parts of the flipflop. Thus, hold time violations in the scan chain are
solved by the tester clock definitions and never have to be timed.
- Roger Gregor
( ESNUG 406 Item 6 ) -------------------------------------------- [02/12/03]
From: Ravisankar Konidena <one=sankarkonidena many=rediffmail pot von>
Subject: A DesignWare, Module Compiler, Design Compiler Licensing Question
Hi John,
I know that on setting
dw_prefer_mc_inside = true
DesignWare invokes Module Compiler modules for some operations and no
Module Compiler license is needed. I am not sure if it is possible to
invoke Module Compiler from Design Compiler for all operations (like
divide) even if we have a Module Compiler license. Can any one throw
some light on this?
- Ravi Sankar Konidena
( ESNUG 406 Item 7 ) -------------------------------------------- [02/12/03]
Subject: Mentor, Erach Desai, Magma, Monterey, Get2chips, Synplicity, IKOS
> I searched the EE Times site on Mentor and Desai. "I bet there will be
> no organic growth from the Mentor/Innoveda acquisition," Desai said.
> "Mentor has become a bottom feeder that sucks up smaller, dying companies,
> not small companies on the rise that haven't reached their full
> potential." In other quotes Desai said that Mentor should try to get
> Cadence to buy them. Or that the much smaller Magma should somehow acquire
> Mentor to put Calibre in the hands of the Magma sales force. I laughed.
> Desai doesn't sugarcoat what he thinks. I respect that. But I have to
> disagree with him on the tone of his view of Mentor as a company overall.
>
> - John Cooley, EE Times, 2/3/03
From: Ry Schwark <hustler=ry_schwark street=mentor naught awn>
Hi, John,
No sugar coating from me either. You missed some of the other quotes where
Erach basically accuses us of accounting fraud because he didn't like that
we'd done better than he thought we should have. From his January 8th note:
"MENT had guided for 4Q revenues of $180.0 mm and EPS of $0.27.
Consensus is essentially in-line with $179.0 mm and $0.27, respectively.
Being the contrarian we are, our estimates are at $165.0 mm and EPS of
$0.18. With a steady stream of one-time charges this year, we do not
quip about whether the company can hit EPS numbers. Company's
announcement did state that revenues would be "in-line". The only way
MENT does $180 mm in 4Q revenues, in this macro environment that both
SNPS and CDN are feeling, is by borrowing from 1Q03. A "normal"
seasonal decline in 1Q for MENT is about 10%-12%. We suspect that when
the company provides guidance for 1Q03, the sequential downtick in
revenues will exceed 20%."
For those who are financially unsavvy, "borrowing" revenue from future
quarters is what other people call fraud. Erach is always talking about
the deals we should be doing, because he wanted the investment banking
business. I don't think he ever paid attention to our base business.
On the donut thing, we have a different view (no surprise) on our product
portfolio than other people do.
We figure that most tool niches are natural monopolies. People want a good
tool that everyone uses, and then forget about it. Few niches are worth
the bother of having two competitors, let alone more. Cadence and Synopsys
are going head to head in this space and pouring a boatload of bucks into
trying to own Synthesis and P&R. It would be great for corporate ego for
us to get into the fray, but it wouldn't help our shareholders, or our
customers.
EDA is a lot more than ASIC. We're happy enough to focus on other areas and
let Cadence and Synopsys pull each others hair out. We think we serve our
customers and our shareholders better this way.
If this means at the end of the day we have Functional Verification, and
GDSII-to-manufacturing, programmable logic, and PCB design, we're not
unhappy with that.
- Ry Schwark
Mentor Graphics Wilsonville, OR
---- ---- ---- ---- ---- ---- ----
From: Tom Wernimont <suspect=tom.wernimont jail=vitesse jot bomb>
John,
As a new user of Magma tools, I am very happy with the "we try harder"
attitude of their FAEs. I am against a Mentor acquisition of Magma on the
basis (just a feeling, of course) that it will turn a hard-charging,
nimble group into a sluggish big company group with a big-company attitude
towards customer support. Place-and-route tools have always required
significant customer support to allow design teams to be successful with
them. Anyway, I realize that this statement ignores the economics of the
situation from the perspective of the EDA companies themselves.
License fees are a major target of cost-cutting in my company nowadays.
Customer companies like the idea of "go to one EDA company to buy all our
licenses for the entire design process", thinking they can save on
overall licensing fees. But, will this really be the case once
consolidation occurs and there ends up being less overall competition?
If the chip design companies have fewer choices, will licensing fees go
down overall? As long as our choices are greater than 1, then perhaps
we'll be okay. We shall see...
- Tom Wernimont
Vitesse Semiconductor Camarillo, CA
---- ---- ---- ---- ---- ---- ----
> The problem is that as a company, Mentor has a hole smack dab in the
> middle where synthesis and place & route are.
From: Howard Landman <whale=howard pod=riverrock.org moomoomoo>
Hi, John,
Even more perplexing is that Mentor HAD the beginnings of a world-class
synthesis tool in Autologic, and failed to either develop it into a full
-strength competitor to DC or to market it effectively. It so frustrated
its creator that he quit and went off to found his own synthesis company.
Perhaps you've heard of them - Ken McElvain, and Synplicity? (I worked
with Ken at Silicon Compilers, which was acquired by Mentor.)
Mentor also HAD a place and route system that, around 1990, was arguably
competitive: Autocells. I used Autocells on the Sun MicroSparc so many
years ago. Where is it today?
Mentor seems to have suffered from a severe lack of vision.
- Howard Landman
River Rock Consulting Fort Collins, CO
---- ---- ---- ---- ---- ---- ----
From: John Reeder <brat=jreeder daycarecenter=microsemi fraught mom>
Hi, John,
Interesting article and right on the spot. I used to work for Mentor as a
Sales AE and that hole has long been a recognized problem.
It will be interesting to see what they do.
- John Reeder
Microsemi Corporate Center Irvine, CA
---- ---- ---- ---- ---- ---- ----
From: Larry Richardson <tenant=lrichardson5 apartment=austin.rr not von>
Hi, John,
I must agree with your assessment of Mentor. At Motorola, I was blown away
by that system's vertical integration capability, as far as tying together
the layout process with the pick-and-place machines down on the floor; but
synthesis was not part of the capability of the system we used there. Have
you ever used MAXIM's ADS system? It was sort of acquired when they took
over the Tektronix integrated circuit design group up in Portland. It has
synthesis capabilities which rival Agilent, and for roughly half the price.
- Larry Richardson Austin, TX
---- ---- ---- ---- ---- ---- ----
From: Hubert Wolters <fish=hwolters school=sonicsinc thought prawn>
John,
If I were Mentor, I would also acquire Get2Chip (http://www.get2chip.com) to
fix the hole in the middle - the synthesis hole.
- Hubert Wolters
Sonics, Inc. Mountain View, CA
---- ---- ---- ---- ---- ---- ----
From: John Purchase <waiter=purchase restaurant=cadence knot tom>
Hi, John,
I'm ex-Mentor and currently work for Cadence. You are correct that Mentor
and Magma would be good fit from flow prespective. The major problem is
Mentor's weak balance sheet (and stock price). Second major problem is
Wally wants to maintain control rather than cede control to Magma execs.
For these reasons I think Monterey is the more likely option. Erach is
correct that Mentor (Wally) is "cheap" and prefers to pay less to buy
troubled companies. This is why they bought Microtec instead of Windriver,
Meta emulation instead of Quickturn, etc. Wally has been patiently waiting
for P&R technology, and will likely pounce when Monterey runs out of
financing.
I totally agree with Erach that Mentor should not have weakened their
balance sheet to acquire Innoveda. This was huge mistake which limited
their ability to acquire valuable companies such as Magma. On a positive
note, it looks like the IKOS acquisition will work out OK.
- John Purchase
Cadence Felton, CA
---- ---- ---- ---- ---- ---- ----
From: Mahesh Chandra <mongol=mahesh horde=cmr-da yacht gone>
Dear John,
Nice to read your views in EE Times on Mentor possibly buying Magma. While
Mentor would love to do so how would they? Mentor's current market cap is
$570 million with cash reserves of $30 million. Magma's current market cap
is $270 million. If Mentor bid twice the present Magma share price, it
will need to fork out an amount equal to their own market cap! This would
rule out issuing Mentor stock for Magma stock.
Another point about Mentor. Though MTI is a very good selling simulator
worldwide, we find two things about it in India:
a) More and more companies doing ASIC are moving from MTI to NCSim
and/or VCS
b) MTI is still the slowest among the three.
c) Simuators like Fintronic are picking up fast.
This is something Mentor should watch out and fix before it is too late.
India is now a significant player in the marketplace with TI, Intel, ST
adding several thousand engineers to their front end design teams in India.
- Mahesh Chandra
CMR Design Automation Pvt. Ltd. New Delhi, India
( ESNUG 406 Item 8 ) -------------------------------------------- [02/12/03]
From: Steve Hoeft <bee=steve.hoeft hive=synopsys caught qualm>
Subject: Synopsys Warns That You *MUST* Use The change_names Command Now!
Hi John,
I am an Synopsys AC in Mountain View and I thought the following would be
useful to the ESNUG readers. It will be a SolvNET article soon, but a
wider distribution is even better.
You should always use "change_names" in your design flow. Do not rely on
"write Verilog" or "write VHDL" to change your design names.
The change_names command will continue to be developed. Write Verilog and
write VHDL will not have bug fixes done to their under the hood name
changing code. This applies if you are passing information between Synopsys
tools using ANY format other than a Synopsys design DB or Milkyway.
Now, you might ask "Why not do the changes under the hood when writing
out the files?"
Doing under the hood changes is not a good thing to do precisely because
it is done under the hood. If there is a problem you have no recovery
method. Additionally, it still means that your design DB and the output
files are out of SYNC!!! By having a central name change command or
commands you can ensure that the changes were correctly and fully done
before saving any data to disk. This is safer than making under the hood
changes.
In the 2003.03 release the current Verilog and VHDL writers apply under the
hood changes if the design DB contains non-compliant names. This has been
their behavior for years and you do not need to worry about existing scripts
or flows. If you have already applied "change_names -rules verilog -hier"
or "change_names -rules vhdl -hier" the writers do not need to make any
changes because the design is already name compliant with your chosen output
format. If you are not applying "change_names" as part of your existing
flow, you should add this now. It will make your flow much more robust now
and in the future.
In the future, the writers will assume that "change_names" is doing all the
necessary changes and will stop making under the hood changes. This is to
avoid duplication of code and duplication of capabilities that are not quite
100% exactly the same. It will also remove the side effect of under the
hood name changes that can cause difficulties when trying to debug design
and netlist inconsistencies.
So, the simple message is:
After ANY design change use the change_names command before you save any
files to disk!
This will ensure that your design DB and any subsequent file formats, and
reports, are consistent with each other and have no naming issues. If your
scripts do not have "change_names -rules Verilog/VHDL -hier" in them, add
it now.
- Steve Hoeft
Synopsys, Inc. Mountain View, CA
( ESNUG 406 Item 9 ) -------------------------------------------- [02/12/03]
Subject: ( ESNUG 405 #10 ) Using Mentor Fastscan Along With DC-Expert-Plus
> Our Mentor AE has informed me that Mentor provides a utility which
> will convert a DCxP generated STIL file into Fastscan dofiles and
> testprocs. My first question is whether or not anybody out there has
> experience either directly with this flow, or with a similar one
> involving using DCxP in conjunction with Fastscan, or other "foreign"
> ATPG tool? My second question is how do people feel about DCxP's STIL
> file generation capabilities? Any "tricks" one should know about
> before basing a design flow on it?
>
> - Rich Conlin
> Paradigm Works, Inc. Andover, MA
From: Ron Press <ship=ron_press fleet=mentorg nought psalm>
Hi John,
FastScan fits well within a DC flow. Many customers use Synopsys DFT
Compiler for scan insertion and use our "stil2mgc" command to convert STIL
outputs from DFT Compiler to a FastScan procedure file and dofile. There
really isn't much more to it. The STIL procedure is usually very simple
and defines the circuit primary input constraints, clocks, scan chains,
and the shift cycles. In fact, many customers in the DC/FastScan flow
don't even use STIL and manually write the procedure and dofile for
FastScan since these files are so simple.
Not to sound like I'm pushing Mentor tools, but some customers use our
DFTAdvisor tool within a DC flow because it provides a lot of scan insertion
flexibility and has good capacity.
- Ron Press
Mentor Graphics Wilsonville, OR
---- ---- ---- ---- ---- ---- ----
From: Ken Butler <preacher=kenb gospeltvshow=ti brought yawn>
John,
I've used "stil2mgc" to go to FastScan quite a few times. Like anything
else, it had a few glitches early on, but I reported those. It seems to be
better these days. I've never used this flow for anything complicated like,
for example, a design where a JTAG must be done to set the chip into test
mode. But for most things I've done "stil2mgc" works fine.
I don't know of any particular "tricks" to get DCxP to generate proper STIL
procedures files other than just the standard things you'd do anyway --
set_input_delay, create_clock, create_test_clock, check_test, and stuff
like that.
- Ken Butler
Texas Instruments Dallas, TX
---- ---- ---- ---- ---- ---- ----
From: Don Skinner <stockbroker=skinnerdj market=sympatico.ca cluckcluck>
Hey John,
We have tried a similar flow to what Rich is suggesting. The tool that
Mentor provides to create it's procedure files from STIL files does work for
the most part, as long as you don't throw anything too complicated at it.
If you are only trying to do it for standalone blocks within a design, you
shouldn't have any problems (this doesn't mean you won't be doing the odd
tweak). Both STIL and Mentor's procedure files are pretty readable once you
get used to them.
We have only done this using a combination of DFT Compiler and Fastscan, so
the actual STIL might be different, but I would be surprised if it varied a
lot. If your client is not using the ATPG features of Test Compiler
anymore, perhaps it's time to switch.
- Don Skinner
ex-Nortel and looking Ottawa, ON
( ESNUG 406 Item 10 ) ------------------------------------------- [02/12/03]
Subject: ( ESNUG 405 #11 ) Tomoo Calls Formality An "Arthur Anderson" Tool
> Originally, Formality and Design Compiler *did* use the same front end:
> HDL Compiler. Thus if there was a bug in HDL Compiler then it was
> possible that during the initial parsing of the Verilog code, both Design
> Compiler and Formality would get the same *wrong* answer. And your
> verification tool would be useless. I don't know if this ever actually
> happened, but it was possible.
>
> - Steve Golson
> Trilobyte Systems Carlisle, MA
From: Bart Willems <european=bart cafe=easics.be ouiouioui>
Hi John,
We actually encountered this type of problem. In one of our designs bad
logic was generated due to a bug in Synopsys DC 2000.11-SP2. We found
this via gate-level simulations of the netlist. I thought this was an
interesting test case to check the dependencies (if any) between DC and
Formality.
First I used Formality 2001.08-FM1-SP3. Using this version, the synthesis
bug was not discovered, and verification between the RTL VHDL code and the
buggy Verilog netlist "succeeded"! Formality didn't find the bad logic.
This was not very encouraging. Next I tried Formality 2002.09-FM, which
at that time was the most recent version. Again the verification
"succeeded". Not good. But this time the following message appeared when
the VHDL RTL code was read:
Info: Formality has a new high-performance VHDL reader that can
be enabled by setting the 'hdlin_enable_rtlc_vhdl' variable prior
to reading in any design data.
So I tried again after setting 'hdlin_enable_rtlc_vhdl'. This time the
verification between the RTL code and the buggy netlist failed, so the bug
in DC was caught.
So it looks like, by default, the old front end is still used when VHDL
code is read into Formality. You have to set the
hdlin_enable_rtlc_vhdl = true
in order to use the new VHDL front end. I didn't find anything about this
in the Formality documentation, but maybe I overlooked it.
- Bart Willems
Easics NV Leuven, Belgium
---- ---- ---- ---- ---- ---- ----
> If Verplex wins in my customer benchmarks, that's great! I'll buy the
> tool! But I don't think that being "independent of Synopsys" is a
> legitimate reason to buy Verplex over Formality.
>
> To the Verplex marketing folks out there: Give up the FUD. That dog
> won't hunt any more. And don't belittle your competitor's products. Let
> us users do that for you!
>
> - Steve Golson
> Trilobyte Systems Carlisle, MA
From: Tomoo Taguchi <piranha=tomoo amazonriver=hp sought qualm>
Hi, John,
A few thoughts on Steve's comments. The whole argument against Formality
and DC being developed by the same company reminds me of issues raised about
another industry in the recent past: accounting.
I think one of the main themes of the Arthur Anderson scandals is that an
accounting firm was also providing other services to a company that created
a conflict of interest that compromised the integrity of their accounting.
But let me explain my thinking. For me simulation or formal equivalency
checking is essentially technical accounting. You're checking if synthesis
did it's job right. So for me, the integrity of the checking tool is of
paramount importance. The first pass of Formality didn't pass this test by
using HDL Compiler for both synthesis and formal checks. (In my opinion,
Synopsys deserves any perception problems eminating from originally using
HDL Compiler - they never should have shipped a tool with such a big flaw.)
Since then, Synopsys has done the technical equivalent of putting up (to
borrow another term from the accounting scandals) a Chinese Wall, by buying
an independently developed HDL engine.
Steve mentions using the -hdlc switch to use HDL Compiler get around any
problems with the Formality HDL reader. Although this is convenient to get
around problems, I find even the availability of this switch disturbing
because it essentially breaks down the Chinese Wall, should you use it.
(And I've been told to use -hdlc by Synopsys without getting an explaination
of its implications.)
Now the ease of use issue. Getting both synthesis and formal tools from the
same vendor will make your life easier. But do you really want a checking
(accounting) process to go too smoothly? As an engineer, wouldn't you
question a perfect first-pass result of anything? I think that any kind of
accouting or checking process needs to be adversarial to some extent to
preserve its integrity. Sure, being able to read in the .db file makes life
easier, but in my mind, formal checks replaces simulation, so I'd rather
jump through the hoops of using the simulation libraries instead. (But I
concede that using .dbs after doing formal checks against the simulation
library is OK.)
For me the integrity of an independent check is very important because I
don't know what Design Compiler is doing under the hood and I don't know
what a formal tool is doing under its hood. The only reason I trusted DC
was that I could run a simulation to see the gates I ended up with toggled
the bits in the way that I expected. Now with formal, I don't do much
gate-level simulation and I have to trust that when the tools says its OK,
it's really OK. Using the accouning analogy again, I don't know the exact
details of what's been happening to my money or even where it is, but I
need an accountant that will tell me that I have enough to do what I want.
And to trust the accountant, I need to make sure that he doesn't have any
incentive to lie to me or shade the truth.
Now having said all this, would I use Formality?
YES, I WOULD.
But, I wouldn't use any of the features like -hdlc which Synopsys touts as
selling points. If I used .db files, I would jump through the hoop of
checking it agains the simulation library first. In my mind they constitute
a "conflict of intrest". Basically, I don't think I would use any of the
features that makes Formality "nice to use".
I just used Verplex to check a 2 Mgate design. It wasn't as easy or smooth
as I had hoped. Verplex has its share of warts. My main complaint was that
it doesn't have a native TCL mode. It's TCL is more or less a band-aid
slap-on which limits its usefulness. You have to manually tell the tool
what architecture a multiplier is using (very annoying). It some times gave
false negatives (miscompares) on hierarchical blocks. And it can't deal
with non-synthesizable DesignWare models.
As a result of these frustrations, I did an evaluation of Formality. It was
easier to use. It dealt with multipliers and designware easier (no surprise
since both tools come from the same company). But eventually Formality lost
the evaluation because it was 3X slower than Verplex. For all the
frustrations that I experienced with Verplex, I did find work-arounds, I
just couldn't tolerate a 3X slow down.
Again, would I trust Formality? Yes I would, with the stated restrictions.
But at least with our design, it lost the benchmark.
- Tomoo Taguchi
Hewlett-Packard San Diego, CA
( ESNUG 406 Item 11 ) ------------------------------------------- [02/12/03]
Subject: ( ESNUG 405 #2 ) Odd Blocks From Floorplan Compiler Choke PhysOpt
> We taped out a design last April using Jupiter/Physopt/Apollo and one "U"
> shaped rectilinear block. The block had pins on 6 of the 8 sides. ...
> Surprisingly we found only one problem with the entire rectilinear flow.
> At the time, the Jupiter function to align the pins of adjacent blocks
> didn't work on our "U" block. I don't know if this has been fixed or not
> in later rev.'s.
>
> - Jon Stahl
> Avici
From: Russ Petersen <penguin=russp iceberg=subasic.sciatl shot balm>
Hi, John.
OK, I have to resond to this as we've had some trouble here. We have been
successful using Floorplan Compiler to create rectilinear blocks and then
passing them off to Physical Compiler, although some significant problems
with PDEF kept coming up again, and again, and again, and again. Does it
sound like I'm tired of the PDEF problems? Hey, and its even Synopsys who
came up with PDEF in the first place, right? Enough with the PDEF problems.
:-)
One thing we did learn was this: Don't ever put a notch in the bottom left
corner of your block (ie: don't make a rectilinear block that would notch
out the traditional origin) if you are going to be using Physopt. Ex:
************************
* *
***** *
* *
0,0 ********************
We had a block that looked like this and PhysOpt (no matter what version)
completely fell apart on it. We eventually got it to work with some
creative workarounds but it was painfull and slowed us down. Hopefully this
will get fixed with an upcoming version as Synopys has been made very well
aware of this problem and the pain it caused us. Since I didn't work with
the block directly I can't remember the final fix or all the issues but it
was doing things like shifting all cell up and to the right, messing up the
pins, etc... In short, it was making a mess of things.
Finally, FPC has a current weakness in that while you can create rectilinear
blocks OK from the start, but you can't easily modify them with the GUI.
That is, if you try to stretch a side it just reverts back to a plain
rectangle. Hence, any adjustments have to made from the command line using
actual coordinates for the corners. Synopsys has been made aware of this
however so it should hopefully be fixed soon.
- Russell Petersen
Scientific Atlanta Lawrenceville, GA
( ESNUG 406 Item 12 ) ------------------------------------------- [02/12/03]
Subject: ( ESNUG 404 #16 ) Better DC/PhysOpt Results With 0 Wireload Models
> Further experimentation after tapeout found that we could reduce the
> area of some blocks even further by not using any wireload models during
> DC synthesis, just fanout rules and reduced cycle times to get the faster
> architectures, and then letting Dolphin do the appropriate logic mapping
> and sizing. The savings were on the order of 10% for a one million gate
> block.
>
> - Tim Lantz
> Tau Networks Scotts Valley, CA
> PhysOpt is good, but it would be great if the buffering removal
> capabilities in PhysOpt were better. We realized a 10-15% timing and
> area savings when going from gates-to-placed-gates if we compiled with
> 0 wireload and fast timing, as PhysOpt just added more buffering to the
> already buffered paths instead of ripping or upsizing.
>
> - Gregg Lahti
> Corrent Corp. Tempe, AZ
From: Benny Winefeld <sock=benny dresserdrawer=mondes tot lawn>
Hi John,
Two comments in ESNUG 404 caught my interest and I wanted to draw your
readers attention to them. Both Tim Lantz and Gregg Lahti have seen a
benefit from using a zero wireload model with tightened timing
constraints to encourage DC to produce a design that is more suitable
for physical synthesis downstream. We have independently found that
same strategy at Monterey and it works pretty well in most cases. The
tighter clock cycles seem to encourage synthesis tools to pick faster
architectures (just be sure to restore your actual timing constraints
before entering into physical synthesis.) Using zero wireload models
keeps synthesis from wasting time on pointless buffering and sizing.
As you know, statistical wireload models are practically useless with
modern processes -- wire delay has become so significant that it needs to
be modeled accurately during optimization. In our experiments we've
found that the improvements in timing achieved during tech mapping using
non-zero wire load models are largely illusory and are not reflected in
the final timing achieved after physical synthesis, during which 80% or
more of the gates are changed anyway. By contrast, choices made during
architecture selection are extremely important to the final timing of
the circuit.
We've embodied the above strategy directly in our Dolphin-RTL product,
but your readers may want to experiment with this approach with whatever
tools they are currently using. It is likely to help, as Tim and Gregg
have both found.
- Benny Winefeld
Monterey Design Systems Sunnyvale, CA
( ESNUG 406 Item 13 ) ------------------------------------------- [02/12/03]
Subject: One Cadence Diva Workaround For A Difficult Extract/LVS Problem
> I am trying to do something unconventional (?) in an extract. I want to
> place properties on a device recognition layer, for properties too
> difficult to extract. I then want to use these properties in the
> extract process to set parameters of the device. For instance, if I
> have a spiral inductor that is generated by a pcell, I do not need the
> extractor to extract its inductance, since I have simulated it with a
> 3D field solver. I would like to somehow attach the inductance to the
> recognition layer shape, and then during the extract process grab this
> property and use it as a parameter for LVS. This would allow me to
> catch if I am using an incorrect inductor, which is the point of the
> LVS, without trying to code the actual inductance extraction. Any
> ideas?
>
> - Jackson Harvey
> Bermai, Inc. Palo Alto, CA
From: Ed Kalenda <ceo=ed company=kalenda got awn>
You cannot do this in Diva. Perhaps Assura or Dracula can do it, but I've
not heard of it. The closest you can come is to use macrocell mode and have
the inductor be a macrocell. The instance and its properties are copied
from the layout to the extracted view. This bypasses the extractDevice
rule. You do have to write your rules in a way that checks to be sure there
are no unexpected connections to the internals of the macrocell, such as a
M1 wire touching the M1 coil of the inductor, since only the terminals of
the macrocell are pulled up for analysis.
- Ed Kalenda San Jose, CA
---- ---- ---- ---- ---- ---- ----
From: Djamel <tree=djamel forrest=bensouiah.freeserve.co.uk hihihihi>
Actually, it may not be that difficult in Diva. Dracula does not let you
invoke Skill code. Assura might offer similar functionality, but I've never
used it. Here's what you should do in Diva:
- you must have a "table" associating your 3d-simulated inductor "x" with
its properties
- your pcell code could add a recognition shape/text to say that this is
inductor "x"
- the extraction runset would extract and save the recognition shape/text
Following extractDevice() for inductors, use an ivCallProc() statement to
process the extracted inductors in any way you want (using a Skill-coded
version of your inductors table.)
- Djamel
( ESNUG 406 Item 14 ) ------------------------------------------- [02/12/03]
Subject: Two Consultants Report On Last Week's DesignCon 2003 Conference
From: James Lee <beginning=jml end=asicgroup fought yawn>
Hi, John,
Here's my quick report on DesignCon last week (January 27-30): Monday with
only technical sessions was well attended. There was a low turnout of only
around a dozen for Stu Sutherland's excellent System Verilog tutorial. The
nano engineering technology forum was better attended. Tuesday's keynote
luncheon speech by Chris Malachowsky of NVIDIA was a great multimedia
presentation starting with the crude graphics of early Atari and PC video
games concluding with the near movie quality of today's video games.
The two SOC panel discussions I attended Tuesday and Wednesday were both
standing room only. Tuesday's panel on SOC testing concluded that today's
fault modeling with stuck-at faults is not adequate for some of the faults
being seen in nanometer designs. Wednesday's panel on IP concluded that the
cost of integration and testing of IP often outweighs the IP cost. One stop
shopping for IP simplifies the integration and support problem. The
panelists comments on the question of IP and its support from an EDA vendor
were, "There is no need to bash Synopsys support" and "There is value to
the one stop shopping".
The DesignCon vendor exhibits were an interesting mix. Synopsys was only
represented by their design services group in a small booth against a side
wall rather than their normal central dominant presence. Cadence/Tality was
completely missing. Mentor and Rambus had a large presense. Rambus was the
primary sponsor of this event and their stock price recently doubled! Which
yields the conclusion, sponsor DesignCon, have a large booth and watch your
stock price double!
On a humorous note, a friend of mine at an EDA vendor said "wouldn't it be
great if Synopsys announced that in 18 months they would discontinue all
support of VHDL and be moving all products to System Verilog?". I'll leave
him anonymous, and just think about the implication this would have for the
industry.
- James Lee
The ASIC Group Fremont, CA
---- ---- ---- ---- ---- ---- ----
From: Dave Chapman <alpha=dwc omega=goldmountain not calm>
Hi, John,
Here are my thoughts about last week's DesignCon:
Best give-away: A really cool, dangerous mountain climbing stick from iROC,
a French company. Their product was pretty good, too. They have software
which helps to protect against logic soft errors. Kind of like using parity
to protect against memory soft errors.
Best technology: Xanoptix has a hybrid chip packaging technology which
allows you to put a III-V semiconductor wafer (meaning a CERDES, laser, and
photo-diode receiver set) onto a silicon die. How do they do it? I don't
know. What I do know is that this might be the future of high-speed serial
chip interconnects.
Second-best technology: Also from Xanoptix. It's a connector for a whole
lot of fiber. Looks sort-of like an RJ-45 connector, but can have up to 70
or 80 fibers. We need this.
Not exactly news: Vera continues to make slow progress in the IP market.
People who pay actual money for IP are increasingly demanding that it comes
with a testbench. Vera seems to be gaining share over Verilog and Verisity
in this market.
Funny thing: The early brochure for the show had maybe 1/4 or 1/3 the number
of exhibitors who actually showed. Looks like lots of people waited until
the very last minute before deciding to buy a booth.
Only about of 1/3 of the companies were in the EDA design space. A lot of
the rest were connector companies from Back East. My suspicion is that the
show promoters gave away a lot of booths to make it look better, and that a
lot of people came in order to make their mid-winter trip to California
a business expense.
Food item: The first night of the exhibits, they had really good food.
There was a big joint of roast beef, and a guy carving slices off of it,
etc. The second night, we got nasty hot dogs and even nastier hamburgers.
What was that about?
Overall: DesignCon'03 was the best show I've been to since the summer of
2001. People didn't look exactly optimistic, but they didn't look like the
survivors of a Death March, either.
- Dave Chapman
Gold Mountain Consulting Sebastopol, CA
============================================================================
Trying to figure out a Synopsys bug? Want to hear how 16,288 other users
dealt with it? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@TheWorld.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
|
|
