!!! "It's not a BUG, jcooley@world.std.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / "One Sheep Farmer's Impressions Of SNUG'01 & HDL Con'01"
_] [_ (plus what 92 other engineers saw there, too.)
by John Cooley
Moderator Of The E-mail Synopsys Users Group (ESNUG)
The 11th Annual Synopsys Users Group Meeting (SNUG'01)
at the Doubletree Inn, San Jose, CA, March 5th - 7th, 2001
"I didn't fall asleep once, so SNUG must have been good. Big rooms
of people all haveing the same problems as you are nice. If
you're a Synopsys user, SNUG was a cool conference."
- Paul Gerlach of Tektronix
"I want to point out that I weighed my baggage before and after SNUG
and somehow it gained 28 pounds; that was my baggage not me. With
470+ people at SNUG over the two days there was over 6 tons of stuff
given away. No wonder everyone looked tired Wednesday afternoon."
- Tom Tessier, t2design
"I asked the presenter what about the Verilog conditional operator
construct (I've been pointing out for years to various designers that
the conditional operator will NOT infer a MUX). I could see the
light go on in the presenter's eyes as he said "yeah, we could make
that work." (John, it's awesome when Synopsys R&D staff members do
tutorials!) I hope to see this feature implemented in the future."
- Bob Wiegand of NxtWave Communications
"I'd like to congradulate Tim Wilson of Intel (the SNUG'01 Chair) and
Joanne Wegener of Synopsys (the Synopsys/SNUG co-ordinator) for this
year's SNUG getting a survey rating of 4.2 out of 5.0 -- the highest
customer survey rating ever given to any SNUG conference. Damn good
job there, Tim & Joanne! Damn good job!"
- John Cooley, the ESNUG guy
"When we surfed the web, we found all the useful acronyms already
taken up by the dot com craze."
- Dennis Brophy of Mentor (on why the OVI/VIUF conference
gave itself that really stupid "Accellera" name.)
( SNUG 01 Subjects ) ------------------------------------------- [ 3/28/01 ]
Item 1: Wally Rhines Keynote At HDL Con'01 -- FPGA's Rule!
Item 2: The Bigwig's Big SNUG Speech -- Was Aart Distracted?
Item 3: Exactly Who Came To SNUG'01?
Item 4: What SNUG'01 Attendees Liked & Disliked
Item 5: What SNUG'01 Attendees Liked & Disliked (Part II)
Item 6: Cadence NC-Verilog & NC-VHDL, Synopsys VCS & Scirroco, ModelSim
Item 7: Cadence Tapeout FUD, Rajeev, & CEO Credibility
Item 8: Synopsys "Chip Architect" -- A Problem Child
Item 9: Tera Systems "TeraForm"
Item 10: Silicon Perspective's "First Encounter"
Item 11: Synopsys NDA "Hidden Dragon" & "SmartClusters"
Item 12: Physical Compiler (PhysOpt) vs. Cadence PKS vs. Magma BlastFusion
Item 13: Controversial HDL Con'01 Panels, C, Superlog, & Verilog-2000
Item 14: Designers Hate SystemC, CynLibs, & C-based HW Design
Item 15: Verplex Tuxedo & BlackTie, Avanti Chrysalis, Synopsys Formality
Item 16: Synopsys Design Compiler vs. Cadence Ambit vs. Get2chips.com
Item 17: Synopsys Module Compiler & Behavioral Compiler
Item 18: TetraMax, Mentor's "FastScan", Synopsys "BSD Compiler"
Item 19: "FPGA Express" vs. Synplicity vs. Exemplar
Item 20: Synopsys "PrimeTime" -- Sitting Pretty
Item 21: Tharas Systems "Hammer" & FPGA Protyping
Item 22: Synopsys Vera vs. Verisity Specman vs. Chronology (Forte)
Item 23: O-In, Synopsys NDA "Ketchum", & NDA "Verification Analyst"
Item 24: Synopsys On-Line Support & the Synopsys Hotline
Item 25: Loving Synopsys LINUX, Cadence LINUX, & Synopsys 64-bit
Item 26: Synopsys "Eagle-i" -- Lost In The Wilderness
Item 27: Libraries, SPICE, PathMill, Synopsys "Power Compiler", EPIC
Item 28: The Synopsys 2001 Report Card
( SNUG 01 Item 1 ) --------------------------------------------- [ 3/28/01 ]
Subject: Wally Rhines Keynote At HDL Con'01 -- FPGA's Rule!
FPGAs WILL RULE THE WORLD: Wally Rhines, CEO of Mentor Graphics, gave the
Keynote Address at HDL COon'01 and it was basically a Motherhood & Apple
Pie speech on how FPGAs will Rule The World. ( Santarini covered it in:
http://www.eet.com/story/design/OEG20010302S0060 )
"You can do multiple passes without people finding out you
did multiple passes."
- Wally Rhines, CEO of Mentor, on one of the big
advantages of designing FPGAs instead of ASICs
"In 1980, we had ~2000 custom designers. In 1990, we had about
20,000 custom designers. In 2010, it's projected we'll have
around 200,000 custom/semi-custom designers. In 1980, designers
designed roughly 2,000 gates per chip. In 1990, that jumped to
20,000 gates per chip. In 2010, it'll average out to 200,000 gates
per chip, when it should be more like 30 million gates per designer
per chip if you follow the curves. To make up for this production gap,
1 in every 30 people on Earth will be have to be doing FPGA design."
- Wally Rhines, CEO of Mentor
Wally forsees massive IP reuse (in this future of mostly FPGA designs) to
enable design productivity gains and EDA software having to become much more
bugfree and robust. "With 200,000 designers using FPGA tools, you can't
afford to have a staff answering the phone when the customers encounter
bugs," said Wally. "I know that you don't associate this with EDA vendors,
but we have to make our software more bulletproof."
"Wally Rhines (CEO Mentor) was the HDL Con Keynote speaker. Talked
alot about porting FPGAs from ASIC designs. He did mention the
performance difference between ASICs and FPGAs."
- Dan Joyce of Compaq
"HDL Con Key Note speaker - Wally Rines - CEO Mentor Graphics
60% of FPGA designers use VHDL, 20% use Verilog. This seems to be
because FPGAs are designed at more of a system level than a chip level.
Due to VHDL-AMS, and FPGAs HDL users are going to increase by an order
of magnitude over the next few years. People will be going to
"platform based design", using an FPGA, which as a CPU core (or DSP);
memory, Buss management, and IP integrated into one chip. Team based
FPGA design will become a big thing."
- [ Kenny, from South Park ]
"Adam Smith ("Wealth of Nations") is giving programmable logic a great
economic hand job. With the rising costs of masks, only a few will
be able to afford doing standard cells. Everything else goes
programmable. Now the EDA world just needs to figure out how to make
money at providing FPGA tools. Synplicity has proved that it can
(sorta) be done. I don't think the PLD industry paid Wally to say
what he did, but they probably should have."
- [ Zul, The EDA Marketing Demi-God ]
( SNUG 01 Item 2 ) --------------------------------------------- [ 3/28/01 ]
Subject: The Bigwig's Big SNUG Speech -- Was Aart Distracted?
NOT ALL THERE: After 10 years of giving very interesting keynote addresses
keeping the audience (and even his Marketing staff) on the edge of their
seats with interesting technology leaks and snappy Q&A, this year Aart de
Geus, the CEO of Synopsys, gave a speech his Marketing staff could have
given. It was sad to see. Usually Aart's on the top of his game. OK, so
some of the engineers expected Aart to know all sorts of Synopsys technical
minutiae, but the guy's a CEO -- he can't do that for all 78 EDA products
he manages. Don't get me wrong; it's *GOOD* to ask Aart these questions
because *someone* will answer them! But I was floored when I asked him
about bad customer reactions to Chip Architect (ESNUG 364 #1) and Aart
replied about it being a *pricing* issue! (This is with customers howling
about Chip Architect not working as a *hierarchical* tool! He should have
known about that one. It's only 1/3 of his physical synthesis offering,
after all...)
"Did you notice Aart "promising" discounts on Chip Architect to
everyone? :-)"
- Paul Gerlach of Tektronix
"...yawn. Sorry, Aart... not much new, but more hope to see more soon.
I wanted more on topics like Linux, 64 bit support, cross talk in
timing delays, & the new tool for sharing views on machines between
Synopsys & customers out in the field for debugging problems
(ViewConnect.) I didn't get to see any of this at SNUG, but heard
about a good demo on it done at EuroSNUG."
- Chris Kiegle of IBM
"In addition to the usual state of the industry stuff, Aart usually
gives some insight into what's coming soon. At the Boston SNUG
(5 months ago), he mentioned the following goodies:
- Synopsys Professional Services is presently doing RTL to GDSII.
- PrimeTime is now in beta with crosstalk analysis capability.
- Signal integrity coming into Physical Compiler
- Synopsys is working directly with tester companies to bolster
their test offerings
In this SNUG speech, it was far more interesting what was NOT said!
Unless I sneezed and missed something, Aart said NOTHING in his
keynote address. What about clock tree synthesis? What about
Route 66? What about signal integrity? What about testability
improvements? Aart, where was the beef?"
- Bob Wiegand of NxtWave Communications
"The Q&A was weak but Synopsys has performed well this last year
so the users really didn't have much ammo. I did like the fact
that ASIC starts are basically constant which I found surprising.
I noticed that SystemC was talked about again but now with the
realization that it will not be replacing Verilog/VHDL anytime
soon. This was in contrast to Aart's speech last year when a
large majority of the talk was on SystemC and the fact that it
would take over the world.
It was nice to see that Linux is getting the ports it deserves.
We will have an issue with Linux hardware not being as large as
SUN/HP but it is catching up."
- Tom Tessier, t2design
"Unfortunately this year Aart didn't make many predictions/promises as
he was warned by his marketing managers. Here were some quotes:
- There is more value in a new car's semiconductors than in
its steel.
- The current problems with the economy put design in the
forefront.
- Physical Compiler will have power synthesis, datapath,
clock tree synthesis and DFT tools.
- Design methodology has a profound impact on the success
of the players as there are more handoffs.
- 6 Design challenges: Timing closure (causes largest schedule
slips), verification, IP and systems integration, test,
signal integrity, power
As usual Aart's speech was very well attended."
- Joe Gilray of Agilent
"Actually I didn't think it was too bad. Aart skimmed over some stuff,
and I still think there is holes in the Synopsys flow that need
addressing (their own router engine will help)."
- Chris Byham of Philips Semiconductors
"Synopsys has changed the licensing daemons for it tools. The new keys
won't run the old revisions of the tools. I tried raising this issue
at SNUG, but Aart just said "why would you want to run old revisions of
tools?" Here's why. We taped out chips at particular revisions of
tools: tools for simulation, synthesis, layout. To reproduce the
chip, we need to be able to rerun those *exact* tools, including which
revision of the tools. Running older chips on new tool revisions
might require extensive work. When someone suggests that my chip in the
field has a bug, I need to come back with a response, quickly."
- an anon engineer
"Key note - CEO Synopsys - March 13 -15 of 2002 will be the next SNUG.
Since 1999 SNUG has grown 31.1%, predicting another 10-22% for year
2000. VHDL Synopsys simulation is 5x slower than Verilog. Scissero
is a new VHDL sim tool that will be 5x faster than VSS. Notes that
the cost of testing a design will equal the cost of creating a design.
At .15u cross talk delay will start to equal interconnect delay. A
good quote from Aart was "Push on us to be as open as possible with our
interfaces" (I wish it were so!). 64 bit version of PrimeTime out now.
DC 64 bit will be out soon. DC on LINUX (red hat) was released two
weeks ago. (485 people attended SNUG this year)."
- [ Kenny, from South Park ]
"Something very fishy is going on at Synopsys w.r.t. the Clock Tree
Synthesis in Physical Compiler. I asked the question about it last
year and Aart said "Its the top priority and it will be release by
December". This year I asked him same question and got the same
answer. At the R&D night, none of the Synopsys engineers could give
me a clear answer. Is Aart hiding something??
Apart from his first 15 minutes that were interesting, the rest was a
marketing pitch."
- Himanshu Bhatnagar of Conexant
"Clock Tree Synthesis in on the top of our queue. I don't want to be
assasinated by the Marketing manager for it, so I can't give out a
specific date as to when it comes out."
- reply by Aart de Geus, CEO of Synopsys
"6) Signal Integrity -- Here, Aart could only hint at a solution
'soon to come'. This is probably tied in with the detail
router solution to be integrated into Physical Compiler.
Everybody at Synopsys is being notably cautious about
revealing any sort of release date for this stuff. I suspect
it's because they require a major update to their internal
timing engine in order to handle detail routing properly
(ie, integrate the PrimeTime engine into Physical Compiler.)"
- Rich Conlin of Paradigm Works
"We are running into the same PDEF 3.0 for PhysOpt problem Bob reported
back in March 2000 (11 months ago!) Wouldn't you think Avanti would
have fixed this by now?! Could anyone who has them please send us the
Scheme scripts used to process the Avanti PDEF 2.0 files for PhysOpt?"
- Andy Pagones of Motorola ( from ESNUG 365 #1 )
"I read some postings on ESNUG referring to the difficulty of using
Apollo as the backend to Synopsys Physical Compiler. We are
particularly having trouble reading PDEF 3.0 into Apollo and we have
tried the various methods that have been suggested (pdef2adb and
Scheme scripts). Do you have any additional information on this?"
- Scott Marvenko, Department of Defense [ Someone during
Aart's Q&A asked exactly this same question. ]
"Here's how you can help. Push on us and the other guys to make it
happen. If we push on Avanti or Cadence, nothing happens. If you
push on them, something happens."
- reply by Aart de Geus, CEO of Synopsys
BTW, Scott's PhysOpt/Avanti PDEF 3.0/2.0 was solved last week in ESNUG 367.
( SNUG 01 Item 3 ) --------------------------------------------- [ 3/28/01 ]
Subject: Exactly Who Came To SNUG'01?
DESIGN, DESIGN, DESIGN!: This data comes from the customer survey taken
at the SNUG'01 meeting itself. A total of 321 out of the 485 SNUG'01
attendees responded to this survey.
Here's the stats on who came:
Design Engineer ############################### 63%
Design Eng. Mgr. #### 8%
CAD Engineer ########## 20%
CAD Eng. Mgr. ### 6%
Academic # 2%
Other ## 4%
The types of designs these engineers are creating:
Standard Cell / Gate Array ############################## 60%
System-On-A-Chip ############### 31%
Full Custom ####### 14%
FPGA/CPLD #### 9%
Other ## 5%
The speed, size, and process of the chips they're designing:
1 - 99 MHz ############ 23%
100 - 199 MHz ################ 33%
200 + MHz ###################### 44%
1 - 100 Kgates ######## 17%
101 - 500 Kgates ########## 21%
501 -1000 Kgates ############# 26%
1 Million + ################## 36%
0.35 um or higher ### 6%
0.25 um ########## 21%
0.18 um ######################### 49%
below 0.18 um ########### 23%
Their design flow (COT means they're doing their own place & route):
ASIC design flow ############################## 59%
COT Cadence P&R ######## 16%
COT Avanti P&R ######### 18%
COT in-house P&R ## 4%
COT "other" P&R # 3%
And the fabs and/or FPGAs they're designing:
In-House Company Fab ################## 38%
TSMC ################ 31%
IBM ######## 16%
LSI ######### 18%
Texas Instruments ###### 12%
UMC ##### 10%
Lucent ## 4%
Toshiba ## 5%
STMicroelectronics
NEC, Fujitsu, Charter,
Mitsubishi # 3% or less
Xilinx ################ 33%
Altera ############ 23%
So, in a nutshell, SNUG'01 was a conference of high-end chip designers.
( SNUG 01 Item 4 ) --------------------------------------------- [ 3/28/01 ]
Subject: What SNUG'01 Attendees Liked & Disliked
VOTING WITH THEIR FEET: One way to tell what's hot and what's not is to
just see how many people attended what talk. Here's what I personally
counted in each room during the SNUG'01 conference.
Monday, March 5 Number Of Attendees
9:00 - 12:15 (MA1) Tutorial on Design Compiler & Presto 231
9:00 - 12:15 (MA2) Tutorial of SystemC 66
9:00 - 12:15 (MA3) Tutorial on Power Compiler 68
9:00 - 12:15 (MA4) Tutorial on Module Compiler 28
1:30 - 3:30 (MB1) Users on Vera, Vera & PhysOpt 214
1:30 - 3:30 (MB2) Power Compiler, Module Compiler, FPGA 76
3:45 - 5:45 (MC1) DC, simple_compile_mode, ACS 296 + 9 standees
3:45 - 5:45 (MC2) Emacs Verilog & Verilog Standards 38
3:45 - 5:45 (MC3) Compute Farms, LSF, Design Data Mgmt 31
5:45 - 8:30 Non-Synopsys EDA Vendor Fair Party Est. 600
Tuesday, March 6
9:00 - 10:15 Keynote Address (Aart's Speech) 287 + 22 standees
10:30 - 12:30 (TA1) DC, FoorPlan Mgr, PrimeTime, ATPG 257
10:30 - 12:30 (TA2) Code Coverage, Verification, BFMs 84
10:30 - 12:30 (TA3) Power Compiler, FPM, PathMill, Libs 23
1:45 - 3:45 (TB1) Physical Compiler (PhysOpt) 247 + 24 standees
1:45 - 3:45 (TB2) PowerMill, OLA, Antenna Effects 37
4:00 - 4:30 Nvidia Real Life Design Project Talk 251
6:00 - 8:00 Synopsys R&D Cocktail Party ~500
Wednesday, March 7
9:00 - 12:15 (WA1) Tutorial PhysOpt/Chip_Arch/FlexRoute 208
9:00 - 12:15 (WA2) Tutorial Presto HDL Compiler 74
9:00 - 12:15 (WA3) Tutorial FPGA Compiler & Big FPGAs 22
1:30 - 4:45 (WB1) Tutorial on PrimeTime 108
1:00 - 4:45 (WB2) Tutorial on TetraMax, DFT Compiler 82
1:00 - 4:45 (WB3) Tutorial on VCS, Vera, Covermeter 51
1:00 - 4:45 (WB4) Tutorial on Arcadia 24
By looking at which sessions where attendees had a choice, you can see the
designers have a strong interest in: PhysOpt, Chip Architect, DC, Presto,
PrimeTime, FlexRoute, simple_compile_mode, ACS, and Vera. Conversely,
they had minimal interested in: Power Compiler, FPGA Compiler, Arcadia,
and Module Compiler. The "standees" data indicated a surprise interest
(i.e. topics were worth standing for) in: ACS, simple_compile_mode, and
PhysOpt.
Overall user attendance for SNUG'01 was 485 customers. Compared to last
year's 474 customers, you could say that SNUG had a steady following.
( SNUG 01 Item 5 ) --------------------------------------------- [ 3/28/01 ]
Subject: What SNUG'01 Attendees Liked & Disliked (Part II)
THE DIRECT APPROACH: The second way to find out what's hot and what's not
is to just directly ask people. Here are the SNUG'01 survey results for
two questions. Out of the 485 uses at SNUG'01, 321 answered this survey.
"10B.) Which Synopsys product are you *most* satisfied with?"
Design Compiler (DC) #########################S S############ 143
PrimeTime #################################### 72
VCS ############## 28
Physical Compiler (PhysOpt) ########### 22
TetraMax ###### 11
Module Compiler (MC) ### 5
Vera ## 4
FPGA Compiler II ## 4
DC-Ultima # 3
ACS # 2
Scirocco # 2
PowerMill # 2
Formality # 2
Behavioral Compiler
Protocol Compiler, Sunrise
DFT Compiler, DA, VSS 1
"10C.) Which Synopsys product are you *least* satisfied with?"
Design Compiler (DC) ######## 15
Chip Architect (CA) ####### 14
Formality ###### 12
Physical Compiler (PhysOpt) ##### 10
Floorplan Manager #### 9
VCS #### 9
PrimeTime #### 8
Test Compiler (TC) ### 6
FPGA Compiler II ### 6
VSS ### 6
ECO Compiler ## 5
Design Analyzer (DA) ## 5
TetraMax ## 4
Scirocco ## 4
Synopsys licensing # 3
CoverMeter # 3
BSD Compiler # 2
DCXP # 2
ACS # 2
Vera # 2
PowerMill # 2
Behavioral Compiler, LMC
RTLA, Presto, PT-Tcl, LEDA
PathMill, TimeMill
Power Compiler, ProVerilog
Design Vision, MC
Library Compiler
VHDL Compiler, HWM 1
DC took 143 positive votes and 15 negatives. No big surprise here with the
Synopsys best selling tool. PrimeTime was 72 to 8. VCS 28 to 9. PhysOpt
went 22 to 10. OK, so it's still under development. TetraMax 11 to 4.
Now to the problem children. Chip Architect had 0 positive votes and 14
negatives. Says something here. Formality 2 to 12. Again, that tells us
something. VSS 1 to 6. CoverMeter, BSD Compiler, ECO Compiler had no
positive votes either; no surprises.
There were a total of 306 positive tool votes and 144 negative tool votes;
which is interesting because customers were asked to list one positive and
one negative Synopsys product. This seems to indicate customers having a
mostly positive view of Synopsys products.
( SNUG 01 Item 6 ) --------------------------------------------- [ 3/28/01 ]
Subject: Cadence NC-Verilog & NC-VHDL, Synopsys VCS & Scirroco, ModelSim
SEPARATE BUT EQUAL: Judging from the reader response, it appears that most
users now see Synopsys VCS and Cadence NC-Verilog as rough equals. And
even though at DAC'00 9 months ago Synopsys secretly demo-ed a VCS' Direct
Kernel Interface (VeriC/DKI) that allowed C object files to link directly
into VCS ("look ma!, no PLI!"), no one here mentioned that new VCS feature.
ModelSim still seems to be the slower younger brother of the VCS/NC twins
and Scirroco is still the neglected step-child in the simulation family.
"20.) What design language(s) are used in your design?"
Only Use Verilog ########################## 51%
Both VHDL & Verilog ################## 36%
Only Use VHDL ###### 13%
"I attended Synopsys' DAC presentation describing their new Direct-C
interface being built into VCS. This is long overdue: replacing the
bulky slow PLI interface with a native interface which will allow
calling C or C++ functions directly from Verilog source, allowing easy
string manipulation and file I/O.
Their "CModule" portion allows instantiation of C or C++ modules right
in the Verilog code. They have added sufficient concurrency (such as
"always @") to allow C/C++ system modeling to be used in a hardware
context. Scheduling and building the golden reference will remain a
challenge, but at least this gives us more flexibility and performance.
Synopsys claims these functions will use VCS's direct kernel interface,
be an integral part of VCS, and be delivered as a free upgrade. We
will certainly give these new features a try."
- an anon engineer ( from DAC'00 #12 of the DAC 2000 Trip Report )
"I found VCS & NC to run at about the same speed. It depends on the
design but they both are about 4x faster than XL. NC-Verilog is
harder to use and the errors and harder to spot due to the log file
file organization and length. VCS is very easy to use and suffers
only from a strange habit of sometimes having to recompile EVERYTHING
including libraries under Clearcase control.
Our management used VCS to beat down the price on more NC licenses.
Now we use NC and XL."
- David Hollinbeck of LTX Corp.
"We use Modelsim for all our simulations. We do mixed VHDL and Verilog
designs. Scirocco might interest us if Synopsys are going to
continually improve the tool. If they intend to ignore VHDL users for
another three years after releasing the new simulator, then I guess
we'll stick to Mentor!
My award for "best demo under trying circumstances" goes to Mentor. I
was given a look at Modelsim 5.5 (launched the day before DATE), they
had it running under a version of linux they don't support and because
the software had come from the U.S., it was an early cut of 5.5 (a GUI
bug was fixed between the version I saw and the release.) The result
was a demo that tried to crash everytime their apps guy tried to show
me a new feature!"
- Chris Byham of Philips Semiconductors
"For VHDL, I do not trust Scirocco. Saw VSS in a previous company and
waited for Scirocco for 2 yrs. It is not their core competency."
- an anon engineer
"We have 25 NC-Verilog licenses, 8 VCS licenses and a couple ModelSim
licenses. The designers and CAD folk prefer them in that order as
well. I have not seen too much difference between VCS and NC-Verilog,
but I would be taken outside and beaten if I told people that they
had to use ModelSim. The tool is strongly disliked because of poor
support from Mentor, a bad waveform viewer and very limited capacity,
and, did I mention it's slow?
- an anon engineer
"VCS, but we haven't benchmarked. If it ain't broke ..."
- an anon engineer
"We are strictly Verilog, so VHDL and mix VHDL/Verilog simulators are
of no interest. I did a detailed evaluation of VCS & NC on designs in
'98 and '00. In some cases NC was faster and other VCS was faster but
the delta was never greater than ~10%. As far as debug environments,
we use Novas Debussy so VCS/NC is used only as a simulator and nothing
else. With good coding standards and effective utilization of the PLI
(tf routines instead of acc) decent performance can be achieved with
either simulator. But bottom line - order of magnitude of where we
would like to be which is >100 cps.
- Jerry Vauk of Sun Microsystems
"I have benchmarked all of these, including on Suns and Linux machines.
I have found that NC-Verilog and VCS are basically equivalent. That
is, sometimes VCS is faster than NC-Verilog and sometimes NC-Verilog
is faster. Mostly it comes down to preference. Modelsim is
significantly slower than either NC-Verilog or VCS but it does seem
to have a nice interface. We don't use Modelsim though since it
benchmarked so much slower than VCS/NC-Verilog. It's cheaper, though,
so you can't really complain. Hence, we use both NC-Verilog and VCS
here since they both are about the same speed (usually the speed
differences are less than 10% on any given test case).
I have to admit I don't try to make use of any of those special
optimization switches though as that often causes me more trouble than
its worth. I have also found that on gate models that VCS will core
dump for no good reason on a particular design, sometimes when only
the testbench has changed slightly from the last time. NC-Verilog
does the same kind of thing, however, so that's why we keep both
around. If it won't run on VCS for a particular case, we use
NC-Verilog and vice-versa. So far, I have never had both core dumping
at the same time.
- Russell Petersen of Scientific Atlanta
"At my previous employer we benchmarked VCS against NC-Verilog a little
over a year ago. We found that even with the Synopsys AE present
making sure we were using VCS properly, that NC-Verilog was much (2x)
faster on our benchmark designs.
My experience with NC-Verilog is greater so I may be biased, but as a
vendor I would prefer Cadence over Synopsys anyway, so I would
definitely recommend NC-Verilog over VCS any day."
- an anon engineer
"We have both simulators in-house (many licenses) so I'm not slanting
things one way or the other. For SDF back-annotation sims, NC-Sim
heaves up and dies everytime we run it on our 3M gate ASIC. VCS
always works fine."
- an anon engineer
"The last time I benchmarked them was about two years ago. At that time
VCS was clearly ahead of NC-Verilog for our design/coding style. I
understand from some people that NC-Verilog has reached parity with
VCS. I plan to benchmark them again this month, actually, to see
whether this is true.
Even if they are even in performance, I prefer VCS to NC-Verilog for a
couple of reasons:
1. I prefer VCS' compile model. It's very simple and clean, looking
very much like a C compiler: you feed it Verilog code, and it
spits out a binary executable that you just run. One step.
It does a nice job of incremental compiles, and so forth, to make
the compile process efficient.
For NC-Verilog, on the other hand, you have to go through at least
two steps: the elaborate step, and then the compile. I never
understood why they did it that way -- hide that complexity from
the user. I don't see the gain.
2. I prefer VCS' PLI linking model. Your own PLI routines are linked
in as a library in that one compile step, with a little control
file (.tab) to tell VCS how they're used. No messing with files
in the VCS directory.
In my past experience with NC-Verilog (and especially Verilog-XL,
and even Fintronics), you had to link your PLI into some part of
the CAD vendor's tools -- and I *hate* mucking with the files in
a vendor's tools release. It just has the potential of messing
something up, and complicates support (what if you roll out
something new, and it turns out to break your whole team's
simulations...?).
That said, I'm as pragmatic as the next engineer: if NC-Verilog turns
out to give us a decided speed advantage, I'm sure we'd be asking for
a quote."
- Kris Monsen of Mobilygen Corp.
"I own a license to ModelSim and have before they got bought out by
Mentor. Often on client sites I am using either VCS or NC-Verilog for
Verilog design and ModelSim for VHDL design work. I can work with any
of them and they all have quirks. Developing scare tissue is what an
EDA Consultant does well as we are always being cut by the tools. So
you asked if I had a preference, right now for Verilog I prefer
NC-Verilog because I have used it extensively over the last year. For
VHDL, I have never preferred anything other then ModelTech. I have
done Verilog designs in ModelTech but it was much slower then
NC-Verilog at the time ~ 1 year ago."
- Tom Tessier of t2design
"We are a Modeltech house that has made extensive use of Modelsim's
integrated TCL interface to create portable chip debug tools that run
on both the simulator and on emulation or the silicon itself.
We have been asked to look at porting our TCL code to Scirocco, and
have found Scirocco as a tool to be quite resistant to the paradigm
of TCL chip debuggers. The simulator command set of Scirocco is quite
limited compared to Modelsim. For example, in Modelsim you can create
a clock in your TCL environment using the force command with the
-repeat option; the equivalent Scirocco assign command has no repeat
option. In addition Scirocco is more unstable, the Virsim interactive
enviroment is primitive when compared to Modelsim, and the restart
command strangely causes all the previous TCL procedures you have run
to be automatically re-executed (each time you restart, it re-runs
all of the commands run since starting the simulator, ad infinitum...)
It appears that the Scirocco designers have not taken the time to find
out how TCL is used by their customers in design simulation flows."
- an anon engineer
"We are a VHDL house and therefore we use ModelSim. Lately we have been
investigating running sims using Verilog gate-level netlists and SDF
files with VHDL testbenches running on MTI LNL under LINUX. We are
seeing very impressive speed improvements.
We passed on Scirocco even when Synopsys offered it to us for free."
- an anon engineer
"The Synopsys LINT checker seemed to have some promise -- especially if
they can undercut Avanti's price on ExploreRTL or whatever it's called
these days."
- an anon engineer
"I had the chance to speak with someone from Synopsys for a while. Here
is a list of some of my questions and his responses:
Q: Will VCS support the new features of Verilog 2000?
A: VCS will only support the synthesizable subset of Verilog 2000
(I have talked with others from Synopsys who say this is not true).
This means no true support for re-entrant tasks! VCS 6.0 has some
of the Verilog 2000 features, but they are undocumented because
they have not been fully tested yet.
Q: What about the future of Vera?
A: Vera will be around for a long time. There are separate development
paths for Vera and SystemC, so there is no plan to drop Vera for
SystemC. Synopsys sees SystemC as an opportunity to help develop
a standard and Vera as a product that is a source of income.
Q: Will Synopsys provide "hooks" between VCS and SystemC?
A: Yes, but only after SystemC has more time to develop. No specific
time frame was mentioned."
- Dan Joyce of Compaq Computers
"From 1993 onward, I was surprised to see that my VCS engineers
managed to to get a 2X speed-up every year -- and that's in
the software -- not from running VCS on faster workstations.
VHDL simulators have not kept up with Verilog. I don't
think VHDL will ever be as fast as Verilog because of certain
structural restrictions in VHDL. World wide, I see users
break out to 55 percent Verilog and 45 percent VHDL."
- Aart de Geus, CEO of Synopsys
What Aart may or may not realize is that 2X VCS speed-up hasn't been really
available to your average non-expert VCS user. Over the past few years, the
Synopsys VCS management has been very, VERY paranoid about the Cadence
NC-Verilog group learning about (and countering) each year's newer VCS
speed-up switches and technolgies. As a result, there have been only two
ways one could learn each year's ever newer VCS tricks. They were:
1.) If you were a Big Money Customer who regularly used lots of VCS
licenses, Synopsys would fly in their VCS specialist to spend
time training you on that year's secret new VCS tips & tricks.
2.) If you don't have that much "pull" with Synopsys as a customer,
you could hire an independent consultant like Cliff Cummings who
would teach you all the newer tricks in VCS.
But, if you were Joe Average chip designer with a limited EDA budget, you
were stuck pawing through thick (and cryptic) release notes to learn that
year's newer VCS tricks.
Contrast this with how Synopsys supports DC. They go out of their way to
repeatedly tell and tell again what each new version of DC can do. Just
look at the past SNUG and BSNUG trip reports here on the DeepChip
archives -- each report is has at *least* 20 new DC switches or useful
tricks mentioned in them. And look at how DC is handled in ESNUG;
week in and week out there's lots of detailed DC discussion going on. If
it's not some DC-Tcl script, or 12 new issues with ACS, or a DW bug -- it's
a review of Presto, or "what's this undocumented report_qor command?", or
troubles doing latch-based designs in DC. Users, FAEs, CAEs, and Synopsys
R&D are all an active part of the DC discussion in ESNUG every week. The
same thing happens with PrimeTime (where they're having a lively "monotonic
or not" lib discussion and Paul Zimmer just put out a kick ass paper on how
to handle the really ugly timing issues in PrimeTime.) VCS has no such
equivalent weekly on-going discussion happening anywhere. Sure there's
Verilog discussion on comp.lang.verilog and VCS is mentioned there sometimes;
but you're not seeing deep "here's this really useful VCS Radiant trick"
or "watch out for the Roadrunner XYZ bug in VCS 6.0 when you..." like the
weekly nitty gritty details you have for DC or PrimeTime.
The net result of this Synopsys VCS paranoia about Cadence NC-Verilog is
that your *average* VCS user doesn't know most of the hot VCS tricks. So,
he doesn't see 2X. He just sees what he gets with VCS "out of the box."
As a consequence, Synopsys now *splits* the compiled Verilog market with
Cadence when, at one time, VCS had *owned* the compiled Verilog market.
I wonder how different things would have been if the Synopsys VCS team
had openly promoted a public and intimate knowledge of each year's new
VCS tricks instead...
( SNUG 01 Item 7 ) --------------------------------------------- [ 3/28/01 ]
Subject: Cadence Tapeout FUD, Rajeev, & CEO Credibility
SEARCHING FOR TRUTH: Three months ago, I challenged Aart's claim of 53
physical synthesis tape-outs. After a count and a recount, I discovered:
Synopsys PhysOpt +
ChipArch + FlexRoute : ################################ 65 tape-outs
Silicon Perspective
"First Encounter" : ##################### 43 tape-outs
Cadence
PKS : ### 7 tape-outs
Mentor
TeraPlace : ### 7 tape-outs
Sapphire
FormIT : ### 6 tape-outs
Magma
"Blast Fusion" : # 3 tape-outs
Monterey
Dolphin : 0 tape-outs
It was all written up on DeepChip and EE Times. I was a bit embarrassed
that I hadn't caught him what I though was a little corporate bragging. Oh,
well. Win some. Lose some.
At HDL Con'01, I went into the Cadence demo suite (along with a number of
other engineers) and saw their PKS demo. It was cool to see. Their slides
outlined all sorts of PKS features and harped about some what some guy in
Synopsys said about correlation in a 1999 issue of EE Times. It closed
with a point-by-point comparison between PKS and PhysOpt. They claimed to
have "10 to 12 tape-outs" with PKS. Then the Q&A came. This guy from
Intel asked: "What about the 53 PhysOpt tapeouts?" The answer (I wrote it
down word for word) was:
"The only thing I hear about Physical Compiler comes from
Synopsys Marketing. I heard that the tape-outs were recounted
and there were only 27 of them. It's on the web somewhere."
- Rashmi Murthy, Cadence Lead Applications Engineer
There was Cadence throwing FUD on *my* tape-out count! (BTW, I don't blame
Rashi for saying what she said -- she was just parroting the responses to
the anticipated Q&A for the PKS demo. Rashi wasn't saying this; Cadence
Marketing was saying this!)
Two weeks later, I read that Ray Bingham, the CEO of Cadence, was now
claiming 35 tape-outs at DATE. (Hmmm... You got 25 *more* tape-outs
in the two weeks since Rashi told me about those "10 to 12 tape-outs"
for PKS? Good for you, Ray! Good for you!)
So I kept that story quiet (to not bias the respondants) and laughingly
added this question to my SNUG'01 trip report survey:
"3a.) At last week's SNUG, Aart claimed to have 85 to 100 customer
tape-outs for his physical synthesis tools. At this week's DATE
conference in Europe, Rajeev Madhavan, the CEO of Magma, claims
to have 25 tape-outs and Ray Bingham, the CEO of Cadence,
claims to have 35 tape-outs. Out of those 3 CEOs, in your opinion,
who is lying and who is telling the truth? (Please be very
specific; I want to tally the total 'he's lying' vs. 'he's
truthful' votes for each CEO.)"
Rather than try to tally the user responses, I've just quoted ALL the user
replies anonymously to this question and you can draw your own conclusions.
Enjoy!
"Rajeev Madhavan, the CEO of Magma, is lying. Aart is telling the truth
(but probably bending the rules to get the numbers.) Ray is telling
the truth (but probably bending the rules to get the numbers.)
But what do you expect from CEOs?"
- an anon engineer
"I dont know. Magma is the most interesting of all. But not yet
useable for normal users."
- an anon engineer
"100 tapeouts for PhysOpt, Aart is definitely LYING."
- an anon engineer
"1) Aart is clearly mistaken -- you CANNOT tape out a chip with Physical
Compiler!!! Any statement to the contrary is just untrue. He
should not be allowed to claim any "tapeouts", unless its in
conjunction with Cadence/Avanti since you'll need a million bucks
worth of their tools to actually tapeout a chip!
2) I don't buy the 25 number from Magma at all.
3) Ray's number, I believe. Given (1) above, in fact, I think he's
being way too conservative. How many of Aart's "tapeouts" were
actually Cadence tapeouts??!!"
- an anon engineer
"I'm convinced Aart is truthful. I remember you counted the PhysOpt
users a while ago and there were a lot. I also suspect Ray Bingham's
number is accurate. I assume it refers to PKS, not Silicon Ensemble,
because I'm sure SE has a lot more tapeouts than that.
For Magma, 25 seems a lot. Could it be they were referring to chips
that have some smaller piece placed with Magma in them, while the rest
of the chip used mainstream tools like Apollo or Silicon Ensemble?"
- an anon engineer
"Didn't you blow December tracking this down? They are all stretching
the truth a little but the CEO of Magma has more to gain (and lose) if
he does not show tapeouts. You made tapeouts the rallying cry for ASIC
EDA vendors. Cadence's CEO will often have higher numbers because of
Spectrum Services are still doing taxi-cab tapeouts and the end clients
don't want to talk about them. They feel selling there soul to Cadence
is not the politically correct view. Finally Aart's claim seem to be
the most accurate going back to your work in December.
My gut feel is it is good to have competition in this marketplace. It
makes all the EDA vendors stay on their toes and we the users benefit."
- an anon engineer
"Aart truthful
Rajeev lying
Ray lying"
- an anon engineer
"I would say that Aart is telling the truth, Rajeev is lying, Ray is
exaggerating the truth (there probably are 35 tape-outs but probably
many of them also used Synopsys for synthesis and therefore these are
probably just "back-end" tape outs)."
- an anon engineer
"Aart : Truthful"
- an anon engineer
"I can't state that I think any are lying (so they can't sue me),
however I'd bet my reputation on all three stretching credibility as
far as possible to make the best marketing story (is a respin really
a seperate tapeout?)"
- an anon engineer
"I'd go with Aart as most truthful, followed by Ray & then Rajeev
from a standpoint of what I hear/see from their involvement in
customer support.
What I am waiting to hear is where they stand as far as designs that
have been done with no or minimal support from their support/R&D folks;
To know when the customer has been fully enabled (new tool & new flow)
without any added support from the EDA vendors that goes beyond their
typical support flow."
- an anon engineer
"After your ESNUG survey a couple months ago and some of the people I
talked to at SNUG, I would say the following:
Rajeev is definitely lying.
Art is telling the truth
Ray is probably being honest."
- an anon engineer
"Rajeev is lying."
- an anon engineer
( SNUG 01 Item 8 ) --------------------------------------------- [ 3/28/01 ]
Subject: Synopsys "Chip Architect" -- A Problem Child
ONE UGLY BABY: When I said I was floored by Aart's "it's a pricing issue"
response to my Chip Architect question, it was because of Chip Architect's
bizzare history. A little over 2 years ago, Jon Stahl of Avici wrote the
first customer review of Chip Architect in ESNUG 338 #1. It was a glowing
report. Then, 2 months ago, Jon Stahl *retracted* his endorsement because
Chip Architect, a hierarchical floorplanner, has problems with *hierarchy*!
"18.) What is your physical design methodology?"
Flat Only ######## 17%
Hierarchical Only ########### 22%
Mixed (Flat & Hier.) ############################### 61%
"It did not completely meet timing and the ECO timing improvement
features of the tool were broken.
I attempted and was able to write a complex script to have Chip
Architect do repeater insertion, but it would only work after I
flattened the entire design (a hierarchical attempt only produced
core dumps). This resulted in timing being met, but led to further
misery as the tool only had the ability to produce a flat netlist
from the flattened physical hierarchy and did not keep separate
logical and physical views. This in itself was ugly, but only
a show-stopper when we attempted to run several other tools which
couldn't handle a totally flat netlist for a design of that size."
- Jon Stahl of Avici ( in ESNUG 363 #1 )
This was a first! Never before in the history of ESNUG had anyone ever
publically endorsed a product and then later retract that endorsement.
Never. And then others started seeing what Jon saw:
"We have a copy of the Chip Architect tool and have attended the
training sessions. While they loudly tout that it supports
hierarchical placement, what is really true and mentioned offhand
by John Stahl is that it can ONLY do separate placement on each
and every hierarchical block.
That means that even DesignWare inserted levels of hierarchy must be
physically regioned on the die if left in the netlist. This is
absurd for large designs with hundreds of hierarchical instances!
You can only run placement starting with lowest levels of hierarchy
and work up. No logical/physical variation is allowed, which is just
a downright odd choice for a company who sold Floorplan Manager
suggesting that you regularly encounter logical/physical mappings."
- Thomas Ayers of Believe, Inc. ( in ESNUG 364 #1 )
"I think that Chip Arch works well as a front end to PhysOpt, but we
don't use it to do placement. Hopefully, Chip Architect will be priced
according to this new (more limited, I guess) role. :-)"
- Lars Bo Graversen of MIPS Technologies ( in ESNUG 365 #4 )
So, basically, Chip Architect is one ugly EDA tool -- which is why I asked
Aart that question during the Q&A after his SNUG'01 Keynote address.
"PhysOpt fits easily in a Synopsys flow. I will have a try on it
(they promised testing licenses). I do not see the use of FlexRoute
or Chip Architect."
- Klaus Vongehr of Philips Semiconductors
"I presented a paper on the breakdown of Synopsys Floorplan Manager
at SNUG'01. We are currently working on the next generation of the
chip I presented and again are improving our flow to solve some of
the problems we had. I am currently looking at using either Chip
Architect or Silicon Perspective's First Encounter for design planning.
We plan on using our front end flow with DC as was presented in our
paper. Both tools have very similar attributes but I feel First
Encounter had done a more complete job of pre-route analysis and
estimates and I am personally leaning that direction. The proof
will be in how either of these tools work with our foundry supplier;
so until that is determined I am keeping an open mind."
- Tom Tessier, t2design
"I benchmarked PhysOpt and got excellent results. I am very happy
about it. I don't see the usefulness of Chip Architect. FlexRoute...
Hmmm. Can not comment as I haven't used it."
- Himanshu Bhatnagar of Conexant
"Chip Architect -
I spent a lot of time learning design flows for Chip Architect and am
concluding that Synopsys may have missed the boat this time. At the
R&D demo Tuesday night I thought I had the scenario figured out. When
I went to the tutorial on Wednesday morning, the scenario started
falling apart when the speaker said CA was the first hierarchical
floor-plan tool on the market. If they really are the first, they
should have asked why.
Chip Architect has all of the ills associated with doing floor-planning
hierarchically. Strict hierarchical approaches divide the die into
non-overlapping regions with logical and physical bounds necessarily
the same. Doing this limits the floor-planner's ability to move cells
anywhere on the chip. I/O cells, hard blocks like RAMs and cores,
clock buffers, and repeater buffers tend to have strong physical
constraints and need to be placed anywhere on the chip regardless of
of their place in the logical hierarchy. Because of the strict
physical constraints on these blocks one solution is to put cells like
I/O cells and hard blocks at the top of the hierarchy. Doing this in
the logical world makes the interconnect a mess. Changing the
hierarchy in the physical world, which CA can do, messes up the formal
verification. The presenter did not have an answer when I questioned
the impact on Formality, but one of the users in the audience was clear
that Formality could not handle the changes in the hierarchy and I
don't think Chrysalis can either.
Without a lot of scripting to reserve space in blocks for logic from
other blocks it is not clear that Chip Architect is usable to do the
type of floor planning we have traditionally done. It may be usable
to do some of the individual tasks in the process like sub-block pin
placement for budgeting, but I'm not sure I'd want to have our
physical/synthesis process revolve around it. The scenario it might
be usable for is the one we originally envisioned for the next
generation of chips. In this scenario we were assembling chips from
chiplets, which were totally self-contained sub designs with
controlled interfaces and buffered inputs and outputs. If you could
rely on Physical Compiler to do all of the internal chiplet placement,
it might be a viable process, but I would not throw out our proprietary
Vimplan-based process just yet."
- Ken Merryman of Unisys
"Did you notice Aart "promising" discounts on Chip Architect to
everyone? :-)"
- Paul Gerlach of Tektronix
( SNUG 01 Item 9 ) --------------------------------------------- [ 3/28/01 ]
Subject: Tera Systems "TeraForm"
THE SMELL OF BLOOD: Like wolves circling a wounded deer, it doesn't take
much imagination to see Tera Systems TeraForm tool going after the Synopsys
niche left open by a wounded Chip Architect. TeraForm is a hierarchical
design tool that does floorplanning and it drives DC and Silicon Ensemble.
(Sounds an awful *lot* like Chip Architect, no?)
"I would be very interested in knowing whether anyone has tried
Tera Systems "TeraForm" tool. Basically it's a fast RTL-to-physical
design-planning/analysis tool. It's supposed to give you a quick
idea of where your critical paths will be.
One bottleneck I see there would be getting your Synopsys tech. library
converted to their "TeraGate" library.
I'm also not convinced that they can accurately predict the results
of other vendors' synthesis and layout tools. Maybe you can get a
gross "levels-of-logic-between-flops" type of feedback, but I don't
see how their "unique structural abstraction that accurately models
logic, layout, and timing" (quote from their brochure) could be so
accurate. Has anyone found it really useful, and how well did it
correlate with their final synthesis & P&R results?"
- Kris Monsen of Mobilygen Corp.
"TeraForm finds a chip solution at the RTL level and then drives DC
and SE for the detailed implementation of the design. I've done two
designs with TeraForm: 1) a 350 Kgate core with 9 RAMs, and 2)
1.2 Mgates with 64 RAMs. Both designs had many clock and tricky
timing exceptions involved. After floorplanning in TeraForm, I walked
through DC (budgeting, dcsh scripts, set_load & custom WLMs) also
inside TeraForm. It passed the design floorplan on to SE in DEF.
TeraForm lets RTL designers to do early design exploration (timing,
floorplanning issues and power planning) by automatically synthesizing
RTL to their higher level TeraGate components. (These 'TeraGates' are
characterized for our fab's and are not just generic macros.) You
then do 'TeraGate' P&R at that higher level. Timing estimation and
budgeting is integrated with automatic floorplanning (this is what
they call virtual prototyping.) The TeraGates are macros like adders
and multipliers, which gives the system an order of magnitude greater
capacity and faster turnaround times than gate-level tools. It lets
do full chip design exploration very early in the design process at
RTL (before synthesis) to identify the chip level issues.
I've found that this way of designing with TeraForm to be about 10X
faster than doing the same things at gate level."
- Arun Balakrishnan of NEC Electronics
"I have been working with the TeraForm tool from Tera Systems for more
than a year now. Recently I was called on to investigate 2 designs
that were causing some major headaches for our design center engineers
here at LSI. These were large networking chips that were having
problems going through the back end and meeting timing.
With the TeraForm tool I was able in a matter of hours to identify the
same critical timing paths in the RTL that had taken weeks to find with
the traditional methods. I was able to find opportunities for retiming
and resource sharing within the designs and also identify logic that
could be restructured for area and timing improvements.
The tool has a nice GUI, the RTL cross probing and ability to view the
generated schematics and timing all in the same environment make it
easy to explore the design and see where the problem areas are. The
logic structures is presented at a level higher than gate, which makes
it _far_ more useful than gate level schematics. TeraForm provides
sufficient information for you to re-architect and/or re-budget your
design. (In my position, I have to interpret customer designs for
back end implementation.) I see TeraForm as a real productivity gain.
- Gopi Kudva of LSI Logic
"I am a repeated customer of TeraForm. I bought the tool again when I
changed jobs recently. I use it for RTL analysis and design planning
of ASICs. I have used TeraForm on chips ranging from a few hundred
K gates to multi-million gates with clock speed ranging from below
100 MHz to above 200 MHz. I used TeraForm mostly in synthesizing other
people's designs. They give me RTL, I responsible for GDSII.
I've found it useful in identifying inefficient structures in RTL
descriptions. By inefficient structures, I mean logic that eventually
causes routing congestion problems and bad timing later at the
synthesis and place & route stages. Complex MUX or datapath structures
are classic examples; also "memories" - array of array of flip-flops
(basically all large regular structures).
These problems are almost impossible to see by just reading their
original RTL files (those big constructs can often be described in
very few lines of code). By the time I see these problems after going
through the entire backend, it is too late and too painful to change
the RTL. TeraForm let find and fix many routeability and timing
problems in the RTL, before spending any time on synthesis and
place & route -- or at least I am made aware of those problems to
find ways how to deal with them without changing the code.
The tool creates a floorplan directly from RTL and derives routing
and timing information from that. Of course that's not as accurate
as a placed and routed design, but it is close enough to identify most
of those problems.
To create the floorplan, it abstacts the RTL into "TeraGates" which
are basically RTL primitives (Mux, Add, Mult, Register etc.) and makes
a size estimate (e.g. 32 bit wide, slow implementation, strong driver
for fanout/length). It then creates a floorplan by actually P&Ring
those TeraGate elements (iterating implementations and drive-strength
in the process). Simply looking at that floorplan and identifying the
"big" elements and routing hot spots then points out those problems
(e.g.reg[32:0] my_reg[48:0]).
This is the only tool I know of that integrates datapath partitioning
and floorplanning. It's especially useful to find out whether a design
is suited for datapath and whether using datapath actually provides
any benefit. (Often, but certainly not always the case!) In case
datapath does get used, the RTL does not have to be rewritten, as the
resulting design already contains all the instantiations of datapath
elements - next to the rest of the logic which gets synthesized
as usual."
- an anon engineer
( SNUG 01 Item 10 ) -------------------------------------------- [ 3/28/01 ]
Subject: Silicon Perspective's "First Encounter"
MORE BLOOD: And here's a user letter from Texas Instruments directly
outlining a "new PhysOpt/no-Chip Architect flow" using SPC's First
Encounter tool! (Oh, and did I forget to mention in this report that
customers weren't happy with how Chip Architect didn't work?)
"We have quite a bit of experience here at TI in the DSP group with
PhysOpt and have developed a new PhysOpt/no-Chip Architect flow.
One key aspect of the flow is that it includes First Encounter from
Silicon Perspectives. First Encounter is used for the floorplanning
and partitioning of the large designs in multiple blocks; this
partitioning includes accurate timing budgeting and pin assignment.
We evaluated Chip Architect for these tasks but found First Encounter
to be much easier to use and quite a bit faster. Physical Compiler
is used for the block-level implementation -- where block sizes are
usually in the range of 80K gates.
The key element in this flow is the timing budgeting. In our flow,
budgeting is an iterative process, starting with an initial quick
compiled netlist, and a floorplan with power grid and placement/routing
obstructions. Block-level timing budgets are derived from applying
IPO's at the top level of each hierarchical block in the design.
These initial budgets are used to drive PhysOpt from RTL-to-gates for
each of the lowest level blocks in the design.
After blocks are synthesized using initial budgets, a new netlist and
corresponding placements are generated by PhysOpt. This new netlist
consists of IPO's that were done at the top levels of each hierarchical
blocks plus the RTL-to-gates derived for each block that was
synthesized. We take this new netlist through hierarchical IPO and
pin assignment and budgeting again -- but this time the block level pin
assignments will be driven by placements that were generated by
PhysOpt.
We use the budgets generated from this refinement step to resynthesize
the blocks that do not meet timing. If after, repeated synthesis, we
don't get timing closure, it indicates that RTL changes are necessary.
We are in the process of taping out our first chip designed with this
PhysOpt/FirstEncounter flow and have started on a much larger design.
My job is to proliferate this new flow within TI."
- Surendra Mistry of Texas Instruments DSP
( SNUG 01 Item 11 ) -------------------------------------------- [ 3/28/01 ]
Subject: Synopsys NDA "Hidden Dragon" & "SmartClusters"
LIAR! LIAR! PANTS ON FIRE! Aart may be considered trustworthy by the EDA
masses (at least when he's being compared to Rajeev Madhavan of Magma or
Ray Bingham of Cadence), but through a buddy or two or six at Synopsys, I
heard that on the day after his SNUG'01 Keynote Address, Aart went to an
"All Hands" meeting with the Synopsys Physical Synthesis team to discuss
any & all issues with PhysOpt, FlexRoute, and *especially* Chip Architect!
Aart was *presenting* at this employee-only meeting and the Synopsys AE's
who support Chip Architect grilled Aart about what to do about Chip Arch's
extraordinary problems. Aart knew all along about the hideous problems
Chip was having!
And now this story gets more interesting.
Yesterday, Synopsys Corporate sent out a memo to the Physical Support Staff
outlining Chip Arch's troubles and a new product from Synopsys R&D that's
supposed to fix Chip Arch's flaws. And I managed to get a copy of this
memo! (It's up on the "Downloads" section of http://www.DeepChip.com until
the Synopsys lawyers make me take it down! Get it quickly, folks!)
Here's my favorite quote. (KEY: PSS is Physical Synthesis Staff, BU is
Business Unit, CA is Chip Arch, PC is Physical Compiler)
"I would like to thank the PSS field organization for the excellent
feedback received at the last all-hands meeting in Mountain View.
Let me re-iterate that the BU hears you loud and clear. This response
should provide insight into product planning and priorities within
the BU.
We need to address a number of CA issues:
1. Missing or overlapping functionality between CA and PC
2. CA IPO capabilities that never delivered on
the promise of timing closure
3. CTS missing from the flow
4. Complex. Some commands are confusing in CA
5. Performance. Some commands are slow and require too much memory
However, let us not forget that Chip Architect has also had significant
success in the marketplace. Large customers such as Toshiba,
Matsushita, ST and Motorola have all had success with CA. Over 25
customer tape-outs demonstrate that CA can be used in a real-world
production flow. We should recognize that the combination of CA & PC
is providing customers with a compelling solution.
Existing and recently announced solutions from Cadence and Avant! for
hierarchical design continue to be very weak and vulnerable. Start-ups
that are trying to address the issue are providing incomplete and
risky solutions."
- from "PSS_CA_Mar2001_all_hands_response_final.doc"
They're clearly discussing CA's weaknesses and trying to buck up the morale
of the field staff stuck supporting CA. The fix is "Hidden Dragon":
"Project Hidden Dragon
Hidden Dragon (derived from Hierarchical Design) is intended to solve
the most critical hierarchical design problems faced by our most
demanding customers. What follows is a brief 10,000 ft. view of
project Hidden Dragon.
- Delivers a scalable 25M-100M gate chip integration flow.
This flow leverages successful technology from Physical Compiler
for critical phases of the flow in which the netlist is modified.
Physical Compiler "engines" will be used to perform CTS and IPO
at both the block and chip level.
PrimeTime and Physical Compiler engines will be used to build
timing (ILM), DRC, constraint and physical abstracts of a block.
These abstracts can then be used to integrate the complete chip.
This involves optimizing chip level timing, CTS and scan chains.
PrimeTime will use the same abstracts to perform chip-level timing.
- New approach to hierarchical floorplanning that uses the full chip
context to produce high quality floorplans from routability and
timing perspective.
This solution will utilize newly developed SmartCluster technology.
Smart clustering traverses the hierarchy of a chip and retains the
minimum data necessary to create a good floorplan, macro placement
and pin assignment. This approach requires a much smaller
fraction of memory and compute cycles. Initial results show that
SmartClusters offer scalable 10X-1000X improvements in capacity and
runtime as compared to detailed placement. SmartClusters are
placed using Physical Compiler's placement engine to produce
complete chip-level placements of 20+ million gates. This provides
the designer a complete and detailed chip-level view needed for
high quality hierarchical floorplan development.
SmartClusters is being augmented with pin-assignment capabilities
already proven in Flexroute. These pin-assignment capabilities
are being extended from the block-level to incorporate a
hierarchical view of the design.
Based on discussions with some of our most demanding customers, we
believe that this approach will save an incremental 1-2 months from
their design implementation schedules.
The Hidden Dragon project does not impact our commitment to deliver an
integrated standard cell router. This project, Route 66, is on
schedule with details to follow soon."
- from "PSS_CA_Mar2001_all_hands_response_final.doc"
So it appears that Chip Architect is going to be replaced by a *real*
hierarchical design planner that has a 25M to 100M gate capacity, that uses
timing "abstracts" and "SmartCluster" hierarchical data compression and
pin-assignment technology from FlexRoute. Oh, and Hidden Dragon doesn't
impact Route 66's delivery date, either! :)
"Did you notice Aart "promising" discounts on Chip Architect to
everyone? :-)"
- Paul Gerlach of Tektronix
( SNUG 01 Item 12 ) -------------------------------------------- [ 3/28/01 ]
Subject: Physical Compiler (PhysOpt) vs. Cadence PKS vs. Magma BlastFusion
ONE LEAK: OK, so Aart was pummelled by customers for not making any of his
usual 4 or 5 technology leaks in his SNUG Keynote. In general, these
customers were right. Aart didn't leak much -- but he did sublty leak
something:
"In the future, you will be able to compile timing delays due
to crosstalk."
- Aart de Geus, CEO of Synopsys
Knowing that crosstalk can have a big impact on timing below 0.18, this
means that the delay calculations in PhysOpt are going to take crosstalk
into consideration. This means a much better QoR for PhysOpt.
Chip Arch games and tea leave reading with Aart aside, PhysOpt enjoys a
strong lead role in the physical synthesis horse race. Physical Compiler
enjoys (at least) 65 verified customer tape-outs and Cadence PKS demos
devote a lot of time comparing themselves to PhysOpt. (Tells you who
Cadence sees is leading.) Rajeev has serious credibility problems with
his so-called "25" Magma tape-outs. And nobody's mentioned the word
Monterey even once. PhysOpt is in a sweet position as it fits nicely into
the standard Design Compiler flow. "It's just a few new commands" sells
a lot easier than a new flow with a new GUI and God knows who helping you
run the tool. Also the level of customer banter about PhysOpt and Chip
Architect and (to a lessor degree) FlexRoute in ESNUG, clearly indicates
that lots of people are actually buying and *using* Synopsys physical
synthesis tools.
"PhysOpt fits easily in a Synopsys flow. I will have a try on it
(they promised testing licenses). I do not see the use of FlexRoute
or Chip Architect."
- Klaus Vongehr of Philips Semiconductors
"Physical Compiler (or a similar tool :-) is the way of the future, but
I have one major request from Synopsys: to provide free "demo"
licenses, the way they do with DesignWare-Foundation. In demo mode,
PhysOpt should do everything it normally does, except saving the
placement information.
That would allow us, the users, to finally get rid of wire load models.
Without spending an extra half a million per seat, of course. Even the
most optimistic sales rep in Synopsys can't believe that will ever
happen.
In the good old days, it used to be "if Design Compiler can synthesize
with no violations, the layout can be made to meet timing as well".
And Design Compiler was more than a synthesizer, it was the feasibility
proof as well. I want to be in that situation again, and I'm hoping
Synopsys might like to get that role back."
- Oren Rubinstein of Nvidia
"I think PhysOpt should have an advantage over PKS because it uses the
native Synopsys constraints and should have consistent modeling and
timing. PKS & Magma have a whole set of timing correlation issues."
- an anon engineer
"Physical Compiler -
They have added several new switches to PhysOpt including a scan
reordering capability, an ECO mode, and power optimization capability.
PhysOpt can do scan reordering which we have always avoided, but might
be worth looking into as a routability improvement PhysOpt will also
do power optimization simultaneously with timing optimization which
may prove important in our next generation. Both Synopsys and three
Intel engineers are reporting better timing results with RTL-to-Gates
versus Gates-to-Placed-Gates approach although they claim the
improvements are design dependent. The cost of doing RTL-to-Gates
with PhysOpt is considerably more than doing it with DC because of the
considerable difference in the cost of the licenses and the number of
licenses we have for both.
Cadence PKS -
I also talked to the Cadence PKS experts & expressed my disappointment
at the lack of support we got on our initial evaluation of PKS. I've
heard that LSI Logic concluded that PKS did a better job than PhysOpt.
Since we are looking at IBM again, I invited Cadence to help us take a
second look at PKS. One of the main advantages I see now with PKS is
they maintain the hierarchy of the design and do not require
uniquification. Our biggest problem with the current Physical Compiler
process is that it has not been able to totally close on timing yet, so
we still need to do a fair amount of placement work. When we need to
make a logic change after doing the physical work, we have no way of
doing it incrementally. If we could maintain the hierarchy we could
probably use our retain_name program to bring in an incremental change
late in the game."
- Ken Merryman of Unisys
"I benchmarked PhysOpt and got excellent results. I am very happy about
it. I don't see the usefulness of Chip Architect. FlexRoute... Hmmm.
Cannot comment as I haven't used it.
Something very fishy is going on at Synopsys w.r.t. the Clock Tree
Synthesis in Physical Compiler. I asked the question about it last
year and Aart said "Its the top priority and it will be release by
December". This year I asked the same question and got the same
answer. At the R&D night, none of the Synopsys engineers could give me
a clear answer. Is Aart hiding something??"
- Himanshu Bhatnagar of Conexant
"1) Physical Compiler may not be that disruptive to our flow after all.
Synopsys has always represented Physical Compiler as the next evolution
of synthesis. Input RTL, output placed gates. But many presenters
on the subject of Physical Compiler actually used it in a gates-to-gates
mode, and it worked well. Although most thought they would have gotten
"even better" results doing RTL-to-gates, the gates-to-gates flow
was good enough for what had been tough timiing closure problems.
The upshot is that clearly Physical Compiler can be thought of as
a synthesis-aware placement tool as well as a placement-aware synthesis
tool. What this means to us is that PC may not cause the sort of
disruption in the flow that I had been assuming, or at least that the
disruption can be held off for a few more years. In the short term,
we may find that simply substituting PC for existing placement tools
is enough, without changing our flow.
In fact, given PhysOpt's rumored high price, this may well be the
standard model for years to come. We synthesize a netlist, and the
vendor (or COT team) uses PhysOpt & our timing scripts for placement.
2) We need to start paying close attention to where we MUX clocks.
The need for accurate top-level (or at least top-of-hardmacro level)
timing scripts is growing and growing. Design Compiler's capacity
is improving, and tools like Physical Compiler and various
timing-driven placement tools will require accurate timing contraints
at high levels of the chip.
This is a real problem for us. None of these tools can propagate more
than one clock to any given flip-flop. Thus, clock MUXes (which abound
in our designs!) are a real problem. We currently get around this
problem by doing synthesis at a low level (below the clock MUXes), then
running PrimeTime at the top in multiple passes. Physical Compiler and
timing-driven placers need to see the WHOLE timing problem in ONE PASS.
We will need to pay more attention to how and where we MUX clocks in
the future."
- Paul Zimmer of Cisco Systems
"I read some postings on ESNUG referring to the difficulty of using
Apollo as the backend to Synopsys Physical Compiler. We are
particularly having trouble reading PDEF 3.0 into Apollo and we have
tried the various methods that have been suggested (pdef2adb and
Scheme scripts). Do you have any additional information on this?"
- Scott Marvenko, Department of Defense [ This problem was
fixed in ESNUG 367. ]
"One interesting fact from user papers at EuroSNUG on PhysOpt was
that most customers use it in a gates2placedgates mode. It wasn't used
as compiler at all, but more as a timing-driven placer. Only a few
users have fully replaced DC with PhysOpt until now, though you can
get ~10% better results when starting at RTL instead of a netlist.
I guess, Synopsys is pretty much aware of the threat by all those
RTL2GDSII companies."
- Lars Rzymianowicz, University of Mannheim, Germany
"Walter Tuck (from Infineon, San Jose) and I are using the PhysOpt
RTL-to-Placed-Gates flow on a 450 Kgate block (upper two-digits
MHz frequency) in a 1.1 Mgate datacom ASIC. 0.25
That block has very critical area and congestion issues. After
having a lots of problems with PhysOpt 1.21 (fatals, out-of-memory,
no high fanout nets fixing) we now see much better results with
PhysOpt 2.0. Timing fixing, DRC fixing, congestion removal and
scan chain stitching/reordering work pretty well now. Convergence
in the Avant! Apollo backend flow looks like it's going to happen."
- Johann Bechteler of Siemens AG (Germany)
"Synopsys really seems to be on the right track with PhysOpt. I think,
however, that which physical synthesis tool you choose is still tied
to which logic synthesis tool you like best. I mean, if you don't
like what Ambit does then you aren't going to choose PKS. Still,
Synopsys is throwing stuff together and their inexperience in the back
end flows is a concern. The bottleneck is still the place and route
tools. These tools are not yet sophisticated enough to properly handle
0.18 micron (and below) design rules and parasitic problems. You can
loop through a physical synthesis flow until you are old and gray and
still not get it clean if you are actually pushing the technology.
Magma still scares me. Too many claims for too few people over too
short a time."
- Grego Sanguinetti of Accelerant Networks
"Session PhysOpt: Physical Synthesis
Of course this is Synopsys' big push to get us all to buy their
new physical synthesis tool. A magical solution to take you from
RTL to a chip all in one tool. Of course they don't have detail
routing, or clock tree synthesis (yet).
Several user papers were clearly invited from around the world
to discuss physical synthesis. It certainly seems that to use these
tools you have to be much more integrated into the back end flow.
You need a floor plan, you need your macros stuck somewhere, you need
to know where you want your pins. PhysOpt takes your block and
doesn't need any wireload models at all. It just compiles it,
optimizes, places the gates. You also need a floorplanning tool
to figure everything out, then there's the power grid, gettin the
power pins mapped out, figuring out from the top level where the
subblock pins should be, the challenges of physical hierarchy getting
routes scribbled all over it and if you make that exist in your
logical hierarchy.
My basic feeling coming out was that PhysOpt was very cool, and I want
to avoid using it as long as possible. That may not be best for
the chips we make, but it certainly lets me concentrate on designing
scopes instead of chips.
One thing is clear: they've got a lot of customers buying (or at least
trying) this product.
- Paul Gerlach of Tektronix
Another very telling PhysOpt event happened during the "Synopsys R&D Night"
part of this SNUG. During this time we're all put in a big hall with lined
by 18 tables staffed with Synopsys R&D engineers. As usual, for the first
30 minutes, all the customers collected around the food and open bar in the
center of the room. Once fed, though, over 60% of the customers in the hall
crowded 3 deep around the 4 Synopsys physical synthesis R&D tables. The
remaining 40 percent were divided amoung the 14 other Synopsys product R&D
tables. A very telling event.
( SNUG 01 Item 13 ) -------------------------------------------- [ 3/28/01 ]
Subject: Controversial HDL Con'01 Panels, C, Superlog, & Verilog-2000
RIDING THE WAVE: If you're on the ESNUG mailing list, you know I polled
users for extra nasty questions to ask during the "SystemC vs. Cynapps vs.
Superlog vs. Good Olde Verilog/VHDL" panel at HDL Con'01. (FYI -- Goering
reviewed that panel at http://www.eet.com/story/design/OEG20010305S0049 )
After the panel, I asked the audience: "You're a manager leading a design
team to make your company's next chip. It's a typical next chip for your
company -- nothing terribly hard nor easy. Your project starts in 6
months. Which of these methodologies would you use?"
Synopsys SystemC ## 3 (4%)
CynApps CynLib # 2 (3%)
C-Level System Compiler ## 4 (5%)
Co-Design Superlog ############ 22 (28%)
Same Olde Verilog/VHDL ######################## 48 (61%)
It's no surprise that SystemC, CynLibs, C-Level got such low support. What
was surprising was newbie Superlog got 28% of designers willing to take the
technology risk on them. I thought about this for a while and realized that
a number of chip designers blurr Superlog with Verilog 2000. That is, there
are a lot of designers who are enthusiatic about Verilog 2000, and, "Gosh
Golly!, if I can get Verilog 2000 under the Superlog label -- I'll take it!"
Now that Superlog's whipped up all this ethusiasm, it's under painfully
crushing pressure to deliver, and to deliver damn soon. Backlash is a
bitch. Think "Star Wars I: The Phantom Menace"...
"SuperLog (Co-Design Automation - http://www.co-design.com)
* Superset of Verilog2001
* Allows coding in Verilog but provides the headroom to move up in
abstraction and use SuperLog.
* Removes PLI bottleneck by compiling Verilog/Verilog2K, SuperLog,
C/C++/SystemC in a single simulator - SYSTEMSIM.
* Additional constructs targeted for verification planned but not
publicly disclosed yet.
* Extensions to Verilog2K Highlights
- Datatypes similar to C to allow direct sharing of data w/ C
(bit, logic, byte, structures, enum, polymorphism)
- Pointers
- Dynamically sized arrays
- Event Control
always @(written: ), always @(changed: )
continue/break
always_comb, always_latch (implicit sensitivity lists)
- 'process' to send something to the background
- Interface - bundle of wires to pass thru port lists
(Interface is to wires as struct is to variables)
- Parameterizable Text Macros
* Concerns
- SYSTEMSIM simulator performance
Currently a little slower than VCS
Plan equivalent VCS performance in MAY/01
Running SuperLog is faster than Verilog due to higher level
of abstraction.
- Lack of companion tools such as lint and coverage.
- Synthesis support starting with Get2Chip Voltaire product.
Verilog2000:
* IEEE Draft draft available JUN (more likely Fall)
* Enhancement Highlights
- open files increased from 31 -> 2**31
- Multi-dimensional Arrays with full or part selects
- 'generate' statement - similar to VHDL
- 'genvar' variable type used during evaluation of generated
instantiations.
- Enhanced I/O functions
- Re-entrant tasks with 'automatic' keyword
- ANSI-C style port declarations
- Parameter passing by name - only parameters which change
need to be referenced in port instantiations.
- Signed Arithmetic
- ifndef/elsif
- Exponential Operator '**'
- Local parameters 'localparam' keyword - cannot be changed
during instantiation.
- Sensitivity lists: comma separated = 'or'
'@*' eliminates the need to list every single always block
input (automatically includes nets/variables from RHS)
- Attributes '(*' '*)' - remove the need for tools to parse
all comments looking for '//synopsys' for example.
When asked, "What will be the next revision to Verilog beyond
Verilog 2000?", Cliff Cummings (member of IEEE 1364 Verilog Standards
Group) said "SuperLog."
- Jerry Vauk of Sun Microsystems
"SuperLog Tutorial at HDL Con'01
This class was taught mostly by Dave Rich with an intro by Peter Flake.
I would have liked to hear Phil Moorby some but he was not there.
SuperLog is an improvement and an evolution on Verilog. It implements
all of the Verilog-2001 standard (they are fixing some semantic
mismatches now). Backward compatibility with Verilog-95.
Reentrant Tasks - YEAH! Finally! When is Synopsys going to add this
support to VCS???
In Verilog, anything that is passed through a module gets turned into
a wire. In SuperLog if the types match they go through as is.
- Multi-dimensional array support
- packed and unpacked arrays
- Structures and Unions
- Dynamic Types
- Interface definition - This allows a change to the port of a
lower level module without having to change all the wrappers
and modules that the interface goes to before it gets to the
other modules on that interface!!!
*** SuperLog translator to Verilog-95 for a subset of SuperLog has
been released for a while (a year I think) ***
State Machine Syntax - Hierarchical State Machines - I did not
understand this part.
Interface between SuperLog and C++. SuperLog allows 1.) calls to
Verilog tasks from C++ and 2.) Calls to C++ functions and tasks
from Verilog. All that is needed is a simple Superglue file to do
this. Easier to setup than a PLI interface - should be significantly
faster also."
- Dan Joyce of Compaq
"Simon Davidmann is pushing his Superlog simulator as an alternative
to a native Verilog simulator but it does not even run as fast as VCS.
Why would I make the transition to Superlog for questionable language
gains and a loss in simulation speed?"
- Andrew Elms of Nortel Networks
"The philosophy behind SuperLog is to provide a "single language for
hardware, verification, systems." At this point, the language appears
to be focused on modeling as opposed to implementation.
I was expecting to see a description of a modern programming language
that included special constructs to handle hardware-specific issues.
Instead, SuperLog looks very much like Verilog with some C constructs
grafted on top of it. Indeed, one of the early slides states it is a
"superset of Verilog (and Verilog 2000) with the addition of C
programming, system and verification capabilities." While this
approach is comfortable to HDL designers and helps with legacy hardware
designs, it seems that it is quite limiting from the standpoint of HLL
design, true system design and hw/sw design.
Most of the tutorial focused on the new constructs that were available
in SuperLog. There is quite a bit of new stuff and they have provided
a fairly clean path for interoperability with C. However, at its core,
the language is still Verilog and does not have the feel of a powerful
HLL. In addition, I detected a bit of the C++ problem in that there
appear to be multiple ways to perform the same function (leading to
uneccesary complications) and there are a number of constructs that
are non-intuitive, contrary to standard C conventions or are context
specific (again leading to complications and possible confusion.)
Co-Design claims that they have a number of users, but the language is
still under development and they are not planning on releasing it until
the end of the year. Note also that Co-Design has a history of
slipping these dates. To get more information on the language, you
need to sign an NDA. The other aspect of the whole SuperLog package
that was not addressed was tool support. Co-Design claims to have a
simulator for the language (but it is not yet available to the public.)
I find it hard to fathom that SuperLog will gain any traction in the
ASIC community (their target) until they have a good flow to
implementation tools. It seems like Design Compiler support is
critical in this regard. How does this play against the Synopsys
SystemC effort?
Overall, I was pretty disappointed in SuperLog, but it has gotten at
least some good press in the hardware community. How much of this
is the vapor-ware effect is still to be determined."
- an anon engineer
"What does Superlog do which we can't already do with Verilog+PLI+Perl
other than getting me to buy a new simulator & synthesizer?"
- Muzaffer Kal, Consultant
"Superlog seems like a logical step from Verilog. Superlog
doesn't support object-oriented programming features. This
seems foolish to showcase a Verilog-like language without all
of the "marketing bullets" that the other languages have. In
my opinion, Superlog could have killed off all of the other
languages if it had the same features just based on the user
acceptance of Verilog as *the* defacto hardware design language
and we wouldn't have "Spank Janick Bergeron" email threads in
ESNUG. Why wasn't Superlog made object-oriented like the Vera
and Specman E languages?"
- Gregg Lahti of Intel
"I liked having an explicit list of Verilog 2000 features for DC and
VCS from Don Mills. I've been trying to pry the same from Cadence,
so far they've responded with FUD, but no real answers.
In my opinion as soon as VCS and DC support 'generate', Cadence is
going to start losing some customers. I won't use DC features that
aren't simulatable, but I'm willing to act to gain that feature at
least."
- Paul Gerlach of Tektronix
"I can't see us using anything other than Verilog until I can read one
of these formats directly into Design Compiler, and even then it would
be a strectch for us to use something like SystemC. Superlog seems to
be the likely choice just because HUGE investment we have in Verilog."
- an anon engineer
[ The Superlog Tutorial is in "Downloads" at http://www.DeepChip.com ]
( SNUG 01 Item 14 ) -------------------------------------------- [ 3/28/01 ]
Subject: Designers Hate SystemC, CynLibs, & C-based HW Design
NO, THANK YOU: Saying "No, thank you" to C-based HW design is putting it
politely. Of the 92 people who responded to my survey, only 3 (yes, that's
3) users had positive things to say about C-based design. One guy wanted
to be anon, another was from Netrake supporting CynApps, and the third
was Dan Joyce of Compaq because his design group had just finished doing a
C-based design using C-Level's System Compiler. He wrote a paper about it
for HDL Con (it got 2nd place, too, in the conference.) But the C-haters
and detractors have come out of the woodword on this! Of special note are
the Motorola engineers who had used SystemC and wrote me signed letters
telling me how bad C-based design work was. And don't forget the anon guy
from Compaq who also writes about his C-hatred. It's all here in the
customer quotes below.
Oddly, perhaps thinking that water reaches its own level, Synopsys has tied
it's cult-tool-at-best Behavioral Compiler to its disliked SystemC
initiative. (Oh, and before I forget, I just love the Synopsys SystemC
propaganda machine, too. They claim ~15,000 users because they got ~15,000
downloads for the SystemC spec on their web site! Don't you just love the
EDA industry!!!)
"Behavioral Compiler failed. Why do you feel that any of these
SystemC/Superlog/C-based tools will be any more useful and/or
successful than currently available behavioral level solutions?"
- Marquis Jones of Motorola
"C sucks for hardware design. It's not concise nor does it offer
parallelism like Verilog without major revisions. The overhead
provided by SystemC or Cynlib is excruciating to design in."
- Gregg Lahti of Intel
"I am against replacing VHDL/Verilog with C, simulation C, or tools
that translate C into VHDL/Verilog for synthesizing. VHDL and
Verilog are specifically built for hardware. Things like driving
signals with multiple sources are allowed in C. All signals in C
would be global unless restrained. The LRM for C would be heavier
than a boat anchor."
- Jayne Meiners of Texas Instruments
"We developed our latest design using SystemC. Compared to Verilog,
we found SystemC to be:
* Harder to read (especially when trying to deciphers
others' code)
* Slower and more clumsy to write
* Harder to debug (we never had the signals we wanted
in the VCD file and following the signal-flow through
the code took longer)
* Less efficient for re-use since all the old code is
in Verilog
* A steep learning curve for all
* In general, a less efficient design flow than Verilog
"In my opinion, if SystemC makes designers less efficient, there will
be a great deal of resistance to use SystemC. What compelling
advantages does SystemC offer that will make designers want to switch
in spite of the above difficulties?"
- John Rinderknecht of Motorola Labs
"I manage a Hardware (FPGA, ASIC) wireless Modem Design team in
Motorola. Accumulated in my team, we have a few hundred man-years
of ASIC experience.
I do not believe that any additional languages are needed, or that
any can be useful. I have been in this game since 1990 when language
based design started. We tried C, Verilog, VHDL, C++, SPW, Vera,
COSSAP, C++ again and back to Verilog again. From all those, VHDL
gave us the best results, followed closely by Verilog. Using C and
C++ for HW design are a disaster. SPW, Cossap and Renoir reduced
productivity."
- Ron Rotstein of Motorola Wireless
"Why should I take the time to work through your new C tools' bugs,
instead of sticking to the bugs I know and hate already?"
- Jeff Deutch of Avici
"This isn't a C vs. Verilog vs. VHDL thing. When you look at the
papers and boil them down, you'll find that everyone doing C based
HW design are using cycle accurate C models. These are all zero
delay register to register behaviors. This is a battle of cycle
based simulators vs. event driven simulators. I don't care for C.
I like VHDL because it's designed to handle concurrency. C doesn't
do this and it's a pain in the ass to try to artificially make C
work."
- Lance Thompson of IBM Server Group
"The C++ issue is just how many Class libraries are needed, or can
they be combined into one hermongous Class Library? Right now
They've identified a Modeling Class Library (SystemC and Cyn-Aps).
The system vendors are now asking for a Test Bench Class Library
(Cadence's Verification Cockpit). And then you need a synthesis
Class library (SpecC)."
- Gary Smith, Senior EDA Analyst of DataQuest
"Well, why would anyone want to use a serial language C to describe a
parallel design conception? Especially when there are already parallel
description languages like VHDL and Verilog?"
- Carl Wakeland of Emu Systems
"CynApps:
This is the C++ language from John Sanguinetti. It is also similar to
Verilog in that there are constructs that resemble the always@(posedge
clk) and always@(sensitivity_list). Like SystemC it also has a kernel.
According to Sanguinetti this kernel is 32k lines of code vs. 96k lines
for SystemC. So he says it is faster than SystemC. We expect it also
to be around 10 times faster than Verilog.
Approximate Simulation Speed vs. Verilog RTL*: ~10x
Simulation Cost: I don't think you have to buy runtime licenses for a
purely CynApps simulation.
Translator Cost: You buy a translator to get to synthesizable Verilog.
Synthesis Cost: Typical Synthesis tools after translation to
synthesizable Verilog or VHDL
http://www.eedesign.com/story/OEG20010301S0043 is a good article from
EETimes on the use of CynApps at Netrake."
- Dan Joyce of Compaq
"I do not see a future with the C based flows. It is not going to be
easy to get a hardware community to adopt a software language. My
focus is on the verification problem - language is not that big of
a concern. I see Vera/Specman as a forced response to today's
verification testbench problem. They however will not succeed in
the long term for one simple reason - PLI. These languages have not
solved the performance bottleneck of the PLI - they have just provided
a layer of abstraction. By the time I constrain the C language to
something manageable for verification and even more so for design I
would of been better off using a design tailored language.
This is what I see for languages - reference modeling done in C/C++,
design done in Verilog and verification in Superlog. For RTL design
the actual coding is not a real bottleneck. We do a lot of up front
planning and "design before entry" work so that when it comes time to
code the actual RTL you are talking a number of weeks - not
significant in the big picture. The real bang for the buck is the
verification infrastructure. Superlog brings it all together in a
single simulator - no PLI bottleneck. This is a real solution. The
obvious concern here is the performance of the Superlog Systemsim
simulator."
- Jerry Vauk of Sun Microsystems
"I don't think there's anything wrong with Verilog. It was designed
specifically to describe hardware, while C wasn't. You can make C do
it, of course. I remember Mentor had something called "M" about ten
years ago, which was a superset of C.
But my question remains: "what is the problem they're trying to solve?"
- Oren Rubinstein of Nvidia
"Session 1 -- Modeling Systems With SystemC
------------------------------------------
I was left wondering exactly what problem SystemC was intended to
solve. SystemC is basically a C++ library which imparts C/C++ with the
necessary functionality to support hardware simulation. There are 4
"levels" of model supported by SystemC -- UnTimed Functional, Timed
Functional, Bus-Cycle Accurate, and Cycle Accurate. As a design
evolves, the theory is that its model progresses through each of these
four stages.
Version 1.0, which was released in 3/2000, supports constructs to
support describing hardware at the RTL level. However, the presenter
told us that if all we were going to do is code at the RTL level, he'd
stick with VHDL/Verilog, because the tools were better and more mature
than for SystemC. He did claim an order of 10x speed up over Verilog
RTL simulations, but SystemC is cycle based, and I can get that same
speed up by going to a cycle based Verilog simulator. It's very
unclear what, if anything, is gained by coding in C/C++ at this level.
Also, if what you wanted to simulate contained any Verilog or VHDL
blocks, you'd have to write a bunch of PL/I code and then be stuck
doing a C/Verilog (or VHDL) co-simulation."
- Rich Conlin of Paradigm Works
"I took a SystemC 2 day class during some slow time last year, trying to
get a feel for where they're going, how it works, etc. I tried to keep
an open mind and learn how to do this stuff. Now understand that I
have never had a C++ or OO class before. But after 2 days I never
wanted to see C++ again. What misery to have to do all that to do my
job, with no real tools to tell me when I'm screwing up typing the same
garbage into 3 files!!! I am so glad Verilog 2000 has gone to ANSI
style declarations - just write everything once. But C++ has you write
not only 2 times, but in different files! I know this is a very small
part, but it seemed indicitive of the rest of it.
I have great hopes for Verilog 2000 and maybe Superlog."
- Paul Gerlach of Tektronix
"HDLCon 2001
SystemC Tutorial
The SystemC tutorial was taught by Mike Baird. He made some comments
about SystemC that were interesting. I'm not sure I agree with all of
this, but it does give an indication of where the experts, and where
perhaps Synopsys thinks SystemC should and will be used.
1) There is no compelling reason to do RTL design in SystemC. It
really should be used for higher level architectural modeling.
- only makes sense at the system level
- direct support for higher level architectural modeling
2) SystemC Behavioral Compiler path to gates is released, but the
RTL path to gates is in beta now!
3) The decision to do Behavioral Compiler depends on how solid your
design is. If you already have a good idea how your architecture
will look, it makes sense to use RTL design. If you're interested
in exploring some design options, BC is very powerful.
4) SystemC is a cycle based simulator.
- But, there are code options available that are similar to
always@(sensitivity_list) in Verilog. I don't understand how
this is implemented in a cycle based simulator. Mike also
said off-line that the code in the always@(sensitivity_list)
segment may be evaluated several times in a single clock.
That does not sound cycle based.
5) Finally, I have heard simulation speed stories about SystemC that
range from slower than a similar Verilog simulation to 10 - 100
times faster than a similar Verilog simulation. It sounds like
the most likely answer is around a 10x speed-up.
6) A signal class is like a reg updated with a non-blocking assign.
Signals are used to communicate between processes.
7) The three code options are:
a) Methods - RTL
b) Threads
c) Clocked Threads - Behavioral
8) SystemC does not have reentrant threads or destructing threads.
BIG BUMMER for testing!
9) Behavioral Compiler will be the same engine for Verilog code as
for SystemC. Does this mean there is no BC advantage to using
SystemC???
VHDL vs. Sequential C Revised:
This was a presentation at HDL Con on a study saying the C++ will only
be about 5 times faster in simulation speed than VHDL. We have found
otherwise. The guy sitting next to me who worked on our C++ simulator
(which is ABOUT 100 times faster than Verilog) was pouring through
their paper trying to figure out why their C++ was so slow."
- Dan Joyce of Compaq
"I'm using one of the C-based methodologies right now. We had a
complete model of the circuit in C++, so it seemed like the logical
progression. The experience for me as a HW designer (MSEE, 10+ years
VHDL/Verilog experience on many large ASICs) was painful, very
painful. At this point I won't go near it again with a ten-foot
pole unless there's a gun on my head. The constraints are crippling,
the tools seem to be made by and for C programmers with only a
fleeting notion of what HW design is really about - it's a very
unnatural way of trying to get "there".
- an anon Compaq engineer
"Still a lot of hype around C/C++ for hardware design. C-Level Design
had one of the largest booths on the DATE exhibition. Co-Design was
a much smaller one outside the main hall.
My experience: coded Verilog for 4 years now. We played a bit with
SystemC. Trying to write some small modules and simulate them. Didn't
work very well. Every time when I see example SystemC code, I don't
see a big difference to normal HDLs. I guess, with some experience,
you can use it for RTL-level code, but you won't raise your
productivity, etc.
Superlog looks much more interesting. Keep your Verilog knowledge, and
extend it step-by-step with advanced constructs. Which language will
prevail? Well, Co-Design is in a mess here. Keeping Superlog under
the hood gives them some time to develop tools and gain some head
start, compared to big EDA companies. But if they wait too long, the
C languages could have grabbed a significant portion of the market
already."
- Lars Rzymianowicz, University of Mannheim, Germany
"No interest in C. NC-Verilog & Verilog-XL are all we use. Don't see
any value in C-based tools."
- David Hollinbeck of LTX Corp.
( SNUG 01 Item 15 ) -------------------------------------------- [ 3/28/01 ]
Subject: Verplex Tuxedo & BlackTie, Avanti Chrysalis, Synopsys Formality
EXIT WOUNDS: Out of the 27 e-mails I received on Formality, Verplex or
Chrysalis: 22 were pro-Verplex; 5 were pro-Formality; and none were
pro-Chrysalis. Years ago, Chrysalis owned the Equivalence Checking market.
Then Synopsys, with it's walking talking million man sales army, took this
market away from what was then the new Avanti acquired Chrysalis. Then,
stupidly, Synopsys never built a community of users around Formality.
Formality wasn't under any real pressure to improve, so when Verplex came
along with its better tool, the customers very quickly abandoned Formality.
This 22 to 5 ratio of customer e-mails clearly shows how far ahead Verplex
is over Formality is in this niche.
"We tried Formality vs. Chrysalis vs. Verplex, in fall 1999. Only
Verplex did the job, so we stay with them.
- Paul Schnizlein of Agere Systems
"Formality... let's just say there's a severe pain threshold there.
Unless you're a Unix-god and eat kernal code for breakfast, the
terse-ness of Formality's scripting/setup is out of hand. And,
beyond that, they had trouble in the 2 key areas regarding my
criteria for the evaluation. Those 2 items were image size (how much
memory is used) and performance (how long Formality takes to do the job
in real-time). I had to run a couple of scripts to bump up the
allowable image size from the default 2G to 4G (actually 3.8) on a
Sun-Solaris UNIX box, so I could get Formality to read in the full
RTL-vs-gates. Once I got the tool to read in the design, I found it
to be dog-slow, and produced numerous false discrepencies.
I can not comment on Mentor, as I did not eval their tool.
Now to Verplex. Wow! Day one I was able to read in and do RTL-vs-RTL,
gate-vs-gate, & RTL-vs-gate, all under the 2G image limit. I think I
got up to 1.3G. Performance is another positive for Verplex. What
took Formality 6 hours, Verplex did in 2 hours, it was that obvious.
Verplex scripting is straight forward, and has a familiar feel to
synthesis scripting, so you don't have to bend over backwards to learn
it. Their GUI is solid, easy to navigate, and their use of Debussy
for schematic management is a great choice.
I would seriously urge anyone, even those happy with the formal tools
they have now, to at least evaluate Verplex and see what I'm talking
about. We are using it as I write this, to finalize designs upwards
of 2-3 million gates (and still under the 2G image-ceiling). That's
2-3 million gates vs. RTL fully verified. I'd like to know if anyone
else can do that out of the box."
- Mike Bly of World Wide Packets
"Our chip has roughly 5 million gates and 120,000 flops with lots of
memory. It also contains hundreds of multipliers which range from 9x9
up to 15x15 in size. We use Synopsys DC Ultra with DesignWare for
synthesis. All arithmetic elements are created with DesignWare. This
design takes weeks to run even the most trivial gate-level simulations
with VCS. Verplex Tuxedo LEC helped us eliminate costly simulation
time. LEC handles design hierarchy by performing a bottom up
verification to quickly isolate problem areas in RTL-to-gate
comparisons. Modules are simply black boxed as you move up the
hierarchy. Multipliers were quickly verified against the synthesized
DesignWare multipliers. The tool has a graphical mode that allows
for easy identification of miscompares. Cut points can be inserted
into the design to break up large fanin points."
- Andy Adams of RealTime Visualization
"We've never tried Formality, but switched from Chrysalis to Verplex two
years ago. We have found Verplex to be much easier to learn and use.
We also believe that the LEC runtimes are much better. The engineers
really like the link to the Debussy tools, which we also use. Our
Verplex LEC model of use has primarily been gate-to-gate, but we
recently completed a VHDL/Verilog chip using LEC RTL-to-gate."
- Joe Gilray of Agilent
"We started to use Verplex's Tuxedo from the end of 1999. It has
successfully performed full chip equivalency checking on our
Verilog-RTL vs. Scan-inserted-Gate vs. ClockTree-IPO-Gate ~2M gate
netlists. Our runtime: 2 hrs (RTL-gate), 1 hr (gate-gate) on a
SUN U60."
- Jim Lee of Ishoni Networks
"Again referencing my presentation, Formality saved us a lot of headache
during our hand editing phase. The ability to do a gate-to-gate
compare on a 870 Kgate chip in ~ 4 hours was invaluable to increasing
our turn time."
- Tom Tessier of t2design
"Verplex complains about things that Chrysalis blithely ignores. We
almost got bitten really really bad in the week before tape-out (!)
because of that; I'd run some blocks in Chrysalis and some (the tougher
ones) in Verplex. I ran one block in Verplex sort of on a whim for
the first time and discovered that there were pins that were entirely
disconnected in synthesis that should have been connected. Eek!
Fortunately they turned out to not be used outside the block, but
what a scare. I was so impressed that I went back and ran all the
blocks in Verplex. Nothing like more accurate results to motivate
a person to really learn a new tool, I guess.
The problem with Verplex,and why I dragged my feet on really learning
it, is that IMHO it's harder to debug non-equivalent points than it is
with Chrysalis, which is odd considering how much Verplex touts their
usability. I've heard people complain about the arcane nature of
Verplex mapping rules, but I don't think they're really any worse than
Chrysalis's.
What I really wish Verplex had was the ability to trace a signal back
through the source code, or at the very least a list of signals that
are duplicates of the signal under examination. Chrysalis has both,
which I really like (although of course they have their own goofiness
as well -- I'd like to be able to look at signal correlates while
tracing back, for instance)."
- Natalie Overstreet Ramsey of Vitesse Semiconductor
"Chrysalis used to be the top dog, but doesn't seem to have progressed
much since Avant! bought it. I also think they lost their best support
engineers."
- an anon engineer
"We evaluated Formality, Chrysalis, and Verplex. We chose Formality.
So far we are using it mostly for gate to gate comparisons and it has
found some ECO errors for us. So far we like the tool."
- an anon engineer
"Gates-to-Gates: Verplex is good. RTL-to-Gates with DW components:
Only Formality works. (Verplex couldn't do it.) Chrysalis used to
be good, but now Verplex is much faster and easier to use."
- Himanshu Bhatnagar of Conexant
"We've got Verplex, and it seems easy enough to use. It has certainly
saved our bacon a couple times, and makes us a lot more calm in the
final weeks before tapeout."
- Paul Gerlach of Tektronix
"I've just used Formality because that is what LSI has certified. It
has always done an adequate job, but then again I don't know what I
might be missing with the others since I've never shopped around."
- an anon LSI engineer
"Not sure about other tools but used Chrysalis and Verplex's LEC. I
started Formal Verification with Chrysalis and I used to think 'wow'.
However, that was till I got a copy of LEC. LEC is more easier to use,
with a bunch of simple commands. It doesn't need huge amounts of
memory to do the job. It doesn't keep you waiting for hours to get
the result. Also, debugging is much easier with LEC. Don't know how
much it costs now, but it was less expensive.
I think Verplex is far ahead in the race."
- Prasad Lakamsani of Chartered Semiconductor
"I've never taken to Formality. Who in their right mind would use one
Synopsys tool to check another? Again a straw poll conducted under the
influence revealed quite a larege support for my opinion (or maybe I'm
just remembering things selectively). Verplex's Tuxedo seemed to be
the most popular alternate choice."
- Chris Byham of Philips Semiconductors
"BlackTie (Verplex - http://www.verplex.com)
* Formal Static Verification - no simulation necessary.
* Very large capacity - "Full Chip capacity"
* Assertion monitors used in code or in assertion file.
* Open source assertion monitor library supported (OVL)
(http://www.verificationlib.org)
* User can contribute new assertion to library.
* Leverages same assertions used in simulation (OVL).
* Extracts assertions (properties) and employs formal techniques
to prove properties - diagnosis engine presents counter
example.
* Use assertions as target or constraints for formal
* Advanced linting (bus contention, dead code, set/reset
mutual exclusivity, tri-state, range overflow,...etc.)
* Uses Debussy debug environment to debug failures.
* User can define additional constraints to limit state space.
The big benefit of BlackTie is the ability to use the same assertions
in Formal Verification as with simulation. Plus the tool appeared
very easy to use - same pragmas as simulation and Debussy debug
environment.
Now if Verplex and 0-In would get together and settle on a common
pragma that would be an awesome solution. Write a set of assertions
to use with simulation, semi-formal and formal."
- Jerry Vauk of Sun Microsystems
"We chose the Verplex Tuxedo LEC for following reasons
1. The support for VHDL was better.
2. Provides GUI as well as script based interface to fire the run
and debug problems.
3. Almost all VHDL RTL constructs used by coders are supported.
4. Whatever was not supported in the tool came up afterwards as
part of Verplex support.
5. Excellent support by the Verplex support team for the issues
that came up when we were in our learning stage.
6. Good documentation, though needs many more details.
7. Tool is easier to understand with the kind of documentation
provided.
- Prasanna Shah of Acorn Networks
"We will not look at Formality period, since it's from Synopsys. Why
should I pay for a tool from the same company to check the logic
created by their other tool? Synopsys would say the R&D teams are
totally different for Formality and Design Compiler. I would believe
it only if the Formality team is composed only of Russians, Egyptians,
and Iranians, working in a "safe" site in Turkey, and speaking not
one word of English.
Never seen FormalPro yet. Chrysalis works but is clunky and showing
its age. Verplex is the winner for ease of use, speed, and capacity.
- an anon engineer
( SNUG 01 Item 16 ) -------------------------------------------- [ 3/28/01 ]
Subject: Synopsys Design Compiler vs. Cadence Ambit vs. Get2chips.com
OLD FAITHFUL: Yes, Cadence tried it's $260 million Ambit push into the
RTL synthesis market, but Cadence would be lucky if they got back 10 cents
on the dollar for that "investment". Design Compiler still completely
owns that market and even the last ditch "Ambit fire sale" pricing scheme
tried by Cadence didn't change the EDA landscape one iota. Too many
Synopsys customers have too much experience, scripts, and know-how
invested in Design Compiler -- and they rather not risk their chips (or
their careers) on a new RTL synthesis tool. Even the managers at LSI are
afraid to do designs relying solely on Ambit -- and LSI was a big backer
of Ambit before it was aquired by Cadence! Get2chips also suffers from
this lack of real customer interest, too. Why? Because Ambit-RTL and
get2chips are "me, too" tools. The best they can do is to catch up with
DC. PhysOpt, PKS, and Magma is where the real battle is being fought
these days. RTL-to-gates is old news. Yawn. It's in RTL-to-GDSII where
the big money 0.18 um crowd is thinking and going.
On the technical front, Synopsys customers loved the idea of marrying DC
with Module Compiler. Also, judging from the recent bug talk exchanges in
ESNUG and the SNUG trip reports, customers are now starting to use DC's
Automated Chip Synthesis (ACS) add-on tool.
"We use DC exclusively; however we have done signigicant benchmarking
and Ambit kicked DC's ass up and down the street -- 6 months ago. It
was faster (there was no ACS at that point, but even with just one
license a piece) and resulted in better area (usually 7%) and better
timing (2-5%) but could easily meet timing for designs that we had to
manually take through DC. You could just throw the whole design at
Ambit and let it go. DC needed more tweaking and guidance.
So, why don't we use Ambit? A fine question. Mostly because we have
too much infrastructure setup for DC. All the managers want to see
Ambit used on a production design, but only if it's not their chip.
Can you say 'chicken'?"
- an anon LSI engineer
"I was surprised when I came back from SNUG and had a customer request
for new vendor inquiries on Ambit, Get2Chip, and Synplicity in an
ASICs flow."
- an anon engineer
"In my opinion DC is the best and the most complete. Don't have first
hand experience with Ambit. Didn't hear good things about it."
- an anon engineer
"I think Cadence will always suffer from the "scripts need converting"
problem. It is a shame that there isn't a truly generic way to have
a script that would run on any synthesis tool: it would be so good
for competitiveness and spur innovation by other companies. It is
good that get2chip now does Superlog synthesis."
- an anon engineer
"Ambit played their part a couple of years ago, when they forced
Synopsys to make a major improvement in the QoR and compile time.
Now it's the turn of Get2chip to do the same... As for ACS, Steve
Golson's paper showed very good results with it, so it's definitely
worth a try."
- Oren Rubinstein of Nvidia
"When I tried to use Ambit BuildGates a year ago, it was poorly
integrated with Cadence's hodgepodge of tools. It was even a pain to
use standalone, because a lot of the on-line help and documentation
was nowhere near as developed as Synopsys.
- an anon engineer
"Don't know anything about ACS yet, but my past experience with
DC vs. Ambit is that DC was better at forming gate logic and
Ambit was better at optimization (for power or area). In fact some
folks were using DC to get the basic circuit and then optimizing
with Ambit. Having Module Compiler also gave DC the edge."
- Grego Sanguinetti of Accelerant Networks
"Session3: Synthesis and other fun stuff
A couple papers on some synthesis ideas using the currently available
tools (Yay - no Physical synthesis propaganda!)
In Paper #1, Bob Wiegand gave his methodology for keeping area small
while still getting things to pass timing in a 3 pass synthesis
methodology. Some interesting ideas there.
In Paper #2, Steve Golson did some interesting experiments comparing
bottom up to top down, to "simple compile mode", to "ACS", the new
automatic full chip synthesis method from Synopsys. He came to some
interesting points, namely:
1. ACS is promising, it consistently had good timing and area
results. But sometimes took a while to run.
2. "simple_compile_mode" which looks really dumb (you set the mode,
give it ALL your RTL, then say compile) has good run times, area,
and just about got decent timing. In terms of least engineering
effort, this seems to be the way to go as a first attempt. If it
works, ship it!
Cliff Cummings wrote up a summary of fun considerations when designing
multiple clock domains, and getting data across them. His talk
seemed to be a good summary of methods; I assume his paper is equally
good. I'll probably route that one around to the ASIC designers for
looking at."
- Paul Gerlach of Tektronix
"Interestingly enough, we use both DC and Ambit. DC is better at first
time synthesis because it gives the best logic mapping. Later we use
Ambit for both timing analysis as well as ECO's because it is better
in timing, area, and runtime."
- an anon engineer
"As an old-school engineer, I still think Synopsys is synthesis. I've
never really taken to Ambit, especially after the "interesting" results
on a previous chip. ACS (when used with LSF) is a powerful idea that
probably needs more time to mature (cf physical synthesis!!)"
- Chris Byham of Philips Semiconductors
"Verilog-2001 Synthesis
Lance Leong (I think) from Synopsys presented what they would support
in the Verilog-2001 std.
Loops (unrollable) - For and While loops will be treated the same.
Arrays of module instances
Module parameters (defparam m1.n1.param = foo) - you will be able to
access parameters in different layers of the hierarchy
+: and -: added to indexes.
sig[i +: c] is the same as sig[i : (i+c)] - this allows for constant
widths in a bit slice operation.
2 dimensional arrays **!!
$signed and $unsigned conversion functions
Recursion"
- Dan Joyce of Compaq
"DesignVision - Replaces design analyzer - look like a much nicer
interface. Allows you to view the hierarchy of your design and can
show you net from the "report" command. This license is a zero cost
upgrade from a DA license. Available in version 2000.11
"Presto" - new HDL compiler. 5x faster, 33% of the memory of analyze.
To enable this feature use the command "set hdlin_enable_presto true".
Verilog compiler bug - When Synopsys put up a slide to show that they
supported multidimensional arrays in Verilog, they put up the following
example "reg [0:3][0:7]t;" which, according to Cliff Commings should be
"reg [0:3]t[0:7];". Chalk up another Presto bug for Cliff.
New VHDL netlist reader (3x faster than the old one) use the command
"enable_vhdl_netlist_reader = true" to enable it. The command to
invoke it is "read -netlist -f vhdl ". This is off by
default.
ACS - Automated chip synthesis
Acs_read_hdl "top" - Reads all of the HDL files in a given directory
(looks allot like Hsurfer).
Then "source top_constraints.dc" - load you top level constraints
Acs_compile_design "top" - Compiles hierarchically
Acs_refins_design "top" - recompiles design.
Case_analysis - ignore timing to tied inputs. "set_case_analysis 0
[get_ports scan_enable]" to invoke "remove_case_analysis" to undo it.
You can report it with "report_disable_timing".
There is also a clock gating check. "set_clock_gating_check -rise
-setup 1.5 -fall -hold 1.4 [get_clocks ck]" to invoke.
New automatic ideal nets. "set_auto_idea_nets -scan true" to enable.
New balance_buffer command. Has a "-prefer (cell)" option to use a
specific cell to balance a buffer tree.
Module Compiler - works by writing TCL scripts. "read_mcl" and
"compile_mcl" are the basic commands.
DC-Ultra - this license provides you with the following extras:
- Critical path re-synthesis
- BOA Behavioral optimization of Arithmetic
- BRT - Behavioral retiming synthesis, does not work with gated
clocks.
Some new commands "set_ungroup design_c false" (or true) to tell a
subdesign to be ungrouped or stay grouped. Use "compile -auto_ungroup"
to use this command.
"report_timing -attributes" gives the timing attributes on cells.
Synopsys Xilinx Libraries xcb_virtex and xdcs_virtex - Note that
xdcs_virtex results in bad logic for FC2. To get around this Coregen
was used to create multipliers. "hlo_resource_implimentation =
constraint driven" - default "none" fastest.
"hdlin_dont_infer_mux_for_resource_sharing = true", "hdlin_innfer_mux
= default" and "hdlin_mux_size_limit = 256" is used to infer muxes
rather than and trees (last depends on the technology).
Steve Golson paper - Compared several compile modes in Synopsys. Turns
out that the best one was to use "set_simple_compile_mode true -verbose"
to enable it, then just do a compile.
Cliff Commings paper - To ignore setup in synchronizers use the
following command "set_annotated_check 0 -setup -hold -from clk1 -to
xxx/D". In synchronizers you don't need to worry about setup, just
hold violations. Use naming conventions - append the clock name to
fast signals, this makes it easy to set constraints on them. Also
presented a nice section on how gray encoding works.
Timing closure talk - Floorplan manager didn't work due to the lumping
of delays in the SDF on input pins, (which is what most vendors do).
Used Formality and hand edits to fix the design. IPOFIX is a SNUG tool
that finds long nets.
Genove - VHDL timing tool, written in German
"set_proppagated_clock clk" - do this only on propagated clocks, saves
you from doing lots of constraints.
- [ Kenny, from South Park ]
"Design Vision - new GUI with a lot of very nice features. Right now
it only works on sun, not on Linux or NT. Linux support should be
available shortly. We can't use Design Analyzer as a fall back on
the other platforms because we only have Design Vision license."
- Bill Lawrie of InfiniCon Systems
"Cool stuff in DC2000.11/Presto:
I'm really hot to trot for MC in DC. I've waited for the bugs to get
worked out, so I'm skipping straight to 2000.11-SP1 (I believe there
were some issuers with 2000.05). I've used transform_csa extensively
in the past, so I'm familiar with those results. I've been exposed to
the use of Module Compiler for heavy datapath stuff and optimizing the
results in DC, so I'm familiar with those results as well. Combining
the two by using partition_dp on verilog RTL is on the very top of my
hit list, I can't wait to get started.
In the Synthesis highlights in DC2000.11 session, I heard a user say
that sometimes transform_csa gives better results than partition_dp on
smaller paths. I wonder how this can be if partition_dp uses timing
and area constraints while transform_csa does not. I would love to hear
more from that user, please post some specifics on ESNUG! I also heard
that transform_csa will be obsoleted sometime in the future. I hope
this issue is resolved before then!
Another new goodie is the hdlin_use_syn_shifter variable to implement
shift functions with DesignWare instead of gates.
Case analysis is a welcome addition to DC. Of course, you don't want
to compile this way, but it would be great for analysis and debug.
Presto:
I attended the Presto session, and picked up some cool stuff. Presto
will allow the use of the infer_mux directive with if/else constructs.
I asked the presenter what about the Verilog conditional operator
construct (I've been pointing out for years to various designers that
the conditional operator will NOT infer a MUX). I could see the light
go on in the presenter's eyes as he said "yeah, we could make that
work." (John, it's awesome when Synopsys R&D staff members do
tutorials!) I hope to see this feature implemented in the future.
The variable hdlin_vrlg_std can be set to 1995 or 2000 to control the
support of Verilog 2000 constructs.
Cliff Cummings attended this session and was answering questions about
Verilog 2000. The combination of Cliff and an actual R&D person made
this a highly informative and worthwhile session.
Automated Chip Synthesis (ACS):
My presentation this year ("Have Your Cake And Eat It Too: How To
Compile For Area AND Timing") was kind of a part 2 to my presentation
two years ago ("Using MIN/MAX Compile In A Multi-pass Synthesis Flow").
Back then, the idea of compiling in 3 passes, not over constraining,
and fixing holds pre-layout seemed highly controversial. Based on the
Q&A afterwards, and also at the poster session, these ideas seem a bit
more acceptable now. The three pass idea has been adopted by ACS and
could actually become mainstream! I received some particular interest
in the way I use 'characterize' instead of budgeting to refine
constraints between compile passes, and how that effects DesignWare
implementation and area. Some individuals from Intel and some past
and present Synopsys folks involved with ACS were particularly
interested in this.
I've been keeping my eye on ACS and budgeting for a while now.
Budgeting was being developed when I was beta testing DC 9802, so I got
some early insight into it. When the first app note about budgeting
came out, it described a three pass flow almost identical to mine.
I'm not so sure RTL budgeting is such a good idea because of capacity
issues that Steve Golson's presentation pointed out. It may be better
just to stick with the 3 passes.
It was very cool to see Steve Golson's ACS area and timing results
agree with my 3 pass results. I still think I have built a better
mouse trap compared to ACS (no bias here, of course!) since I don't
have to recompile everything for a small RTL change, my capacity is
only limited by the largest compiled design I can read in for
characterization and incremental compiling, and I retain the ability
to pick the smallest implementations of DW that still meet timing."
- Bob Wiegand of NxtWave Communications
I put a copy of both of Bob's DC papers in DeepChip's "Downloads".
The Synopsys CAEs for Design Compiler also did something I thought was
really neat; they wrote down all the customer questions asked during the
DC 2000.11 update and they researched answers for all the questions.
Here's the DC 2000.11 Q&A.
( SNUG 01 Item 17 ) -------------------------------------------- [ 3/28/01 ]
Subject: Synopsys Module Compiler & Behavioral Compiler
MIXED SYNERGY: Quite a few customers were happy to see Module Compiler
married to Design Compiler; it sort of legitimized MC. On the other hand,
Behavioral Compiler is still seen as a cult tool with its small handfull
of devotees. Marrying BC to SystemC hasn't helped matters here -- because
of the strong anti-C feelings running through the ASIC design community.
"Isn't Module Compiler included into the latest DC to do the arithmetic
stuff? I haven't seen datapath stuff done on embedded chips except in
the CPUs. As for Behavioural Compiler, I don't know of anyone who
uses it."
- an anon engineer
"MC is widely used for datapath. Synopsys used to treat it as a step
child, but lately they've been working very hard to integrate it with
all their other tools. I see real progress there.
BC was a nice idea that never caught, except for a very small group of
users. I guess you could call it a cult."
- Oren Rubinstein of Nvidia
"Module Compiler is good tool. If you know your design and architecture
you can do a better and faster job manually."
- an anon engineer
"MC is useable as it stands now (in fact we're in the process of using
it.) BC is too high-tech. Might as well use C-based methodologies."
- Himanshu Bhatnagar of Conexant
"Session 1: Module Compiler tutorial:
This was a Synopsys run session showing some coding tricks to more
optimally use Module Compiler (MC) with their special language (MCL)
based off of Verilog. Since it was meant for MC users, it was hard
to get much from it as I've never seen the tool.
But the language seems to have constructs for describing datapath
machines in a much more efficient way that Verilog. The idea is
to be able to simply describe several architectures and build them
all, so you can choose one. Whereas to describe the same
architectures in Verilog RTL would be a pain and you wouldn't want
to do more than one.
The features seem to be broken into two classes: pipeline control
structures, and arithmetic features.
Pipeline control structures allow you to specify that this piece
of the pipeline should take 2 clocks, this piece is a feedback
loop so it should take 1 clock, feeding into this that... The tool
is supposed to then choose the best pipeline flop insertion points
The arithmetic features allow extensive use of CSA (carry save
arithmetic or Unresolved arithmetic in Slavin language) for adders
and multipliers. special functions for doing clever things with
the unused lsb input of booth encoders, etc.
MCL is not simulatable but the tool will write out an RTL version
for simulation, even though it's main output is gates.
The users in the session and at lunch seemed to like using it,
though there aren't many users. They view it as a tool, they've
accepted it, use it all the time, and take it for granted.
They wouldn't want to use RTL instead."
- Paul Gerlach of Tektronix
"We're very satisfied with the results Behavioral Compiler is producing
and the progress the tool has made over the last couple of years.
With the latest release we see really good quality of results (DRC,
performance, area, CPU run time) and very good correlation between BC
and the subsequent Design Compiler synthesis steps."
- Johann Bechteler of Siemens AG (Germany)
"We just finished an eval of MC. We have a design that runs at 1.2 GHz.
A good portion of the logic is datapath and MC ate it for lunch."
- an anon LSI engineer
( SNUG 01 Item 18 ) -------------------------------------------- [ 3/28/01 ]
Subject: TetraMax, Mentor's "FastScan", Synopsys "BSD Compiler"
A MISS AND A HIT: It's unanimous -- everyone who has worked hands on with
Synopsys' BSD Compiler absolutely detests it. BSD Compiler is reliving the
life of its older brother, Test Compiler, when ESNUG was swamped for almost
2 years with "I hate Test Compiler" customer letters. Now, years laters,
Test Compiler was eventually debugged and became passable -- only to be
replaced by Synopsys TetraMax. For a while Mentor's FastScan tools had a
quiet reputation amoungst those-in-the-know as being the best in class.
TetraMax has jumped into their place within the past 18 months. (The '99
DataQuest numbers give Synopsys 52.2% vs. Mentor 24.0% marketshare. "I
see Physical Compiler driving the dominance of Synopsys in the DFT market,"
said Gary Smith of DataQuest. "and Mentor's marketshare should continue
to shrink.")
"If you are referring to BSD Compiler by Synopsys, our opinion is that
it is terrible. We have told Synopsys this before. In my opinion, it
seems to be a tool that was written by some co-op student given its
completeness. In Synopsys defense, they have shown a good bit of
interest lately in improving the tool (since I told them my true
opinion). However, the tool is so far out from being useful that we
have denied being involved in developing it further. I usually help
out if the tool is at least somewhat close to being useful but in this
case it's not even practical. This tool failed even to write the BSDL
(ie: extract the JTAG and write BSDL) for a test case that Design
Compiler itself generated the JTAG for. That is, we used Design
Compiler and the DesignWare JTAG cells to generate a simple test case
and then tried to extract the jtag and write bsdl using the bsd tool.
It failed even on this."
- Russell Petersen of Scientific Atlanta
"As for Synopsys BSD Compiler, it should be flushed down the toilet!"
- Michael Hede of Conexant
"We use TetraMAX, and have had no big problems so far. Some friends
swear by FastScan, but I don't have direct experience.
We tried an earlier version of BSD Compiler, in January through March
2000, and gave up. We now use Logicvision's JTAG insertion tool. We
like it OK, the advantage is it inserts at RTL level, as opposed to
Synopsys gate level. That allows us to easily simulate, and use formal
equivelence checking. I would not consider BSD Compiler again."
- Paul Schnizlein of Agere Systems
"We used to use Sunrise and then wanted to use TetraMax; however, the
first release of TetraMax was purely for marketing and it couldn't
support the complicated designs that we have. As a result we now use
FastScan and DFT Advisor from Mentor only because that's what we are
fluent with. Our DFT guy really likes them and hasn't ever run into
any significant problems. Note that we do use DCXP to do scan
insertion, but not for stitching."
- an anon engineer
"I prefer Fastscan (or the internal tools from Philips) over anything
Synopsys offers for vector generation. Both sets of tools give more
compact vectors and thus shorter test times than TMax. However I still
believe that if using DC for synth, then using "-scan" on the compile
and stitching the chains using DC/TC is the best approach."
- Chris Byham of Philips Semiconductors
"Fastscan is still the leader in technology since it can handle all
fault models - stuck-at, transition, path delay, and IDDQ. However,
TetraMax is fast catching up, perhaps by year end. TetraMax's
debugging tool beats DFTinsight hands down.
DCXP is only for older or legacy designs. No one should touch it
anymore. Don't know why anyone would bother with something like
BSD Compiler or BSDArchitech (Mentor). It's just a couple hundred
lines of code and once written, can be modified and re-used on many
projects."
- an anon engineer
"We're using TetraMax here. It seems to work. It's very picky about
library models - the parser found holes in the UDP tables for several
of our library cells that no other tool complained about. Probably
this is a good thing, although it took us a while to fully understand
the problem.
Hint to library vendors: Try compiling your library for TetraMax. You
might learn something interesting. :-)
Hint to Synopsys: A little more information for those sorts of library
problems would be nice. Also, how about making the library-parsing
part of TetraMax available freely to all library vendors? End-users
shouldn't have to debug this stuff for them."
- Howard Landman of Vitesse Semiconductor
"I have used both FastScan, 3 years ago and TetraMAX last year. The
TetraMax folks have done a lot to make this tool fast and usable. I
like the control and feedback I get from this tool. From what I have
read, no first hand experience, FastScan has not kept pace. Right now
because of my experience and my client base I would prefer TMAX."
- Tom Tessier, t2design
"LastDay!: DFT, Scan, & Test oh my!
I'm the only one who cares about this at the moment, but...
Synopsys added Test Design Rule Checking to the RTL level, so you don't
need to get all the way through your chip level synth to find out that
your test methodology doesn't work. I found doing test for the [ chip
name ] that it was by far easier to go all the way back to RTL to make
something the tool wants than to try to convince it that all was okay.
This tool should make life much easier.
TetraMax now incorporates the "Full-Sequential" scan ATPG algorithms
from the Sunrise product. (That means not all your flops have to be
scanned, it can handle clocking data across a couple flops, then
scanning it out.)
But they still haven't told me how the heck I'm supposed to decide
what flops to scan and which not to. Or how to tell Test Compiler
that. Sure would be nice if Test_compiler knew what to do and I could
tell it: give me a capture depth of maximum 5. Oh well, someday maybe
we'll get half of the 20% area cost of scan back out.
You can tell Tmax a bunch of vectors you want applied to a block inside
your chip, and it will figure out how to turn those into scan vectors.
This has always been there, and if you can use a parallel test to get
there it's still prbably faster tahn scanning it in.
New features that take new licenses:
1. BSD Compiler: build JTAG logic automatically
2. Iddq vectors: create a vector that is "optimal" for Iddq testing
3. Transition delay vectors ATPG: cleverly make scan vectors look
like at speed tests, without having to pay for an at speed
tester. I didn't quite understand how that was possible, so
needs review if we care.
New in Tmax:
set drc -group_clocks
It's good, and it's not the default. Go figure.
Man, Tmax is cool. Somehow whoever made it convinced Synopsys that
they didn't have to follow Synopsys tool interface conventions. Thank
God for that. Test Compiler is a pain in the butt, I try to hit it
with kid gloves to get something out, and solve all my problems in
TetraMax.
For all you EDA guys out there, look to Tmax for an example of how
online help can be done - connected help to error messages, "What
should I do now" sections on every help page. It has some quirks,
but once you figure out the general way things work, all is well."
- Paul Gerlach of Tektronix
( SNUG 01 Item 19 ) -------------------------------------------- [ 3/28/01 ]
Subject: "FPGA Express" vs. Synplicity vs. Exemplar
MENAGE A TOI: Right now, the FPGA synthesis market appears to be equally
split between Synopsys, Mentor, and Synplicity -- but that's shifting.
"For fiscal year 1999, I see Exemplar having 38%, Synopsys 35%, and
Synplicity 26% market share -- and I'm seeing the Synopsys number
going down and the Synplicity number going up. When you talk to
Synopsys users, they're not using FPGA Express."
- Gary Smith, Senior EDA Analyst of DataQuest
"Regarding FPGA Express vs. Synplicity and Exemplar:
We have a 0.5 million gate design, and in one of our modules we have
an 'if (expr)' condition. Now in this 'if (expr)' the '(expr)' is
so long and was dealing with 32 bit data it caused FPGA Compiler II
to crash during elaboration.
Synplicity on other hand was reliable and generated gate level logic
without crashing. One of the biggest disadvantages of Synplify was
"you can't specify multicycle paths from source to destination".
We never tried Exemplar, and heard a few opinions that it is not upto
par compared to FPGA Express and Synplify."
- Subha Pindiproli of Emulex Network Systems
"We favor Synplicity by a long shot. We were using FPGA Compiler a
while ago and were waiting 2-3 hours for a compile to finish.
Synplicity took 45 minutes with the same QOR."
- an anon engineer
"Xilinx - "www.openmore.com" - IP for FPGA users (not necessarily
vendor specific). Mentor and Synopsys created a FPGA design reuse
manual, which is at www.xilinx.com/ipcenter/designreuse/
- an anon engineer
( SNUG 01 Item 20 ) -------------------------------------------- [ 3/28/01 ]
Subject: Synopsys "PrimeTime" -- Sitting Pretty
QUIET UPSETS: PrimeTime has been the source of some quiet upsets in the
Synopsys user community. First, this year instead of some DC (or possibly
PhysOpt) paper winning the SNUG'01 Best Paper, the winner was a paper by
Paul Zimmer of Cisco on how to handle tricky timing analysis situations
in PrimeTime. In ESNUG recently there have been vociferous debates on real
vs. false monotonic PrimeTime libraries. (See ESNUG 366 #6 & back.) And
the only solid technology leak Aart made this year involved Signal Integrity
comming to PrimeTime.
"I do chip Timing Sign-off with ...
Static tools only ############################################# 91%
Dynamic tools only ############# 26%
Both Static & Dynamic ######## 17%
"6) Signal Integrity -- Here, Aart could only hint at a solution
'soon to come'. This is probably tied in with the detail
router solution to be integrated into Physical Compiler.
Everybody at Synopsys is being notably cautious about
revealing any sort of release date for this stuff. I suspect
it's because they require a major update to their internal
timing engine in order to handle detail routing properly
(ie, integrate the PrimeTime engine into Physical Compiler.)"
- Rich Conlin of Paradigm Works
"3) New cross-talk analysis will force us away from SDF.
Synopsys' proposed method of dealing with cross-talk issues is to make
PrimeTime aware of the effect of cross-talk on timing. What this
implies for us is a move AWAY FROM SDF, since delays can no longer be
thought of as independent of timing constraints (the delay on a net
depends on the *timing* of nets switching nearby). To make use of
Synopsys' cross-talk analysis capability, we will have to move to
something like SPEF files and depend on PrimeTime models to calculate
the timing.
This raises the obvious question of timing accuracy. There was an
excellent paper from LSI on the problems that stem from not having
any industry standard for timing calculation."
- Paul Zimmer of Cisco Systems
"PrimeTime Update
This talk was an extremely detailed talk on the 2001 updates in
PrimeTime. The main improvement is a brand new reduction algorithm
for reading in detailed parasitics, called the "Arnoldi Reduced
Order Model". This model reduces the driving cell into an ideal
voltage source with a series resistance and parallel capacitance.
The R and C values are chosen to give the same characteristic as
the full backannotated RC network for each net. If you read
ESNUG 366 #6, this algorithm has recently been the source of some
heated discussion due to the fact that it requires library delay
values to increase monotonically with increasing capacitive load
(RC-004 error messages). The talk went into quite a bit of detail
on the algorithm.
The talk also introduced a new extracted timing model for hierarchical
timing analysis called the Interface Logic Model (ILM). This is
different from a STAMP model in that the ILM simply removes all the
internal register-to-register paths within the block; all interface
logic (and therefore all the backannotated parasitics for the
interface logic) is retained. It seemed a resonable solution to the
limitations of the STAMP models you had to use in the past."
- Rich Conlin of Paradigm Works
( SNUG 01 Item 21 ) -------------------------------------------- [ 3/28/01 ]
Subject: Tharas Systems "Hammer" & FPGA Protyping
BIG IRON: With all this talk of C and Vera and VCS vs. NC-Verilog, it's
still interesting to see that sometimes SW just isn't fast enough.
Designers Protyping with FPGAs:
SNUG'00 ############### 31%
SNUG'01 ################### 38%
"Talked to the Tharas System guys for a while, I think they have an
interesting solution to the Simulation bottleneck. For the client
I am working with now we have found that the Hardware Modeller is
more of a bottleneck then the software simulation. If somehow the
Tharas box could be directly connected to the hardware modellers
then I think a real solution would emerge for this client."
- Tom Tessier, t2design
"Hammer (Tharas Systems - http://www.tharas.com)
-----------------------------------------------
- Hardware acceleration system
- 10K-100K cps
- Compile times: 10min/1M gate equivalent RTL
- Support for all RTL styles: clocks, latches, PLI
- All signals traceable via VCD
- Supports breakpoints
- Compatible with Verilog, Vera, VCS, Debussy
- Capacity 8M gates
Their "10K-100K cps" was on 8M gate equivalent RTL designs with
1GB memory models.
- Jerry Vauk of Sun Microsystems
( SNUG 01 Item 22 ) -------------------------------------------- [ 3/28/01 ]
Subject: Synopsys Vera vs. Verisity Specman vs. Chronology (Forte)
THE HUNTER BECOMES THE HUNTED: Last year (actually 9 months ago) at DAC,
Verisity made a big thing about DataQuest reporting that Verisity owned
77 percent market share and it was obviously kicking Synopsys Vera butt.
But, like many things in EDA, there was an element of FUD here (it's there
always?) At the June 2000 DAC, the only DataQuest numbers available were
for the 1998 fiscal year. Here's the actual numbers:
Fiscal Year 1998 Market Share
Total 1998 Market: $13.6 million
Verisity Specman & 'E' ####################################### 77.8%
Synopsys Vera ######### 18.5%
Chronology RAVE ## 3.9%
Verisity was touting market share numbers which were 18 months old at that
time. Now the 1999 Dataquest numbers are in:
Fiscal Year 1999 Market Share
Total 1999 Market: $22.4 million
Verisity Specman & 'E' ################ 33%
Synopsys Vera ########################### 54%
Chronology RAVE ###### 13%
So it appears that Synopsys has pretty stolen this niche from Verisity. It
gets more interesting if you do some math. Verisity made .778 x 13.6 =
$10.6 million in 1998 and it made .33 x 22.4 = $7.4 million in 1999 -- they
not only lost market share, they also flat out lost $3 million in revenue!
Needless to say, the Synopsys Vera people are falling all over themselves
with this vindication. They're giddy as school kids. Guess it just shows
the power of having a walking talking million man EDA sales army.
Number of Vera licences sold (as reported by Synopsys)
1998 # 500
1999 ##### 2,500 - *
2000 ############## 7,000
(* - But back in Dec. 1999, they claimed 5,000 Vera users!)
"I got a real kick out of Synopsys trying to have something to say to
respond to Verisity's claim of a Dataquest 77 percent market share.
Bottom line to Synopsys' claim about having more installed seats of
Vera than Specman is that there are a lot of Synopsys sites with bins
of free licenses floating around. You can have the installed license
specsmanship award, Synopsys, but I'd look hard and long at the product
people are actually spending $$ on."
- an anon engineer from the DAC'00 Trip Report
"It's bad enough that we had VHDL/Verilog wars, but I absolutely dread
the Vera/E/Superlog war on top of it. What benefit does the
engineering community gain from additional languages like Vera and
Specman? Why do we need yet another language, and can't we just
extend the predominant one (Verilog) accordingly?"
- Gregg Lahti of Intel
"Session2: VERA - a test language
VERA basically seems to be an extra language that is Verilog-esque but
with some object oriented capabilities. OO is there to try to clean
up your stimulus world, as far as I can tell. Vera also has features
for controllable randomization of inputs. The general idea is to set
up a system in which you randomly apply input to your chip, where
"input" has been defined as a legal bus operation containing some
random data. At the same time a message is sent to an "expector"
routine telling it that you have done so. The expector remembers this,
so that when the response comes back, or later on when you read that
data out, it will check the contents to make sure the right number came
out. It also supports assertions for specifying bus handling to watch
for illegal states.
Looking at our internal simulation environment, I can imagine what a
pain in the butt clever stimulus systems are. Perhaps Vera's type of
OO system protects you from trying to do it all on your own.
However, it's a whole other language, and license. If we wait longer,
Verilog 2000 will add some "real" software features like more private
varaibles, reentrant tasks, etc. Then if the world really goes to
plan, SuperLog will add OO techniques into Verilog anyway. (I talked
to some folks at SNUG saying "all" the people that were on the
Verilog-2000 committee are now on the SuperLog committee, and it's
the "wave of the future!!!!" (Their exclamation points, not mine.))
My opinion is we should be pushing on Cadence to support all
Verilog-2000 features as soon as possible."
- Paul Gerlach of Tektronix
"What is the hold-up to releasing the Vera language specification?"
- Sami Nuwayser of Sun Microsystems
( SNUG 01 Item 23 ) -------------------------------------------- [ 3/28/01 ]
Subject: O-In, Synopsys NDA "Ketchum", & NDA "Verification Analyst"
THREE LITTLE PIGGIES: In my DAC'00 Trip Report, I wrote about O-in and a
Synopsys tool that was shown only under NDA to customers:
"Under NDA Synopsys discussed two related but different tools. The
first one was a tool very much like 0-in called "Verification
Analyst" (VA). What VA does is it has "Temporal Assertions" very
much like 0-in's "Checkers" and an "Observation Based Coverage
Engine" (also like 0-in.) And, just like 0-in, you feed it your
design, your test suite, and your Assertions, and then you play the
20-Question Game to see what situations aren't covered by your test
suite, etc. Verification Analyst was the result of an off-site
brainstorming session with the Synopsys VERA, Covermeter, and VCS
R&D guys. VA's main difference from 0-in is that its Assertion
language is supposedly simpler and more power to use over 0-in;
it can easily traverse hierarchies and handles multiple clock domains
without a problem (or that's at least what Synopsys claims.) Their
other bragging point is that VA will run super fast because it'll
have direct links to the VCS simulator through the Synopsys VeriC/DKI
interface that they discussed under NDA in their demo suite. (Other
tools will have to go through the slower PLI.)"
- from the 2000 DAC Trip Report ( DAC'00 #16 )
What's transpired since then is that "Observation Based Coverage Engine"
(OBC) has become productized into a preliminary next generation code
coverage tool. There was even a customer paper in this year's SNUG'01
proceedings about this tool! (Take a look at "An Improved Code Coverage"
by Jeff Deutch of Avici -- that mysterious 'Z' code coverage tool he's
talking about is Verification Analyst's OBC!)
There was another Synopsys NDA verification tool I outed in that same
DAC'00 report:
"The second Synopsys NDA demo during DAC covered a product called
'Ketchum' (which was named after the Pokemon character 'Ketchum'
who tries to catch all other Pokemons.) Ketchum is a semi-formal
automatic test generator that creates functional (not ATPG) vectors.
It typically focuses on FSMs and can craft a small set of functional
vectors that will test every state in your chips internal state
machines."
The new gossip on Ketchum is that Moto (Austin) and possibliy ST Micro
(Agrate, Italy) are doing the 1st round of alpha testing. I'm told that
the way Ketchum works is Ketchum thinks for about 12 hours on your design
and then spits out a Verilog stimulus file. That Verilog file runs for
2 minutes in your chip's test suite and, voila!, you have 100% functional
coverage (or not.) The actual Ketchum runtimes range from minutes to
infinity. It's *very* alpha. Ketchum uses a Synopsys proprietary assertion
language that's made to work with VCS, Scirroco, Vera, and CoverMeter.
(This assertion language may be opened by Synopsys later.) Synopsys tells
the Ketchum customers that the DW team is using Ketchum for its internal DW
development, but I don't know if that true or not.
On the not-so-secret front, O-in also played prominently at both SNUG'01
and the HDL Con'01 conferences:
"0-In Check/Search (0-In Design Automation - http://www.0-In.com)
* Use 0-In pragmas to embedded checkers in RTL or in separate
file.
* Same (//0-in) checkers used in simulation (0-In Check) and
semi-formal (0-In Search).
* O-In Search is an execution path amplification tool. Provide
seed stimulus and tool will systematically try and find way
to fire checkers by changing the stimulus applied to the design.
* Latches not currently supported - planned Beta @ DAC JUN/01
Now if Verplex and 0-In would get together and settle on a common
pragma that would be an awesome solution. Write a set of assertions
to use with simulation, semi-formal and formal.
- Jerry Vauk of Sun MicroSystems
"Foster's 'Assertions Targeting a Diverse Set of Verification Tools'
won the HDL Con'01 best paper award.
Assertions inserted in the HDL were very powerful and are used in
many verification tools. Harry showed a method that allows the same
assertions in your HDL to be used by many different Verification
Tools: 0-in, BlackTie and others.
More information can be found at http://www.verificationlib.org "
- Dan Joyce of Compaq
"Assertions Targeting a Diverse Set of Verification Tools"
by Harry Foster (HP, foster@rsn.hp.com)
----------------------------------------------------------
* Use OVL assertion monitor library to facilitate using the
same assertions in simulation (0-In Check), semi-formal
(0-In Search) and formal (Verplex BlackTie).
* Modules in assertion library (Open Verification Library - OVL)
were modified to encapsulate the related set of 0-In assertion
directives.
* Pushing Verplex and 0-In to remove this redundancy - one set
of assertions for simulation, semi-formal and formal!
It was the best paper I attended at HDL Con'01."
- Jerry Vauk of Sun MicroSystems
( SNUG 01 Item 24 ) -------------------------------------------- [ 3/28/01 ]
Subject: Synopsys On-Line Support & the Synopsys Hotline
THE MAN IN THE MACHINE: Most people don't know that when Synopsys first
did on-line support, they initially called it SOL -- which was supposed
to stand for "Synopsys On-Line". It took less than a day before someone
told them that SOL also is an old military acronym for "Shit Out of Luck".
Very quickly, they changed to "SolvIt" and then years later to "SolvNET".
Trivia aside, they've added some new Internet ideas to Synopsys support:
"Synopsys support has some new ideas as well. For designers who don't
have access to a dedicated AE, they have a setup in San Jose where
the designer can bring (via CD or ftp) his design files and work on
the problem with Synopsys AE's on-hand to help.
They also are working on using something called "VNC" to allow them
(with the customer's permission, of course) to do interactive debugging
across the net (like HP's SharedX or MS NetMeeting).
This VNC tool is apparently free-ware, & I heard good things about it.
According to their web site, you basically set your display variable to
a virtual display, and you can then grab the display from anywhere."
- Paul Zimmer of Cisco Systems
And here's what the SNUG'01 (San Jose) and EuroSNUG'01 attendees thought:
"1. In an average week, how many hours do you spend using Internet
for activities directly related to your job?"
SNUG SJ Europe
less than 5 hours: 32% 31%
6-10 hours: 49% 48%
10-20 hours: 10% 15%
more than 20 hours: 9% 6%
"2. In an average month, how often do you use SolvNet?"
SNUG SJ Europe
More than once a week: 21% 7%
Once a week: 17% 17%
2-3 times a month: 17% 27%
Once a month: 11% 15%
Irregularly: 34% 34%
"3. What is the most important reason that you visit SolvNet?"
SNUG SJ Europe
Immediate access to
specific problem: 87% 81%
Product research: 9% 11%
Delayed/inadequate response
from Synopsys Support: 4% 4%
Other: 0% 3%
"4. How timely and accurate is the information in SolvNet?"
SNUG SJ Europe
Mostly: 74% 86%
Consistently: 24% 13%
Dated/Inaccurate: 2% 1%
"5. Over the past year, how good a job has SolvNet done at
meeting your online support and information needs?"
SNUG SJ Europe
Adequate: 65% 84%
Excellent: 20% 7%
Haven't used in past year: 11% 8%
Unacceptable: 4% 1%
"6. Which other EDA Vendor Web sites do you use at least once a month?"
SNUG SJ Europe
Don't use others: 47% 23%
Cadence: 21% 29%
Mentor: 15% 28%
Avant!: 8% 11%
Other: 8% 9%
"7. Compared to other EDA sites you visit, how well does SolvNet meet
your information needs and support expectations?"
SNUG SJ Europe
About the same: 20% 18%
A little better: 29% 41%
Much better: 47% 38%
Worse: 4% 3%
Much worse: 0% 0%
As for the Synopsys Hotline itself, no statistics were taken at SNUG'01.
But in ESNUG 366 #1 (the ESNUG post right before the SNUG gathering) at
least one customer voiced some bad experiences. Whether this is a
Lone Gunman or part of an overall user experience depends on what other
users say in response...
"I'd have to say that in nearly every case, my call or e-mail to
Synopsys support personnel has resulted in one of the following
ways:
o "No sir, you are wrong. I won't explain why, because you'd
probably catch a flaw in my logic. Can I please close this
issue?"
o "I need you to spend the next 8 hours of your life putting
together a very large and cumbersome testcase for me, which
probably won't give me any more insight than I already have.
Can I please close this issue?"
o "I'll have to get back to you on that one, I'll call you back in
30 minutes"... (one month later)... "I was just checking to see
if that problem you had was resolved. Can I please close the
issue?"
o "Yes, I think you've found something there. I've submitted a STAR
that will have you up and running again whenever we get around to
fixing that bug. Can I please close the issue?"
o "Yes, that may be an obvious bug, but that's just the way it is,
and nothing can change it. I'll close the issue for you now."
I may sound overly sarcastic here, but all of the situations I
described above have happened to me at one point or another."
- [ Rage Against The Machine ] ( from ESNUG 366 #1 )
( SNUG 01 Item 25 ) -------------------------------------------- [ 3/28/01 ]
Subject: Loving Synopsys LINUX, Cadence LINUX, & Synopsys 64-bit
BY POPULAR DEMAND: Last year customers pestered Aart about busting DC out
of its 32-bit limit. He promised then that it would happen, and at this
year SNUG'01 he pretty much said 64-bit was practically here (give or take
a month or so.) The first on the 64-bit train was PrimeTime because of its
memory chowing nature. PrimeTime 64-bit has been out for a while. Second
to go 64 will be DC. (A lot of people are now extra interested in this
since Steve Golson's paper benchmarking 7 different ways to synthesize a
design.) I'm told that 64-bit DC is in beta and when it's released it'll
be on both Sun and HP workstations. Also 64-bit DC will not be on the
Synopsys 2000.11-SP1 service pack released this month.
The other popular demand on Synopsys is to port to LINUX. Two years ago
at SNUG'99 they announced porting VCS to LINUX as a trial ballon. Now at
this year's SNUG, Synopsys said it's porting all its major tools over to
LINUX. And a month later, Cadence jumped in saying it would now port just
its simulators over to LINUX. ( Goering's "VCS goes LINUX" is at
http://www.eetimes.com/story/design/eda_news/OEG19990329S0014 from two
years ago, and Santarini's Cadence "Me, Too!" for LINUX support simulators
http://www.eetimes.com/story/OEG20000417S0090 from last week. ) The LINUX
ports are in the Synopsys 2000.11-SP1 service pack released this month.
"Our data says that 12.2% of EDA users will be shifting to LINUX
this year. That's a big shift! 5% is a big number for this
metric. How many times have you changed you OS?"
- Gary Smith, Senior EDA Analyst of DataQuest
"6) The Penguin is coming!
Linux is growing. Most Synopsys tools are available on Linux, and
people are using it for real chip development, apparently with very
good results. SGI's booth at the vendor fair featured a multiprocessor
Pentium machine running Linux."
- Paul Zimmer of Cisco
"Our benchmark results finally made it to our public web site:
http://www.sgi.com/manufacturing/eda/linux/performance.html"
- Tony Laundrie of SGI
"I've got a question for you: Both Sun and SGI were showing server
farms for simulation purposes. One uses Sun hardware, the other
PC hardware (runing LINUX). Both claimed the other's product cost
$250K plus but their own was about $100K. Soooo, who's telling
porkies?"
- Chris Byham of Philips Semiconductors
"We are pleased to announce the Synopsys 2000.11 release for the Linux
platform. The release introduces the following products:
BSD Compiler
DC Ultra
Design Analyzer
Design Compiler
DesignWare Developer
DesignWare Foundation & Core Library
DFT Compiler
Floorplan Manager
Library Compiler
Module Compiler
Power Compiler
PrimeTime
HDL Compiler for Verilog
VHDL Compiler
The 2000.11 Linux release is available electronically and accessible
using the SOLV-IT."
- a Synopsys "Dear Customer" letter of 2/16/01
( SNUG 01 Item 26 ) -------------------------------------------- [ 3/28/01 ]
Subject: Synopsys "Eagle-i" -- Lost In The Wilderness
NOT INTERESTED: With all this talk of C/C++ based design, you'd think that
the olde HW/SW co-design tools would be an indication of what the C future
will bring. They're C-based HW design tools, right? Well, if Eagle-i is
any indication, C-based design doesn't look too cheery. They re-org-ed in
Synopsys and just can't get that much customer interest -- and they've been
doing the C game *years* before these "new" C initiatives.
"We got an eval copy of Eagle-i in our company. Eagle-i ran so slow,
it was useless for our software guys. They didn't like it at all.
Now, in our design process we write Verilog. When our SW guys need
what we're working on for their simulations, we tranlate it over
to C, bottom up. SystemC works, but it's ugly. It's a solution in
search of a problem we don't have. We'd rather do our hardware
design in Verilog and then translate it to C at the last minute when
it's needed by the SW guys. Verilog is much more graceful for
hardware design. Translating it to C is easy.
I don't think HW/SW co-design is a driving force in design today.
HW/SW co-design's approach is to blurr the line between what's
going to be done in HW and what's going to be done in SW. In every
situation I've seen, everyone knows where the SW ends and the HW
begins. System designers clear know how to partition HW and SW
from the very beginning of their projects. You don't need HW/SW
co-design tools like Eagle-i."
- Martin Gravenstein of TDK Semiconductor Corp.
( SNUG 01 Item 27 ) -------------------------------------------- [ 3/28/01 ]
Subject: Libraries, SPICE, PathMill, Synopsys "Power Compiler", EPIC
THE SPECTRE OF LAYOFFS: One of the odd things I noticed between this year's
SNUG stats and last year's was a quiet interest in Power Compiler. Last
year 34 people attended the Power Compiler tutorial; this year 68 people
were in that class. This could be a statistical fluke or it could be that
power issues are now beginning to bother designers. I expected the Power
Compiler numbers to stay flat or go down because of all the recently
annouced layoffs in the wireless markets. (Wireless guys are the ones most
paranoid about every damn picoWatt.) But then I remembered the Intel paper
yarping about power issues...
"I attended an Intel presentation on Power Reduction In Datapath
Designs. This paper reiterated the advantages of Power Compiler
RTL clock gating and pointed out that Module Compiler doesn't have
this functionality. Intel worked with Synopsys to define clock
gating requirements for MC, and these features are now implemented
in MC 2000.11. Using test cases from their 3D graphics engine,
they were able to show a power savings of 35-57%, and an area savings
of 5-10%. These numbers are in agreement with SNUG presentations
and tutorials I've seen in the past about Power Compiler.
Anyone competing in an arena where power is important should take a
look at Power Compiler. I have not had the opportunity to use it yet,
but I've been watching it closely for some time now. Since area
reduction is my personal crusade, the area savings from RTL clock
gating has grabbed my attention. Basically, a bank of clock enabled
registers, or perhaps registers with MUXes in front of them depending
on the library, is replaced by a bank of smaller standard registers,
and a single clock gating cell.
By gating the clocks to enabled registers, power is saved by only
clocking the register when new data will be captured. If these
registers are capturing the result of some arithmetic functions, power
is still consumed by the data running through this logic. This
problem is addressed by Power Compiler with operand isolation. Think
of this as "data gating", where the inputs to some arithmetic function
are blocked until the capture registers are ready to capture. Power
Compiler also performs gate level optimization to improve power by
assigning high toggle rate nodes to lower capacitance pins of cells.
Toggle rates are determined with a SAIF input file from simulation.
To complement Power Compiler, a new analysis tool called Prime Power
is now available. To use an olde high school college SAT analogy,
"Prime Power is to Powermill" as "PrimeTime is to PathMill." It's
a full chip gate level power analysis tool.
- Bob Wiegand of NxtWave Communications
"Session 1 -- Library Methodologies
----------------------------------
This was a series of three papers on Synopsys library development
issues. The second one was given by an HP engineer in their PA-RISC
group. They do 0.13u SOI, greater than 1 GHz processor
design with custom libraries. The speaker went through their library
characterization process using PathMill. They only use synthesis
on "less than 50%" of their design. The methodology described was
one which enabled their library to be characterized two orders of
magnitude faster than by using SPICE, and the accuracy was within
+/- 4% of SPICE. Also, since PathMill is their signoff timing
analysis tool, the methodology provides an inherently closed loop.
The methodology indicated to me that synthesis has been in use
at HP for PA-RISC design for some time; this paper described a
process which solved their biggest problem with it, which was
responding to device model changes from their fab in a timely fashon."
- Rich Conlin of Paradigm Works
"Session4: libraries!
A guy from HP presented a method of using PathMill, a transistor
level timing analyzer, to characterize his synthesis libraries.
He covers selection of index spacing, and a QA process to compare
his results to SPICE. His results, +/-4% of SPICE, with 2 orders
of magnitude throughput improvement. (I think he said 200x speed
up in characterization process).
Some other library ideas I got, not necessarily from this guy:
1. Have the first index point be 0. That way really small numbers
aren't extrapolated, they're interpolated. The guy found a
large percentage error when it wasn't.
2. Somehow constrain the tools to not use the cells past the last
index point, once again avoiding extrapolation. I think this
means a careful combination of index selection for library
characterization to define the max point, and then some kind of
constraint in Synopsys to limit those cell's usage to be within
the matrix.
3. Someone (I think Synopsys) said that for slew the 20%-80%
measurement points were better than the 10%-90% because it
was more linear, the extra 20% included too much non-linear
curve.
A Toshiba America guy presented using a low Vth (threshold voltage)
library as a way to make timing. The method was to compile with
normal library, fail timing, then incrementally compile pointing
to a low Vth library that includes power info with Power Compiler
to replace just the critical path cells with these fast low Vth.
His low Vth cells required an extra mask step so increased chip cost.
What do we do with our x2 cells to make them the same footprint
but higher power? It's not Vth is it?
I asked him about using the area number to differentiate between
the two like we do. I don't think he understood, and thought I
was stupid. "No, they are the same area; Yes I know, but I don't
want to buy Power Compiler; But that is the only difference, the
power..."
I skipped the presentation on "Scalable Polynomial Delay Model",
a new method for specifying libaries, other than our non-linear
delay model matrices. I knew I wouldn't understand any of it."
- Paul Gerlach of Tektronix
On the business side, it appears that last year's pain and grief of merging
the EPIC group with the PrimeTime group has subsided. Customers are now
interested in the new ideas that this funky hybrid PrimeTime/EPIC group is
generating (such as PrimeTime now having crosstalk analysis capabilities.)
( SNUG 01 Item 28 ) -------------------------------------------- [ 3/28/01 ]
Subject: The Synopsys 2001 Report Card
SUCCESSFUL CHANGE: Other than that very embarrassing black eye with Chip
Architect, from a customer viewpoint, Synopsys has only messed up in
"sideshow" technologies this year. BSD Compiler's hated by all who try it.
ECO Compiler's a lost tool. Most users don't care for the new Scirocco
VHDL simulator. Formality is still getting it's ass kicked by Verplex.
Nobody's said anything positive about Eagle-i for over 2 years now. Only
one or two people in the world ever mention Protocol Compiler these days.
Behavioral Compiler has only a small cult following (even though it was
supposed to "take over the design world" when it first came out.) Gary
Smith of DataQuest sees Synopsys FPGA tools currently owning 35% market
share but he sees "the Synopsys number going down and the Synplicity number
going up" in the near future. Everybody hates the idea of designing chips
using C/C++ and even the designers at Motorola who actually used SystemC
for HW design went out of their way to write me about how much of a design
disaster SystemC is. Yup, Synopsys has it's share of hurting tools here.
But, other than Chip Arch, none of these are (or ever were) mainstream
"Big Money" tools for Synopsys. That is, SystemC is a failing experiment
right now. ECO Compiler was always a small "specialty" tool. And any EDA
vendor getting any cash out of the FPGA EDA market is a miracle in and of
itself. The mistakes Synopsys has made are mostly sideshows; not key.
On the other hand, Synopsys has made and still makes an awful lot of money
off of many key chip design technologies. Design Compiler owns the RTL
synthesis market. PrimeTime owns the Static Timing Analysis. DesignWare
owns the small IP market. Power Compiler owns its little niche. Module
Compiler owns datapath. Synopsys VCS goes roughly 55-45 with Cadence
NC-Verilog in the ~$110 million compiled Verilog market according to
DataQuest. DataQuest also reports that in '99, TetraMax and DFT Compiler
gave Synopsys 52.2% vs. Mentor's 24.0% market share in the Design For Test
business and "Mentor's marketshare should continue to shrink" according to
Gary Smith. And in one year Vera has come from behind (19% market share in
'98 to 54% market share in '99) to very dramatically overtake Verisity (78%
market share in '98 down to 33% market share in '99!)
The other news this year is Synopsys is crossbreeding its technologies.
Customers gush about Module Compiler being mixed with Design Compiler.
PrimeTime is now using EPIC technology to do crosstalk analysis. Each
DesignWare part has Vera testbenches. "I see Physical Compiler driving the
dominance of Synopsys in the DFT market," said Gary Smith of DataQuest.
VCS has its fast own VeriC/DKI C interface in addition to the PLI. The
Synopsys "0-in" tools (Ketchum and Verification Analyst) are made to
work tightly with VCS, Scirroco, Vera, and CoverMeter. Keep on mixing!
In the physical synthesis horse race, from what the customer say, Synopsys
appears to be the leading pony with its PhysOpt tool. (Yea, customers
trashed Chip Architect in this report, but Chip Arch isn't the heart of
Synopsys physical synthesis -- PhysOpt is. And it looks like Chip Arch
will be fixed or replaced by Hidden Dragon pretty damn soon, anyway.)
In the last *independently verified* tape-out count 3 months ago, Synopsys
had 65 vs. Cadence's 7 vs. Magma's 3 vs. Monterey's 0 tape-outs. From
the outside looking in, Synopsys was winning with by a 10X to 20X lead over
Cadence and Magma -- and Monterey was in trouble. For more recent but
*unverified* tape-out numbers, most engineers believe Aart's new SNUG claim
of 100 tape-outs; they have some doubts about Ray claiming 35 Cadence PKS
tape-outs, and simply don't believe Rajeev's supposed 25 Magma tape-outs.
Strategically, Synopsys has an unfair advantage over Cadence and Magma;
PhysOpt is just some new commands inside a very familiar Design Compiler
flow and GUI. (In ESNUG posts, customers have also verified that PhysOpt
works with the Cadence Silicon Ensemble, Avanti Apollo, and IBM backends
-- plus Route 66 and CTS will probably be ready within 6 months making the
backend issue moot.) Last year, 44% of Synopsys customers were designing
at or below 0.18 um. This year that number has grown to 72% of Synopsys
users! And Synopsys is taping into that. "One thing is clear: they've
got a lot of customers buying (or at least trying) this product," wrote
Paul Gerlach of Tektronix about PhysOpt.
Overall, Synopsys appears to be in a sweet position.
"Why is Aart smiling? Let’s look at the numbers. Fifteen thousand
DC current users transitioning to PhysOpt in two to three years at
an average selling price of $180,000 would mean a total market of
nearly $2.7 billion dollars even without market expansion. You can
play other more conservative scenarios and still come up with
numbers that will make Aart smile."
- Kevin Walsh, VP of Sapphire Design Automation, 12/15/00
============================================================================
Trying to figure out a Synopsys bug? Want to hear how 11,000+ other users
dealt with it? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@world.std.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
|
|
