( DAC 03 Item 25 ) ----------------------------------------------- [ 01/20/04 ]
Subject: Cadence First Encounter, NanoRoute, CeltIC, Simplex, Get2chip
ONE UGLY YEAR: Get into an honest private discussion with any of the Cadence
old timers and they'll tell you that 2003 was a brutal year. After 14 years
of being No. 1 in EDA revenue, in 2003 Cadence had to concede that title to
Synopsys. The Cadence old timer will say: "Synopsys is No. 1 because they
bought it. The FTC should have nixed the Avanti merger. Synopsys didn't
earn it on their own." My reply would be: "Whoa! Cadence was formed by
merging ECAD and SDA. You then made a boatload of cash off of Gateway!
Now tell me exactly *who* bought their way to the top here?!?"
Not that I ever have conversations with Cadence old timers... :)
On the technical side, Cadence made some savvy purchases of late: Verplex,
Get2chips, Celestry, Antrim, and K2. First Encounter painfully dominates
the ASIC floorplanning market to the great chagrin of Synopsys & Magma.
All the custom layout rivals beg to steal scraps from Virtuoso. Plato
NanoRoute is getting good user comments. The Simplex tools look OK, too.
And in ESNUG 420 #1, Broadcom published user benchmark where CeltIC mopped
the floor with Synopsys PrimeTime-SI -- which is especially biting because
SI issues took the front seat with users at this year's DAC.
We are using Cadence tools for chip design, actually, during the last
year we have taped-out six times, all of them work on first try. Cadence
seems to have very good point tools like PKS, First Encounter, CT-PKS for
clock tree and BuildGates for synthesis.
The problem is that in each category one can find at least two to three
solutions, some of them phasing-in and some phasing out: NanoRoute or
Wroute? CTS or CT-PKS or CTGEN? PKS or Encounter? Get2Chip or
BuildGates? HyperExtract or Simplex? Qplace or Amoeba placer? As
users, we really wish to see one integrative and stable flow using common
database (OpenAccess may be a good choice).
Tip for TSMC customers: download Voom's great reference flow for Cadence
environment from the TSMC website. It will help you to design your flow.
Cadence is decently on its way to become the "all-in-one" choice for new
and existing COT departments. With their integrative approach for the
encounter, there is more than a good reason to "return home" in terms of
CAD flow.
- Eli Assoolin of Transchip Israel Research Center Ltd.
Cadence continues its buying spree from last year, this time acquiring
Simplex (OK, that one had been announced last DAC), Celestry, Get2Chip,
Antrim Design and K2. One must wonder exactly what Cadence R&D is doing,
other than trying to figure out how to bolt all these independent tools
into something resembling an integrated system.
- John Weiland of Intrinsix
Overall, we have been quite happy with SoC Encounter; since we haven't
used any of the competitor's products, I can't really give an opinion
as to how it stacks up (although I can say that Monterey's display at
DAC looked quite interesting.)
SoC Encounter strengths:
- Works with a wide variety of industry standard file types (important
when 3rd party tools must integrate with SOC-Encounter)
- User interface is simple enough for a beginner to use; advanced users
have access to a variety of tcl commands/routines (scripting)
- Results correlate well -- PrimeTime vs PKS / Columbus vs Fire&Ice.
SoC Encounter weaknesses:
Although capable of "hierarchical" design implementation, using the
tool in such a fashion is far from simple -- the steps can be
complex and result in a significant increase in run time.
- Jason Sheplak of Insyte
I have been a Cadence PKS and First Encounter user. So far I have been
involved in 4-5 chips that we taped out and the tools have been good in
terms of both performance and run times! The combination of
Encounter/PKS has been very helpful to us in getting timing closure in a
predicted manner. I must say we have NOT gone back to RTL guys to
restrucure their RTL or resynthesize RTL to meet timing once the input
netlist meets certain criterion like a 20% slack with zero wire load.
And I guess we'd like to continue using these tools!
- Srinivas Kakumanu of Time2mkt.com
Synopsys' stutter step on floorplanning may be exploited by Cadence.
By bundling their floorplanner with their P&R, Cadence can get people
to join the patch-of-the-week club. Smart move on their part.
- John Weiland of Intrinsix
We like Cadence's physical tools.
- Damien Chardonnereau of Iroc Tech
We are using the Cadence PKS/Encounter platform. We evaluated also the
Monterey tools, but unfortunately these tools were too complex to use
(required specific tuning per each and every block) and also did not
reach timing closure on any of our test-case modules (challenging
designs). The Encounter platform proved to be an efficient platform with
many interesting features.
The First Encounter and Monterey IC-Wizard are different. While the
First Encounter provides real assessment while floor-planning the design,
IC-Wizard is only a floorplanning and for assessment you'll need to use
Sonar. As such it is simpler to use and faster to implement the early
stages with Cadence. However both tools are lacking some of the real
floor planning features that used to be in DP (Design Planner - also from
Cadence) and as such we are still using DP for these specific features.
- Yuval Itkin of Metalink Ltd.
PhysOpt is great but has a capacity problem and very long run times.
Magma BlastFusion (or actually Blast RTL) is OK but is still not mature
enough. Cadence First Encounter works very fast but the results are not
accurate comparing to PhysOpt and full layout results, so it cannot be
used as a real physical synthesis.
- [ An Anon Engineer ]
Magma BlastFusion - I try not to think about it.
Synopsys PhysOpt - Still the 800 pound gorilla, but I'm not sure that
they're moving fast enough to work SI and power into the mix.
Cadence PKS/Encounter - Won't knock off Synopsys PhysOpt, but the overall
suite of tools is much better than it's been in the past.
Monterey Sonar/Dolphin - Are they still around?
Sequence's Physical Studio - Didn't look. Not a real player in my world.
Avanti Jupiter/Saturn - In all my time in the Synopsys suites, I heard
nothing about Saturn. I assume it's going away (or being renamed).
- [ An Anon Engineer ]
First, let me introduce our story of NanoRoute 3 years ago. We had been
struggling very hard to complete top level routing on network processor
ASIC design. The design was 10 M gates and hierarchical layout. The
chip size had already reached the limit of process at that time. There
was no more room to shrink block layout size for giving channels top
level. Wroute always reported so many violations on top level routing.
Actually the contender was FlexRoute at that time. No designer here
thought of NanoRoute as a favorite because we had already started using
Synopsys FlexRoute ourselves and NanoRoute was operated at Plato by a
Plato guy.
FlexRoute did a good job, it was faster than Wroute, and also finished
routing on top level with some violations, good. We began the timing
closure work with a sigh of relief. However, the situation became
worse as design closure proceeded. Routing violations increased and no
sign of convergence.
Then Plato gave us a big Christmas present, routing result with only 8
violations! We rushed to DRC confirmation and it was correct. Also,
FlexRoute support had a problem -- they didn't want to guarantee the
output DEF is compatible to Silicon Ensemble. They only guaranteed that
the output GDSII was clean when the violation report from FlexRoute is
zero. The design required so many manipulations at the final design
stage with Cadence Silicon Ensemble, so our expectation to FlexRoute
was misdirected... On the other hand, Plato worked hard not just solve
routing violation problems but also design DRC problems for our design
completion.
After this design, we kept using NanoRoute especially for top level
routing because the key feature "chip assembly mode" works very well
when top level has big blockages like block layout. Less detour was
another good point. Multi-Thread was innovative! Wroute still had an
advantage in case of block level which was occupied with standard
cells, therefore we kept using Wroute for flat design and block level
routing -- also Wroute is cheaper than NanoRoute.
The biggest NanoRoute problem is that it "misses the wisdom of age".
In most of the design, NanoRoute requires Wroute because of minor DRC
problems. This situation is almost over now but annoyed us for so
long. I actually spent my time checking DRC and reporting them to
Plato so many times it was like playing a whack-a-mole game you see
at carnivals.
Wroute has so many options (how many hidden?) helpful to clean up
design, but NanoRoute hadn't. Wroute has a very strong ECO routing
feature compared to NanoRoute. I guess these are the reasons why
NanoRoute can't be a cleanup batter, honestly speaking.
- Kazushige Itazu of Fujitsu
NanoRoute is an interesting step. We started to use it several months
ago, and after tuning the router it does significant better job than
older generations (like Wroute).
- Yuval Itkin of Metalink Ltd.
NanoRoute looks very promising, if the SI features work as advertised.
In DRC/LVS, it's really a Calibre vs. Hercules world. Hercules still
looks like the better tool to me, but both are highly dependent upon how
well the rules decks are written. Cadence may as well admit they've lost
that market.
- [ An Anon Engineer ]
We've been evaluating most of the available mixed mode tools since this
is something where we really need a good solution for. We're currently
using Nanosim since it was the only tool available at the time we
started looking. We're *not* happy since this tool is proving to be
buggy and quite difficult to use. We're getting a lot of support from
Synopsys and it's just keeping us alive. They don't have a single
kernel simulator and are co-simulating with two engines. This is not an
ideal solution.
We looked at the Cadence AMS Designer and are not likely to proceed
with it at this point. It looks like it has some nice features,
particularly in terms of the UI and we like NC-Verilog, but it
currently doesn't have integration of a fast SPICE engine (Ultrasim)
and that's promised for Q4. Since that's essential for us to get any
benefit from this kind of tool, we're not interested until it's there.
Mentor's AdvanceMS seems to be the strongest of the tools based on what
we've seen so far. It is a single kernel engine and seems to have nice
features, particularly in terms of analog pass through and control of
the DA/AD conversions. If we were starting today, we'd almost certainly
go with Mentor.
We're probably going to struggle on with Nanosim since we have tapeouts
due before the end of the year but once we're past that point, we'll do
a full scale evaluation and consider moving to AdvanceMS.
- Kevin Jones of Rambus
AmmoCore Fabrix - Still too immature. Will probably be bought by Cadence
at some point.
- [ An Anon Engineer ]
AmmoCore sells a hierarchical placer. It first does a fast partitioning
of the design into blocks of 300 to 3000 cells (S blocks), based on min
cut set, timing and logical hierarchy. These blocks are then placed to
create the overall design. Blocks are iterated if pin placement is bad.
They say this gives much faster results for physical design prototyping
plus it minimizes signal integrity problems. They also do scan chain
ordering. They say they have done 10M gate designs.
- John Weiland of Intrinsix
We purchased CeltIC because we need the tool to simulate noise and
crosstalk issues for all of our designs in 0.18 um, 0.13 um, 90 nm
technologies. We need to identify all noise failure nets and fix them
before tapeout to guarantee that we will have working silicon.
CeltIC provided excellent values for our designs which identified all
noise issues and provided the ECO fixes to work with the place and
route tools (Silicon Ensemble, PKS, NanoRoute). Signal integrity is
very critical at < 0.18 um technology and we endorsed CeltIC as the
sign-off tool before tapeout.
Strengths:
- Accurate, proven sign-off tool.
- Easy to use and interface well with industry standard tools and file
format (LEF, DEF, SPEF, DSPF, Verilog, PrimeTime, etc.)
- Works smoothly within the Cadence's PKS flow with automated ECO fixes
for SI.
- Support ECO features for other place and route, such as Magma and
Apollo. Good waveforms and detailed reports.
- Run time is reasonably fast.
Weaknesses:
- Speed (run time) can be improved for big design.
- Incremental SI analysis can be helpful to save turn-around time.
I hope this is of value to your readers.
- Andy Le of Toshiba
We have used CeltIC on several tape-outs from .18 um to .13 um as part
of our standard ASIC flow. It has a good set of noise analysis and
filtering methods to minimize the number of false errors reported.
It also has SPICE-like accuracy and a fairly quick runtime
CeltIC integrates well into a comprehensive noise flow of prevention,
analysis, and correction. Most real noise issues can be avoided very
effectively by setting appropriate design rules during synthesis and
layout optimization. Tools like CeltIC are essential to remove the
cases that pass through our standard design flow and to verify for
sign-off.
- Steve Majors of Mindspeed Technologies
In terms of both accuracy and capacity of timing and noise analysis,
CeltIC is a much better tool than PrimeTime-SI. However, with the
dominant STA, PrimeTime-SI will still be very competitive.
- Weikai Sun of Volterra
We used Cadence's CeltIC for SI checking on a large, complex SoC. Our
design used 0.13 um technology and well over 100+ million transistors.
The chip has now been in lab evaluation for about two months, and we
have not seen any issue that is related to crosstalk or noise.
This is how we used CeltIC: We ran Cadence's PKS on several blocks
that were representative of all the blocks on the chip. After routing,
we used CeltIC to determine how SI issues were impacting performance.
From that data, we tuned the routing parameters related to SI. We then
repeated the route. Fairly quickly we converged on how to route the
blocks without SI issues.
The rest of the chip was then completed, and each block was run through
CeltIC to determine if the routing parameters were set correctly to
avoid SI. By doing the up front analysis, we were able to route blocks
correctly the first time.
CeltIC also has the capability of writing out ECO instructions to use
in re-routing, but we did not use this feature.
An improvement I would like to see to this flow is for the router to
automatically compensate for SI and adjust the routing parameters
accordingly rather than having to go thru a route-analyze-adjust loop.
As to why we initially chose CeltIC, Layer N Networks has a design flow
that is primarily Cadence-based. We use SE-PKS (Wroute) for place and
route, so it made sense to use CeltIC as it was integrated with those
tools to drive SI closure -- provided it gave acceptable results.
CeltIC allowed us to tape-out with high confidence that the design
would be functional. The tool was not difficult to use and ran in a
reasonable length of time. Cadence gave us excellent support.
- Scott Herrington of Layer N Networks
CeltIC weaknesses:
- Need better documentation about the tool.
- Need clearer msgs on errors.
- Need Linux support
CeltIC strength
- Quite fast
We picked CeltIC because there was no other tool available at the time
which did noise analysis. Also CeltIC was used on previous projects
with good results.
- [ An Anon Engineer ]
We have been using CeltIC for the past 2 years in our production flow
environment and have successfully completed 20 tape-outs to date using
CeltIC. We're generally pleased with its performance. Oki does about
30 - 40 Multi million gate designs every year, with frequency range of
100 - 350 MHz in a range of sub micron technologies, and we use our
own libraries and foundries.
Most recently we evaluated CeltIC 4.2 and were impressed by its
performance enhancements compared to CeltIC 4.1, especially with its
internal timing engine which eliminates the need for timing windows
files. Also liked its analysis of glitch propagation to latches. We
have seen a 50% reduction in glitch noise nets due to improved accuracy
in CeltIC 4.2. Combined with NanoRoute crosstalk-aware routing, we
were able to reduce the number of noise nets by an additional 50%. So
based on our eval of combined NanoRoute and CeltIC 4.2 results, noise
nets were reduced to 25% of the original on a number of benchmarked
designs.
We want improvements in CeltIC are output repair files. Currently it
outputs repair files for fixing crosstalk nets by shielding, buffer
insertion and extra spacing on the noise nets which are used in a
mutually exclusive mode. We would like CeltIC to fix these noise nets
by using all 3 techniques in a single run by outputting a single ECO
file, so that we can simultaneously apply all the above techniques in a
single run.
- Jaweed Ali Mohammed of Oki Semiconductors
CeltIC is the only signal integrity tool that utilizes a piece-wise
linear (PWL) instead of a triangular waveform to represent the noise
signal. To reduce the number of SI false positives (which can be huge),
CeltIC restricts its analysis to paths that only go to sequential
elements. The combination of these two capabilities may be responsible
for making CeltIC the best SI tool in use today. CeltIC integration
with SignalStorm (CeltIC NDC) is planned for June 2003 and static
timing analysis + CeltIC NDC (NanoTime) is planned for Q1, 2004.
- [ An Anon Engineer ]
CeltIC vs. PrimeTime-SI Benchmark Results:
CeltIC PrimeTime-SI
-------- ------------
Max Rise Mean Error: 4.9025 -23.2759
Max Rise STD Dev: 11.0508 25.3116
Max Fall Mean Error: 11.3949 -0.1695
Max Fall STD Dev: 10.6221 30.7975
Min Rise Mean Error: -6.4781 0.9596
Min Rise STD Dev: 8.2935 15.5052
Min Fall Mean Error: -6.0534 2.0522
Min Fall STD Dev: 9.7295 18.2835
Our results showed that CeltIC has better bounded accuracy than
PrimeTime-SI for crosstalk induced delta delay calculation.
- Jatan Shah of Broadcom from ESNUG 420 #1
The strength of CeltIC is the ease of use and the thorough analysis of
all SI effects. Its weakness is that the waveforms in the SI report do
not have a defined timing scale, which effectively makes them hard to
interpret. The number of alarms being reported is acceptable due to
the advanced filtering of false alarms.
We have had a good experience with it.
- Yuval Itkin of Metalink
We have been doing a CeltIC 4.2 evaluation at Toshiba America (TAEC),
San Jose, California. We use CeltIC at the post route stage for cross
talk analysis and repair to fix glitch/delay violations due to cross
talk. After post route design optimization when timing is met, we run
CeltIC for cross talk analysis. CeltIC 4.2 can generate repair file
for fixing noise violations in a number of formats including SE, PKS,
FE, NanoRoute. We can also specify the type of fix such as buffer
insertion, resizing, spacing, shielding etc.
- Sampath Oks of Toshiba
We've been using CeltIC for a couple of years. CeltIC is used as a
point tool to verify the signal integrity performance of each design.
CeltIC slotted into our existing Synopsys/Apollo flow reasonably well,
though there were quite a few flow issues that needed to be ironed out.
The tool was purchased because we saw crosstalk noise problems in some
0.18u chips.
Here's a quick overview of our flow:
We analyze designs hierarchically, using the tool to generate a model
for blocks and using these abstract representations when analyzing the
next level of hierarchy. Transition time information is taken from
Primetime and fed to CeltIC. All noise problems flagged by the tool
are fixed through an ECO in the layout tools, and crosstalk-induced
delay variation is generated for use with our STA analysis in
Primetime. Any timing issues caused by the delay variation in STA are
fixed. After ECOs are done, CeltIC is run on the netlist again.
The design will go through this loop a number of times, with the number
of noise problems usually converging to zero after a couple of passes.
CeltIC has been pretty useful. We had to develop a lot of
infrastructure around it to get it to work within our Synopsys/Apollo
environment, but the newer releases make this a lot easier; the ability
to generate Apollo ECOs for example. Since CeltIC was introduced to
the flow it has saved us from any noise issues on tape-outs, providing
the tool has been used properly. Correlation to silicon is good - one
recent example was a device revision where STA did not flag a problem,
but STA with CeltIC-supplied delay variation information did show a
timing failure.
Tool shortcomings - lack of integration into the rest of our flow.
Could be a lot more useful if it played well with the rest of our
software. Also, the tool can be non-intuitive for the user - we hide a
lot of the complexity through wrappers, but getting useful information
from the logfiles can be quite a challenge. One final comment is that
memory usage seems to have increased with recent releases - this may
become an issue.
Our big bottleneck is generating transition times from Primetime.
Noise analysis with CeltIC is pretty fast.
Overall, CeltIC does what it claims to do. We have not had any noise
problems since it was introduced to our flow, again provided the tool
and associated flow have been used correctly."
- [ An Anon Engineer ]
Here's a dump of my experiences with CeltIC (and PrimeTime-SI).
We've been using CeltIC (and before it, PacifIC) for about 5 years.
During that time our design style has evolved from a near-full-custom
approach to a synthesis based std cell approach. CeltIC was adopted
because it was the only practical SIV solution we could find.
At the time, the only known alternative was Assura-SI, which had major
capacity problems and the only output it provided was a report of
glitch voltages -- it was left to the user to decide how much noise was
too much. The sensitivity report generated by CeltIC provided the
filtering needed to correctly prioritize repair work. In versions of
CeltIC prior to 4.0, the default method calculated sensitivity as a
sort of AC voltage gain for a given gate. A sensitivity whose
magnitude approached or exceeded 1 indicated that the noise at the
gate's input had reached the high gain portion of the gate's transfer
curve and the noise would be propagated and possibly amplified.
CeltIC also provided incremental SDF to feed delay variations due to
noise into PrimeTime. Initially, no slope variations were generated to
feed to PrimeTime, and so the impact on cell delays was missing. Along
the way, the ability to generate slope annotation was added to CeltIC
(not sure what version).
After Cadence bought CadMOS, it appears that most of the development
work on the tool has focused on integrating it into their NanoRoute/SoC
Encounter flow at the expense of CeltIC the point tool. Many of the
default behaviors of the tool have changed in versions 4.0 and 4.2,
leaving us to scramble to get CeltIC to replicate results from earlier
versions.
About 4 months ago we began benchmarking Primetime-SI against CeltIC
with PrimeTime for timing. We initially found large differences in
predicted path delays, with Primetime-SI typically being much more
pessimistic. The differences were due to missing slope annotation in
our CeltIC/PrimeTime flow. When the noise impact on slopes is
accounted for (with the associated changes in cell delays), the
CeltIC/PrimeTime combo and PrimeTime-SI agreed relatively closely, and
matched HSPICE results to within a few percent.
Adding the SI analysis (2 iterations seemed sufficient for convergence)
to a PrimeTime run seemed to roughly double the analysis time. The
CeltIC run to get comparable delay/slope annotations required adding a
"-all" option to the analyze_noise command; without this option set,
small incremental delay annotations are lost due to filtering. This
option appears to have little if any impact on CeltIC run time.
In one example, for a module of ~400K nodes, the basic PrimeTime timing
run took approx 2 hours, which went to 4 hours when SI analysis was
added. The CeltIC run to generate SI delay and slope annotations,
along with sensitivity analysis took 3.5 hours. A 2 hour PrimeTime run
using the delay and slope annotations from CeltIC is required to close
timing, though Cadence is testing the incorporation of a timing engine
which will enable CeltIC to complete the timing closure task.
At present, the total run time results can't be compared since
PrimeTime-SI is not checking "functional" noise issues; glitches that
can disturb flops, and invalidate static timing by introducing
transitions not predicted by STA. This capability is being tested in
PTSI by Synopsys, but requires additional library characterization.
It appears that Synopsys is not going to provide the tools for
performing the necessary characterization. CeltIC has this base
covered, and has been enhanced recently to cover gnarly problems like
multiple transitions on clock nets (ripples on transitions that can end
up amplified into extra clock pulses). Sensitivity analysis, which is
currently formulated as a measure of the disturbance voltage on the
output of a gate receiving a noisy signal, is by far the best way to
prioritize nets for repair, since it accounts for the noise rejection
properties of individual library cells.
CeltIC comes with make_cdb, a characterization program executed on
SPICE extractions of cells to create the noise library used by CeltIC.
Characterization of a full standard cell library over multiple PVT
corners can be completed in a few hours, or at worst overnight. The
characterized library contains tabular data for fast noise analysis and
also SPICE connectivity which allows CeltIC to engage a SPICE engine
for nets with significant noise.
It is yet to be seen how well Synopsys will do in adding glitch
analysis to PrimeTime-SI and how well Cadence will do in adding full
timing capability to CeltIC. At this point, a clean CeltIC stability
report is a requirement to validate the noise impact on timing analyzed
by either a PrimeTime-SI or a CeltIC-PrimeTime flow.
- Bill Griesbach of Agere from ESNUG 417 #7
I would be curious to hear if anyone has any actual hands on use with
Cadence's (Simplex's) STA tool, as it seems like their idea of a next
generation STA tool is much more correct than Primetime-SI's (which
appears to be more incremental of a tool). My only worry is that such a
tool needs to have a strong link to a place and route tool, so we can
have a closed loop... and since we are Magma P&R users, using a Cadence
or Synopsys STA tool could prove painful if all these next-generation
effects actually start to become meaningful beyond a few hand-fixes.
- Jeff Echtenkamp-Cho of Broadcom
Cadence Simplex VoltageStorm and SignalStorm look really good. I think
Synopsys will be replacing AstroRail and PowerMill somewhere down the
line.
- [ An Anon Engineer ]
We use VoltageStorm a lot and are comfortable with it. Powermill is good
but it is more for power estimation, while VoltageStorm can take your P&R
stuff and look at power distribution. So you would, I think, use both
tools.
- [ An Anon Engineer ]
Simplex Fire&Ice extraction has been enhanced and now supports 1M nets
(previously 250k nets). It is now the defacto standard cell extraction
tool for Cadence. (Hyperextract will be discontinued).
VoltageStorm deserves special mention in that it can perform IR-Drop
analysis on full custom designs with GDSII data. The advanced modeling
capability of SignalStorm (Effective Current Source Modeling or ECSM)
claims accuracy to within 2% of Spice on delay calculations.
- [ An Anon Engineer ]
We are using the VoltageStorm for power-grid validation.
- Yuval Itkin of Metalink Ltd.
Cadence Nanometer Analysis
Cadence Nanometer flow is targeted for high-speed custom digital circuits
(basically the complementarily flow of SoC Encounter for non standard
cell based designs). This flow is based on tools acquired from Simplex,
Celestry, and CadMos. The primary interface is through the Virtuoso
layout editor. VoltageStorm encapsulation within Virtuoso appeared to
be very good and supported full cross probing between IR-Drop and layout
views. An impressive feature of this integration was that it could
quickly zoom to any IR violation (such as lack of vias, metal widths,
etc - very cool!). Signal integrity analysis utilized PacifIC, which
claims to support floating body and parasitic bipolar noise effects of
SOI. UltraSim integration within VoltageStorm allowed for easy dynamic
power simulations. Parasitic extraction was based on Assura. Assura is
the extraction tool for custom designs and planned enhancements include
support for RF (Assura-RF).
- [ An Anon Engineer ]
Synthesis
Incentia now sells a synthesis tool that they try to make as similar as
possible to Synopsys. They claim their static timing analysis is more
than 10X faster than Synopsys' so they can do timing optimization faster.
Cadence just bought Get2chip. Wonder what they're going to do with
Ambit BuildGates now.
Prolific sell Protiming, which sizes cells to optimize timing. It ties
to PrimeTime and they say they can get 1%-2% improvement using existing
cells (what does that say about timing optimization?) and they've seen
6.5% to 15% timing improvement by creating new cells at custom drive
strengths. They also claim that Design Compiler only uses maybe 5 drive
strengths of any given cell no matter how many are in your library.
- John Weiland of Intrinsix
Cadence RTL Synthesis
Cadence RTL synthesis is now based on the technology acquired from
Get2Chip, which is built on a single global optimization algorithm
instead of the usual RTL elaboration, structuring, mapping, and
optimization process (Design Compiler). This methodology is
significantly faster and claims of 4-8M gates in 1 day on a 32-bit
machine were made. During synthesis, speed has the highest priority
(cost function) followed by power and then area. The scripting
language is Tcl and multiple libraries (dual Vt - high speed and low
power) are simultaneously supported. Enhancements planned for the end
of the year release are VHDL support and simultaneous min/max analysis.
- [ An Anon Engineer ]
Sonar/Dolphin still has ways to go, but PKS/Encounter could fall behind
PhysOpt & Magma if they don't get their story about Get2chip properly.
I didn't understand why Get2chip should be in the flow simply because
it can compile faster!!
First Encounter is the leader.
- [ An Anon Engineer ]
The thing that surprised me the most this year was the claims being made
by the new synthesis providers; 4-5M gates flat in hours. Our synthesis
process takes days. I'm going to definitely going to check out Get2Chip,
Synplicity, Magma.
- Tomoo Taguchi of Hewlett Packard
We're still using DC.
- [ An Anon Engineer ]
X Initiative
The two year old X-Initiative has gone from about a dozen members to
37, all interested in taking interconnect beyond vertical and
horizontal. They claim their tests show you can use 20% less
interconnect and 30% fewer vias by using diagonal lines. Their current
plan is to use diagonal lines only on the upper metal levels and leave
lower levels orthogonal so that existing IP will be unaffected. They
echoed what Gary Smith had said -- the cost of maintaining a lead over
the competition in processing is escalating every year and is now into
the billions if you want, say, a two year lead.
They have recently completed a 0.13 micron test pattern using diagonal
lines and are starting a 0.09 micron one. They said the 0.13 micron
pattern required no unusual tools or processes and had the same costs
and process times as a straight orthogonal pattern.
I checked with a friend of mine who makes masks and he agreed with my
concern -- you will probably need a smaller spot size (basically your
pixel size) for diagonal lines so it will take longer and cost more to
make the masks. Still that should be a relatively small effect in the
overall cost.
- John Weiland of Intrinsix
Does anyone outside of Toshiba/Cadence really care about the X
architecture or see it in their future? Their benchmarks are funny...
they take blocks that have seen silicon already, and redo them
and brag about a 10% area savings. Most P&R engineers I know would
probably say if they could redo their blocks post-tapeout and without
chip-level concerns, they could make them smaller as well.
The economics of it just don't make sense either: it requires 2 more
metal layers than we normally use, uses a more expensive process & mask
design, doesn't really shrink your analog or pads or memories at all.
And it wouldn't shrink any white space on your top level if you are
channel based (where 45 degree angles would be meaningless).
The Cadence/Simplex just seems like a classical case to me
of some really neat academic project accidentally escaping academia and
someone putting money behind it. I even asked them this straight up at a
DAC presentation. Every engineer at the presentation agreed with me, but
the presenter kinda just nudged it off by saying, "well, we're not saying
everyone will get these types of results" and went on with his
presentation.
They obviously appear to have some pretty smart people working on this,
and are coming up with some clever technology. It's sad to see this
effort going on and making progress, and other useful tools sit around
dead and never mature or innovate.
- Jeff Echtenkamp-Cho of Broadcom
While on the subject of Cadence as a company:
a. They seem to be going for feature headlines at the moment, rather
than thinking about or developing the tools in depth. Stressing
the tools, e.g. the PCB tools, with large designs often seems to
break them. Does anyone else feel this is the case?
b. What's happened to Cadence's product testing? E.g. in SimVision
(LDV5.0) there's a new feature which aborts display of signals or
instances after 10,000. That's fine, it should speed up display.
So, what happens if I want access instance 10,001? I do a search
for it. I find it, and now I want to find a sub instance of this,
so I try and display it. Guess what, as soon as you try and display
instance 10,001... it aborts on instance 10,000. This makes the
tool unusable for gate level simulation unless you know the exact
hierarchy of the design, which sort of makes a nonsense of the
"Design Browser" window name. Problems like this shouldn't make
it through Cadence testing.
c. We don't appreciate Cadence's sales technique, but that's not a
new gripe for us.
d. Cadence documentation still lags behind Synopsys. Their teeth
grindingly bad cds_doc system has at least become more reliable in
later releases. (Why, oh, why does it have to launch its own http
server? Why can't you just look at the HTML directly like everyone
else?) There's still a lack of introductory material, how-to
articles and such like.
- Thomas Fairbairn of 3com
The database wars are just getting worse. Cadence claims Synopsys will
support OpenAccess and Synopsys claims Cadence will support Milkyway.
Do these guys talk to each other? Magma might have a better database
than either Cadence or Synopsys. And Monterey Design just created their
own database that they claim is the best.
- John Weiland of Intrinsix
|
|
