!!! "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 (causin |
