!!! "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'02 & HDL Con'02"
_] [_ (plus what 131 other engineers saw there, too.)
by John Cooley
Moderator Of The E-mail Synopsys Users Group (ESNUG)
The 12th Annual Synopsys Users Group Meeting (SNUG'02)
at the Doubletree Inn, San Jose, CA, March 13th - 15th, 2002
"These informal gatherings are great for meeting new people and getting
reacquainted with old colleagues. You might even win prizes. I never
do, but you might."
- Joe Gilray of Agilent
( SNUG 02 Subjects ) ------------------------------------------- [ 5/15/02 ]
Item 1: The Bigwig's Big SNUG Speech
Item 2: SNUG'02 & HDLcon'02 Attendance Numbers
Item 3: Exactly Who Came To SNUG'02?
Item 4: Customers Rate The Best & The Worst Synopsys Tools
Item 5: NC-Verilog & NC-SIM, VCS & Scirroco, ModelSim, Fintronics
Item 6: Verisity Specman 'e', Synopsys Vera, Chronology/Forte RAVE
Item 7: Superlog, Verilog-2001, Synopsys SystemC, CoWare
Item 8: Synopsys 'Eagle-i', NDA 'Ketchum', & NDA 'Verification Analyst'
Item 9: Synopsys TetraMAX & Mentor FastScan
Item 10: Verplex, Chrysalis, Synopsys Formality, Mentor FormalPro
Item 11: Design Compiler, Ambit-RTL, Get2chips, Synplicity ASIC, Incentia
Item 12: Module Compiler & Behavioral Compiler
Item 13: Synplicity Synplify FPGA, Mentor Exemplar, Synopsys FPGA Tools
Item 14: PrimeTime, PrimeTime-SI, Avanti Mars-Xtalk, Sequence, Simplex
Item 15: PhysOpt vs. Magma vs. Cadence PKS vs. Monterey
Item 16: Hidden Dragon, First Encounter, Aristo IC Wizard, Soc Ensemble
Item 17: Aart's Technology Leak
Item 18: Nassda HSIM, Avanti StarSim, Synopsys EPIC NanoSim, Apache NSPICE
Item 19: The Synopsys 2002 Report Card
( SNUG 02 Item 1 ) --------------------------------------------- [ 5/15/02 ]
Subject: The Bigwig's Big SNUG Speech
STATE OF THE TECHNOLOGY ADDRESS: As usual Aart covered everything from SOCs
to SystemC to NanoSim to TetraMAX to PhysOpt to Formality to 64-bits in his
annual SNUG address.
"Keynote
Dr. Aart de Geus's speech is always good fodder. Here are the
highlights. The market is still depressed (peak to trough it is
down 45%). He sees the semiconductor industry recovering in a year.
Some areas are still strong, namely games, wireless lans & automotive.
SOCs encompass more and more of the value chain, including many risky
handoffs. Synopsys wants to help by moving toward 'monotonically
decreasing uncertainty'. The challenges he sees and Synopsys
initiatives in those areas are:
Timing closure. Iterations between logical and physical design are
costly. Synopsys intends to continue focusing on PhysOpt 'the
fastest growing EDA tool with 500+ tapeouts' while still investing
heavily in their largest product, DC, particularly in the areas of
power, signal integrity and test. The dominance of interconnect delay
in modern processes causes timing closure problems. He sees
floorplanning moving to a Front End tool. Chip Architect is getting
lots of attention as 'Design Planning is the core of methodology'.
Chip Architect will be the corner stone of full chip content hierarchy
design.
Test. They are adding 'delay test' to TetraMAX to catch late
transition problems.
Verification. Three ways to attack the problem of verifying huge
designs:
- Faster Verification: server farms, mixed language simulation
(with Scirocco), Nanosim (fast SPICE sims)
- Smarter Verification: Formality and assertion-driven
verification via Open VERA
- Earlier Verification: moving to higher levels of abstraction
(gates -> RTL -> transactions) with System C and Cocentric
Design Integrity. Physical effects are sneaking up on us. We can
now measure crosstalk with PrimeTime-SI, but how to fix it? The
answer is to prevent it in the first place. Synopsys is working on
additions to PhysOpt to fix crosstalk problems on critical nets.
PrimeTime will also be enhanced to deal with multiple voltages and
data-to-data checks.
Mixed Signal. EPIC NanoSim is being integrated with Scirocco.
IP Reuse. Synopsys professional services has growing expertise.
Dr. de Geus reported that Synopsys has ongoing plans to support all
its tools under Linux and 64-bit OSes. In answering a question it
came out that Clock Tree Compiler (CTC) will support hierarchy via
interface logic models (ILMs).
Finally, he spoke on the Avanti merger saying that Avanti complements
Synopsys. He said their overall goals if the merger goes through are:
- Connect PhysOpt to Apollo/Astro
- Use back-end knowledge to help prevent Design Integrity issues
- Improve system level verification
Aart said that the current plan is to continue with both the Avanti
tools and Route Compiler until they can be naturally merged."
- an anon Agilent engineer
"Aart's keynote speech was less humorous than usual. He must be
feeling the recession, too."
- Oren Rubinstein of Nvidia
"Aart was impressive. His understanding of his business, the industry
and his products is incredible."
- Brent Lawson of Texas Instruments
"Aart always gives an interesting speech. I'd like to meet his writers
some time. They at least sound like they know what they are doing."
- David Bishop of Kodak
"I thought having the tool managers up on stage provided Aart some real
backing."
- Tom Tessier of t2design
"Aart's keynote address was fine however some of us that had been to
a number of previous SNUGs thought it perhaps lacked any exciting
new 'pre-announcements' of tools and / or features to come. The
group of technical leaders he brought up with him on stage to back
him up and keep him honest reminded me of the team of lawyers that
Mr. Burns (a.k.a. The Simpsons) brings with him when facing any
dicey legal situation."
- Jeff Waite of Netergy Microelectronics
"Aart is smart, so he bring his technical team to answer questions
after his keynote speech."
- Hui Fu of Infineon
"The Q&A people from Synopsys really didn't help Aart. They reminded
me of some type of 1960s dating TV show because they where sitting
on stools."
- Frank Wolff of Case Western Reserve University
"A panel of technical heavies from Synopsys backed Aart by for his Q&A
session, a great idea that demonstrated his willingness to answer
questions openly, honestly, and accurately. When asked about the
future of the Synopsys vs. the Avanti routers, he said that both would
be supported until they could be merged into something better."
- Bob Wiegand of NxtWave
"I liked the pointed questions at Aart's speech about Linux support.
Better Linux support would be better for the design community in
general. Even though Aart mentioned the Avanti merger briefly, the
future direction was still unclear with the back end. I guess we'll
have to wait for the lawsuits and such to sort themselves out first."
- an anon engineer
( SNUG 02 Item 2 ) --------------------------------------------- [ 5/15/02 ]
Subject: SNUG'02 & HDLcon'02 Attendance Numbers
UP & DOWN: Overall user attendance for SNUG'02 was 451 customers. Compared
to last year's 485 customers, that's a 7 percent drop in attendance -- not
bad for a conference in the middle of a recession.
This year's bad economy was even more evident in the HDLcon numbers. The
total attendance for HDLcon'02 was 623 people, up 30 percent from last year
but not really. Yup. But not really. Last year, 210 people were free
'Exhibit Only' HDLcon attendees. This year, 446 people attended HDLcon'02
wearing free 'Exhibit Only' badges. That means that only 177 people
actually attended the papers/panels/presentations part of HDLcon itself this
year -- a 35 percent drop because of the hurting economy.
"Overall I was impressed at the turnout at SNUG --- close to 500 people
in this economy was a pretty good attendance."
- Pallab Chatterjee of SiliconMap
( SNUG 02 Item 3 ) --------------------------------------------- [ 5/15/02 ]
Subject: Exactly Who Came To SNUG'02?
A MINI-CENSUS: This data comes from the customer survey taken at the SNUG'02
meeting itself. A total of 269 out of the 451 SNUG'02 attendees responded.
Here's the stats on the types of designs these engineers are creating:
Standard Cell / SoC ######################################## 79%
Full Custom ##### 11%
Gate Array ## 5%
FPGA/CPLD ## 4%
Other # 2%
The speed, size, and process of the chips they're designing:
1 - 99 MHz ###### 13%
100 - 199 MHz ############ 25%
200 - 299 Mhz ############## 27 %
300 - 499 MHz ############ 23%
500 + Mhz ###### 12 %
1 - 300 Kgates ######### 17%
301 - 500 Kgates ###### 12%
501 - 999 Kgates ## 4%
1 Mgates ######## 16%
1.001 - 2 Mgates ########## 19%
2.001 - 5 Mgates ######### 18%
5+ Mgates ####### 14%
0.25 um or higher # 3%
0.25 um ### 7%
0.18 um ######################## 48%
0.15 um ##### 10%
0.13 um ############# 26%
0.11 um # 3%
0.10 um 1%
below 0.15 um # 2%
Ckeck out last year's stats in SNUG 01 #3 and you'll be surprized to see
how dramatically things have changed in one year -- especially in design
gate counts and fab processes being used. Last year only 36% of designs
were 1 million gates or more. Now 67% are! Last year 73% of designs were
at or below 0.18 um. Now 90% are.
Their P&R design flow:
Hand-off P&R To ASIC Vendor ############### 29%
We Use Avanti P&R ################# 33%
We Use Cadence P&R ############ 24%
We Use Magma P&R # 3%
We Use Our Own In-House P&R ## 5%
"other" P&R ## 6%
Again, much has changed in 12 short months. Last year, 59% of designers
handed off P&R to their ASIC vendor; this year only 29% are. Also 18%
used Avanti P&R and 16% used Cadence P&R. This year it's 33% Avanti,
24% Cadence, and 3% Magma for customer-owned P&R tools.
And the fabs they're designing for:
In-House Company Fab ################## 35%
TSMC ########################## 52%
UMC ############### 29%
IBM ######### 17%
LSI ######### 17%
Xilinx ###### 13%
Texas Instruments ##### 10%
Altera ### 6%
Philips ## 5%
Chartered ## 5%
STMicroelectronics
NEC, Fujitsu, Lucent
Toshiba, Mitsubishi # 3% or less
While these numbers are generally the same as last year's, this year TSMC
and UMC jumped dramatically. Last year (2001) they were:
TSMC ############### 31%
UMC ##### 10%
Which explains why all the EDA vendors are going out of their way to say
that they work with TSMC in their press releases.
So, in a nutshell, SNUG'02 was a conference of high-end chip designers.
"The one thing I appreciated at SNUG was the poster session. I think it
is a really valuable part of the conference -- both for the presenters
as well as the audience."
- C.V. Krishna of Case Western Reserve University
( SNUG 02 Item 4 ) --------------------------------------------- [ 5/15/02 ]
Subject: Customers Rate The Best & The Worst Synopsys Tools
READING THE TEA LEAVES: The best way to find out what's hot and what's not
is to directly ask the users. Out of the 485 users at SNUG'01, 321 answered
the 2001 survey. Out of the 451 users at SNUG'02, 269 answered this year's
2002 survey. So to compare apples to apples, I scaled up the 2002 answers
by 19.3% -- the 321/269 scaling needed to make this year's 269 proportional
to last year's 321.
"6b.) Which Synopsys product are you *most* satisfied with? (write in)"
Design Compiler '01 #########################S S#################### 143
Design Compiler '02 #########################S S#################### 132
PrimeTime '01 #################################### 72
PrimeTime '02 ############################################# 91
PhysOpt '01 ########### 22
PhysOpt '02 ##################### 42
VCS '01 ############## 28
VCS '02 ##################### 41
Vera '01 ## 4
Vera '02 ####### 13
TetraMax '01 ###### 11
TetraMax '02 ###### 12
*Mill/AMPS '01 # 2
*Mill/AMPS '02 ## 4
Module Compiler '01 ### 5
Module Compiler '02 # 2
SystemC '02 # 2
FPGA Compiler II '01 ## 4
FPGA Compiler II '02 1
Scirocco '01 # 2
Scirocco '02 1
Formality '01 # 2
Formality '02 1
DFT Compiler, FPM
CoCentric, TC
Module Compiler '02 1
Looking at these numbers, Synopsys customers appear to be happier this year
(compared to last year) with PrimeTime, PhysOpt, VCS, and Vera. Hmm...
Vera's up 4X. I didn't expect to see them in this "happier" category.
"6c.) Which Synopsys product are you *least* satisfied with? (write in)"
Formality '01 ###### 12
Formality '02 ############ 23
Design Compiler '01 ######## 15
Design Compiler '02 ####### 13
Chip Architect '01 ####### 14
Chip Architect '02 ####### 13
PrimeTime '01 #### 8
PrimeTime '02 ###### 12
TetraMax '01 ## 4
TetraMax '02 ##### 10
PhysOpt '01 ##### 10
PhysOpt '02 ##### 10
VCS '01 ##### 9
VCS '02 ### 6
BSD Compiler '01 # 2
BSD Compiler '02 ### 5
Power Compiler '01 # 1
Power Compiler '02 ### 5
Scirocco '01 ## 4
Scirocco '02 ## 4
FPGA Compiler II '01 ### 6
FPGA Compiler II '02 # 2
ECO Compiler '01 ## 5
ECO Compiler '02 # 2
Vera '01 # 2
Vera '02 # 2
PowerMill '01 # 2
PowerMill '02 # 2
VirSim '02 # 2
Lib Compiler '01 1
Lib Compiler '02 # 2
Design Analyzer '01 ## 5
Design Analyzer '02 1
Test Compiler '01 ### 6
Test Compiler '02 1
VSS '01 ### 6
VSS '02 1
Floorplan Mgr '01 #### 9
Floorplan Mgr '02 1
CoreConsultant
SystemC, DWPCI
Clock Compiler
DW, Route66
MemPro, LEDA
PrimeTime-SI
RTL-Analyzer
CoverMeter
DesignVision
FPM '02 1
A quickie analysis: first off, I ignore the negative votes on DC, PrimeTime,
and VCS. There are 10 positive votes for *each* negative vote that appears
here. For example, DC has 132 positive & 13 negatives. Washes out.
PhysOpt appears to be doing even better this year. Last year PhysOpt had
10 detractors and 22 advocates (a 2.2 ratio.) This year PhysOpt again has
10 detractors but it now has 42 advocates (a 4.2 ratio.) Happy PhysOpt.
Formality is still in trouble, though. Only 1 or 2 people have ever
rated it as the "best" Synopsys tool. Last year 12 people hated it.
This year 23 people hate it -- roughly a 2X gain. Bad Formality.
Those unexpected 2.5X and 5X jumps in negative votes for TetraMAX and Power
Compiler indicate that something's going on. Keep an eye on those two.
Last year, Floorplan Mgr had 9 negs. This year it's only 1 neg. Either
Floorplan Mgr is getting better, it's being used less, or a little of both.
Lacking any positive votes, Chip Architect (13 negs) and BSD Compiler
(5 negs) are again seen as damaged goods by users. Same as last year.
Overall in the eyes of EDA users, Synopsys tools appear to be good and
getting better. Last year there were a total of 306 positive tool votes
and 144 negative tool votes, a ratio of 2.125 to 1. This year it's 344
positive to 131 negative making 2.626 to 1. What's also noteworthy
here is that users were asked to list one positive and one negative
Synopsys product in the survey question, so these ratios *should* have
been 1 to 1. That is, the users went out of their way to list extra
"best" Synopsys tools in the survey.
( SNUG 02 Item 5 ) --------------------------------------------- [ 5/15/02 ]
Subject: NC-Verilog & NC-SIM, VCS & Scirroco, ModelSim, Fintronics
GONE COMMODITY: From the Dataquest 2000 market share numbers and reader
response, Synopsys VCS and Cadence NC-Verilog each own about half of their
market. ModelTech owns 73% of the mixed Verilog/VHDL simulation market
and nobody really cares about pure VHDL simulators like Scirroco any more.
Dataquest FY 2000 Simulator Markets (in $ Millions)
Verilog Total ######################################## $120.7
Synopsys ################## $55.5 (46%)
Cadence ################## $53.1 (44%)
Fintronics ## $7.2 (6%)
others ## $4.8 (4%)
Verilog/VHDL
Mixed Sim Total ############################ $85.2
ModelTech ##################### $62.2 (73%)
Cadence ####### $21.3 (25%)
others # $1.7 (2%)
VHDL Total ####### $22.1
Cadence #### $10.8 (49%)
Aldec ## $6.6 (30%)
Synopsys # $4.0 (18%)
others $0.7 (3%)
The other thing to notice in this data is that 52.9% of designers do pure
Verilog design, while only 9.6% do pure VHDL. The remaining 37.4% have
their feet in both Verilog/VHDL worlds probably because of 3rd party IP.
"Fintronics was the surprise this year. They found out that the LINUX
server farm market is a gold mine that everyone else is missing."
- Gary Smith of Dataquest
"Don't use Verilog. Wish I did."
- Brent Lawson of Texas Instruments
"I never used NC-Verilog. I'm happy with VCS. VHDL is a four-letter
word. (Count them if you don't believe me :-)"
- Oren Rubinstein of Nvidia
"VCS and NC-Verilog are like Coke and Pepsi."
- Dave Chapman of Gold Mountain
"We use VCS. It was faster in our last tests plus we're still waiting
for further integration of Vera into VCS.
- Tom Heynemann of Compaq
"I strictly use ModelSim for both VHDL and Verilog simulations. Happy
with it."
- Kevin Hubbard of Siemens
"For small quick sims, I use ModelSim. For full tests, I use
NC-Verilog. ModelSim is useful for sub-module debugging on my
PC. NC-Verilog is useful for the Unix (X-Windows) platform with
files located on various servers. This just happens to be my setup,
and it works well. No interest for now in the Synopsys Scirocco VHDL
simulator, I'm writing everything in Verilog."
- Eric Mitchell of Cypress Semiconductor
"We needed to revert back to NC-Verilog. Until now we've used VCS for
everything, but next generation we may be migrating back to the
old guard."
- an anon engineer
"We use Modeltech for most of our internal simulations. The majority of
my consulting customers use Synopsys VCS."
- Tom Moxon of Moxon Design
"We would like to see a more direct and easy path for co-simulation of
SystemC into the MTI flow. Their new 5.6 version includes a C-debugger
so I assume they are moving down that path although not as fast as we
would like."
- an anon engineer
"VCS. For legacy reasons."
- Kalyan Chakravadhanula of Texas Instruments
"We have access to MTI, VCS and NC-Verilog. Personally I prefer
NC-Verilog. While I have not benchmarked them, VCS and NC-Verilog
are about the same speed for RTL simulations. NC appears to compile
faster. Once you use the PLI, VCS slows way down. Systemsim
(Superlog) is about the same speed but their compile feels slower,
again no benchmarks. Modelsim is nice for GUI users, but always
just feels awkward to me there is no "xl mode" with a singl
invocation like XL, NC, and Systemsim. VCS is only two easy steps,
but MTI is too many steps."
- James Lee of Intrinsix
"We deal with a mix of Verilog/VHDL, and for us Cadence NC-Sim running
on HP is our tool of choice for front-end sim. The environment's
clunky and goes down in flames every so often, but I suspect this to
be more related to HW/SW/network issues. (Hey, if I had my druthers,
I'd rather have an UltraSparc on my desk.) Compared to previous
Cadence Leapfrog versions, it seems fairly stable. There are a few
PC-based renegades here who swear by ModelSim, but I just don't feel
the necessary horsepower is there. No way would we bring VCS into
the picture."
- an anon engineer
"Last eval was 4 years ago. VCS won the speed war at that time but I
am not up to date."
- Scott Vincelette of Flarion
"I was earlier working in TI doing ASIC library (simulation models
and VITAL) development. My impression was that ModelSim is the best.
NC-VHDL is close to it. We used VSS years ago, but it was very slow
and our customers mainly used to ask for ModelSim or Leapfrog/NC-VHDL."
- an anon engineer
"Being a mostly Cadence house, we are using NC-Verilog. We do want to
evaluate and benchmark VCS, however. We would use NC-SIM if NC-Verilog
is chosen over VCS. ModelSim would be nice but since we already have
licenses for VCS and NC-Verilog, we aren't gonna spend money for
another tool. Scirocco would be interesting if we used VHDL (which
we do not)."
- an anon engineer
"Synopsys has put a lot of effort into VCS recently, especially adding
(finally) the Verilog-2000 "synthesizable subset". I have yet to
use those constructs, though, so I can't vouch for the quality.
I *did* have a significant case where VCS 5.2 in 2state mode simluates
*faster* than VCS 6.0.1/6.1 in the same 2state mode. In fact
5.2/2state was faster than *any* VCS 6.1 combination of optimization
switches. I'm working with Synopsys ACs on that. Don't know how
much that might affect other people."
- Kris Monsen of Mobilygen Corp.
"I'm a VHDL guy, not a Verilog one, thus I have little interest is some
of the above mentioned Verilog tools. However, my current FPGA/ASIC
flows are designed around ModleSim. Synopsys has never had a competent
offering in the VHDL simulation game. Hopefully the Scirocco compiler
will fix some of their deficiencies.
I actually write VHDL code which is "dumbed down" so that Synopsys VSS
will compile it. None of the other VHDL simulators (or synthesis
tools) takes such a small subset of VHDL. It will be interesting to
see how fast they come up to speed with Verilog-2000 (which adds many
of the features from VHDL into the Verilog language)."
- David Bishop of Kodak
"Cadence all the way! Synopsys tools don't follow the IEEE standard
as closely, and therefore has some delays that happen incorrectly.
Speedwise Cadence seems to win out, too."
- Fraya Cohen of Procket Networks
"Some years ago, I used QuickHDL and ModelSim to do mixed simulations
(VHDL/Verilog) with 100K gates design. It was working fine.
Today, I am using NCSIM simulator, and it's a pain. This tool does not
know how to handle mixed simulations, Signalscan makes NC-SIM crash,
each new version has its bug. NC-Verilog works fine but if you want
to do VHDL-Verilog simulations, use ModelSim."
- an anon engineer
"I prefer VCS over NC-Verilog. A lot of my simulations are gate level
and some require SDF backannotation. VCS having the ability to compile
SDF reduces my memory usage and runtime. It is also more mature at
the gate level. One problem that has crept up occasionally with VCS
is mismatches on no timing scan chain simulations because of event
scheduling. I believe Synopsys has fixed this."
- an anon engineer
"We only use NC-SIM and ModelSim, so I can not comment on VCS part.
Between ModelSim and NC-SIM, personally I prefer ModelSim a bit more.
We have no problem for NC-SIM and ModelSim to integrate into our
design flow.
We are interested to Scirocco VHDL simulator as well because of it's
SystemC simulation support."
- Hui Fu of Infineon
"We had Verilog-XLs, NC-Verilogs and VCS - everything. It was always
a neck-to-neck between NC-Verilog and VCS although recently we have
observed that VCS has surged ahead with release 6.1. NC-Sim would be
interesting to try and we are looking at it moreso because we have
frightful prospect of sharing IP from two different languages for
future products. We will also look at VCS+Scirocco combination
for mixed mode simulation. It is the most expensive combination of
all. Interestingly, Synopsys is now pushing for Linux platforms,
especially for VCS because they have seen very good benchmarks on
superfast Intel CPUs."
- an anon engineer
"We use NC-sim. We have not benchmarked VCS so I cannot compare.
NC-Sim is very reliable and fast with only a few problems in
backannotated netlist simulation."
- Karl Kaiser of Resonext
"We're using VCS and are very happy with it. Dropping Covermeter in
for free was a good idea."
- Jeff Waite of Netergy Microelectronics
"We normally utilize ModelSim to suppport mostly VHDL designs. We have
not considered Scirocco and don't expect to unless ModelSim seriously
tanks in performance."
- Scott Campbell of Motorola
"We benchmarked ModelSim vs. NC-Sim (with NC-VHDL) independently without
any support from the vendors. NC-Sim is clearly the winner when it
comes to simulation speed. However when it comes to interactivity, i.e
the ability to change your RTL and launch another simulation, we found
ModelSim a little bit easier to use (lower turnaround time). NC-Sim
has a command to "re-invoke" the simulator after you change the RTL,
but it goes through an elaborate phase which is sometimes time
consuming. The NC-Sim GUI and waveform viewer have improved a lot in
version LDV3.4. Our benchmarking was done with versions LDV3.2, LDV3.3
and Modelsim 5.5 PE. Overall, I would say that I would pick NC-Sim
over the ModelSim. I have heard good reviews about VCS, but never
tried it. We noticed a big improvement in memory usage going from
LDV3.2 to LDV3.3."
- an anon engineer
"Where I work, we are fairly happy with Cadence NC-Verilog. We use
mixed Verilog with IP in VHDL, so we would like a lot better mixed
language support in all of the EDA tools."
- Mark Gonzales of IBM
"We use VCS based on the impression that it ran faster, but also because
we wanted to use a short list of vendors. We're using other Synopsys
tools."
- Curt Beckmann of Rhapsody Networks
"I noted that in one tract at HDLcon'02 all the papers but one said
basically, 'we are working with (standards groups, users, our
competitors) to come up with the best solution'. This was evident
in the PLI discussion from Lee Tatischef of Cadence (Best paper),
the System Verilog Accellera standard presentation, and the
Assertion standard presentation.
The last paper in the group was from a Synopsys employee on the
Direct-C interface he was working on. He made no mention of
cooperation/standards. It would be nice if he/Synopsys worked
with the other vendors. It would appear that Co-Design's Systemsim
simulator has what they call 'C-blend', which is a similar concept
to Synopsys's Direct-C. It would be nice if these guys worked
together like Cadence did with Synopsys and MTI. I'd hate to see
more needless divergence in the tools."
- James Lee of Intrinsix
( SNUG 02 Item 6 ) --------------------------------------------- [ 5/15/02 ]
Subject: Verisity Specman 'e', Synopsys Vera, Chronology/Forte RAVE
STRUGGLING FOR MINDSHARE: When I asked about Vera/Specman/RAVE usage, the
most common response I received was 'we don't use them' and 'we make our own
test suites with C/Perl/Verilog' -- which means it's one small market.
Dataquest FY 2000 Functional Test Simulator Market (in $ Millions)
Synopsys Vera #### $12.0 (43%)
Verisity Specman 'e' #### $12.0 (43%)
Forte/Chrono RAVE # $3.6 (13%)
Total ######### $28.0
Functional verification is supposedly one of the biggest bottlenecks in chip
design these days, yet so far EDA companies can't seem to make any serious
cash selling in this niche. $28 million is chump change for a *serious*
design problem. The year before it was $22.4 million. Chump change.
"The funny thing is Vera and 'e' sell to different markets. Vera sells
to the design teams. 'e' sells to the verification teams."
- Gary Smith of Dataquest
"Three new languages? No thanks. But I think the real question here
is how did these guys come up with their product naming??? It seems
to me that around the bay area, 'RAVE' and 'e' are two things that
you more commonly find in the clubs on weekends in the San Francisco
SOMA district then something you use to verify chips."
- Jeff Waite of Netergy Microelectronics
"I prefer Perl test benches. I generate input vectors in Perl and
compare output vectors with Perl. I don't really want to learn yet
another language."
- Kevin Hubbard of Siemens
"Although Specman/E and Vera are roughly equivalent in features, I get
the feeling that Specman is in the lead. I'll bet both will be dead
when System Verilog has all those features. Vera and Specman basically
highlight weaknesses in the HDL for verification, and it looks like
that's exactly where System Verilog is headed."
- James Lee of Intrinsix
"Why use Vera/e/RAVE? C/C++ is the way to go. You can do anything you
like and C/C++ doesn't handcuff you like those 3 do."
- Scott Vincelette of Flarion
"e: I love its macros. I can add just about any construct I want to.
It's like a back door into the language. I hate all those curly
brackets and semi-colons. (Also, add good debug environment,
will ya?)
Vera: I love the stream generator. Someone did their homework on
this one. Please, please, please let me add constraints
standalone, and while you're at it grow the constraint language
(and the conflict checking).
Having worked in both 'e' and Vera for several years now, I typically
like the one I am not currently using at the time."
- Peet James of Qualis
"Don't use either. Can't get excited about learning 'e'. (Have you
seen the manual?)"
- Brent Lawson of Texas Instruments
"I don't use any of these. I typically use VHDL under ModelSim for
testbenchs."
- Donald Whisnant of John Deere
"The majority of my customers are using Verisity Specman. Personally.
I'm agnostic."
- Tom Moxon of Moxon Design
"I'm in the same boat as Gregg Lahti. These new verification languages
are all nice and dandy, but I haven't seen anything they do that can't
be done with standard tools (Perl/shell/C) to justify their cost."
- Doug Hillmer of XTAR
"We are using our internal test generator and analyzer. Using Specman
in our case required much more human resources and do not have any
advantage over our own in-house tool."
- Gideon Paul of TeraChip
"We use 'e' here, although I have used Vera before. If you are
devloping complex code I think the Specman debugging environment
is much better."
- Shirish Gadre of Sony
"These appear to be dead-end languages. Of these Vera is 'open' though
I know of only one vendor selling the tool. So all of these suffer
from the same proprietary language issues."
- an anon engineer
"Vera's what we use."
- Tom Heynemann of Compaq
"Synopsys tries to convince me of Vera with the argument of its strict
object orientation. Otherwise I (or somebody else) might corrupt data
within the deeper layers of my sources from the top. But that is
exactly what I want and this is possible with the aspect-orientated
approach of Specman and e.
Synopsys still tells the users how difficult it is to pick up e. At
the same time they refer to a bulky Vera-training book making it much
easier to pick up Vera -- why should this be necessary? And when I
have to decide between a book and substantial onsite e support where
I don't get lots of answers to questions I never asked it is rather
clear what I prefer."
- Andreas Dieckmann of Siemens
"Verisity is clearly emerging as the leader over Vera for functional
verification tools. The Specman Elite tools are easier to use, and
the growing list of third party eVC (e Verification Components)
provide a clear path toward a modular plug & play approach to building
test benches. Verisity is constantly improving their tools in order
to make verification easier. I can't wait to see what Verisity comes
up with next."
- Steven Besser of Intrinsix
"I can't really compare because I haven't tried Vera or Forte. I
attended a Specman training recently and found it easy to understand
once the concepts underlying its design were described. I like the
constraint solver and the concept of temporal expressions (just
like regular expressions, temporal expressions allow an infinite
sequence to be described using finite number of operators). There
is a learning curve associated with the e Language, but that is
true for any HVL.
The only point of comparison I have is with Cadence TestBuilder which
is basically a C++ library for verification. The biggest hurdle was
that C++ does not have language support for concurrency and garbage
collection. Therefore writing a verification environment is like doing
a C++ project. It takes a long time before there is any meaningful
testcase. There is also no debug environment for the tests. For
example, if there is a failure, it is hard to find out why. Specman on
the other hand, has GC and other features desirous of any HVL and
therefore we like it very much."
- an anon engineer
"I did not heard about RAVE before. We are using Specman and satisfy
with its verification approaches."
- Hui Fu of Infineon
"We are *very* happy with Specman. It is an orders of magnitude
improvement over our previous Verilog-only verification environment.
We last evaluated Vera a couple of years ago, but went with Specman
instead."
- Mark Gonzales of IBM
"Vera and Specman are getting the most press. I have not heard of RAVE.
We are not using any of these tools so I don't have a feel for this."
- an anon engineer
"We have talked to the sales reps but haven't selected any such tool.
Vera and e appear to be the popular choices with Vera being easier
to learn and utilize while e is more powerful. Therefore we would
probably go with Vera since we don't need the horsepower (or the
complexity) associated with e."
- Scott Campbell of Motorola
"These tools (Vera/Verisity-Specman/Forte) force a split between design
and verification. With all the languages an engineer needs to know,
adding another one does not solve any problems. Most, if not all
projects I have ever worked on re-use designer to help out with
verification. When using these new language it becomes nearly
impossible to share engineering resources. "
- Neel Das of Corrent Corp.
"We will be looking at Vera in the next 6 months."
- an anon engineer
"We use Specman partly because a partner was using it. My sense is that
Verisity is winning because their technology is good enough and they
market/partner very well. That enabled us to be creative for co-
verification. This was one case where we overrode the 'short vendor
list' approach."
- Curt Beckmann of Rhapsody Networks
"Forte's Rave is dead. Nobody bought it. Vera and Specman are still
too close to call, but I'm betting on Vera, for a variety of reasons.
The open-thing for one, and the fact that it's part of Synopsys, for
another."
- Dave Chapman of Gold Mountain
"Actually, I'm more interested in Forte's Perspective tool. We have
been asking ourselves whether there's a better way to answer the
question:
- did the test we wrote or the stimulus we generated actually
*cover* the intended specification item? i.e., did we really
test what we were supposed to test?
It seems like Forte Perspective might be a way to answer that question.
Someone, of course, would have the job of translating the design
specification document into the Perspective language, but once you
do that, Forte's tool could help you keep track of your functional
coverage.
Some of this is covered by elements of Specman and Vera, but I haven't
seen anyone coming from the direction Perspective takes.
We haven't used it yet, but we're planning to set up an evaluation."
- Kris Monsen of Mobilygen Corp.
"We don't use these."
- an anon engineer
( SNUG 02 Item 7 ) --------------------------------------------- [ 5/15/02 ]
Subject: Superlog, Verilog-2001, Synopsys SystemC, CoWare
STICKING TO WHAT WORKS: On the 'to C or not to C' question, my readers
have been very adamantly anti C. This isn't a polite 'no, thank you'. It's
a deeply distrusting we-don't-want-to-relive-the-VHDL-wars-where-a-lot-
was-promised-but-nothing-changed NO, THANK YOU. This mimicks last year's
reaction (see SNUG 01 #14) with the exception that now it's a specific
dislike for SystemC design because SystemC is the only remaining survivor
out of the last 2 year's crop of failed C-based HW EDA companies. Facing
this user wrath, SystemC had to back off and become an architectural
algorithm exploration simulation. (Yawn) Superlog and the Verilog-2001
extentions are what's capturing the attention of engineers who actually
design real chips these days.
"Superlog Superlog Superlog. By the time SystemC is done, it combines
all the disadvantages of C (a contrived event model, nor an inherent
concept of time) with all the disadvantages of HDLs (runtime
"challenges" -- continental drift anyone on a 70+ million transistor
design? -- and a lack of high level abstraction mechanisms.)
Superlog addresses these in a much cleaner way.
In addition, it's high time to dispel the myth of if we can use C to
design ASICs, then C programmers can be ASIC designers. That's BS."
- Tom Heynemann of Compaq
"Having done one core in VHDL and one in Verilog and having translated
both into the other language, I have to say Superlog as superset of
both languages best features would be THE way to go. I'd love to see
this succeed."
- an anon engineer
"SystemC and Superlog are good ideas. The problem is that they have to
be generic (work with several vendors) and be deterministic (work the
same way on several vendors tools) before you can mainstream them.
Otherwise you may be left holding the bag on code you can't use again."
- David Bishop of Kodak
"The Verilog 2000 extensions are a step in the right direction but we
need more than a step. However, I'm sure we will use whatever is
supported BOTH synthesis and simulation tools. Superlog is a natural
progression it requires minimal training and can be used for both
design and verification. SystemC will most likely become an
architectural trade-off tool."
- Neel Das of Corrent Corp.
"I don't see us using SystemC now, but possibly within a year to
18 months. You ask if I would want to.
Hmmm, I don't know C/C++ but I am afraid that C-level RTL is on its way
in. I have put off learning C/C++ but I think I will have to learn it
now. So to answer the question, no I don't want to but I think
industry is headed this way.
I like what Superlog has to offer. From what I understand Superlog can
call in C (C, C++, SystemC) for simulation, synthesize the ESS portion,
read in Verilog 2001 (Verilog 95 included) all in the familiar Verilog
environment. I find this attractive because I know that the learning
curve will not be a steep since I do not know C/C++."
- Steve Elzinga of Xilinx
"Personally, I will vote Superlog. SystemC RTL modeling is really
really terrible. I can not imagine to use SystemC for RTL modeling.
One thing I like very much is the System-Verilog's encapsulation for
the interface. This is a very useful feature for SoC integration.
And we are already doing this by using PERL script on the current HDL
based design, but it will be much more convenient if this is already
built in the language and handle by the tools. Only remaining problem
is when SYNOPSYS start to support System-Verilog? I know that now the
Get2chip can take the System-Verilog (or synthesisable Superlog), but
I also would like to see SYNOPSYS move to this direction."
- Hui Fu of Infineon
"Don't see myself using SystemC. Don't want to."
- Brent Lawson of Texas Instruments
"I think that it's plain old Verilog up in front, with Superlog a length
behind, and SystemC asleep at the starting gate."
- Dave Chapman of Gold Mountain
"C-based chip design is not the answer."
- Kevin Hubbard of Siemens
"SystemC for synthesis just doesn't make sense. Of course you can't
take any C and synthesize it, you are limited to a synthesizable
sub-set just like in Verilog. Synopsys claims they can synthesize
SystemC and get the same Quality of Results as with Verilog or VHDL
if it is written at the SAME LEVEL OF ABSTRACTION. Why bother? I
don't need another language for design that is doing the same thing
as what I already have!
I don't think Superlog is a competitor for SystemC, C is. Superlog
is a design and verification language, not a architectural modeling
language. Use plain old C or C++ for that and then simulate it with
Superlog or Verilog."
- Anders Nordstrom
"I think SystemC shows some real promise and am looking forward to
seeing how it progresses. It should make a nice addition to our
current VHDL-only design and testing. But, I probably won't be
using it within the next 6 months."
- Donald Whisnant of John Deere
"SystemC holds the most promise. I like Superlog better - but it isn't
a gate simulator, and rumours are the PLI's lacking to a certain
degree. Verilog isn't enough for testing, one needs either C++
or SystemC.
The main issue with SystemC as a modelling language, is the lack of
cosimulation capability - unless you sign up to Synopsys' or CoWares
simulators. If one came out with a reasonably priced PLI between the
open source SystemC and VCS and/or Verilog-XL - we'd buy it. Until
then, we're researching building the PLI in-house. If Synopsys would
license a full blown version CoCentric System Studio for debug, and a
dumbed down version for regressions (no GUI for a lesser price) - we'd
go for that. But alas...
We do not plan to use SystemC for synthesis, but this could change if
the language catches hold."
- an anon engineer
"We use our own C++ based library for system modeling, so I have no
experience with SystemC. However having a standard tool/library is
definitely what we want to see. It is very expensive to support your
own library. Particular the debugging support is important. So we
are starting to consider SystemC.
I observed that system engineers natural choice is a C++ based
language. I believe that it is very difficult to changes this
preference within the system engineering community to a Verilog based
language. This is not so much a technical but rather human/cultural
issue but has to be taken into account as well.
On the ASIC side, a Verilog based approach is most desirable. A
Verilog language extension is overdue and most likely will result in
the least tool problems (simulation, synthesis.)
I am not even sure whether a single language for system simulations
and ASIC design will increase the productivity. Usually two different
engineers perform these duties. It's VERY difficult to find engineers
with solid knowledge in both fields."
- Karl Kaiser of Resonext
"We do behavioural modeling in plain old C -- I have no use for SystemC
or any other licenses I have to PAY for. Been doing it that way for
over 2 decades."
- Tom Moxon of Moxon Design
"We will not use any of the 'new' languages in the next 6 months. I
prefer C/C++ for verification, and plain old Verilog for HDL. If
SystemC does the job, working in a 'standard' language would be the
best of all worlds. I don't think it is there yet."
- Scott Vincelette of Flarion
"We have been using SystemC for architecture exploration and software
simulator purposes for a while. My personal view is SystemC is
excellent for algorithm level or software level analysis. Now the
question is do you want to use this language for hardware design?
I see there can be two paths to do that:
1) Define a 'synthesizable subset', which essentially is a dumbing
down of a language. A la SystemC version 1.0 or 1.2. And if you
are describing your design at a RTL level. But then if you are
choosing this apporoach then why not stick to Verilog?
2) New synthesis approach that can do synthesis at higher level of
abstration. This would definitely take time to gain acceptance,
maturity and quality as compared to today's RTL based synthesis.
Regarding Verilog 2001, I think the acceptance should be no-brainer.
Only problem is that EDA vendors should synchronize the increments they
are supporing. (HA! good luck !!) Currently I see every vendor trying
to support whatever feature is easiest or what their 'A-List' customers
want. Regarding Superlog, I am confused if it's still proprietory or
now adopted by Accellera."
- Shirish Gadre of Sony
"Never used SystemC. No plans in the next 6 months."
- an anon engineer
"Both SystemC and Superlog try to leverage object oriented programming
to boost hardware design and verification productivity. Still the
fundamental simulation throughput is not addressed. Aart's talk
points out the big problem of simulation performance relative to the
verification need. It may be the right time for designers to think
hard about the the synchronous design discipline and adopt the
cycle based simulation technique to improve simulation performance.
Besides the simulation performance improvement, a good cycle-based
compiler can pin-point lots of severe design errors at early RTL stage.
I like to say that a RTL design good for cycle-based simulation will
have better quality synthesized output and is a much cleaner design
for static timing analysis."
- Liang Chen of Sun Microsystems
"SystemC looks promising. This is a tool which has the same syntax as
C++ and thus has every advantage of C. SystemC synthesis tool can even
generate the gate level for us. Therefore, many people think that it
will replace Verilog and VHDL. I don't see that in the near future.
I think the mindset of ASIC designer is: if I'm happy with Verilog, why
bother to change to another tool? More important, even if I changed
from Verilog to SystemC, what do I do with my legacy code?
In previous years, Synopsys emphasizied the synthesis ability of
SystemC but it backfired. Many designers, sticking with Verilog,
reported the inability for SystemC compiler to synthesize large design.
This year the approach of Synopsys is to focus on the 'system
integration' advantage of SystemC since all software, firmware,
simulation file and RTL can be written in SystemC (ideally). Yet their
marketing is very careful when they introduce SystemC in verification
area because they don't want the sales of SystemC to diminish the sales
of Vera. Their R&D guy, on the other hand, was very friendly and kept
asking me whether we'd like them to come to Cisco for a demo."
- Andrew Cheng of Cisco
"I found SystemC interesting, but no, I don't see using anything but
Verilog-2000 for the next 6 months to 1 year."
- Fraya Cohen of Procket Networks
"We are sticking with plain ol' Verilog. No plans to use any of the
other languages in the near future. I'm sure there will be some
resistance if other languages are introduced."
- an anon engineer
"Don't use SystemC/Superlog and don't yet have a need. For our chip
sizes (approx. 300k gates not including RAMs), Verilog is doing just
fine. And besides, we have an internal ANSI-C simulator that a
software guy here loves to create C models for. He translates our
Verilog *after* it's been written and doubles as a good code reviewer,
too. And a lot of each new chip we turn out is built from exiting
new IP, so dropping in new C models to test various functions
becomes a pretty quick process for us."
- Jeff Waite of Netergy Microelectronics
"Don't know SystemC well. Superlog / Verilog 2000 seem very close, and
I would prefer a standard. Definitely would not initiate design on new
chips in the next 6 months with any of them. In 12 to 18 months I would
consider it depending on industry support."
- Curt Beckmann of Rhapsody Networks
"We won't be using SystemC design for the forseeable future. Seems that
there's enough juice left in Verilog (-2000, and other variants) to
satisfy us for a while.
I've been reading through some of the Verilog-2000 IEEE standard. It
improves many aspects of the language, no doubt, and I am sure that
we'll take advantage of it.
No offense intended towards the many people who worked on it, but there
were some things not included that would have made life much simpler
for me:
1. Generate statements that can generate module *ports*, not just
internal logic/instantiations, etc. Yes, we are actually writing
code doing this, crazy as it may seem. It comes in handy. We're
solving this right now using "generator pre-processing scripts".
A bit ugly. Unless I'm missing something in the standard...
2. A simple namespace directive like C++. Verilog-2001 has a pretty
complex "config" construct, and I still have to figure out how to
use it. Maybe it will solve our problem, but I don't think so.
Would be nice to change one "namespace" line & have it encapsulate
all our module names, etc. in a separate namespace.
Anyway, we'll definitely migrate to Verilog-2000 (2001?) over time, and
I hope that some good work comes out of the Accellera standards efforts
and System Verilog."
- Kris Monsen of Mobilygen Corp.
"SystemC could provide the object-oriented features VHDL lacks. It's
not a requirement for success. For now, VHDL is enough."
- an anon engineer
"Verilog 2000 seems like the least worst of the bunch. SystemC looks
like it combines all of the bad features of C with all of the bad
features of HDLs. I would rather become a goat farmer than design
with SystemC.
- Mark Gonzales of IBM
"I am interested in using SystemC for simulation program. The reason
is when doing simulations, it is unnecessary for test bench programs
to meet actual hardware requirements. VHDL is a very foolish language,
no flexibility. I don't use Verilog, either. SystemC introduces C
programming style into hardware simulation program. But I think there
are still obstacles to use SystemC, at least now I am not sure if
ModelSim software supports the SystemC."
- Weng Tianxiang of Micro Memory, Inc
"I have no use for SystemC. Superlog could be interesting, but less so
since the Verilog 2001 standard appeared. Verilog-2001 is the one I'm
interested in, because it addresses some of the Verilog weaknesses,
especially the genif statement and always @*"
- Oren Rubinstein of Nvidia
"If the language war was over, and supposedly won by Verilog, why are
all these languages/variants popping up that add all these great 'new'
features that VHDL users have enjoyed for years? Assertions in RTL?
User-defined, abstract, and/or enumerated data types and structures,
even on ports? All of these have been available since 1987 in VHDL.
My only hope with all these 'advances' is that, if and when VHDL
finally goes away, I won't have to go backwards to the next best
language. Since 1993, when VHDL added the ability to directly
instantiate entities, even the major objection to VHDL (the cumbersome
component definition and configurations) has been unnecessary. Y'all
go ahead and keep working on Verilog and it's variants; maybe some day
it will get better than VHDL, and then I'll switch!"
- Andy Jones of Lockheed Martin
"I don't know what kind of HDL most ASIC designers will use in the year
2010, but it will be called 'Verilog'."
- Steve Golson, guest speaker at SNUG'02
( SNUG 02 Item 8 ) --------------------------------------------- [ 5/15/02 ]
Subject: Synopsys 'Eagle-i', NDA 'Ketchum', & NDA 'Verification Analyst'
LOST OR PRESUMED DEAD? Last year Eagle-i, a C tool, quietly disappered from
the SNUG radar screen. Apparently it had died, & nobody noticed. (See
SNUG 01 #26.) This year, two Synopsys tools ('Ketchum' & 'Verification
Analyst') that I had been tracking under the Synopsys NDA cloak have
disappeared. They were verification tools similar to 0-in (SNUG 01 #23).
Dataquest FY 2000 Formal Analysis Market (in $ Millions)
0-in # $1.1 (51%)
Averant # $1.1 (49%)
Total ## $2.2
I know there have been layoffs at Synopsys over the past 8 months. Maybe
Aart just decided that a miniscule $2.2 million market was small potatoes
not worth chasing after.
"Those functional verification guys will all be bought up next year
when that market consolidates. Last count there are 81 of them.
This is ridiculous. It should be 3 or 4."
- Gary Smith of Dataquest
( SNUG 02 Item 9 ) --------------------------------------------- [ 5/15/02 ]
Subject: Synopsys TetraMAX & Mentor FastScan
WHERE THERE'S SMOKE: Something's up with TetraMAX. Last year, 4 users
listed it as Synopsys' worst tool. This year, 10 did. I'm also seeing a
50/50 split of user letters liking TetraMAX and its rival FastScan.
Dataquest FY 2000 ATPG Market (in $ Millions)
Synopsys ############### $15.1 (52%)
Mentor ########### $11.3 (39%)
SynTest ## $1.5 (5%)
Fluence # $0.9 (3%)
Last year, Mentor had a 24% marketshare and Gary Smith of Dataquest had
even said in the SNUG'01 Trip Report that "Mentor's marketshare should
continue to shrink." Something's going on with TertraMAX *and* FastScan.
Ironically, Synopsys owns 51% and Mentor only owns 20% of the market of all
the test tools that aren't ATPG (like scan insertion, BIST, BSD Compiler,
etc.) Maybe that's what Gary was talking about last year...
"Mentor has put more emphasis into DFT development than Synopsys has
over the past year and the numbers show it."
- Laurie Balch of Dataquest
"We bought TetraMax, again because of the 'minimize vendors' philosophy,
but I think we might have had a little easier time with FastScan. We
used LogicVision for Memory BIST and JTAG."
- Curt Beckmann of Rhapsody Networks
"We use TetraMAX here. We have had actual silicon results here with
success. The TetraMAX solution requires no further library model
support. (We can use the Synopsys libraries already provided for
synthesis.) TetraMAX has also been a natural migration from the old
Test Compiler. Other groups are using FastScan. Our group here has
no experience with this tool, however."
- an anon engineer
"I prefer FastScan. It takes longer to figure out, but it's alot
more flexible. Also supports custom tap controllers and scan
chain reordering."
- David Bishop of Kodak
"TetraMax. We like one stop shoping."
- Brent Lawson of Texas Instruments
"We use FastScan and I like the tool. The DeBussy GUI helps a lot to
debug some of the DFT issues fast."
- Karl Kaiser of Resonext
"I'm agnostic. But my customers are using Mentor Fastscan."
- Tom Moxon of Moxon Design
"I have tried a few different ATPG tools over the years and TetraMax is
the easiest one I have ever used. It has good on-line help manuals
and decent debugging features. It also generates ATPG vectors very
fast. A feature I would love to see would be the ability to mask out
specific flops in specific vectors in the generated WGL file using the
command line instead of post-processing scripts."
- an anon engineer
"The TetraMAX product was not presented in a very good light at SNUG.
They indicated a full design of several million gates was run through
TetraMAX and it checked 3 critical paths. Only 3 paths in a million
gate design? They indicated the tool has since been improved and does
a much better job, but did not give statistics. If this is their idea
of test coverage, then Synopsys needs to rethink the ATPG area."
- Pallab Chatterjee of SiliconMap
"We prefer FastScan."
- Scott Campbell of Motorola
"We use Mentor Fastscan, but I am not sure why we have not looked
at Tetramax."
- an anon engineer
"We are using FastScan since its more user friendly, so we save time."
- Gideon Paul of TeraChip
"We use DCXP + Tetramax. Never looked at Mentor."
- an anon engineer
"We chose Mentor's FastScan and MemBist architect as it simplified the
DFT 'effort' for us, given that Synopsys did not have an offering for
memory BIST. Our FastScan vs. TetraMax study did not reveal any
compellingreasons to go either way, however."
- Neel Das of Corrent Corp.
"Tetramax is a great tool! I was one of the first users. The GUI is
much better than FastScan's and allows me to debug issues very quickly.
For example, I've tried to use the FastScan GUI to debug why a fault
was not detected and FastScan just hung. TetraMAX shows the
appropriate data immediately. Support is very good. I've been doing
some benchmarking between FastScan and TetraMAX lately, and TetraMAX
is much faster. It didn't help my opinion of Mentor when I went to
training and for any moderately difficult question I asked the trainer,
he answered 'well, just use TetraMax.'
BSD Compiler: Why would anyone use this thing? If you are doing memory
BIST with Logicvision, their flow works very well. Some of my
colleagues argue that the ability to do compliance checking with BSD
Compiler is valuable, but LogicVision generates a testbench that
simulates very quickly.
ILM models: Synopsys really plugged these during SNUG. I have two
thoughts on ILM models:
1.) I hope they are more robust than Stamp models, QTM and
any other model Synopsys has tried in the last few years.
2.) It would be great if they work for scan insertion. Not
because of capacity, runtime etc. but because it would be
a way to finally have DC stitch without changing anything
inside a block.
I don't know how many times I've don't touched a block that had scan
stitched, only to have DC mess with it. All I wanted is to hook up
its scan chains at another level."
- an anon engineer
"TetraMax and Fastscan have similar performance. For me, both tools
can be interchangeable."
- Hui Fu of Infineon
"Thank God for ASIC vendors who take care of scan and JTAG insertion.
I don't want to go there."
- Kevin Hubbard of Siemens
( SNUG 02 Item 10 ) -------------------------------------------- [ 5/15/02 ]
Subject: Verplex, Chrysalis, Synopsys Formality, Mentor FormalPro
THE EMPIRE STRIKES BACK: Last year users crucified Formality in the SNUG'01
Trip Report. It was brutal. Out of the 27 e-mails I received then, 22 were
pro-Verplex and only 5 were pro-Formality. (See SNUG 01 #15.) Users took
great joy in praising Verplex while trashing Formality. But it appears that
at least some of the Synopsys Formality R&D staff noticed this and spent the
last 12 months fixing things. This year, there were 28 e-mails; 14 were
pro-Verplex; 12 were pro-Formality; 2 pro-Chrysalis; and 1 pro-FormalPro.
Formality hasn't 'won', but it's definitely now a viable rival to Verplex.
Dataquest FY 2000 Formal Verification Market (in $ Millions)
Synopsys Formality ############## $14.0 (44%)
Verplex ########### $10.5 (33%)
Avanti/Chrysalis #### $4.1 (13%)
others ### $3.2 (10%)
"Gee whiz, I didn't even realize that Mentor *had* an equivalence
checker, despite the fact that we have other Mentor products
in-house. They're definitely behind on mindshare, then. :-)
With Formality and Chrysalis, I can't see Synopsys continuing to
support two equivalence checkers, and I'm not sure which one will
win. Formality has the Synopsys in-house advantage, but with
formal verification, Chrysalis might be the right choice. It
might be the way for Synopsys to alleviate concerns about inbreeding
with Design Compiler.
Verplex hasn't made debugging any easier with its new versions
(disclaimer: I haven't played with version 3.3 yet). But it
continues to be powerful enough to handle all the designs that
get thrown at it here, and it's straightforward to set up and
run. And it's surprisingly fast. So, all things considered, I'd
say they're still ahead. They're definitely ahead politically,
and I have no complaints about the technology."
- Natalie Overstreet Ramsey of Vitesse
"We received a Verilog RTL design and a Verilog netlist that was suppose
to partially match. The design had 50 modules. We started with
Formality. Some of the Verilog files couldn't be read in. At that
point the guy that worked on this specific module tried to run
Verplex - and it passes smoothly. This happened on several modules.
To be fair with Formality, many of the modules caused Verplex to just
hang up and not finish. We tried them in Formality and they passed.
My conclusion is that there is no absolute 'best tool'. We are lucky
to have both so we can easily switch between the two and have the
best from both worlds. If someone would ask me which tool to use if
he can afford only one, I would probably say Verplex but definitely
recommend using both."
- Shimon Gur of Conexant
"Chrysalis and Formality have worked fine for me. Results are all
that count. Never heard of the other two. How many equiv checkers
do we need?"
- Brent Lawson of Texas Instruments
"We recently evaluated Verplex vs. Formality. Our conclusion was that
both tools are equivalent, and we decided to go with Synopsys mostly
for business reasons. We already taped out two designs with Formality
and although we found some bugs and some limitations (mostly in the
hierarchical RTL-to-flat-gates domain), we are very happy."
- Nir Sever of Zoran
"I have not tried Mentor's FormalPro. I feel Verplex is simple and best
for most of the ASIC designs. It works faster than others. It lacks
the TCL interface which Synopsys tools provide. We gave up Chrysalis
since it makes life complicated without providing any benefits."
- an anon engineer
"We consider Verplex the market leader with Formality a close
second. We expect to go with one of the two within the next
6 months."
- Scott Campbell of Motorola
"After 3 years, Formality still has problems verifying RTL vs gates for
multiple instanciated multipliers."
- an anon engineer
"Verplex, Verplex, Verplex. We did a benchmark on a DSP based block,
letting the FAE's of Verplex and Formality grunt it out. Verplex took
5 minutes on our block, Formality 55 minutes. Also taking advantage
of FAE's, Verplex was able to handle our whole chip (1M gates with a
lot of DSP). Formality struggled and was newver able to complete.
Currently we're running a gate-to-gate Verplex comparison on the same
design and it completes in 10 minutes on a 2.2GHz Linux box. Amazing."
- Scott Vincelette of Flarion
"In the middle of a tapeout, we were using Formality and Verplex LEC
to help verify our backend transformations. It turns out Formality
showed a failed verification, while Verplex showed a successful
verification. I was worried about the discrepancy, so I called our
Synopsys ACs to ask for their help. Quickly, they determined that
our design did indeed have real errors and isolated the errors down
to the faulty module.
It turns out our backend tools actually swapped port directions on
several lower level modules. While I could've reproduced this result
with Verplex, given the information from the Synopsys ACs, I'm glad
we were able to automatically identify the problem in time with
Formality. It's nice to avoid problems downstream. I'm glad that I
didn't trust the Verplex alone, and double checked with Formality."
- an anon engineer
"We tried Formality and got memory segmentation faults. Then we tried
Verplex and it was able to do a better job. The tool is simple enough
and quite fast. However we also found issues with arithmetic elements
like multipliers which forced us to recode some of our design to
satisfy Verplex. But Verplex Inc. was quite supportive helping us to
resolve the issues."
- Karl Kaiser of Resonext
"We use Formality (again 'short vendor list'). Only did gates to gates
comparisons."
- Curt Beckmann of Rhapsody Networks
"I've only used Chrysalis, no experience with the others. It does the
job, but you'd better have a big memory machine."
- Tom Moxon of Moxon Design
"Six months ago we started to use Formality as a equivalence checker
between the RTL and the final routed gate netlist. During out final
verification, our testbenches passed the netlist but Formality flagged
a difference between the RTL and gates. Initially we though that
Formality was incorrect, but as we looked into the problem more, we saw
that the testbenches actually did not cover all tests and there was a
difference.
From that moment on, Formality has become a important part of the
verification flow for us."
- Paul Kelleher of Motorola
"We did some evaluation and Verplex was the best overall. I can't
give any details."
- Hemant Kumar of Morphics
"Verplex is #1, Formality is #2, Chrysalis is at #3 and falling, and
FormalPro looks like another Mentor pipe dream at the moment. I got
on board with Verplex last year, and though we hit the 'hidden switch
nightmare' with this tool (which Synopsys customers are very familiar
with) overall it worked. Note that a big part of any formal
verification tool is a very good support structure. The ASICs I put
through the tool actually resulted Verplex support spending a day
with us to get the designs through."
- David Bishop of Kodak
"I had a chance to test Formality 2002.03 on our 1.3 M gate design that
we split into 3 partitions. There were several levels of hierarchy
under each partition. For this evaluation, we did an equivalence check
of our design's taped out netlist (scan+clktree+PhysOpt+ECO+etc.) to its
corresponding RTL (VHDL) source code.
Runtime Memory Usage Diskspace Gate Count
(min) (max) (bytes) (instances)
Par1 123 2,234 MB 21,829,047 499,240
Par2 64 1,431 MB 12,577,337 329,912
Par3 138 2,386 MB 18,853,207 533,912
With some mapping rules, we were able to verify all units successfully.
Most of our verification was done using bottom-up approach except for
Par2. Once a design was compiled into a container at the partition
level, it can be reused for comparison and debugging purpose. This
reduced compilation times when we worked on same designs. This version
of Formality has a hierarchical write script available to propagate
constraints down to lower modules for bottom-up compares. It also
picks up IEEE libraries and other Synopsys libraries automatically.
Formality can also read in libraries in db format for faster runtime."
- an anon Intel engineer
"Chrysalis is not in competition anywhere. It is an interesting fight
between Verplex and Formality. We recently did an eval on Formality
and found it quite useful. A design that was not even able to read
into Chrysalis passed RTL -> Gate in 4 hours using Formality."
- an anon engineer
"I don't see formal verification as cost justifiable for RTL designers.
If your RTL doesn't match your synthesized gates, chances are your
Formal Verifier is going to have problems, too, (or your RTL is cr*p)
and report lots of false negatives, etc. I do see a need for Formal
Verification on scan insertion, but I don't mess with that."
- Kevin Hubbard of Siemens
"Formality: It seems like Synopsys had to play in the FV market so they
just came out with something! Very limited, you can not do half the
things you can do in Verplex such as black-box pin mapping. Crashes
constantly and we saw some dangerous assumptions that were being made
during HDL read. The TPT was too much on Formality!
Chrysalis: I think when this tool was written, it was meant to do
EVERYTHING in the world! This is why it is very hard to use, too many
concepts to learn just for simple verification. The messages are not
clear, the same message can be in multiple places. The TPT for designs
that were easier to run thru Formality was large for Chrysalis. It was
good with aborted points but lack of other capabilities made it too
difficult to use.
Mentor FormalPro: Isn't this very old tool? Heard the name from some
of my co-workers, did not hear many good things!
Verplex's Tuxedo: If all above tools are 'og', then Verplex is
'EXCELLENT'. Two things top the chart, TPT i.e. it is lot faster than
any of the above tools, secondly the capabilties in the tool are very
impressive i.e. name mapping, black-box pin mapping, port mapping,
capability to save maps and re-use later, capability to write Verilog
for anything that goes in the tool (.lib, .spice, .vhdl), plus very
good logic-transistor-extraction capability. The switch b/w LEC/SETUP
mode is sometime a nuisance especially when some commands only work in
one mode and not the other, but this is very very minor compared to
other things we get from Tuxedo. The TCL interface moving forward is
a big plus, too."
- an anon engineer
"Verplex is still the king. This year, there's only one paper that
talks about Synopsys Formality. Furthermore, that paper talks about
using Formality in FPGA design, not ASIC design. I think Synopsys will
never have success in Formality. After using Synopsys DC for
synthesis, why on earth do we want to use another Synopsys tool to do
the equivalence checking? People would rather use the not-so-user-
friendly 'Chrysalis' to avoid using Formality."
- Andrew Cheng of Cisco
"One thing I can say about Formality 2002.03 is: no more MainWin!
Hooray! I can't be the only EDA user fed up with installing the
constant stream of O/S patches and deleting endless ~/.wind*
hidden directories.
Oh, and the new debug features in Formality are pretty cool, too :-)"
- Tom Fairbairn of 3Com Europe Ltd.
"We used to use FormalPro but found it pretty painful. We beat up
Mentor pretty hard and they started putting in some more useability
features which made significant improvement, and I believe they will
roll these into future releases. They were hierarchical block-by-block
hierarchical FV of RTL-RTL.
We evaluated Formality and found it a lot easier to use out of the box.
We now use Formality for RTL-RTL (VHDL to Verilog; as we supply both
flavors of IP) as well as RTL-gates. Formality has some very nice
debug features. We decided to buy it, and now support it to our IP
customers.
We also evaluated Verplex and liked it a lot but their business model
made no sense. They would not do Global WAN licenses. I also didn't
like the way they throw FUD about the Formality logic synthesis being
related to DC; even though Synopsys license the synth engine for
Formality from Interra."
- an anon engineer
"In one case, I inserted a bug in a design with a multiplier. Formality
can verify it (the previous version could not). But, with four bugs
added to the original design, even the current version cannot complete.
In both cases (with one and four bugs), Verplex LEC caught all the bugs
with almost the same runtime as when no bug is inserted."
- Hiroshi Furukawa of NEC
"I had a chance of using new Formality 2002.03 for my 15 million gate
design. I have been using 64 bit Formality because 32 bit version was
failed before. Now I have no problem to use 32 bit version and 64
bit version. In some cases, 32 bit version was faster. And the new
GUI become faster to be coming up. Most verification for such a
huge design could be done in 5 ~ 7 hours."
- an anon engineer
"We are using both Verplex and Formality. Verplex is winning now.
Verplex has a better GUI and better debugging tools, but has somewhat
of a bigger learning curve than Formality. Formality seems to be able
to do simple jobs quickly but is hard to work with when debugging
larger designs. Verplex is MUCH faster in run time. Synopsys is
putting more support into Formality so it should improve."
- an anon engineer
"I think that Verplex is more mature, but is not enough user friendly.
Mentor FormalPro is much more user friendly, easy to use, and gives
faster results but it's not enough mature."
- Gideon Paul of TeraChip
"I have about two years of experience with Formality and Verplex LEC.
We use them for block-level RTL2gate and full-chip gate2gate
equivalence check. For our million gate design, I tried to set
up both tools but finally integrated Formality into our flow.
The problems I saw problems with LEC were when some blocks ended up
with aborted points even if I set compare effort high and some blocks
rely on specific Verplex version to pass. Formality also needed some
workarounds like using an earlier version to read in the design. But
other than that, all 11 blocks went through 2001.08-FM1-SP2.
Runtime for each block in Formality was less than half hour on Solaris
and even less on Linux machines. Generally I saw 2-3X speed-up on
Linux machines. LEC used to be faster than Formality. Not any more."
- an anon engineer
"We began using Verplex after an eval that had also looked at Formality.
We'd found Verplex to be significantly easy to come up to speed on, and
it had better debugging capabilities."
- Neel Das of Corrent Corp.
( SNUG 02 Item 11 ) -------------------------------------------- [ 5/15/02 ]
Subject: Design Compiler, Ambit-RTL, Get2chips, Synplicity ASIC, Incentia
ATTACK OF THE CLONES: Not much has changed in the ASIC synthesis market.
Synopsys Design Compiler still easily dominates against 4 rivals.
Dataquest FY 2000 ASIC Synthesis Market (in $ Millions)
Synopsys ############################### $154.7 (87%)
Cadence/Ambit #### $18.7 (10%)
others # $5.2 (3%)
Cadence's Ambit BuildGates is the distant 2nd place contender to DC, but it
has all the problems & support of a low importance tool inside the Cadence
empire. As far as I can tell, it's just a basic synthesis tool. I'll wish
you luck if you're using Ambit on a large design with multiple unrelated
gated clocking and scan issues. You'll need it.
Get2chip.com may not have Ambit's 10% market share (yet), but they seem to
be focusing on building better RTL synthesis. You'll get better support
from them because it's their cash cow; but this may disappear if the rumors
about Cadence buying Get2chip.com are true.
Despite the media hoopla (ESNUG 393 #3), Synplicity's Synplify ASIC appears
to be a greener version of Ambit. Over the past 12 months, Synplicity has
reported to the Wall St. analysts in their quarterly conference calls that
their ASIC synthesis tool has a grand total of 12 customers. That's still
beta country as far as I'm concerned.
And Incentia from Taiwan? I'll let Nvidia's Oren Rubinstein describe
them: "Ambit had potential before being acquired by Cadence. Synplicity
never got past the FPGAs (not seriously, anyway). I tried Get2chip about
a year and a half ago. It wasn't there yet, but I don't know about its
current state. What is Incentia?"
Customers do like the idea of having viable alternatives to Design Compiler.
But users have too many scripts and too much personal know-how invested in
Design Compiler. It's just not worth it to them to risk *their* chips (or
*their* careers) on any of these alternatives.
"Price isn't everything, or we'd all be driving Yugos."
- Gregg Lahti of Intel (ESNUG 333 #2)
"Competition is good, even if I'm not using the competition's tools."
- Neel Das of Corrent Corp.
"DC works. Everybody speaks it. I'm stick'n to it until somebody
else has 50% market share in ASIC Synthesis."
- Kevin Hubbard of Siemens
"We have both Synopsys and Ambit licenses. However Ambit does not run
on Linux. Synopsys is consuming a lot of MIPS compared to Ambit but
a fast Pentium4 machine with Linux can makeup for some of this.
Therefore Synopsys on Linux is our choice. We also use Power Compiler
to insert clock gates which we have not tried with Ambit."
- Karl Kaiser of Resonext
"We did very careful detailed comparison between Ambit and Synopsys
synthesizers and we got to the conclusion that they give identical
performance, but Ambit cost 1/5 of Synopsys and have also built-in
scan insertion mode with no extra charge. So Ambit is our RTL
synthesis tool."
- Gideon Paul of TeraChip
"Never used ACS (Automatic Chip Synthesis). Can't we just have a
stable flow for a few years? (kidding) Synopsys is still the best.
Investment in scripts and knowledge keep it that way whether it is or
not. And it's 'Design Vision' now, DC is passe."
- Brent Lawson of Texas Instruments
"All of my customers are nowing looking into new synthesis tools. They
use Synopsys DC as the reference, and then take the best results from
Incentia or Get2chips, both which are producing good results
with faster runtimes."
- Tom Moxon of Moxon Design
"SNUG'02 Paper: RTL Coding and Optimization Guide for use with
Design Compiler, Jack Markshall, Tera Systems
This paper focused on the impact of RTL styles on synthesized logic,
specifically when using Design Compiler for synthesis. This paper was
so full of value, it should be referred to before starting any new
project, and probably several times during a design cycle. Suggestions
are made for pre-coding checklists, the importance of paying attention
to DC messages, rewards of preparation. The paper on the CD, as well
as in the manual, is a bit mixed up, with the general slides listed
first, followed by appendix slides which had the real meat. Rather
than just parrot the slides, I would just make a recommendation that
this be read and used as part of our design cycle."
- Eric Mitchell of Cypress Semiconductor
"We like DC and have yet to see overall incentive to change. We used
ACS for our last chip, liked it, and plan to use it again on our
current chip."
- Jeff Waite of Netergy Microelectronics
"About ACS: I think its good but costly. Why? It's because most of my
jobs per block, takes on an average of 10 hrs. My design is over 10 M
equivalent gates, divided in approx 30 blocks. Each block is thus
300k+ gates. Using ACS means I need to give-up on 1 license which will
manage all the jobs. I have my Perl scripts which manages the jobs. A
separate Perl script summarizes the report on all the blocks, and also
tells me if the job has not finished.
It will be useful if the main process can manage the other jobs as well
as synthesize a block or few in spare time."
- Hemant Kumar of Morphics
"The conservative part of me says: keep what works, what you've had
years of experience using. Design Compiler is mature, has been for
years, and 'everybody' uses it. We have zillions of scripts. Don't
stir up a hornet's nest & get stung.
The other part of me says: man, they charage a lot of money, and the
tool, despite what they say, still doesn't do a great job of compiling
complex designs top-down. I'd love to be able to use Get2Chip's tool
(we've played with it some). They seem to be taking the right approach
to the synthesis problem for BIG designs. And as a small company, they
seem willing and eager to work with you on both technical and business
side of things. Haven't tried Ambit or others."
- an anon engineer
"Design Compiler is still in the lead. I would like to see someone
compete, but have yet to experience this."
- Scott Vincelette of Flarion
"DC seems to work fine for us as a synthesis engine, although I can't
say we've ever considered alternatives. I won't say its the best tool
for the money. The guys at Cadence would probably pay us at Philips
to publicly endorse Ambit, but then other people have to deal with
that problem not me. I just want my design to work and if we have to
pay insanely high maintenance/license fees to Synopsys Inc for it, so
be it. But I don't have to be happy about it."
- an anon engineer
"We are a long time users of Design Compiler, and it wasn't even
considered to try anything else. However, through an acquisition,
we got hold of few Ambit licenses. Couple of months ago, we were in
a situation in which we were short of DC licenses because a few
projects entered synthesis at the same time. I suggested to one of
the project managers to give Ambit a try and it was a success. After
a relatively short time, the scripts were converted, and with good
support from Cadence, we were able to run the entire project in Ambit.
The results were comparable to DC (some blocks better, some worse).
For the final runs, we will probably switch back to DC, but as I see
it, we will start using Ambit more and more in future designs."
- Nir Sever of Zoran
"We have been doing some comparisons between Design Compiler and Ambit
and the results are slightly better for Synopsys than for Cadence. The
big advantage on Ambit is the time it takes to synthesize the designs.
Since we prefer results over a short synthesis time, we will continue
to use Design Compiler.
Regarding ACS, it reduces the scripting time but the results appear to
be slightly worst. Nothing is free."
- an anon engineer
"Although ACS is nice it is an additional $ which 99% of my client base
have never needed. In fact with the improvements to DC with simple
compile mode; I get acceptable results that I can then do a "compile
-inplace" on after the first P&R run. Many of my designs are big but
not fast!
I think Synplicity ASIC will fall flat; the CTO does know his stuff,
but I haven't met an ASIC design which can use a pushbutton flow. You
didn't mention Exemplar, they have had an ASIC flow for years!
Get2Chips and Incentia have interesting stories to tell, we'll have to
see how they fare. Given the fact that they have completely re-written
the database from scratch they may have something!
Cadence is still pushing Synopsys, which is good, and the little
startups are just beginning to address issues that Synopsys may not
have identified. The capacity vs. speed issue being a big one. It was
great when DC allowed us to grow from 5K blocks to 25K blocks to 100K
blocks in a couple of releases. We still have capacity issues which
the little guys are solving, new database without any legacy stuff,
which Synopsys can't match."
- Tom Tessier of t2design
"As mainstreamers we expect to stick with Design Compiler and will
probably migrate to PhysOpt eventually."
- Scott Campbell of Motorola
"I tried Ambit Buildgates about a couple of years back. Based on what
I've seen, I can tell you that its not worth wasting your time on.
Synopsys was way ahead. It really pains me to see these startups who
make tall claims about their tools when their underlying technology is
not vastly different from Synopsys. They do not publish any technical
details about their technology, but use terms like 'pin-based timing
analysis' and 'behaviour extracting synthesis' to justify why their
tools are better. As if I'm supposed to know what 'pin-based timing
analysis' is all about.
When we benchmarked Ambit, we began to discover so many limitations.
It's VHDL support sucked big time. There were no DesignWare quality
components to use. When we changed our RTL so that it could be read
into Ambit, we found that there were errors in the generated netlist.
So we decided to give up.
Basically, companies like Cadence and Mentor were built on efficient
schematic and layout generation. They probably thought that synthesis
will never be the preferred way of implementing designs - and that's
why they're struggling to catch up.
I tried ACS, too. It's remarkable how Synopsys can keep thinking of
such things. For designs with simple clocking schemes, etc., ACS
compiles are the best. It takes us hardly any time to get a netlist.
I am waiting for something that will couple ACS with PhysOpt, which is
now becoming part of our synthesis flow."
- an anon engineer
"Design Compiler rules. Ambit had potential before being acquired by
Cadence. Synplicity never got past the FPGAs (not seriously, anyway).
I tried Get2chip about a year and a half ago. It wasn't there yet,
but I don't know about its current state. What is Incentia?
As for ACS, it doesn't fit in our current methodology, but it's a good
idea, so maybe I'll try it one of these days."
- Oren Rubinstein of Nvidia
"If Synopsys gets some major competition in the ASIC synthesis area,
I will jump on the band wagon. Synopsys's price increase from two
years ago is still stuck in my throat. ACS is something which has
been in Exemplar and Synplicity for years for FPGAs, and Synopsys
is just figuring it out now for ASICs."
- David Bishop of Kodak
"We only use Design Compiler and are not very knowledgeable about the
other options, though I'm quite pleased that others are giving Synopsys
a challenge. I don't like having just one big gorilla in the market."
- Curt Beckmann of Rhapsody Networks
"I'm only using Synopsys Design Compiler currently. I've used
Synplicity for FPGA prototyping, and there were some oddities that
needed sorting out before everything would compile. I'm a big
fan now of DC."
- Eric Mitchell of Cypress Semiconductor
"We are using Design Compiler exclusively. We are not using Automated
Chip Synthesis (ACS). Synopsys tech support beats Cadence hands down
so we are sticking w/ DC. Haven't tried any of the smaller players.
Libary support would be an issue for other tools outside of DC."
- an anon engineer
"Due to the lack of competition, Design Compiler hasn't make much
improvement for the past year. Synopsys is undoubtfully the biggest
guy in the landscape. The trend among synthesis users is to use 'ACS'
(Automatic Chip Synthesis). For large chips this is the way to go.
Though there were no papers for ACS this year, the tutorial session
did spark lots of discussions about this methodology.
DC Ultra license won't be integrated into DC in the near future.
Synopsys still wants to make the most $$ out of it."
- Andrew Cheng of Cisco
"Synthesis Highlights in DC 2002.05:
+ Support for ILMs in synthesis
+ Improved Verilog reader can distinguish between netlist and RTL
+ Better handling of bidirectional ports
+ Fix DC-TCL memory requirements
+ Many other minor improvements
DC-Ultra Enhancements:
+ Better FSM/datapath optimization,
+ compile_ultra command reduces variables that need to be set.
Advanced Chip Synthesis (ACS) is a tool in DC to:
+ Budget lower level partitions from top-level constraints
+ Provides Top-level synthesis commands
+ Manages parallel synthesis jobs on multiple CPUs
Q: How does the ACS parallel job function compare to Makefiles?"
- Kent Ng of Microsoft/XBox
"Synthesis Highlights in DC 2002.05:
- significant runtime enhancements
- can create on-the-fly Interface Logic Models (ILMs) to improve
capacity, also for PhysOpt (see Physical Compiler Intro Tutorial
for more on this topic) and for DFT-Compiler
- read_verilog & read_file now merged into read -f verilog (yeah!)
- better bidir ports w/ (timing_disable_internal_inout_net_arcs)
- ideal_network command to propagate ideal nets (note that the
latency and transition times can be set manually on these nets)
- improvements in TCL performance, Design-Vision and FSM-Compiler
- DC-Ultra now accessible through compile_ultra command
Plus a set of scripts to automate the ACS flow.
- an anon engineer
"Of course, DC still dominant the market, but the capacilty has to be
improved. ACS for me, it looks like a work-around."
- Hui Fu of Infineon
( SNUG 02 Item 12 ) -------------------------------------------- [ 5/15/02 ]
Subject: Module Compiler & Behavioral Compiler
UNRELATED TWINS: It's rumored that Behavioral Compiler is approaching its
End-Of-Life notice. It appears that nobody will be crying at the funeral.
"Behavioral Compiler? - yuck. Let's you exchange one set of arbitrary
limitations on coding style with another. BC was overpromised and
underdelivered."
- Tom Heynemann of Compaq
On the other hand, there is a growing cult following of Module Compiler.
Those who don't use MC tend to see it as being like BC and avoid both.
Those who use MC tend to pretty fanatically positive about MC.
"Module Compiler and Behavioral Compiler are more effort than they're
worth. Designers still need to be aware that they are creating
'circuits' and understand what they are building. Writing the code
has never been the bottle neck. Design is not done in a text editor."
- Brent Lawson of Texas Instruments
"My impression is MC & BC are not ready for prime time."
- Curt Beckmann of Rhapsody Networks
"We don't use MC/BC and I personally think they will be killed in the
near future."
- an anon engineer
"They're both a waste of money."
- Kevin Hubbard of Siemens
"Module Compiler is a great tool. Behaviour Compiler just didn't
catch on."
- an anon engineer
"Module Compiler rules. The quality of the netlists produced are
sometimes better than those produced by designers. The new release
of MC has links to PhysOpt by means of relative placement generation.
Datapath structures produced by MC are not perturbed by PhysOpt."
- an anon engineer
"Behavioral Compiler and Module Compiler both offered nice capabilities
in their niches. But Synopsys is not a niche player. It looks like BC
is now in the End-Of-Life phase. That is a shame. Most engineers
missed the point of BC. Which was not exactly behavioral synthesis but
behavioral simulation speed. In a time when ever project I know about
is claiming simulation and verification if the bottle neck, a 10x to
100x improvement in simulation shouldn't go unnoticed.
Module Compiler will only be come useful when it is fully integrated
into PhysOpt. If that doesn't happen, it will only survive as an
under-the-hood feature of DC.
There's also some debate within Corrent as to how desirable a
PhysOpt/MC flow would be given that you can't run RTL-to-gates formal
verification if you use MC (at least, not with Verplex, which is
what we use.) Also, what's the benefit of using PhysOpt/MC vs. using
Apollo/Astro in a semicustom approach (with Scheme scripts to fine-tune
placement, for example?)"
- Neel Das of Corrent Corp.
"We use Module Compiler a lot. Synopsys has been treating it as a
stepchild for a long time, but lately they seem to pay more attention
to it. Anyway, regardless of the integration weaknesses, it's a good
tool. BC had a lot of press 5-6 years ago (I've actually tried it
then, with decent success), but it's now a niche tool. It's not the
next big thing, though, the way Synopsys was hoping."
- Oren Rubinstein of Nvidia
"Module Compiler is great for datapath work. I have no use for
Behavioral Compiler at all."
- Tom Moxon of Moxon Design
( SNUG 02 Item 13 ) -------------------------------------------- [ 5/15/02 ]
Subject: Synplicity Synplify FPGA, Mentor Exemplar, Synopsys FPGA Tools
SYNPLICITY RULES: One of the biggest business mistakes Synopsys did in the
FPGA synthesis market was to team up with Xilinx in an exclusive OEM
agreement. All that Xilinx cares about is selling their chips; they're
honestly not all that concerned what EDA tools their customers use. Because
of this, Synopsys completely lost direct touch with FPGA synthesis users.
Dataquest FY 2000 FPGA Synthesis Market (in $ Millions)
Synplicity ####################### $22.7 (45%)
Mentor/Exemplar ################### $18.7 (39%)
Synopsys ##### $7.1 (14%)
others ## $2.0 (4%)
Last year Synopsys owned 35% of this market. Now they only have 14%! The
other gotcha for Synopsys in this scenario is that in this year's SNUG'02
survey, 38% of users are using FPGAs to prototype their ASIC designs. From
the marketshare numbers and the user comments below, Synplicity rules this
niche. This mean Synplicity has a synthesis 'in' with at least (45% of 38%)
17% of the ASICs being designed -- not exactly a bad place from which to
springboard a new ASIC synthesis tool. (But to be fair, Exemplar's had an
ASIC synthesis tool for years now, and it's *no* threat to DC whatsoever.)
"We're seeing the entire FPGA synthesis market going flat this year.
This is probably due to the fact that PCB designs have had a
negative book-to-bill ratio for the past year. They're driving down
the number of FPGA design starts."
- Gary Smith of Dataquest
"Regarding FPGA Express, their results are very disappointing. Synplify
has much better results in FPGA synthesis."
- an anon engineer
"I have evalusted these FPGA tools head to head probably 3 times in the
last 7 years. Synplicity has won hands down each time. It's easy to
use and faster. Results of each are fairly similar but it took a lot
more work on the two other tools to get the same results.
- Scott Vincelette of Flarion
"We're in the middle of evaluating all three tools. Haven't really
exercised Exemplar, yet. Between Synplicity and Synopsys, Synplicity
worked better for us for ASIC prototyping. Note: we're NOT doing
FPGA designs; we're prototyping large ASICs, and so our coding style
is not optimized for FPGAs. We got better results much faster out
of Synplicity.
Synopsys, though is very interested in our ASIC prototyping problem.
They seem to be putting resources into improving FPGA Compiler II, so
that their latest release (3.7) improves their compile time greatly.
Haven't evaluated it yet. I'll let you know our eval results later."
- an anon engineer
"Forget Synopsys in the FPGA race, they have really dropped the ball.
Synplicity and Exemplar will remain the leaders. Synplicity will
win the new users. Exemplar will win the power users. Pushbutton
vs. Depth of Control. I own Exemplar, many of my clients own both.
They each have issues, but I feel Exemplar has better control and
depth to the tool. Marketing wise I think Synplicity is winning;
but is really beginning to have problems with incremental synthesis
linked with FPGA P&R tools. Amplify is just another way to make
money. They learned well from Synopsys. (Can you say PhysOpt?)"
- Tom Tessier of t2design
"Synplify seems solid in FPGAs. FPGA Express has always seemed lacking.
Never tried Exemplar."
- Kevin Hubbard of Siemens
"Synplicity for FPGAs. Popular, simple, and produces good results."
- Scott Campbell of Motorola
"As far as I know, FPGA Express is dead. We haven't tried FPGA
Compiler II. Synplicity is good but is often too smart for my
own good. We chose Synplicity over FPGA Express for our 200 MHz
Virtex E and Virtex 2 designs because we seem to need the extra knobs
to tweak synthesis results. So far, we've met our goal of not using
schematics or hand-placement to achieve our performance targets in
the slow speed grade Virtex 2."
- an anon enineer
"Synplicity is on top, with Exemplar a very close #2. FPGA Express
(which is actually a dead product now, replaced by FPGA Compiler II)
is a distant third. I field about 20 FPGA design questions every
week, with only a few ASIC questions, so I know a great deal about
this issue. I grade these FPGA tools on:
1) Quality of output
a) Accuracy
b) Speed (of resulting design)
2) VHDL constructs the tool understands
3) Support for new FPGAs
Thus my main stream FPGA tool is Synplicity. I keep a copy of
Exemplar around as a second opinion, and I have dropped support on
my FPGA Express seats."
- David Bishop of Kodak
"I use FPGA Express. I haven't really compared these because when
working on a design, usually the FPGA chip supplier already has
libraries and things setup for FPGA Express, so that's what I've
been using."
- Donald Whisnant of John Deere
"I don't know much about Exemplar, but I am very familiar with Synopsys
FPGA Express/FPGA Compiler II (FC2) and Synplify Pro for FPGAs. I have
used both for real designs. No contest. Synplify Pro wins hands down,
walking away. It is faster. It covers more of the VHDL language. It
supports inferring single or dual port (either distributed or block)
RAMs from arrays in RTL. It makes better use of built-in arithmetic
carry logic. Synplify's schematic creation/viewing abilities are far
beyond the feeble attempts by FC2. It works with directly instantiated
entities/architectures, instead of dumping core with no warnings,
messages, etc. as does FC2, even though Synopsys directly states in
their manuals that this is supported.
Last summer, the Synopsys FC2 marketing team came in here as part of
their marketing "We care about FPGAs" blitz. This was right after last
year's SNUG'01 when FC2 did not even have a booth at R&D night. When
I asked them about RAM inferencing from RTL, they got this confused
look on their faces, and asked, "Why would you want that?" Their
competitors know why I want it. Try storing enumerated state variables
in instantiated Xilinx RAM primitives; you'll see what I mean. Better
yet, try displaying the contents of all those single bit instantiated
RAMs in a waveform viewer as words, rather than so many bits scattered
all over. Or just display the array of enums, much easier. Synopsys
seems to be stuck in this mindset that the only folks doing FPGA design
are just doing ASIC prototypes.
What if Synplicity teamed up with a memory compiler company to infer
RAMs from RTL for ASICs? Maybe then Synopsys would begin to
understand. Even Synopsys DesignWare FIFOs don't use RAMs! Why on
earth would I want a synchronous FIFO, more than two or three words
deep, built out of flops when my FPGA has all that RAM that is more
compact, and faster too?"
- Andy Jones of Lockheed Martin
"We use Synplicity and it works well for us for FPGAs. I would like to
see more elaborate features for setting timing constraints in
Synplicity. At the time we tried FPGA Express was extremely slow
compared to Synplicity."
- Karl Kaiser of Resonext
"No contest, Synplicity gives me the best results."
- Tom Moxon of Moxon Design
( SNUG 02 Item 14 ) -------------------------------------------- [ 5/15/02 ]
Subject: PrimeTime, PrimeTime-SI, Avanti Mars-Xtalk, Sequence, Simplex
LIFE IS GOOD: Last year Aart leaked the PrimeTime-SI story in SNUG 01 #20
in his keynote address. Since then, it's had the usual thumbs up & down & up
early acceptance feelings from the beta users. There's nothing quite like
expanding one's 97% market share Static Timing Analysis monopoly is there?
Dataquest FY 2000 Static Timing Analysis Market (in $ Millions)
Synopsys PrimeTime ########################## $26.0 (97%)
Mentor SST Velocity # $0.6 (3%)
Cadence Pearl 0.0 (0%)
"I'm getting good reports from the field on PrimeTime-SI. They seem to
have a good grasp of most of the SI analysis problems. The trouble
with SI tools is that they tend to focus on one aspect of signal
integrity. Those one trick pony tools are going by the wayside."
- Gary Smith of Dataquest
"PrimeTime is rock solid. It's GUI is a joke, but GUIs are anyways.
Haven't tried SI."
- Kevin Hubbard of Siemens
"PrimeTime Technology Update (New in 2002.03):
+ Multi Clock Propogation allows timing of multiple clocks in a
clock domain (similar to clock phases in IBM Einstimer).
+ Data to Data Timing Checks (also similar to Einstimer).
+ Clock Network Timing Reports.
+ Interface Logic Models (ILM) and Extracted Timing Models (ETM).
+ ILM are better at modeling since they keep first input, last
output FF in design.
+ ETM better when interfacing with 3rd party tools."
- Kent Ng of Microsoft/XBox
"Paul Zimmer and Andrew Cheng of Cisco did their presentation on timing
DDR interfaces in PrimeTime. They showed lots of PrimeTime tricks
along the way, which made this an effective part 2 for Paul's award
winning PrimeTime paper from last year."
- Bob Wiegand of NxtWave
"We use PrimeTime to sign off. It is still the most reliable tool out
there. We did a lot of comparison with Ambit and the results were
sometimes quite different. However the paths we extracted & simulated
in SPICE showed a incredible match between PrimeTime and SPICE."
- Karl Kaiser of Resonext
"Paul Zimmer (Cisco Systems) said that he was doing yet another
PrimeTime paper. We talked about PrimeTime-SI and the Sequence tools
and PT v2002.03 beta. He said that he really appreciated the new
ability (v2002.03) to pass multiple clocks through a MUX in PT. He
also said that he still uses a bottom-up compile strategy (with no
compile at the top level as WLMs are especially bad there). He has
an old set of scripts that supports this methodology."
- an anon engineer
"I use PrimeTime a lot and, for the most part, I like it. It has it's
issues, but, overall, it's a pretty good timing tool. The 64-bit
version is really fast.
The GUI has been improved in the last year or so and now the user gets
to see what is happening during a long run. Path exceptions are
relatively easy to assert and the case_analysis has been fixed (doesn't
propagate backward anymore) so static signals can be modeled. There
are a lot of nice 'get' and 'all' commands so it is easy to identify
and make lists of parts of interest in the design. In particular, the
'report_transitive_fanin (fanout)' commands are a great way to identify
whole cones of logic. And the user can define and set attributes on
pins, ports or nets which is handy to use in a TCL script for many
different reasons.
Tho some nice new features have recently been added for latch-based
timing, unfortunately, it still can't handle non-overlapping (split)
clocks or cut 'path sets' (yeah, yeah, I know, that is a *dynamic*
operation and this is a *static* timing tool). Maybe someday ..."
- Tamar Barry of Honeywell Space Systems
"The PrimeTime-SI stuff still assumes that every signal is in transition
which may or may not be the case. You could be over designing to get
rid of all PrimeTime-SI warnings, but as geometry's get smaller this
will become a larger issue. It nice to have the Timing Analysis and
the Signal Integrity together."
- Tom Tessier of t2design
"Many of the Primetime-SI papers at this year's SNUG looked like they
were cut and paste from Synopsys documentation. The tutorials were
rather bland and looks like Synopsys will keep telling same things
time and again."
- an anon engineer
"I found Primetime-SI not that attractive, but that is my personal
opinion. I have heard some people all praises for it."
- an anon engineer
"We use PrimeTime-SI as the successor of our internal SDF generation
tool. So signal integrity was taken into account by a 'rule of
thumb' approach. In those days PrimeTime was used to do STA.
Now we introduce PrimeTime-SI to measure the effects of signal
integrity. Our chip is roughly 400 k logic + 2 M Ram in 0.18 um.
It is a flat design.
PrimeTime-SI needed approximately 15 hours for STA (3 Cases) and
4.8 G of RAM on a Sunblade with 8 G memory. I wonder how you can
ever do STA with PrimeTime-SI on a real big chip!
Some new variables were introduced to PrimeTime-SI and we needed some
consulting on how to set these variables.
We saw that Apollo P&R did not correlate smoothly to the timing
results delivered by PrimeTime. This is really annoying because
turnover cycles (P&R -> STA -> P&R) are really long.
Three times the version of PrimeTime-SI was updated in the course of
our design. Each new version should be 'faster and less pessimistic'.
I had the impression that PrimeTime-SI crashed when you really wanted
to use TCL and analyse parts of the design thouroughly.
The main drawback of PrimeTime-SI is its speed (very slow) + its memory
requirements. Additionally the P&R/STA flow is not satisfying."
- Klaus Vongehr of Philips Semiconductors
"We just evaluated PrimeTime-SI (PT-SI) for crosstalk analysis and
Mars-Xtalk from Avanti for crosstalk prevention and correction.
PrimeTime-SI was very easy to integrate in our 'normal' STA flow. We
just installed the relevant licenses and added a few commands to the
setup script to enable the crosstalk analysis. This was done with the
assistance of our local AE. We use Simplex Fire&IceQX and getting SPEF
with coupling capacitances into PT-SI was no problem.
Our Mars-Xtalk/PT-SI evaluation was done on a relatively small block,
approximately 18K instances and 20K nets with a layout size of about
600u x 600u, for a reasonable test run time.
A 'side effect' of PT-SI is that it is possible to write (and read)
binary SPEF. This significantly reduces the time it takes to load the
parasitics into PT-SI for subsequent runs. You should expect
significantly longer run times for the update_timing (we saw something
in order of more than 2x) when enabling crosstalk analysis.
The initial layout (without Mars-Xtalk) did show a significant
performance drop (increased WNS) when analyzed with crosstalk analysis
enabled in PT-SI. Mars-Xtalk operates with a so-called 'threshold'.
By default, the threshold is 0.45 which means, that a net is considered
to have a crosstalk violation if one or more aggressors induce a total
noise voltage on it that is greater than 0.45xVDD. Playing around with
different settings of the threshold, we managed to remove almost all
crosstalk degradation (with a runtime penalty in the order of 2x for
our routing.)
This flow has a fundamental problem in that Mars-Xtalk uses the size of
the noise voltage as the selection criteria for avoiding and correcting
crosstalk violations, while PT-SI analyzes the degradation of the path
delays due to the crosstalk effects. It does not matter whether the
noise voltage is large or small. A small noise voltage might create a
setup or hold violation on a critical path, whereas a large noise
voltage might be relatively harmless on a non-critical path. This
means Mars-Xtalk is only indirectly solving the crosstalk problems. We
created sort of a workaround for this problem by extracting a list of
nets on critical paths with a 'significant' crosstalk contribution and
fed this to Mars-Xtalk as nets needing repair. This required some TCL
and Perl scripting.
It will be nice to see a better integration of the tools (PT-SI and
Mars-Xtalk) in the future with the Avanti merger. Crosstalk analysis
is of limited value without the ability to repair (and vice-versa).
Another thing we would like to do with the analysis results from PT-SI
is to verify that the tool is not overly pessimistic. We are trying
to do something with SPICE here, but have no results as of yet."
- Lars Bo Graversen of MIPS
"15. PrimeTime-SI gains great attention among designers. Within one
year of the release there are already two papers that talk about
the pros and cons of this tool in SNUG this year. 'SI' here
stands for 'signal integrity', but it is exaggerated since this
tool can only analyze the cross talk effect. No IR drop and other
SI effect can be taken cared of at this time, although Aart
promised the R&D team of PrimeTime will look into these issues
very seriously. To use PT-SI, the traditional SDF file our
vendors provide us won't be enough anymore. Because the delay of
a net now depends on the timing of the nets switching nearby, we
need the SPEF file which can give us more info. Indeed more and
more designers are asking their vendors to provide SPEF file.
Synopsys itself are promoting its own 'SBPF' format which it
claims can greatly shorten the runtime. Personally I feel that
the lack of industry standard for timing calculation is a
danger in this area.
Though PT-SI is not perfect, it is going in the right direction."
- Andrew Cheng of Cisco
"Not even a mention of Simplex or Sequence, hello? Primetime-SI is a
good incremental inprovement. But if I have to pay for mask set, I'm
going to do my post-route extraction and SI checks with Simplex and
Sequence Design tools. PrimeTime-SI is not even in the running here."
- Tom Moxon of Moxon Design
( SNUG 02 Item 15 ) -------------------------------------------- [ 5/15/02 ]
Subject: PhysOpt vs. Magma vs. Cadence PKS vs. Monterey
GLOAT, GLOAT, GLOAT: Right after DAC'01 last year, I reported on ESNUG the
following June 2001 physical synthesis numbers:
Synopsys ########################################### 170 tape-outs
Magma ######### 36
Cadence PKS ### 12
Monterey 0
This data was explained at the time in DAC 01 #27 & ESNUG 374 #7. Well, lo
and behold, Dataquest reported 5 months *after* I reported my tape-outs
their marketshare numbers. I'll be damned! Matches my data nicely.
Dataquest FY 2000 Physical Synthesis Market (in $ Millions)
Synopsys ################### $19.1 (64%)
Magma ####### $6.9 (24%)
Cadence ### $2.9 (10%)
Monterey # $0.5 (2%)
I'm sorry for gloating here, but you don't know the crap I got from Cadence,
Magma, & Monterey for reporting those tape-out numbers. I don't blame them
really. They came out behind, so it was in their best interest to discredit
anything that made their physical synthesis marketshare look bad -- even
though it was the bloody truth at the time! (Sheesh.)
Anyway, here's my estimated tape-outs for May, 2002:
Synopsys PhysOpt ######################################## 600 tape-outs
Magma ####### 100
Cadence PKS ## 36
Monterey 3
Synopsys reported 500 tape-outs at SNUG'02 and just this week they claimed
600 tape-outs in a press release. Magma made the 'over 100 tape-outs' claim
at the big press event they had 2 weeks ago. I called them on it and they
said 50 of them were from TI. That kind of surprized me because I know that
at least TI Dallas Broadband, TI Phoenix MSP, TI Houston DSP, TI India, TI
France, and TI Japan Wireless are firm PhysOpt users -- not Magma users. It
turns out that the only group I could find that's using Magma was TI ASIC.
This complicated things because TI ASIC is an early Magma investor. It
means they're under internal pressure to show that the investment in Magma
was wise. That 50 could be real or political... Wait! Either way, this
is no biggie. We already know PhysOpt and Magma have working flows. If
there are 6X or 12X PhysOpt tape-outs for every Magma tape-out, does this
say anything new? PhysOpt's way ahead of Magma. No new news here.
Now the hard part. I found 7 Cadence PKS tape-outs in my initial Dec 2001
tape-out count. Three months later (Mar. 2001) in SNUG 01 #7, Cadence
reported a total of 12 PKS tape-outs. By scouring ESNUG and the press
releases/success stories on the http://www.cadence.com web site, I found:
# of Cadence
Date Company Tape-outs Tool Source
-------- ----------- -------------- ---------- ---------
01/17/01 Crest Microsystems 1 PKS/SE-PKS Press Release
01/17/01 Fujitsu 1 PKS/SE-PKS Press Release
08/29/01 Cisco 1 PKS/SE-PKS ESNUG 376 #3
09/01 AHA 1 PKS/SE Success Story
09/28/01 TDK Semiconductors 1 PKS/SE-PKS Success Story
11/01 XtremeSpectrum, Inc. 4 PKS/SE-PKS Success Story
11/28/01 Sunplus 4 PKS/SE-PKS ESNUG 383 #1
01/02 Jaldi Semiconductors 1 PKS/SE-PKS Success Story
This is a total of 14 PKS tape-outs being reported on the Cadence web site.
Since 2 of these are on 01/17/01, I'm assuming they're already part of the
Mar. 2001 count of 12 PKS tape-outs. This means that altogether, I can find
only 24 Cadence PKS tape-outs. Now assuming that there's an additional 50
percent of PKS tape-outs that Cadence couldn't get the customer to agree to
talk about publically, this makes the true total of 24 + 0.5(24) = 36 PKS
tape-outs one can reasonably justify. This makes PKS 15X behind PhysOpt.
"I would have said that PKS only has about 30 user tape-outs right now,
but that's a guess. People are trying it from their bundled tool
purchases from Cadence. Power users don't use PKS; it's the under
200 Mhz, 0.25 um, under 2 million gate mainstream users trying it."
- Gary Smith of Dataquest
The 3 Monterey tape-outs I counted myself: 2 at Infineon and 1 at Zoran. It
must really suck to be Monterey. With 740 rival tape-outs ahead of them,
this makes Monterey 248X behind everyone else! Ouch.
"We expect to migrate to PhysOpt in the next 12 to 18 months. We
expect it to be easy to migrate to from Design Compiler."
- Scott Campbell of Motorola
"There's no way to avoid one of these tools. When Synopsys gets to
RTL2GDSII, they will be hard to beat. Until then I'll use whatever
tool my ASIC vendor tells me to (which is Magma for this chip)."
- Brent Lawson of Texas Instruments
"You ask if we using this within the next six months? We're using
PhysOpt on real designs as I write this. We chose Synopsys after a
lengthy eval, in large part due to past experience with their toolset.
Having said that, there's a strong base of PKS users in other groups
here and a drive to 'converge' on a single toolset; this may affect
our future tools."
- an anon engineer
"PhysOpt works good enough. We don't have to have a Synopsys engineer
holding our hand. These other companies (and to some extent Astro,
from Avanti, for that matter), address some issues today, that PhysOpt
doesn't: such as integrated clock tree synthesis (available with
PhysOpt to 'limited' customers), detail routing (again, available to
'even-more-limited' customers), and some degree of SI-aware P&R.
PhysOpt has caused us some heartache in post-route optimizations of
congested designs. It's Steiner router does not correlate with
detour routes taken by Apollo/Astro to work around congested areas,
resulting in huge numbers of DRC violations. This problem will
continue until Synopsys gets Route66 (or some other *working*
detail router built into PhysOpt) productized!"
- Neel Das of Corrent Corp.
"We use PhysOpt here and been generally been happy with it. However we
use it mostly to 'prove' feasibility to our customers. Their design's
scan/clock_tree/ECO etc is done back in Japan."
- an anon engineer
"Introduction to Physical Compiler (PhysOpt)
+ Overview of PhysOpt flow (nothing really new presented)
+ PhysOpt is suppose to have sufficient command line interface
to do floorplanning (without GUI).
+ ClockTree Compiler and Routing Compiler not released yet.
Q: How will Avanti flow integrate with PhysOpt flow?
Hierarchical Physical Synthesis with ILM Models
+ Interface Logic Models (ILM) allow PrimeTime/DC/PhysOpt to run
faster using less memory.
+ PrimeTime ILMs are flat with no phyiscal information, written
out as flat Verilog netlist and support back annotation.
+ DC/PhysOpt ILMs contain original hierarchy and physical info,
in DB format and support back annotation.
+ DC/PhysOpt ILMs will allow top-level optimizations/routing to
be run on the full-chip without having to load entire design.
Q: How well will ILMs interface with 3rd party tools?"
- Kent Ng of Microsoft/XBox
"I asked Oren Rubenstein (ex-HP Canada, now with nVidia) what he thought
about doing RTL2PG physical synthesis and the ideas behind MPC (minimal
physical constraints - a way for logic designers to create a quick dumb
floorplan and run compile_physical with it). He said they don't route
each block (they route groups of blocks) so it wouldn't be useful."
- an anon engineer
"PhysOpt-MPC sounds interesting, but not if it costs much more than
Design Compiler."
- Oren Rubinstein of Nvidia
"I attended the second Wednesday session entitled 'Physical Synthesis
/ Timing Closure'. The first two talks had very little of interest
in them. It seemed to me that Jay McDougal had talked about most of
the material 3 to 5 years ago. The first presenter did mention using
PhysOpt MPC beta and getting good results, but they only used the
netlist. They threw away the floorplan as it had illegal cell and
macro placements (overlaps), core rows unflipped (causing VDD and GND
shorts), and other problems. The presenters agreed that RTL2PG can
lead to long run times. Other points that were made: don't use
map_effort medium with congestion_effort high, set both to high, also
it would be nice to be able to tune X and Y congestion thresholds
independently.
The third presentation was an excellent overview of the timing closure
problem and the flows that have been used to attack it. The only
criticism I have is that the testcases used were both fairly small by
today's standards. Interesting ideas from this presentation:
- Two pass placement: first place the cells connected to IOs,
then place the rest of the cells
- Run initial physopt twice: first with -area_recovery, second
with -incremental
- G2PG flow results in a much better area than RTL2PG flows
- PrimeTime and PhysOpt's timing numbers are close so no need to
overconstrain (though Kurt Baty says overconstrain by 15%.)
The paper's called 'A comparison of Timing Closure Approaches'."
- an anon engineer
"Overall I think PhysOpt is not ready to compete against LSI's MPS and
MRS. However Synopsys appears to be committed to making PhysOpt a
standard in the industry.
Cons: Some of the problems I saw with PhysOpt was that it was not
user friendly when it came to placing individual cells, had bad
optimization techniques during placement, had no crosstalk placement
analysis, has only been tested on small designs, and does not
interface Avanti very well.
Pros: Some of the benefits of PhysOpt were the use of ILM's to
perform Hierarchy flows, its ability to work with other Synopsys
tools (DC and PrimeTime) for timing based placement and that it
could be run in non-GUI format.
There is a new Beta tool that ST and Synopsys are working on called
PC-MPC. It has the same purpose as lsimom, in that its trying to go
from RTL -> to route with minimal human engineering efforts. Overall
the presentation was good but MPC has its limitations. ST is the first
to point out its weaknesses but its clear there is a push in the
industry for this kind of technology. It might be worth getting in on
some of the Beta test programs of this tool to see how effective it
really is. One down side is that it uses PhysOpt for its automation
placement. Good informational presentation."
- an anon engineer
"PhysOpt to me basically seems like DC with a lot of clumsy overhead
used to replace WLMs. We are currently using it at Philips based
the on judgment of a CAD manager who fancies himself to be a guru of
all things Synopsys. I think it came down to less work for him than
using Cadence PKS as an alternative."
- an anon engineer
"I haven't used PhysOpt, but for timing critical designs, the philosophy
behind it seems very sound. If I do switch from DC, I would push for
PhysOpt, given my familiarity with DC."
- Eric Mitchell of Cypress Semiconductor
"Actually about a year ago we compared 3 tools: Cadence Silicon
Ensemble PKS (SE-PKS), Avanti Apollo2 and Monterey Dolphin as a back
end tool. At that time, Synopsys PhysOpt didn't have a router. We
left it out of our selection. Magma was also attractive, but it needs
a lot of scripts to run, so it was left out, too.
Our key points were:
- Since we started a new design team with a few engineers (and
not very experienced), the tool/flow should be easy to learn,
very self-explanatory and straight-forward.
- Very fast turnaround time needed. For schedule reason it was
important to be able to re-run quickly in case mistakes are made.
- Due to the tight time schedule and no time to plan/design system
upfront, we had to make sure that we don't have iterations for
timing closure, routing, etc.
Silicon Ensemble and Apollo are tool sets. They are very flexible, but
need a lot of scripting work and CAD management to maintain.
Furthermore, Cadence and Avanti had their engineers focused on their
new EDA tools, Integration Ensemble and Astro. They announced they
won't do any enhancement requirements concerning legacy tools like
Silicon Ensemble and Apollo II except certain bugs.
On the other hand, Monterey didn't have all that baggage.
It took about 3 month to build a basic Monterey design flow with
Soliton's (Japan Agency of Monterey) help. We believe that
Dolphin should satisfy our many requirements for improved TAT and
design efficiency in the mid-range Mixed Signal ASIC design flow."
- Hiroyuki Nakamura of Canon
"We evaluated PhysOpt and thought the tool did a good job but was
overpriced. A floorplanning tool should be incorporated into PhysOpt
and not be a separate part of it. I want a tool that you can floorplan
with at the pre- and post-RTL stages, and then use that same tool to
turn your floorplanned RTL into a placed gate netlist. This also
implies that power routing and clock tree insertion should also be done
with this same tool. PhysOpt tool on its own is only half a tool."
- an anon engineer
"At this point I have two choices as I see it, get a PhysOpt seat, or do
RTL hand off. I think I'll most likely do the latter because of the
learning curve on these tools."
- David Bishop of Kodak
"I attended the tutorials on PhysOpt. Tech content pretty good. I do
not understand why every single session indicated 'you do not need wire
loads for PhysOpt'. In order to use PhysOpt you need to have a floor
plan already built and all of these tools need a wire load to setup
the block level partitioning. All of the PhysOpt sessions also had the
same question over and over from the audience - 'how do you get the
initial module placement?' The correct answer should be 'from a timing
driven floorplan created with Chip Architect or Planet/Jupiter' however
this was not offered for 4 sessions. The response instead was 'we are
working on it'. Unfortunately, the physical world is not the same as
synthesis. You need to have some sort of basis for the pad ring,
origin for the power grid and hard macro placement for all the 'detail
placement' tools to know where the boundries on the design are.
Synopsys needs to let these front end designers know that unfortunately
the concept of a physical size and pin out are coming to their world."
- Pallab Chatterjee of SiliconMap
"PhysOpt looks to be late in incorporating clock tree synthesis as part
of their flow. This feature is available now with Astro, Monterey,
Magma. We have seen also some SI divergency between PhysOpt and Apollo
(the flow we use is Physopt + Apollo).
We ran comparison benchmarks about a flow composed of PhysOpt 2001-08
+Apollo 4.9 versus Monterey 2.1 versus Magma 2.1 on a 0.18um process.
What we saw:
- Significant run time improvement with either Magma and Monterey
versus PhysOpt+Apollo with normalised CPU runtime, independantly
of multi threading.
- Fast prototyping loop available in Magma and Monterey (Sonar) which
allows to save a lot of time in tuning the timing constraints and
floorplan. It was typically 7 hours compared to a whole 34 hours
implementation run.
- QoR better with Magma & Monterey for what maxCap/Tran fixing is
concerned.
- Fact that clock tree is part of the physical synthesis process is
simplifying the iteration loops, and reduces the overdesigning.
- Apparently, Signal Integrity is better handled - at least seems
transparent - in Monterey and Magma.
- Scripting is much more simpler in Monterey and Magma than with
PhysOpt + Apollo.
Overall, we think there is an advantage to move to Magma or Monterey.
Our fear is that those approaches are a bit 'black box' and less open
to manual tuning than PhysOpt and Apollo. Although Monterey is more
open than Magma, using DEF interface at the placed gates level."
- an anon engineer
"No, we don't envision forking out more big bucks for these new
physical synthesis tools. Our DC/Apollo/Primetime flow seems to
be still chugging along fine for our 300k gate chips."
- Jeff Waite of Netergy Microelectronics
"PhysOpt Advanced Topics:
- the -check_only and -quick options are useful
- overconstraining unnecessary and costs time and area
- use GUI to find congestion, use -congestion_effort high
and -timing_driven_congestion
- set_congestion_options command
- wide power nets should be complete obstructions
- average cell displacements should be less than one row height,
large displacements mean a poor floorplan
- check_legality -verbose command
Other tutorials that look good are:
Test Synthesis and ATPG Methodologies for Large, Complex Designs
Physical Synthesis Heirarchical Design Flow"
- an anon engineer
"Synopsys has done a great job of selling PhysOpt into the DC installed
base, but my impression is that they are still selling mostly to
front-end designers. While it is true that PhysOpt can output a
DRC-correct placement, I don't know of anyone who is using PhysOpt as
the final, detailed placement engine for >1 million gate designs.
Magma is enjoying some success selling into Avanti's installed base.
They seem to do very well on small, sparse designs that are timing
limited. They have trouble on designs larger than 1 million gates,
or on designs that are very dense and congested area or routing
limited. Their fixed timing approach requires a certain amount of
'area slack' in order to be able to swap in the required cells.
They also require a cell library with a high level of granularity.
Monterey claims to have done some very large, flat designs (3-5
million gates). Their big drawback is that they require a huge
machine, and they do not yet support Linux. Their constraint
reduction capability is an absolute 'must have' for large designs.
Plus, for block assembly Aristo continues to gain design wins."
- an anon engineer
"Synopsys PhysOpt: costs too much relative to what you get out of it,
also it works on different database from the P&R tool, not give a
complete solution, not really save time in the flow, and I think that
its time pass already.
Cadence PKS: also does not give a complete solution, and does not solve
issues related to a deep sub micron processes, the internal algorithm
is based on S&S that activate some old other Cadence tools, and have no
signal integrity solutions, its time pass.
Magma: a tool from the new generations that give a complete solution
from RTL to GDS, take care of most of deep sub micron issues and signal
integrity. Seems to me a very powerful good tool, needs to demonstrate
itself on some big designs, cost a lot.
Monterey: a tool from the new generation very user friendly, give
complete solution from netlist to GDS, IC-Wizard is a very powerful
placer that saves many many hours of work, and enable to achieve a very
fine tuning floor plan ready for Dolphin. Dolphin is also a very
powerful tool, very simple to use and give fast results with very good
performance, save also many engineering hours of work, in the block
level the tool is mature, in the full chip top level some issues are
still under development and need improvement.
We are using Monterey tools and very satisfy from it, its enable us to
short schedule dramatically comparing to Avanti or Cadence flow with
much smaller team (basically one engineer).
Also we got very attractive price on Monterey, so the total price
performance is really good."
- Gideon Paul of TeraChip
"Two of my customers are using Monterey Sonar/Dolphin with excellent
results. You can use 4/8/16 processors with Sonar/Dolphin and get much
faster turnaround than using PhysOpt. None of my customers are using
Magma Blast or Cadence PKS yet for production work, although they are
evaluating them."
- Tom Moxon of Moxon Design
"I was requested by an independent consultant of Monterey to give you a
response to some of your questions. Synopsys PhysOpt is certainly the
tool of choice. Reasons
a) Proven technology - has much greater silicon behind it to have
hashed out the bugs.
b) PhysOpt is linked somewhat with logic synthesis and no one would
choose other synthesis tool for risk management issues, other
than DC.
If I am looking to solve a point problem, then I would consider Magma
or Monterey, but I cannot trust my $30 M to $40 M design project with
a new methodology."
- an anon engineer
"I had some experience with PhysOpt in the past and I think it's an
excellent gates-to-placed-gates point tool. The problem is the flow.
We are doing low power designs, and we gate clocks extensively. This
was a headache for most of the physical design tools. Since PhysOpt
doesn't contain a clock tree compiler (at least available for us. I
guess they are trying it with some big customers) I didn't see a full
solution. We started to work with Monterey recently, and we already
taped out our first design. The nice thing is that Monterey gives you
a complete gates-to-layout solution including floorplaning, physical
synthesis, clock tree generation, routing and X-talk awareness."
- Nir Sever of Zoran
"I'd like to look at Magma as it has a complete solution. I think they
may either go out of business or blow Synopsys away in the next two
years in this market. It will depend upon how quickly Synopsys
can swallow Avanti."
- Tom Tessier of t2design
"We've found Monterey Dolphin correlates within 1-2% of Simplex
extracted parasitics through PrimeTime. CPU time used by Dolphin is
higher than what I'm used to in the Avanti tools, but Sonar, with it's
early estimates of timing based on early placement, helps to reduce
iterations due to incorrect inputs, poor floorplanning, or bad
netlists. Sonar is essentially the early stages of Dolphin, they
correlate within 10% of each other and Sonar uses 30% the CPU time
of Dolphin. There is also less interaction with Dolphin than there was
with Avanti. Dolphin generally creates first pass Calibre DRC/LVS
clean GDS, so the actual wall clock time to finish a block is less.
Dolphin is very good at block level, but is missing a few features for
an easy hierarchical flow. The top level chip is treated the same as
block level such that a lib and a LEF is required for all mega cells.
IC Wizard helps with this issue, but until Dolphin and IC Wizard are
integrated, it isn't enough."
- an anon engineer
"Synopsys (including Avanti) and Cadence (without Silicon Perspective)
have no new ideas. They have limitations in design size, turn around
time, clock implementation (e.g. usefull skew), power optimisation.
If I use them in the near future ,it would be not my choice but comming
from the management.
Magma and Silicon Perspective (paired with Plato) seem to have the more
innovative approaches. Of course, they also can't solve all problems,
but their R&D teams are adressing them at least.
We have very good results from Magma and working closely with them for
further improvements. The timing closure is excellent and we see
nearly no DRC, LVS or formal verification problems. (And a fix if
something is found is available very quick). Design size, useful skew
and their roadmap (in terms of timing accuracy for IR drop) make them
my first choice.
In Silicon Perspective the turn around times are excellent and the
timing closure is good. If my main goal is time to market and my chip
is not timing critical, they are my first choice. (For Plato, the
approach sounds good but I was not able to test them yet.)
For Monterey: I have not used their tools and have no contact to anyone
who has used their tools without major help from their R&D team. So no
statement on this from me."
- an anon engineer
"If we were to migrate to a physical synthesis tool, it would be
Synopsys."
- an anon engineer
"Even though PhysOpt is selling well, people don't use it in a
RTL-to-placement flow. Instead, people still use DC for RTL
to gates and then use PhysOpt for gates-to-placed-gates. This
means they practically treat PhysOpt as just a placement tool
(plus some global route function) for now.
- Andrew Cheng of Cisco
"We are using Magma now. The reason are:
1) Capacity. Magma can handle our chip flat with a reasonable
turn-around cycle.
2) Real integrated flow under one tool, one GUI. The same
interface is used for P&R, DRC, Extraction, and STA. You
no need switch to other tools. And this can save some
iterations.
3) Hold timing fix. We have run a few tests on Magma, almost
no design has hold timing violation which we spend most of
our time for ECO with Apollo.
Magma works for us."
- Hui Fu of Infineon
"We will be using PhysOpt for a 0.18 um tapeout within 6 months."
- an anon engineer
"We outsource layout. I'm intrigued by what I hear about Magma, but
I've also heard very good things about PhysOpt."
- Curt Beckmann of Rhapsody Networks
"We chose PhysOpt, and now we're living with the results. One area
that's giving us problems is tool integration. Data exchange isn't
particularly smooth, even among Synopsys' own tools. (e.g. Chip
Architect currently cannot create a DB on its own; it can only
update an existing DB with physical information.) But Synopsys is
pretty responsive, and we have a good apps engineer to help us."
- an anon engineer
"PhysOpt is the only interesting one, in my opinion, and we use it
with great success. And it's one of the main focus points for
Synopsys, right now, which means we'll see constant improvement."
- Oren Rubinstein of Nvidia
"These are new tools and so support is a very important. We will be
using PhysOpt as Synopsys has the best customer support. We don't
want to wait for a long time for the AEs to come and fix a problem."
- an anon engineer
"I'm using PhysOpt on my current project."
- Scott Fuller of Creative Labs
( SNUG 02 Item 16 ) -------------------------------------------- [ 5/15/02 ]
Subject: Hidden Dragon, First Encounter, Aristo IC Wizard, Soc Ensemble
A LITTLE BIT OF KNOWLEDGE: Normally, I edit ESNUG and my Trip Reports for
the engineering community with the focus on deep technical detail and user
opinion. In this section, because of the 147 Wall St. spies who'll be
reading this (see ESNUG 391 #9), I'll have to explain a basic situation
involving the physical synthesis 'block assembly' problem I've been publicly
spanking Synopsys & Cadence on. (See DAC 01 #30.) Basically I'm answering
the questions I know I'll be asked on the phone by at least 3 of these Wall
St. weenies a week after this report goes up on DeepChip. Namely: "How can
PhysOpt have 600 tape-outs with Chip Architect & Hidden Dragon not working?
How can PKS have 40 tape-outs with Integration Ensemble not working? Isn't
this a disaster for Synopsys and Cadence? Should I short the stocks?"
My quick answer: "No, those are *new* tools I'm trashing. Avanti customers
use Planet/Jupiter/Apollo & Cadence users use Silicon Ensemble/HDP to glue
together the blocks they're getting from PhysOpt or PKS. Those established
chip assembly flows work, but are slow. The Hidden Dragons and Integration
Ensembles are supposed to vastly speed up this process. They're also
supposed to enable optimal partitioning/floorplanning of a chip's blocks
before the individual blocks are fed into PhysOpt or PKS."
Sometimes a little bit of knowlege on Wall St. can be a dangerous thing.
Anyway, for the chip designers reading this, Chip Architect still sucks.
Nobody's saying all that much about Hidden Dragon, so it probably won't
be out until next month's DAC in New Orleans. Integration Ensemble or
SoC Ensemble is also Missing In Action. Maybe at DAC? Monterey (Aristo)
IC Wizard seems to be getting some attention and users are concerned that
Cadence acquiring Silicon Perspectives might crap on First Encounter's
support and development.
"Synopsys is going to take the hands off approach with Avanti for now.
The biggest conflict I see right now is between Synopsys Design
Assistant and Jupiter/Planet floorplanning. Both tools do the same
thing and Synopsys seems to advocate the use of Design Assistant (which
is bizarre since there were no presentations on it at SNUG.)"
- an anon engineer
"It's a well known that Synopsys wants to extend its realm into the
backend world. So far the only success is with PhysOpt. They gave
a demo about their "turnkey solution" -- Chip Architect + PhysOpt
+ FlexRoute. However, immediately after demo several designers
pointed out that this methodology wouldn't work for design larger
than 2 million gates. The floorplan ability of Chip Architect was
greatly questioned, and few people were using their router, let
alone the RTL2GDSII flow claimed by Synopsys. The Cisco COT team
currently uses 'First Encounter' from Silicon Perspective and most
people think the tool is very cool. Silicon Perspective had been
acquired by Cadence and let's hope that FE can still keep its
prestigious status after the acquisition."
- Andrew Cheng of Cisco
"We settled on Chip Architect, though we might find ourselves
'encouraged' to switch over to First Encounter. (They take a really
long time to make decisions here.) We looked at Monterey's IC Wizard,
but came away unconvinced that it would fit into our flow. For one
thing, we like channel-based design, rather than abutted blocks. For
another, we place strong emphasis on early floorplanning and involving
logic designers in the physical design.
While we were investigating tools, I got the feeling that most
floorplanning and partitioning software doesn't fit easily into a flow
like this. They assume you have a full netlist (i.e. logic design is
complete) before you start breaking things up. Chip Architect was the
closest fit, but even it needs a little help.
Since we use Chip Architect, are we waiting for Hidden Dragon? Not
particularly, except that it may fix some issues. Hidden Dragon's
newest features seem geared toward abutted blocks, which we don't use."
- an anon engineer
"Chip Architect what a joke; still doesn't work and where is Hidden
Dragon? The only tool that has this issue licked from the design
engineers view, and is viable, is Silicon Perspectives. Too bad that
it is now part of Cadence, we will have to see what happens in a
couple of years. Right now SPC is still an independent acting
company; which will continue to push Synopsys to get it's act
together in this area."
- Tom Tessier of t2design
"We use First Encounter for most of our design planning and prototyping
activities. I wish it had hierarchy manipulation. I wish it had more
'production-worthy' floorplanning capabilities.
We need a real partitioner, one that can take our logical design and
spit out a physical partitions that hit the sweet spot of the backend
tools. We will always trade engineering time for computer timing.
When we take a small block through the backend it takes about the same
amount of engineering time as a large block. A partitioner that could
manage constraints, too, would allow us to convert our design to a
small number of large partitions.
Haven't looked at Chip Architect yet, but seems like the tool is
now mature enough to warrant a second look. It would be intriguing
to try it out and compare to FE."
- Neel Das of Corrent Corp.
"We use Chip Architect here and it is really unstable buggy tool which
is not even a halfway descent floorplanner."
- an anon engineer
"Personally I like First Encounter, mainly because it's quick turnaround
and capacity. Chip Architect is somewhat pre-mature. I heard lots of
Hidden Dragon hype from Synopsys, but have not yet seen the demo. I
will not have too high expectations. Aristo is another floorplan tool
I will like to give a try, if I have chance, because the tool claims to
provide couple of timing vs. area suggestions."
- Miaoching Chu of Microsoft/Xbox
"There was a lot of hype about Hidden Dragon. Color me unimpressed. It
just looks like warmed over Chip Architect. Definitely a floorplanning
tool aimed at frontend designers who have never seen or done physical
design. Might be acceptable for an ASIC flow but a real SOC COT flow
requires a more powerful tool. Silicon Perspective looks like it will
fit the bill. The new Cadence PKS First Encounter (or what ever its
called these days) flow should be a real challenger to Synopsys. Add
Plato and Simplex and it should blow away Synopsys."
- an anon engineer
"I had a chance to go across the street and demo First Encounter from
Silicon Perspective a year or so ago and was very impressed. Powerful
tool that ran in next to no time. Motorola had an internal tool
(Predix) that did a lot of the same things 10 years ago but nice to
see this (and more) in a commercially available tool. The question
is, how successful will Cadence be at integrating the tool.
- Jeff Waite of Netergy Microelectronics
"Monterey's IC Wizard is a good chip level planner. It works well with
RTL, black box models, and partial gate level netlists. It can
cluster or flatten hierarchy as needed and place pins based on a quick
route, global route, and the blockages or macros inside a level of
hierarchy. Although the GUI is nice, the command line interface isn't
intuitive, and the setup is overly complex.
IC Wizard is not a good block level floorplanner, but it wasn't
intended for this. The power insertion is not DRC clean, mega cell
manual placement is difficult, and ICW lacks many options required for
a good floorplanner. Monterey has shown me a road map for the coming
releases and I can see how they are going to improve this, but the
proof is when they deliver. For now, I struggle for lack of a good
floorplanner."
- an anon engineer
"IC Wizard lets you work with a top down black box approach (and
budgetting), that allows you to perform concurrent top level design
and block design. This is a key piece of our design approach. This
approach is starting to be available in Hidden Dragon, apart from
automatic Groute based channel sizing and variable die size approach
where they have no answer. Generally speaking, we need to floorplan
bus-based SoC's before any netlist of the whole chip be available.
This is not supported efficiently by First Encounter nor Hidden Dragon
at the moment."
- an anon engineer
"Since SNUG was a primarily front end conference the oversight of
techfile correlation for the flows presented was OK as the audience
does not have to deal with that yet. It is interesting that the only
complete multi-vendor flow that was presented at both SNUG and the
Avanti Users Group was a
Planet -> Apollo/Astro -> PhysOpt -> Star -> PrimeTime
flow. This flow was presented at SNUG as a 'look how great the tools
work and PhysOpt aided getting things through STA' flow. While at the
Avanti Users Group meeting, they focused on how the flow worked but it
was a major effort to corolate the RC extraction and setup for the
floorplanner, placer, detail router and the post-layout extractor.
The Avanti users warned that you can't close timing unless you use the
same numbers for all the signoffs."
- Pallab Chatterjee of SiliconMap
"[ User Name Deleted ] told me about some of the problems they've had
with First Encounter and Sequence Sapphire. They both are good at
minimizing skew, but if you have a net with fanout, they don't want
to find the shortest path, instead giving you a scenic path. Apollo
also gives a scenic route because it wants to treat everything like a
clock and start buffering from the center of the chip. He mentioned
that Cadence is buying Sequence. He is working on a 14 mm on a side
chip 1.6 Million gate ASIC in TSMC .13 um. They are also working on
a 18 x 18 mm chip! They are using Virage for RAMs and they keep
changing timing specs with each test chip result."
- an anon engineer
"Silicon Perspective certainly has the technology edge. As far as
integration with Cadence, I am not sure if they will work it out.
Typically when Cadence buys the best technology company after 1 year,
they are probably in the 2nd or 3rd. Same thing happened when I was
a design engineer at Sun, we helped develop Pearl. The minute Cadence
bought it, PathMill and PrimeTime took over the market.
I do believe Aristo offer a good methodology for block-level, but it
will be ONLY a point tool. No comments on Magma or Chip Architect."
- an anon engineer
"Hidden Dragon and Integration Ensemble are promised for such a long
time that I don't believe in them any more. For Magma and Silicon
Perspective we made some tests but were not impressed. The race is
close and open. I don't see us using them in production for the
next 6 month."
- an anon engineer
"I have to say that SPC's FE is really impressive. We have one eval,
the whole chip ( about 1.2m logic gates) can run through within
6 hours. And definitely, SPC's (Cadence) FE is ahead in this area.
But if you only use it as for prototyping, the cost of the tool
seems too high."
- Hui Fu of Infineon
"I'm a strong believer in IC Wizard (Monterey/Aristo). I've used it in
the past and I plan to employ it here as well. Once they will
integrate the Dolphin router and timer into IC Wizard, that will be a
killer environment."
- Nir Sever of Zoran
"I have been using Monterey (Aristo) IC Wizard for about a year. Our
main use is in reading arbitrary high level Verilog, and use the tool
to partition a design across multiple large fixed sized 'containers'.
IC Wizard has the ability to graphically 'push' into the hierarchy and
re-structure it by dragging blocks across hierarchical boundaries.
It then outputs the newly restructured Verilog.
There are some limitation to the tool, like supporting only 2 regular
grids that one can snap to. This is sufficient for regular users, but
due to our unique technology we have to do some contortions to emulate
a third grid in it. It's TCL interface helps.
The version I use (2.2) already has support for automatic partitioning,
but the new version has some of Sonar's partitioning and timing
algorithms - so it should be even nicer. I just hope the price will
not go sky high. :-("
- Ze'ev Wurman of eASIC Corp.
"With all those tools did anyone say 'framework'? I didn't hear it,
but how else are customers going to manage them?"
- Jack Marshall of Tera Systems
( SNUG 02 Item 17 ) -------------------------------------------- [ 5/15/02 ]
Subject: Aart's Technology Leak
GREENHORNS VS. VETERANS: This year's Aart keynote technology leak was a bit
more obscure than I had originally thought. Aart had annouced that PhysOpt
now corrects for crosstalk in its compiles. It's called "Enroute". When
Aart said this, it triggered a spontaneous thinking-out-load discussion
between Kurt Baty, Steve Golson, Oren Rubenstein, David Bishop, and myself
about how this would work. We were eventually told to quiet down by some of
the Synopsys bigwigs, but it got me to thinking. Here's what I see:
1.) Synopsys has working clock tree synthesis. See ESNUG 393 #9.
2.) Aart also reported that he had 2 Route66 tape-outs. This
means he has a working detailed router.
3.) Synopsys mentioned a few months ago in EE Times that they had
created a new 2.5 RC extractor. This means they're not using
their Arcadia extractor -- which makes sense because PhysOpt
would need a screaming fast extractor for its crosstalk cost
function in it's synth runs.
Put this all together and you'll see that Aart didn't announce that PhysOpt
now simply handled crosstalk at all. With the exception of some power
planing and IR drop issues, Aart effectively announced that Synopsys now
has a full soup-to-nuts RTL2GDSII physical synthesis tool. In very
discrete terms, he was saying that PhysOpt now no longer needs to rely on
anyone else's backend tools because he has them already any they work.
This now begs the question: "So why is Aart buying Avanti, then?!"
I pondered this a bit and realized that acquiring Avanti's $62.5 million a
year 45% marketshare P&R customer base didn't fully justify the $830 million
Avanti purchase price -- not to mention the ugly legal hassles involved.
Why Aart wants to buy Avanti is because he wants to secure his place in
the 90 nm battleground. Sure, Avanti's tools work at 0.13 um; what's
more important is that Avanti's R&D *people* are extremely experienced in
developing tools for new process nodes. Let me say that another way. OK,
so PhysOpt, Route66, Enroute all now work at 0.18 or 0.15 um. Get to 0.13
or 0.09 and it'll be a new learning curve for the less experienced Synopsys
R&D staff. Whereas the Avanti R&D guys have been here before. They know
the gotchas shrinking processes throw at you. They also know what does and
does not work to get around them. Add veterans to the deal, and suddenly
$830 million becomes not such an expensive asking price for Avanti.
"People we concerned about the Synopsys/Avanti merger. Since the
general opinion is that Avanti has a far better router (Apollo), in his
speech, Aart got asked about the fate of Synopsys' own router. Aart
said that he planned to keep both teams co-existed. I guess in public
he ought to say that in order not to diminish the morale of his own
engineering team. Yet keeping the two teams doing the same stuff
obviously is a waste of resources. I don't believe he'll do that in
the long run, and many attendees shared my view."
- Andrew Cheng of Cisco
"Aart gave everyone a sneak peek of what's coming in the pipe from
Synopsys. The new PhysOpt includes:
Clock-Tree Synthesis
Extraction
Detailed Routing
Signal Integrity Optimization
Aart shared early results from a beta customer on how crosstalk noise
was addressed. Several paths had noise above their 3.3 VDC threshold.
Enroute plotted crosstalk noise against the slack on each path. 30%
of the nets analyzed were critical, failing timing (negative slack)
and showed significant crosstalk delta delay. The next slide showed
the results after using the new PhysOpt. Crosstalk induced delay had
been reduced quite a bit and almost all the paths met timing.
I talked to a few Synopsys people at R&D nite. Their cost function now
includes noise. PhysOpt uses a very fast 2.5D RC extractor. Not
sign-off. PhysOpt generates distributed RC networks for delay and
crosstalk calculation. The noise analysis engine then computes the
peak switching noise for each net to create arrival time windows. If a
victim net n1 is aggressed by another neighboring net n2, PhysOpt will
either :
1. size up the driver of n1
2. insert a buffer on n1/n2 to reduce the extent of
coupling capacitance
3. move the buffers on the net
4. introduce another routing track between n1 and n2 to
reduce coupling capacitance
End result is a low noise legal routed database that meets timing."
- an anon engineer
"Aart gave a sneak peek into PhysOpt's future capabilities to reduce
crosstalk delta delay. He said early results looked good, but they
were far from done."
- Bob Wiegand of NxtWave
"The PhysOpt-SI product was pretty cool. This one was thought out well
and looks like it should work as advertised."
- Pallab Chatterjee of SiliconMap
"The block consisted of 60 K instances of logic with 5 memories, and was
targeted for TSMC 0.18 um 7-layer metal. The biggest issues were
timing closure in the presence of its complex clock tree, design
congestion and the routability of the design after back-end place and
route. The RTL, area and port locations were fixed and couldn't be
changed. In addition the block had low utilization (35%) due to the
fixed area constraint. All the other flows within Vitesse failed to
get closure on this problem block. They gave us 2 weeks to get it
through PhysOpt / Clock Tree Compiler and tape-out.
Clock Tree Description:
- 4 sub clock trees driven by a top-level clock (the top level clock
is also driving 8800 FF's) plus 5 reset trees & one scan mode tree.
- Clocks specification 2.0 ns, 4.5 ns and 5.5 ns periods with 10%
uncertainty
Here is what we got.
Clock tree # of FF Latency(ns) Buffers Levels Skew (ps)
----------- ------- ----------- ------- ------ ---------
Sub clock 1 2200 1.3 600 6 55
Sub clock 2 320 0.8 24 2 40
Sub clock 3 5000 2.4 340 7 200
Sub clock 4 175 0.7 12 2 15
Top clock 8800 2.1 560 7 200
Reset 1 2200 1.2 120 3 60
Reset 2 320 0.8 18 2 20
Reset 3 5000 1.3 275 3 75
Reset 4 170 0.6 14 2 12
Top reset 8800 2.0 599 7 326
Scan Mode 16400 2.1 916 6 160
In 5 days we taped out and met our clock skew spec on this block with
room to spare."
- Jens Michelsen of Vitesse (in ESNUG 393 #9)
( SNUG 02 Item 18 ) -------------------------------------------- [ 5/15/02 ]
Subject: Nassda HSIM, Avanti StarSim, Synopsys EPIC NanoSim, Apache NSPICE
BETTER BUY AVANTI: Synopsys EPIC has tried keep up in the near-SPICE
simulation market with its new NanoSim tools, but Nassda's HSIM and Avanti's
StarSim still seems to be kicking Synopsys butt here. And it appears that
the new kid, Apache NSPICE, might be coming out to play, too.
Dataquest FY 2000 IC SPICE Market (in $ Millions)
Avanti ############################### $43.2 (62%)
Cadence ######### $11.8 (17%)
Nassda ####### $9.0 (13%)
others ##### $5.7 (8%)
"IC SPICE is a very volatile market. The lead shifts back and forth
fairly frequently. As a new technology comes out, people aren't
afraid to throw away their old SPICE tool for a new one."
- Gary Smith of Dataquest
"The SNUG'02 mixed signal tutorial on Synopsys NanoSim w/ VCD showed
some severe limitations to NanoSim that have already been addressed or
have functioning work arounds with the Avanti & Mentor solutions.
NanoSim's drive strength to resistance conversion at the A/D interface
for simulation does not work or translate for multi-voltage designs. A
lot of the new processes have a multi-voltage operation where the I/O
with data conditioning is at one voltage and the digital design logic
is at another. This is the most common interface for mixed analog and
digital boundries. The NanoSim tutorial and demo do not indicate that
NanoSim can address this. If/When the merger happens, this definately
puts StarSim in the driver's seat for high-capacity device level sim.
Also, John, these SPICE simulator guys are at it again. (Just like at
DAC last year.) In the last 4 weeks Nassda HSIM, Avanti StarSim and
Synopsys NanoSim all claim to have the largest installed base and the
highest accuracy. The speed/accuracy game they play is hilarious.
Nassda/Avanti/Synopsys benchmark metrics of 'high accuracy and slow' vs
'low accuracy and fast'. They then puposely put the numbers as 'high
accuracy vs low' and 'slow vs fast' and try to get EDA users to buy
off on it being real."
- Pallab Chatterjee of SiliconMap
"We use NanoSim/EPIC tools for mixed signal verification in our group.
I know that HSIM and Celestry are also being used elsewhere here."
- an anon engineer
"The combination of NanoSim and VCS for mixed-signal sims is very
interesting as I'm working on mixed signal designs. However our
company has already purchased NC-Verilog, and after speaking with
Synopsys people at the SNUG Synopsys night, I don't think NanoSim
will cleanly interface with NC-Verilog. It was stated that 'at
some point' that interface will be available. I'd hate to have to
switch the current simulation flow from a known commodity like
NC-Verilog just to use NanoSim."
- Eric Mitchell of Cypress Semiconductor
"Since we're a mixed-signal design house, my analog colleagues use
these kind of tools. They have tried several and have chosen
PowerMill. They are going to upgrade now to NanoSim. They are
very happy with this tool."
- an anon engineer
"We have both StarSim and TimeMill/PowerMill here. We just started to
evaluate Nanosim last week. We have evaluated Mach TA and Nassda HSIM
before. I think in the digital transistor level circuit simulation,
EPIC tool is the best in speed and result. Nanosim can be equally
good if Synopsys don't make mistake. Nanosim has also good promised
features in next release like mixed-language (SPICE, Verilog,
Verilog-A, Verilog-AMS) simulation making it more likely to support
whole chip simulation.
The only drawback of EPIC is the capacity due to flatten architecture.
Nanosim seems to have the same weak point compared with Nassda HSIM.
Nassda HSIM is good in accuracy but slower than EPIC tool although
capacity is a benefit. But we didn't bother to wait for it complete
our benchmark with maybe 1 months run time. But I think Nassda is
not aimed for pure digital world.
Mach TA performance varied widely among different cases. We have seen
good performance in many cases although some are really bad. I think
Mentor didn't take effort to promote this tool. It should be more
visible.
I personally believe StarSim(XT) will be vanished like Motive (vs.
PrimeTime) judging from past Synopsys behaviour no matter how good it
is. In the past few months, we didn't see any improvement on it from
Avanti just like Hspice."
- an anon engineer
"Nassda seems to give me the best runtimes."
- Tom Moxon of Moxon Design
"We evaluated TimeMill, PathMill, Nassda HSIM. I'm experienced with
PathMill, and understand what Celestry is doing. Not sure how to
compare static tools to dynamic tools, but here is my take:
1) For our applications, StarSimXT still outperforms Nassda HSIM and
(there's no doubt) it out performs Celestry's tools.
2) We also found that StarSimXT in certain modes (still more
accurate then TimeMill) is better performance from capacity
AND runtime than TimeMill.
3) As static timing tools go, PathMill is extremely complex for
some of the engineering staff who are used to dealing with gate
level timing. But, I believe after about 5-6 months of experience
with it, it is reasonably accurate and faster than dynamic
simulation of the same circuit. Typically, it doesn't do a lot
of the coupling stuff (glitches, timing windows) that gate level
tools have started to offer.
4) The new entrant 'Apache' with it's NSPICE might be a threat to
HSPICE, particularly due to Apache's improved convergence,
better/faster processing of the same matrices and also multi-port
network simulations. All this while also doing *transient*
s-parameter simulations for RF/high speed simulations!
On static side, I believe Sapphire/Sequence's Physical Studio products
(FormIT, FixIT, etc.) are still much faster and more accurate than
PrimeTime-SI."
- an anon engineer
"We looked at Nassda. We were very impressed with it's runtime,
however, it wasn't as accurate as Avanti's StarSimXT. For a lot of
circuits this inaccuracy would have been acceptible, but for our
simulations which is mostly on memory circuits we liked the accuracy
of StarSim. We didn't evaluate any other tools for circuit simulation.
The EPIC tool, Pathmill, is for static timing analysis. Comparison
between this tool and Nassda/StarSim isn't applicable."
- Mamun Rashid of Specular Networks
"Nassda HSIM and Avanti Star-SimXT are close. Nassda is ahead with
Star-SimXT close behind."
- an anon engineer
( SNUG 02 Item 19 ) -------------------------------------------- [ 5/15/02 ]
Subject: The Synopsys 2002 Report Card
There's been a noticable crop of killed off smaller technologies at Synopsys
this year. ECO Compiler's has been End-Of-Lifed as Behavioral Compiler is
rumored to be. Eagle-i is dead. The Synopsys 0-in rivals 'Ketchum' and
'Verification Analyst' have been killed even before they were announced.
Nobody's seen Protocol Compiler for the past 12 months.
Then there's are the niches Synopsys is messing up in. Chip Architect and
its secretive Hidden Dragon replacement both suck. Everybody *still* hates
designing chips in C/C++ and now that hatred is being focused on SystemC.
Synplicity's kicking their ass in FPGAs. Last year, Synopsys owned 35% of
the FPGA synthesis market. Now they only own 14%! (Ouch.) Users yawn at
their day-late-and-a-dollar-short Scirocco VHDL simulator. And new this
year Mentor's FastScan appears to be seriously threatening TetraMAX in the
ATPG market. Oops.
There have been two noticable improvements this year, though. Formality is
still losing to Verplex, but it's been making a very noticable comeback in
the eyes of customers. BSD Compiler's no longer hated by users. It's moved
up to being just distrusted.
Other than FPGAs, most of these wounded/dying Synopsys tools are playing in
under $10 million markets. That is, they're mostly expendable experiments.
If they succeed, great. If they fail, kill'm. Let the market decide. The
only baby tool they can't ignore, though, is Hidden Dragon. In terms of
future tools, Hidden Dragon (or something like it) must work.
On the other hand, Synopsys has made and still makes a boatload of money off
of many key EDA tools. Design Compiler owns 87% of the $178.6 million RTL
synthesis market. PrimeTime owns 97% of the $26.6 Static Timing Analysis
market and it's successfully expanding into SI. Synopsys VCS goes roughly
50-50 with Cadence NC-Verilog in the $108.6 million compiled Verilog market.
DesignWare pulls in $45 million capitalizing the small IP market. DFT tools
pull in $39.9 million with a 51% market share. Formality has 44% market
share and pulls in $14 million. Vera has 43% and does $12 million. Power
Compiler owns its little niche. Module Compiler owns datapath.
But the two most important pieces of EDA news this year are that Synopsys
clearly dominates the physical synthesis market:
Synopsys PhysOpt ######################################## 600 tape-outs
Magma ####### 100
Cadence PKS ## 36
Monterey 3
and that Synopsys is acquiring Avanti.
"I think it's also especially bad news for Cadence. While their
corporate officers may simply shrug this off, I believe this merger
hits them where it hurts the most. They've been struggling to get
PKS production worthy, trying to add synthesis to their place and
route tools. But their toolsets and framework were always kind of
ad hoc (some would say baling wire and spit) and they've had
predictable results. Meanwhile, Synopsys looked from their position
of strength (synthesis) and forged a new approach based on their
strength and an astute analysis of the most basic problem in the
backend flow. The result is PhysOpt, and it is off to such a good
start that even many small firms are beginning to shell out the
4X DC price to start working with it. Now that Synopsys will add
what many consider to be best-in-class place and route to their
toolset, Cadence must feel great pressure."
- Mark Wroblewski of Cirrus Logic (in ESNUG 384 #8)
"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
[ Editor's Note: Please feel free to email me at jcooley@TheWorld.com if you
you have gripes/praise/questions about any part of this report. - John ]
============================================================================
Trying to figure out a Synopsys bug? Want to hear how 14,000+ other users
dealt with it? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@TheWorld.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
|
|
