( ESNUG 463 Item 2 ) -------------------------------------------- [03/16/07]
Subject: Answers from John Chilton, SVP of Synopsys
> There are 20 or so DFM companies. How do you segment the market and how
> many of them will you buy?
Well, DFM is a pretty overused word. As far as I remember, designs have
always been made to be manufacturable.
What most of these people call DFM is really "Manufacturing Software" - in
other words, software that's used by the mask & fab guys, not the designers.
These are well established things like CATS, Mask Synthesis, TCAD, Yield
Management, etc. The good news for us is that those are all areas where
Synopsys is a leader. The other leading vendors are also large companies.
With the space already pretty well covered by trusted companies and
manufacturing being a necessarily pretty risk-averse space I wouldn't be
very hopeful about most of the startups.
---- ---- ---- ---- ---- ---- ----
> Is simulation dead? With STA so complex and advanced these days, why
> should anyone bother to buy any Verilog, VHDL, or System Verilog
> simulators? Are your VCS sales dying because of your PrimeTime sales?
Verification is the EDA segment which is really exploding right now. Our
"Discovery" platform is growing revenue right now at 25% and the other guys
are reporting something similar. Why? Well, I suppose there is a lot
more RTL to verify. There is also a LOT of cool new technology that has
made it into verification lately that takes it way beyond banging cycles
through a simulator - things like testbench automation, constrained random
techniques, assertions, coverage metrics, etc.
Interestingly enough, we do see a bit of a return to gate-level cycle
banging for power analysis.
We shouldn't leave out mixed-signal -- SPICE and fast SPICE -- simulation
either, but that's a long story.
---- ---- ---- ---- ---- ---- ----
> What is Synopsys going to do to counter the Cadence ETS threat to the
> PrimeTime monopoly for static timing signoff?
We like competition; it is good for the market place and our customers.
We're going to work as hard as we can to keep PrimeTime as far ahead of the
competition as it's always been.
I do think it's funny to see others talking about how well their STA
correlates to their implementation. We're going to stay focused on how
well Primetime correlates to silicon.
---- ---- ---- ---- ---- ---- ----
> Why are you starting to blackmail customers who just want to buy your IP
> but don't want your antiquated tools? Is it because Cadence has an
> answer for DC and PrimeTime now?
I've never heard of that happening, but thanks for the compliment on our IP.
We think it's pretty good, too!
---- ---- ---- ---- ---- ---- ----
> Why is Synopsys making its software so kernel specific. They are now
> migrating their RHEL foundation to a different RHEL version. They keep
> changing the kernels (which will not support older versions of Synopsys
> tools) for the newer kernel versions and cause so much pain to their
> customers to make these changes. Why do they do this? They are software
> engineers and should make sure their code works across multiple kernels.
The problem here is that Red Hat only guarantees binary compatibility
between 2 versions of their OS, so in order to support their newer version
(version 5), we have to drop support for the older version (version 4).
The other option would be to support more incompatible versions. It might
be a surprise, but each new platform we support costs us literally millions
of dollars. Why? Because we have thousands of regressions and test
designs running on many, many computers to ensure that everything works.
We do try to select the version of the OS that is in broadest use in
industry and work with the rest of the industry via EDAC to establish
an industry-wide platform roadmap to make OS selection and transitions
as painless as possible.
---- ---- ---- ---- ---- ---- ----
> Why do you still promote 2 Fast SPICE tools - HSIM and NanoSim? Wouldn't
> it make sense to offer a single simulator?
Customers just have a preference. I guess that's why they bought one or
the other in the first place. We don't want to take something away that
customers want. HSIM seems very popular for things with regular structures,
while our high end logic-oriented customers use a lot of NanoSim. Both are
large products for us.
---- ---- ---- ---- ---- ---- ----
> Why, in this day and age, does Synopsys still dictate weird ASCII formats
> that are not:
>
> 1. Tcl morphed (command arg1 arg2 ...)
> Or
> 2. Released with official yacc code
>
> I mean, DEF is old news but CCS could have opened a new page. Did anybody
> try automating PrimeTime/PrimeTime-SI report reading?
>
> Flow automation is done by customers individually according to their local
> cultures and methodologies. Why not help us read and manipulate your
> formats? That could be more helpful than RAM or GRF.
Good point, but many of these formats you speak of have been around for
quite some time, so we need to be consistent when we enhance them with new
capabilities. Many customers rely on this consistency to enhance their own
home grown scripts and flows.
For example, with CCS, it needed to be consistent with the rest of Liberty;
same for new reports in PT/PTSI. We do provide free parsers for existing
open source standard formats.
One thing to look at might be our RAM and Pilot flows, which are useful for
customers who do not want to build their own environment but want to take
advantage of the most efficient use of the tools in the flow.
---- ---- ---- ---- ---- ---- ----
> Verification of power domains, power isolation, level shifter insertion,
> etc. is a real concern during design. Why have Cadence and Synopsys
> decided to be totally incompatible with each other?
>
> One aligns everything, the other adds extra files to the side. Imagine
> the scenario where our tool set is: NC-Sim simulation, DC synthesis,
> Conformal LEC for FV. I have to maintain, and make sure they match, two
> complete sets of power directives. Why?
At Synopsys we are fully committed to supporting the Accellera UPF standard
for low power design and verification. We have been actively participating
in the development of this open industry standard with user companies like
TI and Sun, plus EDA vendors like Mentor and Magma and with IP providers.
We think UPF 1.0 enables interoperable flows and is ready for industry use.
We REALLY want there to be one standard out there. Now that Si2 has
published their CPF standard we think it's time for the two groups to get
together and quickly merge them into one standard.
---- ---- ---- ---- ---- ---- ----
> Concerning the library format extensions to Liberty, could it be possible
> to make agreements on one standard instead of two? It's VERY annoying to
> be forced to support 2 formats. (ECSM from Cadence and CCS from Synopsys)
We too would like to see the industry converge around a single format in
Liberty. We have had discussions with our brethren across the table but we
haven't gotten much agreement yet.
Much like the VHS vs Betamax format wars, ultimately the industry will
decide. It will come down to openness of format (accessibility), ease of
adoption, extensibility (adaptability to tomorrow's challenges), quality
(technical merit), content availability (libraries), and key app support.
With this in mind, Synopsys is doing several things to help the industry:
- Provided industry access to CCS through Liberty, which is truly open
source. This makes Liberty the most open standard in the industry.
It's because it's open source that ECSM could branch off in the first
place. Now it's time to bring that back into the standard code stream.
- We created the Liberty TAB with broad industry representation (EDA,
designers, IP providers) to guide the evolution of Liberty CCS.
- Providing tools to enable easy adoption: parsers, checkers, library
validation utilities, characterization tools, guidelines, etc.
We are seeing tremendous momentum in CCS adoption at 65 nm: Libraries from
the key commercial IP providers, support from all the characterization tool
vendors, standardization at most of the major semiconductor companies, and
even an open source CCS-to-ECSM translator from a tool company.
---- ---- ---- ---- ---- ---- ----
> For Synopsys -- Why do you think that you get a hall pass for not truly
> opening up .lib and .sdc? Isn't that a double standard? (pun intended)
Liberty and SDC are the most open formats in the EDA industry - they are
open source.
Bottom-line, the EDA industry and our customers have benefited greatly
from Liberty and SDC over the last 20 years. We have made vast amounts
of investment and innovation aligned with solving key industry problems:
timing, SI, low power, variation-aware design. We have opened this
innovation to the industry while providing stabilizing force. Since then,
Liberty and SDC have become the backbone of EDA tools and de-facto
language of libraries and design constraints.
If startups had to create this from scratch they wouldn't exist today.
---- ---- ---- ---- ---- ---- ----
> Do you see any path where an efficient compile in DC, using all the
> optimization power, can have formal verification applied, and not use
> binary files passed from DC? If I'm trusting the FV tool to tell me
> my gates match, I sure want to be able to *SEE* what it is making that
> judgment from. "Under the hood" just doesn't cut it when mask sets
> cost in millions.
We agree that "under the hood" solutions are unacceptable. Formality
automatically converts and writes the TCL representations for any file
used. As a user, you are free to review every line within the file and
use these reviewed files in all of your verifications.
---- ---- ---- ---- ---- ---- ----
> Multi-CPU machines have been available for several years now, when will
> there be a multi-CPU version of PrimeTime available to take advantage of
> the other 3 processors on our machines (where you can take a single run
> and distribute it across N CPUs to get a speedup of N... not just the
> "job distribution" you currently have where you take 10 jobs and
> distribute them across 10 machines.)
No doubt about it -- parallel CPU architectures present an interesting
opportunity if you can figure out how to capitalize on them. This is one
more in a host of techniques we have in development to boost productivity.
For example, today we have a capability called DMSA -- distributed multi-
scenario analysis. Everyone runs multiple corners and multiple modes for
analysis and signoff in PT. DMSA, like you said, distributes multiple PT
runs across N CPUs. The value of this is not just faster runtime of
multiple scenarios. The true value is also the merged reporting and "what
if" analysis capability -- this can save days and weeks of analysis, debug
and ECO time -- orders of magnitude larger then STA run time.
Now that multi-core processors are becoming standard new boxes shipped we
will see more and more clever ways to make use of them in leading EDA
tools. Stay tuned.
---- ---- ---- ---- ---- ---- ----
> Why we were told that Physical Compiler was the best tool ever when it
> first came out. We then later found out that the synthesis engine in
> PhysOpt only did a few of the dc_shell bag of tricks when they started
> pushing DC-Topo. Is DC Topo a backdoor price raise?
Physical Compiler was the best tool ever when it first came out! PT solved
the timing closure issue that was killing design productivity at the time.
That's why it was the fastest adopted EDA tool in history.
DC Topo is the next evolution in the same story. It's brand new technology
introduced in DC 2005 to help the synthesis users improve their productivity
by providing very accurate correlation between synthesis results and the
results post layout. The great new thing is that, unlike Physical Compiler,
it requires no physical expertise and fits seamlessly into your existing DC
synthesis flow.
As for the backdoor price raise question, the answer is "no". DC Topo is
included in DC Ultra (no extra charge). Did we leave some money on the
table there?
---- ---- ---- ---- ---- ---- ----
> Approximately what is the bug count on Design Compiler, and has it been
> increasing or decreasing over the past 3 years?
Over the last years we have been investing significantly in improving the
quality of all our products including DC. In the last 2.5 years we have
reduced the DC weighted defect count (which is what we measure) by >35%.
---- ---- ---- ---- ---- ---- ----
> Is DC-Topo really doing an actual placement under the hood or is it some
> kind of "virtual placement"? If it is a true legal placement, why can't
> DC-Topo write out DEF?
DC-Topo uses the same physical algorithms as IC Compiler to generate what we
call 'virtual layout and clock-tree' and drive accurate information into the
synthesis engine. This allows for very close correlation between DC-Topo
and IC Compiler.
Being a synthesis tool for the front-end designer, DC-Topo does not require
any physical expertise, does not perform full placement and passes a pure
netlist to the back-end.
---- ---- ---- ---- ---- ---- ----
> Why is the VMM code still not freely available? Is it because you want
> your customers to use the AVM instead? Or is the implementation so lousy
> that you are ashamed to show it?
>
> Is VMM actually written in Vera, not System Verilog? If not, why won't
> you release the code? AVM is open source, and Cadence say their P2C
> libraries will be. Why not yours?
VMM has had wide adoption. Thousands of books sold, hundreds of design
teams adopting VMM, no problems agreeing to our license agreement.
All VMM code is written in IEEE compliant System Verilog. We have open
sourced the specification of the VMM class library. The actual source
code of our implementation is available to all VCS licensees at no charge.
Beyond the code, we have completely open sourced the whole methodology
through the VMM. How much better can it be than that?
---- ---- ---- ---- ---- ---- ----
> How do you expect to continue innovation when majority of the R&D work
> force is moved offshore (ie. India) just for the sake of saving cost?
The majority of our work has not moved offshore by any means. We're
seeking out smart people from all over the world -- some of those smart
people work here where we benefit from their proximity to so much of the
industry infrastructure and many work overseas.
---- ---- ---- ---- ---- ---- ----
> Please ask the Synopsys guy about the "openess" of Vera. They had
> promised a long time ago to open the whole language, yet my impression
> is that they have only opened the core of it.
OpenVera is an open language specification. Anyone can use it, they just
need to license it from Synopsys. We continue to invest in supporting
our Vera customers and enhance the technology and continue to drive our
System Verilog offerings.
---- ---- ---- ---- ---- ---- ----
> We use a Cadence NC-Sim/Specman combo with Synopsys Design Compiler for
> synthesis. What we forgot was their System Verilog interoperability;
> they do not support the same subset of the standard! When will it be
> possible to run verification on code that's synthesizable and vice versa
> in System Verilog with industry standard tools? (I don't doubt that it
> may be possible with a pure Cadence or pure Synopsys solution -- but for
> various reason's that is not desireable...)
The whole idea behind System Verilog was to bring advanced verification
techniques to a broad range of users in a single, open industry standard
language. As a leading proponent of System Verilog we are certainly
working toward this goal. Today you can design, synthesize, lint, formally
verify and run dynamic verification on a System Verilog design and it all
works well together.
---- ---- ---- ---- ---- ---- ----
> What is Synopsys' position on SystemC? If you think System Verilog is a
> better choice, why do you still sell Cocentric SystemC Studio? Are you
> just trying to cover your bets?
We love SystemC. Sometimes there seems to be confusion because we also
love System Verilog. (I guess because they both have the word "System"
in their name).
In fact, SystemC and System Verilog are very complimentary. We see SystemC
being used primarily for system modeling and transaction level interfaces
and System Verilog used for verification including testbench authoring,
constrained random generation, assertions, etc.
We continue to develop tools to support both languages as well as VHDL and
Vera in a mixed language environment. This gives our customers a broad
range of language choices to pick the best language for the job.
---- ---- ---- ---- ---- ---- ----
> Are you going to buy Synplicity to break into the FPGA market, or are you
> just going to continue to try and become a DFM company, even though the
> amount of research needed to even begin in that market is out of any
> single company's league?
We're happy to be the largest synthesis and largest DFM company. We
continue to be interested in FPGA, but it hasn't grown that much.
---- ---- ---- ---- ---- ---- ----
> Many of our large designs use FPGAs to demonstrate correct operation with
> the intention of eventually porting to ASICs. Often, "eventually" never
> happens. My question is: are we going to see integrated tools for the
> FPGA-then-ASIC design cycle, or do I have to continue to use the crazy
> mix of kludge tools we've got now?
As Synopsys does not presently provide tools for FPGA implementation. We
are working with other vendors via our interoperability programs to provide
interoperable flows and solutions to customers that design FPGAs and then
take them into ASICs.
---- ---- ---- ---- ---- ---- ----
> After all this time is anybody using System Verilog for design?
Absolutely yes, including multiple tapeouts. Nearly 10 percent of the 2006
SNUG attendees said they were using System Verilog for design.
---- ---- ---- ---- ---- ---- ----
> Cosmos is dead, what/when is coming the answer from Synopsys to Virtuoso?
> Is it true that most of this effort is concentrated in Armenia?
Cadence does have a large market share in analog/custom implemention. (We
are happy to have the largest share in analog/custom verification.) We'd
like a piece of implemention. We're continuing to work on it but we're not
announcing anything right now. It is a space that's dying for some
competition and innovation.
It's true that we're working on this in many parts of the globe.
---- ---- ---- ---- ---- ---- ----
> Can Hercules do 65, 45 and 32 nm? Is Synopsys working on any new
> development to answer Quartz (Magma) and PVS (Cadence)?
Hercules is already in production at 45 nm and ready for 32 nm.
With over 18 months of production silicon on 65 nm, the tool completed its
first 45 nm tape out in Q4 2006 and has several active 45 nm designs in
progress in 2007. In addition, Hercules run set development is underway
for 32 nm at a leading IDM.
We continue to invest in developing new features, and improving performance.
We were recently told by a large foundry that Hercules is the leading
performance tool in the category and there has been more innovation and
advancement in that tool than in any other in the category. We have won
several competitive benchmarks against new and existing PV tools over
last 4 months.
---- ---- ---- ---- ---- ---- ----
> When will Hercules be integrated into IC Compiler and will the engine be
> utilizable to allow DRC clean 45 nm routing?
Hercules can be used to verity IC Compiler's routing. Both Hercules and
IC Compiler operate natively on the Milkyway database. Customers who take
advantage of the tcl-based menu access to Hercules VUE can launch and
debug errors inside IC Compiler.
---- ---- ---- ---- ---- ---- ----
> Is Synopsys ever going to release a real database? Or are they just
> going to continue and attach files, stick a feather in their hat, and
> call it macaroni?
Milkyway is a real database heavily optimized for digital design, which
requires manipulating millions of elements (it's not like analog).
I assume you're talking about Open Access as the "real" database. Just
remember that very leading-edge digital designs are done on top of
Open Access.
Index
Next->Item
|
|
