!!! "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'00 & HDLcon'00"
_] [_ (plus what 38 other engineers saw there, too.)
by John Cooley
Moderator Of The E-mail Synopsys Users Group (ESNUG)
The 10th Annual Synopsys (& EPIC) Users Group Meeting (SNUG'00)
at the Doubletree Inn, San Jose, CA, March 13th - 15th, 2000
( SNUG 00 Subjects ) ------------------------------------------- [ 4/05/00 ]
Item 1 First Impressions
Item 2 Stats On Who Came
Item 3 Attendee Count In Each Class/Tutorial
Item 4 Aart's Big Speech
Item 5 Hierarchical vs. Flat Physical Design
Item 6 Frank Emnett's Power Compiler Paper
Item 7 Verilog vs. VHDL; Initial User Impressions of Scirocco
Item 8 "Symbolic Simulations", Frequency Technology, Ultima ClockWise
Item 9 The Current RTL Synthesis Market & Gregg Lahti's Yugo Speech
Item 10 Tricks & Tips To Create Small Area Designs With DC
Item 11 Users Debate Sign-off & Higher Levels Of Abstraction
Item 12 Avanti Apollo, Cadence Silicon Ensemble, Mentor Calbre
Item 13 System C vs. CynLibs For C/C++ HW Design
Item 14 Superlog's Coming Out Party At HDLcon'00
Item 15 Eaglei, Seamless, COSSAP, SPW, Quickturn, IKOS, Aptix
Item 16 ASIC Prototyping With Actel's ProASIC & Design Compiler
Item 17 PrimeTime & Pearl & Velocity SST
Item 18 Avanti Saturn, Cadence PKS, Synopsys PhysOpt, Magma BlastFusion
Item 19 The EPIC Division Of Synopsys Has Problems
Item 20 Synopsys/Mentor's DFT/ATPG Tools; LogicVision's BIST
Item 21 Formality/Chrysalis OK For Now; Verplex Coming Up, Though
Item 22 The Sun Compute Farm Talk & EDA Machine Use Stats
Item 23 The Year 2000 Synopsys Report Card
( SNUG 00 Item 1 ) --------------------------------------------- [ 4/05/00 ]
First Impressions
-----------------
"The truth is rarely pure and never simple."
- Oscar Wilde, British author, 1854 - 1900
One of the odd things of hearing a retrospective of 10 years of SNUG is not
what they're saying on stage as much as what they're *not* saying on stage.
When that Synopsys exec had us doing a show of hands of who in the crowd
was at the First SNUG meeting, my hand wasn't up. Why? Because, at that
time, I was still embroiled in a very ugly legal battle with Synopsys for
having created ESNUG. It was classic EDA company intimidation. I worked
at a company called Sequoia. Instead of telling me directly in our usual
weekly Sequoia/Synopsys phone call, the Synopsys Legal Department sent a
letter to the CEO of Sequoia Systems (my employer) claiming that I had
"violated the Synopsys/Sequoia NDA agreement" by running ESNUG. How I got
this news was by my CEO standing at my cubical entrance saying "I don't
know what you're doing, John, but you've gotta talk to our Legal Counsel
about this." It was ugly. Very ugly. It turned out Synopsys had no legal
standing because of this silly thing in the Bill of Rights called the First
Amendment, so Synopsys and I eventually resumed our weekly phone calls and
talking bugs. Then, when Sequoia went belly-up and I was laid off, I got a
message on my home answering machine from Synopsys gleefully saying: "John,
you don't work at Sequoia any more. Therefore you're not a legitimate
Synopsys user any more. So our guess is ESNUG is now shut down. Goodbye."
(If you want to view the history of this, watch how my phone number and ISP
changes from ESNUG 86 to ESNUG 89. Synopsys didn't know about non-work
ISPs at the time and was quite unhappy that ESNUG found a new home.) ESNUG
had officially become a guerrilla organization. And although, legally, I
couldn't get copies of Synopsys manuals, users would mail them to me at
home anonymously! I burst out laughing when Richard Goering of EE Times
caught wind of ESNUG and wrote about it. Over night Synopsys suddenly
became more co-operative. The weekly bug phone calls resumed.
On the company front, Synopsys, Inc. was having one hell of a time getting
any users to join the SNUG Board of Directors because it was known it would
be just a "Yes" group completely under Synopsys control.
Eventually, Synopsys management calmed down. They realized I wasn't the
Anti-Christ out to bring Armageddon unto Synopsys, and that maybe, just
maybe, I was just an engineer who wanted to swap bugs, tips, workarounds,
and *honest* user thoughts on EDA tools. So, by the time I made it to the
2nd Annual SNUG Meeting, Synopsys had accepted the idea of SNUG becoming
truly user-driven like ESNUG. Thereafter all Synopsys sales & marketing
were banned from SNUG. CAEs and R&D were very welcome. User papers were
expected to be completely truthful, warts and all discussions. And SNUG
started having customers eager to join the SNUG Board of Directors.
Since that time, I've had more ups and downs with Synopsys, but generally
I've been in this weird role of 1.) keeping Synopsys (and many other EDA
companies) "honest", 2.) making sure the SNUG gathering stays user-driven
(with the SNUG Tech Chair, Don Mills, doing 99.9% of this work), and 3.)
encouraging EDA customers to tell it as it really is every week in ESNUG,
warts and all.
It's funny how these stories don't get told at 10-year retrospectives...
"We have 2000 CPUs on our compute farm running all of SUN's EDA
tools 24 hours a day. About 80 percent of those CPU cycles are
running VCS."
- Pramod Rustagi of Sun Microsystems
( SNUG 00 Item 2 ) --------------------------------------------- [ 4/05/00 ]
The Numbers
-----------
Throughout this year's SNUG'00 Trip Report you'll be seeing all sorts of
statistics flying around. This data comes from the customer survey taken
at the SNUG'00 meeting itself. A total of 305 out of the 474 SNUG'00
attendees responded on this survey. Also, be very aware that all of these
stats have a +/- 6 percent margin of error. This means for every number
you see, the REAL TRUE percentage as projected to ALL SYNOPSYS CUSTOMERS
is within +/- 6 percent of the number you're seeing reported here.
So, these warnings aside, here's the stats on who came:
Design Engineer ############################## 61%
Design Eng. Mgr. #### 8%
CAD Engineer ########## 19%
CAD Eng. Mgr. #### 8%
Academic 1%
Business/Mrktng Mgr. 1%
Other # 3%
The types of companies they were from:
Wireless/Telecom/Modem ############################ 57%
Computers/Peripherals ################ 32%
Semiconductors ###### 13%
Audio/Video/Games/Appliances ###### 13%
Indust./Aerospace/Defence ## 5%
Medical 1%
Other ## 4%
The types of designs these engineers are creating:
Standard Cell / Gate Array ################################ 65%
System-On-A-Chip ################ 32%
Full Custom ##### 10%
FPGA/CPLD #### 9%
PCB # 3%
Multi-Chip Module # 2%
The speed, size, and process of the chips they're designing:
1 - 99 MHz ############ 24%
100 - 199 MHz ###################### 44%
200 + MHz ################ 32%
1 - 100 Kgates ######## 16%
101 - 500 Kgates ############ 25%
501 -1000 Kgates ############## 28%
1 Million + ############### 31%
above 0.35 um ## 5%
0.35 um ##### 10%
0.25 um #################### 41%
at or below 0.18 um ###################### 44%
Their design flow (COT means they're doing their own place & route):
ASIC design flow ############################## 59%
COT Cadence P&R ########## 20%
COT Avanti P&R ########## 19%
COT in-house P&R ### 6%
COT "other" P&R ## 4%
And the fabs and/or FPGAs they're designing:
In-House Company Fab ############### 30%
TSMC ############ 24%
IBM ######## 17%
LSI ####### 14%
Texas Instruments ##### 11%
UMC ### 7%
Lucent ### 6%
STMicroelectronics ## 4%
VLSI, Toshiba, NEC # 3%
AMI, Samsung, Fujitsu,
Charter, Intel, Epson,
Mitsubishi, National 1%
Xilinx ####### 15%
Altera #### 9%
Actel 1%
So, in a nutshell, it was mostly serious, high-end chip designers at last
month's SNUG'00. (A few years ago, I was a keynote speaker at both the
Cadence and the Mentor User's Group meetings. What I found there was these
conferences were dominated by SysAdmin guys and PCB designers -- with very
few actual chip designers attending. I'm proud to say that SNUG had a good
69 percent of its attendees were designers. Cool.)
( SNUG 00 Item 3 ) --------------------------------------------- [ 4/05/00 ]
And you can get a good idea of what these guys are and are not interested
in by seeing how they voted with their feet. All of this data I collected
personally by counting each head in each room in each session:
Monday, March 13 Number Of Attendees
9:00 - 12:15 (MA1) Tutorial on DC, BOA, BRT, WLMs, MC 308
9:00 - 12:15 (MA5) Tutorial of FPGA Compiler II 22
9:00 - 12:15 (MA4) Tutorial on Behavioral Compiler 21
9:00 - 12:15 (MA3) Tutorial on EPIC Tools & RailMill 14
1:30 - 3:00 (TB1) coreBuilder, Asynch Dsgn, Testing IP 103
1:30 - 3:00 (MB2) TetraMax, BIST, ATPG, Scan, DC/XP 117
1:30 - 3:00 (TB2) makefiles, Cliosoft, Synopsys ReOpt 116
1:30 - 4:45 (MB4) Tutorial on EPIC, ACE with VCS 17
3:15 - 4:45 (MC1) OO Dsgn, Dsgn Methodology, FlexRoute 219
3:15 - 4:45 (MC2) Verilog Verification, VCS 102 + 12 standees
3:15 - 4:45 (MC3) Large FPGAs, FPGA Express, FPGA WLMs 31
5:00 - 8:00 Synopsys R&D Cocktail Party Est. 600
Tuesday, March 14
9:00 - 10:15 Keynote Address (Aart's Speech) 327 + 26 standees
10:30 - 12:00 (TA1) PrimeTime, DC, Power 210 + 15 standees
10:30 - 12:00 (TA2) Verilog BFMs, VERA 81
10:30 - 12:00 (TA3) Module Compiler, DC 54
10:30 - 12:00 (TA4) TimeMill, Synopsys SLE, PathMill 16
1:15 - 2:15 (MB1) Soft IP, FPM, reoptimize_design, WLMs 206
1:15 - 2:15 (MB3) OO-VHDL, Behavioral Compiler 31
1:15 - 2:15 (TB4) EPIC PathMill 71
2:30 - 4:30 Panel "Ten Years Of SNUG" 202
4:45 - 5:30 Sun Microsystem's Compute Farm Talk 206
6:00 - 8:00 Non-Synopsys EDA Vendor Fair Party over 500
Wednesday, March 15
8:30 - 11:45 (WA1) Tutorial PhysOpt/Chip_Arch/FlexRoute 216
8:30 - 11:45 (WA2) Tutorial on TetraMax, BSD Compiler 47
8:30 - 11:45 (WA3) Tutorial on Advanced Formality 29
8:30 - 11:45 (WA4) Tutorial on EPIC PathMill 11
8:30 - 11:45 (WA5) Tutorial on Scirocco VHDL 9
1:00 - 4:15 (WB1) Tutorial Special Topics in PrimeTime 137
1:00 - 4:15 (WB2) Tutorial Design Reuse Workshop 27
1:00 - 4:15 (WB5) Tutorial on VCS, Vera, Covermeter 25
1:00 - 4:15 (WB6) Tutorial on System C++ 57 + 9 standees
1:00 - 4:15 (WB4) Tutorial on Power Compiler 34
By looking at which sessions where attendees had a choice, you can see
these designers have a strong interest in: PhysOpt, Chip Architect, DC,
PrimeTime, FlexRoute, reoptimize_design, WLMs, BOA, and BRT. Conversely,
they weren't interested in: TimeMill, PathMill, RailMill, ACE, Vera, and
the new Scirocco VHDL simulator. The "standees" data indicated a surprise
interest (i.e. topics were worth standing for) in: VCS, PrimeTime, DC,
Power Compiler, Verilog verification, and especially System C++. (A
whopping 14 percent of the System C++ talk attendees stood to hear it!)
The overall user attendance for SNUG'00 was 474 customers. Comparing this
to last year's SNUG'99 attendance of 528 customers, you could erroneously
say SNUG (and customer interest in Synopsys) dropped 10 percent this year.
Why would this be wrong? Because in October '99, Boston had its first
local SNUG meeting with 263 customers at it -- explaining the San Jose
SNUG'00 drop. (Oddly enough, Boston SNUG was originally planned with an
attendance of 150 customers in mind; so when 263 arrived, it caused some
serious behind-the-scenes scurrying for the conference organizers!) So,
you could then say that SNUG (and customer interest in Synopsys) grew 55
percent this year (474 + 263 = 737; 737/474 = 1.55 = 55%) -- but that
wouldn't be quite right, either. Apples vs. Oranges and all. So, we'll
just have to track local SNUG stats separately now and leave it at that.
( SNUG 00 Item 4 ) --------------------------------------------- [ 4/05/00 ]
"All tools suck. Some just suck less than others."
- the motto of the unknown physical design engineer
The Bigwig's Big Speech
-----------------------
"The high points of Aart's speech is that Synopsys is going into the
physical space because with deep submicron, it is needed. They now
have an integrated floor-plan manager, top level router, and
placer/synthesis. He said that they would soon have a router this
year. He bragged about 6 designs that were taped out using PhysOpt,
but when John Cooley asked for the names of the companies, Aart just
said that they were from the same family as most of the ESNUG posting,
Anonymous! He showed slide that compared 1st pass timing from a chip
that was synthesized with Design Compiler, and placed/routed with Avanti
P&R to a chip that was synthesized with PhysOpt, and routed with Avanti.
The Design Compiler results had a few nets that were broken by -3.2 ns
(200 Mhz system clock), and quite a few (in the 100's) that were broken
by -2.3 ns. The PhysOpt results had just a few nets broke by -0.64ns,
and most meeting timing. Aart also mentioned that they are also adding
clock tree synthesis to their new physical tools. He also said that
the COSSAP tool will be replaced this year, and its custom input
language will be replaced with SystemC. He also strongly hinted at a
SystemC to RTL/gates synthesis engine."
- an anon engineer
"Why did Aart de Geus hype up verification as one of the 3 key problem
areas facing customers and yet not hardly even mention Vera? Vera is
the only tool in his arsenal that has any hope of making major
improvements in verification productivity. You may not agree, John,
as many engineers do not, but as someone who has used Vera I am quite
confident that it at least contains the seeds for significantly
advancing the state of verification today. I thought it was a glaring
omission. Should I buy stock in Verisity?"
- an anon engineer
"Where, oh, where did my sweet VERA go? In Aart's speech, VERA was last
year's big news. This time around, VERA hardly got a mention. Just a
little bubble on the side of one of his slides. Is VERA the 90 miles
per gallon carburetor that Synopsys bought but will put on the shelf?
Seems Art and Synopsys are going to push SystemC instead."
- Peet James of Qualis Design
"Most out-to-lunch quote? Aart's comment that we'll all be writing our
ASIC code in SystemC, so we better prepare ourselves professionally,
was pretty out-to-lunch. Didn't Aart tell us 4 years ago that we'd all
be writing Behavioral Compiler code by now?"
- an anon engineer
"Synopsys is once again trying to increase the level of abstraction in
product development from RTL to higher level languages. Aart's latest
attempt (after the failure of Behavioral Compiler to catch on) is
SystemC. Aart made an non-announcement announcement that Synopsys
would be offering a tool to synthesize SystemC into gates by the end
of the year."
- an anon engineer
( SNUG 00 Item 5 ) --------------------------------------------- [ 4/05/00 ]
RELIGIOUS WAR RESOLVED: If you've been reading ESNUG for the past 3 or
so months, one of the recent contentious issues that's come up within the
backend Place & Route community has been between working hierarchically
versus in a flat mode. The SNUG'00 survey asked about this and got:
Flat Only ########## 20%
Hierarchical Only ############ 24%
Mixed (Flat & Hier.) ############################ 56%
Average Number
Of Blocks At Top Level: 12 (with 34 percent saying 15+)
A total of 80 percent of physical design is done either hierarchically or
in a mixed flat & hierarchical mode with 34 percent of designers saying
they have over 15 blocks at their top level. Case closed.
( SNUG 00 Item 6 ) --------------------------------------------- [ 4/05/00 ]
"Frank Emnett's presentation on Power Reduction Through RTL Clock
Gating with Power Compiler was the most impressive one I saw. He
achieved a 50 percent reduction in power without changing his RTL!
I'm impressed and will now consider Power Compiler where I was never
much interested before. According to Synopsys, Formality supports
equivalence checking with RTL clock gating as well."
- an anon engineer
( SNUG 00 Item 7 ) --------------------------------------------- [ 4/05/00 ]
ANOTHER RELIGIOUS WAR REVISITED: The Verilog/VHDL SNUG'00 user stats
clearly give Verilog dominance in the North American market. When the
EuroSNUG'00 data comes in, this might be another story -- but since
Europe only accounts for 19 percent of the World EDA market (Dataquest),
it's not *that* much of a change in the story. The SNUG'00 user stats:
Only Use Verilog ########################### 54%
Use Verilog & VHDL due
to IP purchase/reuse
or another design team ######### 19%
Write RTL in VHDL,
Gates in Verilog ###### 13%
Use Both For Other Reason # 2%
Only Use VHDL ####### 15%
And the tools they used:
Synopsys VCS (Verilog) ################### 38%
Cadence NC-Verilog ############ 24%
Synopsys Vera ####### 15%
Synopsys VSS (VHDL) #### 9%
Cadence NC-VHDL ### 6%
Synopsys Covermeter ### 6%
ModelTech, which would probably have made a very good showing here, wasn't
in the survey because we were interested in the UNIX EDA used to design
the big chips. (When you're designing 0.18 um, 300 Mhz, 3 million gates,
you not using ModelSim and PCs no matter how nice you think the GUI is!)
"Ofek, Smith and Collett agreed that Verilog is here to stay, but
noted that VHDL is growing much faster. Collett predicted that the
VHDL and Verilog simulation markets will be roughly equal in 1994,
and that toward the end of the decade, the HDL market will be around
60 percent VHDL and 40 percent Verilog."
- Richard Goering, EE Times, May 2, 1994
"Not interested."
- an anon engineer on the new Synopsys Scirocco VHDL simulator
"Does Synopsys have any credibility with VHDL simulation? I'll believe
it when I see it. We've been using ModelTech/ModelSim almost
exclusively, despite owning dozens of VSS licenses."
- an anon engineer on the new Synopsys Scirocco VHDL simulator
"8:30 - 11:45 (WA5) Tutorial on Scirocco VHDL 9"
- the number of attendees at the Scirocco VHDL tutorial
"Right now, there's no real meat to SystemC, and yet we have to be
planning NOW for the next-generation verification methodology. So
SystemC is a Sword of Damocles which will chop off any residual interest
in dedicated verification languages like Specman and Vera, dooming them
all to orphan status, while itself remaining unrealized for the
foreseeable future. We'll be left with self-checking HDL benches or
C-language hacks for the next two years. Gack!"
- an anon engineer
"On Verilog versus VHDL: imagine all those years ago if we had one
language instead of two. Think if all that duplicated effort could
have been directed towards one language. How much further ahead would
we be today?"
- Aart de Geus, CEO of Synopsys, in his SNUG'00 keynote
"VHDL is one of the biggest mistakes the Electronics Design Automation
industry has ever made. A $400 million mistake. Wouldn't this money
have been better spent on handling submicron design, testability
issues, or even a new type of HDL that had significantly more
capabilities than what Verilog and VHDL offer today?"
- Joe Costello, then the CEO of Cadence, in his 1995 OVI keynote
( SNUG 00 Item 8 ) --------------------------------------------- [ 4/05/00 ]
FUTURE SHOCK: One odd discoveries I made at HDLcon'99 was a lone vendor
booth in the hallway by Innologic Systems. I didn't quite fully understand
what they were saying about doing "symbolic simulations", but in my gut I
felt the same way I felt when I visited my first formal verification
equivalency checking booth years ago. (And now equivalency checking is a
mainstream part of many large chip design flows!) Check this "symbolic
simulation" stuff out at: http://www.innologic-systems.com and tell me
what you think.
"Worst Booth: Frequency Technology. I think they must have a very
interesting product, but couldn't learn anything from the booth."
- an anon engineer
"Biggest lie? Don't know, because Cadence wasn't there. (Yes, it's a
cheap shot but they deserve it.)"
- an anon engineer
"At the vendor fair I saw a tool from Ultima called ClockWise. Caught
my attention as a stand alone clock tree generation tool since Chip
Architect/PhysOpt does not have this capability yet (but will soon).
However, this tool claims to be able to use clock skew as an advantage,
moving the clock edges to fix setup/hold times. Their idea both
intrigues and scares the hell out of me. This would have very serious
implications on hold violations on scan flops."
- an anon engineer
"Hmmm... You bought LEDA for RTL DRCs. OK, I'm listening. Talk to me."
- overheard at the SNUG'00 R&D night
( SNUG 00 Item 9 ) --------------------------------------------- [ 4/05/00 ]
NO NEWS HERE: The SNUG'00 user survey stats on the mainstream Synopsys
synthesis tools yielded no news. Synopsys still owns RTL synthesis.
Synopsys Design Compiler ######################################## 81%
Synopsys DesignWare ################## 37%
Cadence Ambit Synthesis ### 7%
Synopsys Library Compiler ######### 18%
Synopsys Module Compiler ######## 17%
Synopsys Power Compiler ###### 13%
Synopsys Behavioral Compiler ## 5%
One interesting thing to note here, though, was that roughly 20 percent of
Synopsys customers used Library Compiler. Users would only have this if
they're a foundry or that they're doing full Customer Owned Tooling (COT)
designs (i.e. they're going from RTL to GDS II in house, so they make
their own Synopsys .lib files).
And, yes, Behavioral Compiler is still a cult-following-only tool as it was
last year and the year before and the year before that.
One of my own stats I've been tracking on my own has been:
Known Number of Synopsys
Design Compiler Licenses
In Actual Design Use: ################################ ~ 16,000
Known Number of Cadence
Ambit Synthesis Licenses
In Actual Design Use: # ~ 360
Cadence claims 120 sites using Ambit and assuming there are, on average, 3
licenses per site yields 360 active Ambit licenses. And while 300 Ambit
users is confirmed by Missing Elf Analysis (see ESNUG 339 #11), the Cadence
claim of 1,500 active Ambit users doesn't stand up under such scrutiny.
Why I track this stat is because I'll occasionally get a phone call from
a customer or a Wall Street type asking about Cadence Ambit taking over the
RTL synthesis market from Synopsys because Ambit's cheaper. I tell them
that stat and then give them my patented "Gregg Lahti Yugo Speech" -- which
basically boils down to the true cost of RTL synthesis tool (or any EDA
tool for that matter) isn't just the software price itself, but:
1.) MOST IMPORTANTLY: Does the new tool produce significantly better
(greater than 20 percent timing reduction) results to justify
the switching risk? If not, exactly why are you risking your
project schedule on this new tool? Who is sleeping with which
one of our people to get us to use this tool?
2.) You gotta pay/schedule for ramping-up the learning curve.
3.) You gotta pay/schedule for bug chasing & debugging time. This
is always much higher with new tools. (See Question 1)
4.) Is there a pool of experienced users around? What happens
when you're in trouble and those really sharp pre-sales tool
support people who were around when you were about to sign the
Purchase Order are long gone? What type of ugly schedule hit
is this going to be? (Again, see Question 1)
5.) How many fully tested/debugged ASIC libraries are there? Has
your fab actually fabbed customer designs with this tool or are
you the one on the bleeding edge? (See Question 1)
6.) How many real life chip designs have taped out with this tool?
7.) What about scan, ATPG, testing issues? (See Question 1)
8.) What about static timing issues? (See Question 1)
9.) Do the people in the selling EDA company really KNOW the tool
(inside and out) or is it a tool they acquired? (See Question 1)
10.) What about other related 3rd party EDA tools -- do they work
well with the new or old tool better? (See Question 1)
11.) See Question 1.
Switching from Design Compiler to Ambit is like switching from Windows'98
to IBM OS/2 on my laptop computer -- what do I gain and what do I lose by
doing this even if IBM *paid* me $100 to use OS/2 ??? Most chip designers
clearly know the true costs involved and only use the pseudo-threat of
switching over to Ambit as a bargaining chip w/ Synopsys at renewal time.
"Price isn't everything, or we'd all be driving Yugos."
- Gregg Lahti of Intel from ESNUG 333 #2
Now if Ambit *DID* get greater-than-20-percent-timing improvements over DC,
THAT would be another set of questions altogether! Then, the questions
would be: "When can I get the Cadence sales-sleaze in house?" and "How long
will it take for us to get an Ambit Purchase Order processed?"
And for me personally the questions would be: "OK, John, how long would it
take to convert ESNUG over to AmBUG -- that new widely read Ambit Users
Group e-mail newsletter?" and "How can I get more chummy with Ray Bingham,
that absolutely brilliant new CEO of Cadence?" (Freelance consultants like
myself owe loyalty to no one but to whoever owns the best technology.)
The real battle in the EDA world isn't in RTL synthesis; it's in physical
synthesis. Because that's where we're going to find those super sexy
greater-than-20-percent-timing-improvements for our big designs. So for
now, ESNUG is still ESNUG.
"The 1998 ASIC synthesis market breaks out to:
Synopsys: 91.1 percent
Ambit: 8.7 percent
Avanti: 0.1 percent
Magma: 0.0 percent
These are revenue numbers, not licenses."
- Gary Smith, Dataquest EDA Analyst
"It's good to see the second generation Ambit synthesizer on the
market. The funny thing is that it's Magma who is selling it. All
but two of the Ambit developers each took their half million Cadence
cash buyout and walked off to Magma. Kind of funny to see this.
Cadence can't negotiate acquisitions worth shit."
- an anon observer
( SNUG 00 Item 10 ) -------------------------------------------- [ 4/05/00 ]
"Here are the commands Synopsys stressed to create smaller designs:
set_max_area 0 - Since version 1998, area optimization is not carried
out unless this constraint is set.
hdlin_infer_mux = "all" - This allows mapping to MUXes. Synopsys
assumes that most cell libraries best tuned and area utilized
cell with the MUX.
hdlin_infer_multibit = "default_all" - This allow the use of library
cells that have multi-bit components (registers, MUXes...)
hlo_resource_allocation = area_only - Only use for designs that have
non-critical timing.
hlo_resource_implementation = area_only - used together with the above
transform_csa - will convert an add array (a+b+c+d+e...) to a
csa tree to reduce logic, and create a faster design.
set_simple_command_mode true - generate a faster compile, reduces area,
should not uniquify design. (Again, only used for timing
critical designs.)
compile -map_effort med -area_effort high - now the compile has an area
effort switch. Note, that if map_effort is high will
automatically set area_effort high.
compile_sequential_area_recovery = true - Remaps all sequential cells
to recover area.
set_dont_use {list of high drive cells} - only do this in the first
compile... Allows initial mapping to use lower-drive cells,
will reduce runtime by eliminating cell downsizing.
ungroup - removes hierarchy, and could possibly reduce size.
compile -boundary_optimization - optimize across boundaries.
compile_new_boolean_structure - enables new boolean structure.
set_structure true -boolean true - Must go with the
compile_new_boolean_structure. Reduce area of don't care
logic by using logic reduction techniques.
I liked this particular tutorial a lot. It was full of useful tips."
- an anon engineer
( SNUG 00 Item 11 ) -------------------------------------------- [ 4/05/00 ]
"People are missing the point here. We need levels of abstraction to be
removed -- not added! In the not too distant future we'll need
RTL-level sign-off and we'll also need good RTL-level power, area, and
timing estimation tools."
- Steve Golson of Trilobyte Design
"We already do RTL sign-off today. It doesn't make sense that every
designer knows synthesis details. We just have one engineer in our
group that does that and the rest of us write the Verilog RTL."
- Paul Zimmer of Cisco Systems
"The status right now is we're at 55 bits."
- Aart de Geus, CEO of Synopsys, joking about 64 bit Design
Compiler coming out by the end of the year.
( SNUG 00 Item 12 ) -------------------------------------------- [ 4/05/00 ]
WE PLAY BOTH COUNTRY AND WESTERN MUSIC: To the great glee of the Synopsys
physical synthesis marketing droids, the backend place & route world is
still very much evenly split between Cadence and Avanti. (They just love
this because PhysOpt is the only physical synthesis tool that's compatible
in both the Cadence and Avanti backend flows.)
Avanti Apollo ########### 23%
Cadence Silicon Ensemble ########### 22%
Avanti Star Tools ###### 13%
Mentor xCalibre #### 8%
Avanti Milkyway Database ##### 11%
Avanti Taurus 1%
Cadence Dracula ########### 22%
Avanti Hercules #### 9%
Synopsys EPIC CoreMill 1%
Mentor's Calibre was missing from the SNUG'00 user survey, but it easily
owns the physical verification (i.e. tools that check GDSII plots for
errors) market. According to Dataquest's 1998 numbers, Mentor's Calibre
had 40 percent, Cadence Dracula 29 percent, & Avanti Hercules 28 percent
market share. EPIC CoreMill wasn't on the radar screen back in 1998, and
it still wasn't noticed now in 2000.
"So now we know we've got a cross-capacitance problem, and we know we
can't just blindly jam buffers in to fix it, so what do we do? We go
check out the signal integrity option on Cadence Silicon Ensemble.
The best thing I can say for SE is that it runs without crashing.
Here are the problems we've found:
1. The parasitics coming from HyperExtract are up to 200% off
compared to 3D field solution. A chimpanzee throwing darts
at a diagram of parasitics could do better.
2. It's flagging over 1000 noise violations in a few hundred K
gates of logic. Over 1K noise violations in < 9mm^^2 of
randomly routed die? Gimme a break! Simulation showed that
SE was over-estimating noise by > 100%. It was using a slew
rate less than half of the actual slew rate. Its hard to say
how many real noise violations are in there, but my simulations
are saying my usual layout topologies ought to give me < 10
noise violations per 100K gates *usually*. Not 1000!
3. The repair file isn't. I'm still playing around with this to see
if other PBopt options might get me a better repair rate, but so
far I'm still left with A LOT of xcap timing and noise violations
reported even after I run through the check/repair flow a couple
of times. Given that these results are based on the HyperExtract
parasitics that I know to be bogus, I'm not really motivated to
run this into the ground. To me, the whole solution has the feel
of something that isn't going to gel.
Lesson learned: Just because your EDA or ASIC vendor shows you a
pretty drawing of a flow, don't buy it until you see the parasitic,
noise, and delay modeling correlation. Cross-capacitance isn't like
bringing a router up where the right values for metal pitch go a long
ways towards getting you something reasonably DRC clean. Cross-cap and
noise really require some tuning before you get back something clean."
- [ Born To Run ] from ESNUG 348 #6
"Give me 2 million gates flat and one Avanti license. I'll give you
a fully laid-out design."
- overheard at SNUG'00 conference
( SNUG 00 Item 13 ) -------------------------------------------- [ 4/05/00 ]
FROM C TO SHINING C: So far there are at least 4 major initiatives to make
a C Standard for HW design. C-Level has one from EASICS; SpecC is from
U.C. Irvine & Toshiba; Synopsys has System C; and CynApps has CynLibs.
Each is backed by an endless list of companies and Motorola appears to be
backing them all! Here are some of the details of system C. It is class
libraries for C++ that allow hardware to be modeled. It uses standard
C/C++ development along with the class libraries, and C/C++ source to
produce an executable which is your simulation. That simulation can run
on any platform. The key classes are:
Concurrency - processes (sync and async)
Communication - signal, channels
Notion of time - multiple clocks with arbitrary phase
Reactivity - watching for events
HW data types - bit vectors, arbitrary precision integers
Simulation support - debug support, VCD files
Here is an example for an adder that adds a + b then registers the output
to register c in both Synopsys SystemC and CynApps CynLib:
a --->|--| temp -----
|+ | ------>|reg|----> c
b --->|--| -----
|
clock -------------
Synopsys SystemC CynApps Cynlib
---------------- --------------
#include "systemc.h" #include "cynlib.h"
struct adder_reg : sc_module { Module adder_reg (
sc_in> a; In<8> a,
sc_in> b; In<8> b,
sc_out> c; Out<9> c,
sc_in clock; In<1> clk )
// internal signal Always (Posedge(clk))
sc_signal> temp; c <<= a + b;
EndAlways
// adder process EndModule
void add() {temp = a + b;}
// register update process
void reg() {c = temp;}
// Constructor
SC_CTOR(adder_reg) {
SC_METHOD(add);
sensitive << a << b;
SC_METHOD(reg);
sensitive_pos << clock;
}};
Both C-based design systems require their own special pre-processors to
make the macros they use actual true GNU gcc compile-able; it just appears
that CynApps pre-processor "Cyn++" is more adapted to having engineers
write C pseudo-code that's very Verilog-like. See http://www.cynlib.com
and http://www.systemc.org for more. (And, oh, yea, if you download the
System C classes, I'm told they have this odd policy where they assume
you're also endorsing it -- so don't be surprised when your company name
suddenly appears backing SystemC!)
"Verilog seems a whole lot easier than SystemC and I do a significant
amount of C++ programming. If you plan on using SystemC you better go
learn C++ in detail including templates, overloading, etc. so you can
actually understand how the thing works. Also, I assume one can only
do a small portion of an ASIC in C/C++, etc. Much of our ASIC IP,
re-use, or legacy certainly will not be in C/C++. Anyway, it is all
pretty useless until there is a good tool which maps C/C++ to Verilog."
- an anon engineer
( SNUG 00 Item 14 ) -------------------------------------------- [ 4/05/00 ]
THE SUPERLOG DEBUT: Besides all the talk of switching over to C and C++
at both SNUG'00 and a lot more at the proceeding week's HDLcon'00, yet
another language finally had it's "coming out" party: Superlog. And
once I find a stable new home for DeepChip.com, I'll have the slides
for Superlog up there. Last year I ridiculed Simon Davidmann, the CEO of
Co-Design, who makes Superlog. But this year, after seeing the Verilog
users I respect express a real interest in Superlog, I've got to eat a
little humble pie now. The big Superlog selling point that attracted
these design veterans was that Superlog was being designed as a super-set
of Verilog. That is, present day Verilog will run within Superlog with
full compatibility -- yet Superlog would have extra features that Verilog
lacks today. And with Phil Moreby, the father of Verilog, on board with
the Superlog team, this is no empty promise. http://www.co-design.com
"I don't see Superlog as a new language, I see it as an evolution of
Verilog. You can use whatever language you like as long as it is
compatible with Verilog. We are using Verilog exclusively for design
and verification and by now we have 50 million lines of Verilog
code that we are not going to replace. I know some C but I am not
using it for design or verification, neither is anyone else that I
know around here. C++ is even more of an unknown! Yes you can make
C look like Verilog if you are using some of the tools like CynApps
but the designer have to rewrite his code several time to make behave
like Verilog and then what is the point. Surely there are instances
where C is a better language, but using C in isolation and trying to
link it to a Verilog simulation via the PLI I don't think is the right
solution. A much tighter coupling between the two languages is
required and ONE way of achieving that is SuperLog."
- Anders Nordstrom of Nortel Networks from ESNUG 345 #10
"Please don't allow every special interest group to add their special
construct to your systems language. I saw this before on the VHDL
committees and it's an unworkable mess."
- Bill Billowitch of Intrinsix
( SNUG 00 Item 15 ) -------------------------------------------- [ 4/05/00 ]
MOSTLY HOMEGROWN SOFTWARE TESTING: If you take a look at how the SNUG'00
attendees responded on the questions concerning the design of chips that
have a lot of related software around them:
low software chip design
with no related SW testing ############# 26%
we build a HW prototype
to test the related SW ############# 26%
we use HW/SW Co-Sim tools
to test the related SW ############ 25%
We use only SW simulation
to test the related SW ########### 23%
we use HW emulators
to test the related SW ######## 16%
Yes, it adds up to 116 percent because design teams use mixed approaches.
This is not my point here. Read on. Now take a look at these SNUG'00
user tool use stats:
Cadence Quickturn Emulation ##### 11%
IKOS Emulation #### 9%
Synopsys LMC Hardware Models ### 6%
Aptix Emulation # 2%
Denali Memory Products #### 9%
Synopsys LMC SmartModels ##### 11%
Mentor SEAMLESS HW/SW Co-Sim ## 4%
Synopsys Eaglei HW/SW Co-Sim ## 4%
Cadence SPW ### 6%
Synopsys COSSAP # 2%
You'll notice that these are relatively very low numbers. (For example,
only 8 percent of customers are using either commercial HW/SW co-sim tool,
yet right above a whopping 25 percent of customers claim to be using
HW/SW co-sim tools.) What this means is that a lot of designers are still
using the tried-and-true Verilog-with-PLI-to-run-outside-SW approach.
Basically, customers aren't buying as much as making their own. The same
holds true with prototyping:
we prototype w/ FPGAs ############### 31%
we don't prototype w/ FPGAs ################################## 69%
when you compare the 31-percent-proto-w/-FPGAs to what their commercial
equivalents are getting (for example, the 11 percent using Quickturn).
Homegrown rules, which explains the percentage of Synopsys users who also
use FPGA Compiler II:
Synopsys FPGA Express ###### 13%
Synopsys FPGA Compiler II ###### 13%
So this might mean that Synplicity and Exemplar probably aren't as big
Synopsys FPGA synthesis competitors as was originally thought -- they're
in different niches.
"The first presentation discussed the results of digital filter
implementations in FPGAs. The author explored FPGA use (as opposed
to an ASIC solution) at the direction of his management. He explored
results compiling DesignWare components into Altera FPGAs using FPGA
Compiler (fpga_shell) and FPGA Compiler II (fc2_shell), paying close
attention to design power. In summary, the results were not very good.
The speed goals were only attained by targeting less than the number of
desired bits in the filter. Also, the design power was very high due
to the SRAM lookup table architecture of FPGAs. The conclusion was
that FPGAs were too pricey ($2K) for the desired design (modems)."
- an anon engineer
( SNUG 00 Item 16 ) -------------------------------------------- [ 4/05/00 ]
"Actel did a presentation on the ASIC methodology for their ProASIC
family of FPGAs. They have definitely got the right idea for ASIC
prototyping with FPGAs. Their approach is to use a standard Design
Compiler ASIC flow, with no special FPGA-centric tricks or tools. With
many man-years invested in DC scripting and ASIC flow, the last thing I
want to do is learn new point tools for prototyping in FPGAs, spend many
more man-months trying to get the FPGA to route/meet timing, etc, and
have to start from scratch to make the real ASIC. Been there, done
that. I've been using this off & on for a few months, and my results
have been pretty good. The best part is that there is no FPGA-centric
wasted effort/scripting, etc. The ProASIC library looks like just
another vendor library in my DC flow. This is made possible by their
fine grain architecture and hierarchical wireload models. Instead of
having huge building blocks, they have small "tiles" with 3 inputs that
can be configured as MUXes, various gates with up to 3 inputs, or D
flipflops. It hasn't been a cakewalk since this is pretty new and the
tools/support are a work in progress, but I like it so far."
- an anon engineer
( SNUG 00 Item 17 ) -------------------------------------------- [ 4/05/00 ]
TRUSTING THEIR MOTIVE(S) When Synopsys bought ViewLogic a few years back,
they effectively bought the entire Static Timing Analysis (STA) market
because, at the time, ViewLogic owned the best and most popular STA tool
around: MOTIVE. Since then, Synopsys replaced MOTIVE with its own STA
tool, PrimeTime. It's funny how that paid off for Synopsys now:
I sign-off with Static
Timing Analysis (Only) ################################ 65%
I sign-off with both
Static & Dynamic Analysis ########## 21%
I sign-off with Dynamic
Timing Analysis (Only) ####### 14%
Also from the tool stats:
Synopsys PrimeTime ############################# 58%
Mentor SST Velocity 1%
Cadence's Pearl STA tool wasn't on the survey. Dataquest's 1998 market
share numbers gave Synopsys PrimeTime 74.1 percent, Cadence Pearl 22.6
percent, and Mentor SST Velocity 2.7 percent. Good acquisition.
"Strangely enough, it looks like it's a race between Synopsys and
Mentor in the static timing analysis market because Cadence is
de-emphasizing Pearl in favor of the Ambit static timing analysis
engine. Ambit STA is not a stand alone product yet, so it's not
in the numbers."
- Gary Smith, Dataquest EDA Analyst
"The second author, London Jin of Toshiba, presented a litany of issues
and pet peeves associated with static timing analysis using PrimeTime.
The first problem the author had was unknown clock networks which
resulted from "black box" cells in his clock tree. Primetime cannot
successfully propagate clocks through cells that are modeled as a
"block box". The "transitive_fanout -clock_tree" command was used to
uncover these unknown clock networks. The second problem Jin had was
untested timing checks. The "report_analysis_coverage" command was
used to uncover untested timing checks. Jin also suggested the use of
the "derive_clocks" command to extract and analyze clock networks
within a design. I'm glad I sat in on his presentation."
- an anon engineer
"Day 3: PrimeTime Special Topics (Tutorial Session)
This two-part tutorial first dealt with setting timing constraints and
then static timing models. The first part of the tutorial didn't
introduce any revolutionary information that wasn't already is use
within our group, with the exception of On-Chip variation. On-Chip
variation is the capability of Primetime to account for delay variations
due the PVT changes across the die. When using on-chip variation, a
"clock reconvergence adjustment" is used by Primetime to account for
cells common between the clock and data paths. It is assumed that a
single cell cannot have two delays. The second part of this tutorial
presented three types of static timing models that are available with
PrimeTime: Stamp Timing Models, Extracted Timing Models, and Quick
Timing Models. Stamp Timing Models are primarily used by ASIC vendors
to characterize such things as memory cells.
Extracted Timing Models are very interesting and could be very useful
to reduce the run-time of static timing analysis. A timing model can
be "extracted" automatically from a design instance and used for
subsequent timing analysis. Since the extracted timing model only
contains the information necessary to model timing at the boundary of
the design module, it reduces run-time.
Quick Timing Models are also interesting as they can be used to describe
the timing of a design module where no netlist is available. This can
be useful during hierarchical design to best describe the timing
characteristics of a design not yet complete. How to extract a Timing
Model and generate a Quick Timing Model were both presented."
- an anon engineer
( SNUG 00 Item 18 ) -------------------------------------------- [ 4/05/00 ]
THE BIRDS & THE BEES: Currently, to manage the funky effects of hanging
out around 0.25 um, chip designers use Design Compiler in conjunction with
Wire Load Models. They're also using a class of tools which guesstimate
physical effects (within 15 percent or so) that are best thought of as
"planners". Their user stats:
Avanti Planet-RTL ######## 17%
Synopsys Chip Architect # 3%
Synopsys FlexRoute 1%
Once you're past the physical effects planning stage, there's another class
of tools that manages physical effects via post-synthesis optimizations.
Their SNUG'00 tool survey stats:
Synopsys Floorplan Manager ########## 21%
Avanti Saturn ###### 12%
Cadence Phys Design Planner ## 5%
Cadence PBopt should also be included here for completeness even though it
wasn't in the survey. Anyway, the big problem is these Wire Load Model
tools/approaches only work so-so, but they're as good as it gets for now.
Also, everything gets much worst the deeper below 0.25 um you get. This
is where the new class of RTL-to-GDS-II physical synthesis tools come in.
Their SNUG'00 user survey stats:
Cadence Ambit PKS ## 5%
Synopsys PhysOpt # 3%
Magma BlastFusion 1%
And this is where John Cooley steps in for a nice little talk on the Facts
Of Life In The EDA World...
First off, remember that +/- 6 percent margin of error I talked about for
this SNUG'00 user survey data? It applies here. Basically, the big EDA
companies are in the fight of their lives as far as future business is
concerned. Because physical synthesis entails going from RTL-to-GDS-II,
whoever owns this market will be obscenely successful; whoever misses
it will be have all the business and respect that ViewLogic gets. (One
motto on the ViewLogic web site last year was "Believe In Reincarnation".
And, no, I'm not making this up.)
This being said, let's say you're a Magma or a Cadence and you don't have a
working physical synthesis tool yet. You spread FUD (Fear, Uncertainty,
and Dis-information) to buy time for your developers to get your own bloody
tool working and to stall customers from buying a rival's working physical
synthesis tool. If you're Synopsys and you just happen to be lucky enough
to have a mostly functional physical synthesis tool, you try to do your
best to prove to customers it does work despite the FUD being blasted your
way -plus- you generate your own anti-Cadence and anti-Magma FUD, too. If
you're Avanti and don't even have a physical synthesis tool, you promote
your Saturn netlist optimizer like crazy and pooh-pooh all RTL-To-GDSII
tools. And with FUD, it gets worst. EDA employees don't just work for
salary any more; they all wanna get rich off of company stock options just
like their buddies in the .com companies. So they're all using FUD to
trick that EDA analyst at Goldman-Sachs into upgrading her eval of their
individual stocks, too!
"Hey, John, these EDA company press announcements have quotes from customer
VPs in them; there must be something good going on for the customer VPs to
be speaking up.", you reply. And my answer is one word: MONEY. When was
the last time you saw a VP design a chip? VPs don't design anything! VPs
are corporate politicians. Follow the money. Customer VPs give cheery,
sometimes-outright-lying quotes because they get a serious price cut or
some other behind-the-scenes favor from the benefiting EDA vendor. Why do
you think you're seeing "Success Stories" from ASIC Alliance on *both* the
Cadence and the Avanti web sites? Why do you see nVidia on the Avanti and
Synopsys press releases? Why do you see ARM, Ltd. (every EDA company's PR
whore) promoting every EDA company's software everywhere? Why do you see
Fujitsu supporting both Ambit in the Cadence press releases and BlastFusion
in the Magma press releases?
For a detailed example, let's look at the recent hunk of FUD where Cadence
is repackaging PKS and trying to say it's "new" and "improved" with their
SP&R press announcement from last week. In it you have Jayan Ramankutty,
the VP of engineering at EmpowerTel saying:
"With PKS, we eliminated design iterations and got higher-performance
results in a much shorter time. Adding routing to PKS and PKS to
Silicon Ensemble will allow us to achieve correlation across tools
and continue meeting our aggressive performance goals."
Do some digging and you'll find Jayan Ramankutty was the same VP at Lara
Technology in the Ambit press announcement a year earlier. Do some more
digging and you find that EmpowerTEL and Lara Tech are the same company
(they're just about to split) and they have 12 Cadence Verilog licenses,
5 Ambit licenses, 1 PKS license, and 1 complete Cadence Silicon Ensemble
suit -- roughly about $1 million worth of software. Ramankutty's quote
vaguely implies they used PKS in a big tape-out. (I'm sure that's what
the Cadence sales force is saying to the customers and Wall Street.) It
turns out that, yes, this is the first known PKS tape-out I've found,
but PKS was only used on 50 kgates of MIPS core buried inside a 130 Mhz,
2.5 million gate design that had a lot of RAM. The role of PKS in this
design at EmpowerTEL was trivial -- yet the Cadence press release was
purposely written to *imply* much more. Classic FUD.
And they all (Synopsys, Mentor, Avanti, Cadence, Magma, Monterey, etc.,
etc., ...) do it! Don't trust any of them, I say. Here's my known
list of physical synthesis tape-outs as of April 5th.
Cadence PKS
Design Size Clock Company Location Designer Tape-Out
--------------------------------------------------------------------
50 kgate MIPS 130 EmpowerTEL San Jose, Can't Say Apr./00
core in 2.5 Mhz CA
million gate
design
testing PKS Toshiba San Jose, unknown none
on 200 kgates CA
dumped PKS Micron Can't Say Can't Say none
testing PKS Agilent Corvalis, Jay none
Oregon McDougal
dumped PKS Agilent Colorado Can't Say none
Magma BlastFusion
Design Size Clock Company Location Designer Tape-Out
-------------------------------------------------------------------
testing around 3-D Labs England unknown none
BlastFusion 200 Mhz
testing unknown SUN Calif. unknown none
BlastFusion Microsystems
testing unknown Texas Texas unknown none
BlastFusion Instruments
testing unknown Fujitsu Calif. unknown none
BlastFusion
Synopsys PhysOpt
Design Size Clock Company Location Designer Tape-Out
--------------------------------------------------------------------
5+ million > 180 nVidia Santa Clara, Joe Nov./99
gates Mhz CA Grecco
3+ million > 180 Matrox Montreal, David Nov./99
gates Mhz Canada Romanauskas
135 kgates unknown STMicro Europe Can't Say Dec./99
300 kgates ~150 STMicro Europe Can't Say Mar./00
0.18 um Mhz
8+ million > 300 SGI/Cray Chippewa Roger Apr./00
gates Mhz Falls, WI Bethard
1.2 million 66 STMicro Agrate, Ezio Apr./00
gates Mhz Italy Pacileo
DSP unknown Texas unknown unknown Apr./00
unknown Instruments
I can't say how I know that TI has taped-out a PhysOpt design, but it did
come from a historically reliable source. When I asked Synopsys about
this TI PhysOpt tape-out, they stonewalled with me with "We can't say that
they have. We can't say if they haven't."
So, as of April 5th, this makes: for PhysOpt, 6 (possibly 7) tape-outs;
for PKS, 1 small tape-out; and 0 tape-outs for Magma.
"P.S. I still stand by my original argument: this physical synthesis
crap isn't showing drop-dead results against the tuned "DC w/ timing-
driven placement" flows I have today. Why bother with them???"
- [ Tony, the Tiger ] from ESNUG 348 #3
"My local layout people had a real hoot over the slides in the Physical
Synthesis tutorial. Especially the slides on multi-pin bus routing
(crosstalk central) and the clock balancing cell (signal disintegrity).
Can't wait to try it! (sarcasm)"
- Brian Logsdon of Philips Semiconductors
"There was only one paper from Sam Appleton from SGI that was very
good. He actually showed die photos of before, and after their new
methodology. He achieved some impressive results with FlexRoute.
We all know that by intelligently placing the block pins we can get
the job done. The problem is how to you manage the pin placement
complexity. It was nice to see that Synopsys FlexRoute will do the
job. Now if I can convince my clients to pony up the necessary funds."
- an anon engineer
( SNUG 00 Item 19 ) -------------------------------------------- [ 4/05/00 ]
HOUSTON, WE HAVE A PROBLEM: As a business division, the EPIC part of
Synopsys seems to have pretty good penetration with its tools. You
can see this from the SNUG'00 user tool survey:
Synopsys EPIC PathMill ###### 13%
Synopsys EPIC TimeMill ###### 13%
Synopsys EPIC PowerMill ###### 12%
Synopsys EPIC Arcadia # 3%
Synopsys EPIC RailMill # 2%
Synopsys EPIC CoreMill 1%
Synopsys EPIC ACE ## 5%
Cadence Mixed-Signal Sim ## 5%
Mentor Mach-TA 1%
Mentor AccuSim 1%
The problem is that these customers are really paranoid of each other, so
you can't get a critical mass of them together discussing the tools. Go
snip out the EPIC stuff from the SNUG breakouts:
9:00 - 12:15 (MA3) Tutorial on EPIC Tools & RailMill 14
1:30 - 4:45 (MB4) Tutorial on EPIC, ACE with VCS 17
10:30 - 12:00 (TA4) TimeMill, Synopsys SLE, PathMill 16
1:15 - 2:15 (TB4) EPIC PathMill 71
8:30 - 11:45 (WA4) Tutorial on EPIC PathMill 11
and you see most of the time there are only about 17 users talking EPIC.
"So what?", you may ask? What keeps a tool growing and doing well in the
EDA world is the community of users around that tool. No community, and,
given enough time, the competition will scarf up all those customers.
"I heard that the EPIC part of Synopsys is falling apart; many of
the old EPIC team have left and the remaining ones are unhappy.
Also, customers are drifting off to other tools. What's up here?"
- a Wall Street stock analyst
"We have long complained about the Synopsys-Pathmill correlation
issue. This is mainly a problem with setup and hold time calculation
at latch nodes by Pathmill. If there are finite (i.e. slow) transition
times on the clock signals (transistor gates) controlling a latch node,
the analysis is inaccurate. Where Synopsys synthesis libraries are
derived from SPICE characterizations, any EPIC Pathmill runs on
post-synthesis netlists have an ugly tendency not to correlate well
with reports from Design Compiler. We have been pretty frustrated that
EPIC (now call "Nanometer Analysis Technology" inside of Synopsys) has
not resolved this, since they agreed that it was indeed a problem.
With both Pathmill and DC now in the same company, it is even more of a
question. After Aart's bold statement, I have to ask, is this an
issue at any other design houses?"
- Chip Laub of Intel from ESNUG 348 #7
( SNUG 00 Item 20 ) -------------------------------------------- [ 4/05/00 ]
WATER & OIL DO MIX: The SNUG'00 user tool survey numbers for the DFT/ATPG
market may not seem odd at first:
Synopsys DFT Tools ############## 28%
Synopsys ATPG Tools ############# 26%
Mentor DFT Tools ########## 20%
Mentor ATPG Tools ######## 16%
LogicVision Memory BIST ###### 13%
LogicVision BIST #### 9%
Mentor BIST ### 6%
until you realized that the Dataquest numbers for 1998 had Synopsys owning
94.4 percent of the test-chain-insertion market and Mentor owning 94.6
percent of the ATPG market! This SNUG'00 survey data indicates a very
dramatic shift in that market in just 2 years. Is TetraMax *that* good?
For comparison, in the 1998 BIST market, LogicVision held 59.5 percent
and Mentor 27.7 percent -- which pretty much correlates to the SNUG'00
tool survey data.
"To date, I have successfully used TetraMax to produce scan vectors
for 4 chips: 2 one-million plus gate ASICs, 1 one million gate ASIC,
and a 600k gate ASIC. Two of these chips are in production & running
vectors while the others are in the proto stage.
Our current scan methodology calls for multiple groups of scan chains
that are scanned independently (i.e. serially as groups) from one
another. This requires that a test tool not look at each scan chain
as identical in terms of its scan requirements. Synopsys has added a
very flexible enhancement to the tool that will pretty much allow you
to do any kind of funky setup you wish when scanning any particular
chain. With Sunrise our only way to do this was by post-processing
and other convoluted procedures. You can probably tell I am pretty
happy about this feature in TetraMax. My only gripe is w/ TetraMax's
vector generation and hopefully it will be addressed soon in an
enhancement. Specifically, TetraMax currently will scan all groups of
chains for each vector, whether or not it is needed. This wastes
tester cycles and has to do with a fundamental algorithm used in most
ATPG tools.
As for performance, TetraMax is extremely fast and produces good
results. I benchmarked it against Sunrise/Testgen last year when
TetraMax was still Beta on a few near-full scan designs for
combinational and fast-sequential vectors. TetraMax managed to
produce roughly equivalent results to Sunrise in about 1/10 the run
time and less setup time! (That was enough to get me converting
over, despite the fact that the code was still Beta at that time.)
Another feature I have found useful is the graphical debugging
abilities of TetraMax. This allows you to view ATPG violations as a
schematic and "browse" the schematic with annotated values for
different stages of the ATPG algorithm. This has been extremely
useful to me and is a very nice change from the sometimes cryptic
outputs of Sunrise. It also can be used to diagnose vector failures
and help zero in on model problems. This is also the one feature
that needs some more work however in that it still occasionally gives
"schematic too big" errors or acts a little flaky. Still very
useable, it just needs some polishing. I'm not complaining too much
though given that this is the first tool I've seen that gives you
this ability, although I think Fastscan may also have some of this
ability.
One final note regarding TetraMax is with regards to its modeling
methods. With TetraMax you can use Sunrise models, Verilog models,
or custom models written by you or the ASIC vendor. This pleases me
to no end. One of the biggest hassles in the past for me has been
obtaining correct "Sunrise" models for cells, something vendors are
often slow to give or something you must come up with yourself. It
was a major pain. With TetraMax you can often just use the Verilog
model (although there are issues here that must be considered).
Synopsys is also adding library validation procedures that should
help identify problems early on before one has a vector to debug on
a big nasty gate model.
I used to abhor test as the ATPG process was just so damn painful.
TetraMax, however, is fast enough and has some really good debugging
facilities so iterations can be done pretty quickly to zero in on
the vector set's true problems. That makes me one happy customer."
- Russell Petersen, ASIC Engineer, Scientific Atlanta
( SNUG 00 Item 21 ) -------------------------------------------- [ 4/05/00 ]
FAT, DUMB, & HAPPY (FOR NOW): The SNUG'00 user tool survey numbers look
good for Synopsys in the equivalence checking (formal verification) biz:
Synopsys Formality ############ 24%
Avanti Chrysalis Verifyer ######### 18%
That is, until you read Gary Smith's quote below:
"Verplex is eating everyone's lunch right now in the equivalence
checking market. It basically can compare more gates and its
speed is much faster than Formality or Chrysalis. I can't say
market share numbers yet, but they're winning all the technical
benchmarks everywhere right now."
- Gary Smith, Dataquest EDA Analyst
Now the pressure is on for Synopsys to technically improve Formality or to
go on a little acquisition shopping spree in the not too distant future.
"When will you get ECO Compiler out of its hibernation state?"
- a customer question to Aart de Geus, CEO of Synopsys, during
the Q&A part of the SNUG'00 keynote address
"Now that PhysOpt exists, we'll have to see how ECO Compiler endures.
It all depends on what customers want."
- Aart's answer.
( SNUG 00 Item 22 ) -------------------------------------------- [ 4/05/00 ]
A PLACE IN THE SUN: One of the surprising parts of SNUG'00 was how the
majority of engineers stayed around for (and were actually interested in)
the Sun Compute Farm talk at the end of the conference. This talk was
a gimme to Sun because they helped underwrite SNUG'00. (I gotta give
some real credit, too, to the Sun guys because they didn't make that talk
an infomercial, but instead, they just told the honest experience of what
it was like to run a 500 machine compute farm for chip designers.)
"Day 2: Managing EDA Complexity (General Session)
Sun Microsystems discussed their regression environment and compute
farm. Starting in 1991, Sun developed an in-house regression
management tool similar to LSF called DREAM. They have about 500
compute servers, 2000 processors, and around 1.6 Gbytes/processor in
their compute farm. Also, they are in the process of upgrading the
connections of their servers to Gigabit Ethernet. Other than its
massive size, the regression environment described was remarkably
similar to our own."
- an anon engineer
"Sun Microsystems gave an interesting presentation on their server
ranch. Here are some of the interesting statistics. They have 530
systems, 312 of them are compute servers. This averages out to 3 CPU's
per engineer. Memory is about 850 Mb per CPU and total disk space is
75 Tbytes (terra-bytes). They run about 1 million batch jobs a week.
Every user has 100bT to the desk, connected to a fully switched network
using gigabit Ethernet between the switches and routers, with every
user seeing only one router hop delay. They have a custom environment
to keep it operating at about 95% capacity. It was a real impressive
presentation showing how to make a big server farm successful."
- an anon engineer
The SNUG survey stats came in with:
I design on a: 32-bit Sun ################################# 66%
64-bit Sun ############## 29%
32-bit HP ######## 16%
64-bit HP ### 7%
Windows or NT PC ####### 15%
Linux PC #### 9%
other platform # 3%
This adds up to 145 percent because most engineers design on more than one
computer. Sun seems to own most of this market, though, with the Sun OS
versions breaking out to:
Solaris 2.7 ################### 39%
Solaris 2.6 ####################### 47%
Solaris 2.5.X ########## 21%
SUN OS ## 4%
don't know #### 9%
And this year's new OS golden child is Linux on PCs. Designers in the
SNUG'00 survey reported:
I have low
interest in LINUX ###################### 44%
I have medium
interest in LINUX ################### 39%
I have high
interest in LINUX ######## 17%
Whether Linux is this year's fad OS request for chip designers or something
that'll stand the test of time, nobody can tell. Just a few years ago,
customers were badgering the EDA vendors to port to Windows and...
"This is the beginning of the deluge," said analyst Rita Glover, of
EDA Today. "There wasn't a full design flow until we got Synopsys
synthesis there. The others will come if they're not there now."
But the expected deluge is starting slowly, given that the latest
market figures from EDAC show that Unix-based software still accounts
for more than 90 percent of total EDA revenues. An e-mail survey
conducted last year by John Cooley, moderator of ESNUG, found that
many Synopsys users lost interest in Windows NT when they discovered
that software pricing would be the same as for Unix.
Analyst Gary Smith of Dataquest predicted that Windows NT would
account for 30 percent of EDA revenues by 2000."
- Richard Goering, EE Times, Feb. 23, 1998
"Today, it's maybe only half a percent on the Intel/WinNT platform. By
the year 2000, that will probably rise to 20 percent to 25 percent."
- Aart de Geus, CEO of Synopsys, EE Times, June 22, 1998
"Windows NT has not even met our conservative estimates."
- Aart de Geus, CEO of Synopsys, in his SNUG 1999 keynote address
"We all know NT for EDA is in the toilet."
- Aart de Geus, CEO of Synopsys, in his SNUG 2000 keynote address
"Those who cannot remember the past are condemned to repeat it."
- George Santayana, American philosopher, 1863 - 1952
( SNUG 00 Item 23 ) -------------------------------------------- [ 4/05/00 ]
The 2000 Synopsys Report Card
-----------------------------
With the advent of hard customer data, this year's SNUG'00 conference has
yielded an amazing portrait of Synopsys and its customers. From the
customer's viewpoint, Synopsys appears to only be doing poorly in mostly
"fringe" areas. ECO Compiler is hibernating. Most customers don't seem
to care about the new Scirocco VHDL simulator announcement. Behavioral
Compiler is still very niche -- but it might bust out of that niche if
C/C++ design becomes mainstream. Protocol Compiler is practically dead.
VERA is now surprisingly used by 15 percent of Synopsys customers -- but
may die if SystemC takes off. Formality is facing some serious technical
threats from Verplex. Eaglei isn't really all that hot because it's
competing against homegrown verification. FPGA Express always seems to
be playing catch-up against Synplicity and Exemplar. And the EPIC branch
is doing a slow self-destruct sequence. Yes, this is all the bad news,
but when you look at it, they're mostly sideshows, the low revenue parts
of Synopsys that have always been low revenue.
On the flip side, Synopsys owns 91 percent of the ASIC synthesis market.
Power Compiler's hot. Module Compiler is keeping the datapath weenies in
bliss. Test Compiler and especially TetraMax are upsetting Mentor by
taking the lead in the scan insertion and ATPG markets. Static Timing
Analysis is now the way 86 percent of engineers do sign-off and, oops,
PrimeTime owns 74 percent of that market. VCS is blindingly fast, still
the strongest market leader, and, oops, Verilog accounts for 85 percent
of the North American market. Those widely used DesignWare libraries
generate mondo gravy dollars for Synopsys because 37 percent of customers
use them. More gravy because FPGA Compiler II is used by 13 percent of
customers to prototype their ASICs. And that controversial SystemC
idea opens the door to a whole new possible market of System Designers
where Synopsys is already developing new C/C++ tools to sell there.
But the biggest assets Synopsys has is the undivided attention of the high
end, big & fast chip designers. Go back and look at those stats on who
attended SNUG'00. They're 69 percent design engineers making an average
chip that's over 1 million gates, around 200 Mhz, at or below 0.18 um,
and 49 percent of them do their own Place & Route. This means Synopsys is
perfectly positioned to capitalize on the physical synthesis market. And
to my utter surprise, Synopsys appears to be winning in that strategic EDA
market with 6 (possibly 7) known, confirmed PhysOpt tape-outs of some very
serious chips from some very big customers. Compare that to Cadence's one
limp PKS tape-out that's 6 months after PhysOpt; or to Magma not having a
tape-out yet. Whoa! Chip Architect and FlexRoute are doing well, too.
Plus, Aart says he'll have Clock Tree Synthesis by DAC and a detailed
router before the end of the year. And I had originally thought that
since Cadence and Avanti dominated the backend, they'd be the obvious ones
dominating physical synthesis and Synopsys was going to be the one playing
catch-up. (Man, did I miss seeing this one coming!)
Overall, Synopsys appears to be kicking ass this year.
(Gawd! I hate having to say that. But I honestly believe it from what I'm
seeing and am therefore obligated to say it. Could some users PLEASE send
me some nice, juicy Synopsys horror stories to make me feel normal again??)
- John Cooley
the ESNUG guy
============================================================================
Trying to figure out a Synopsys bug? Want to hear how 11,086 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."
|
|
