( SNUG 02 Item 17 ) -------------------------------------------- [ 5/15/02 ]
Subject: Aart's Technology Leak
GREENHORNS VS. VETERANS: This year's Aart keynote technology leak was a bit
more obscure than I had originally thought. Aart had annouced that PhysOpt
now corrects for crosstalk in its compiles. It's called "Enroute". When
Aart said this, it triggered a spontaneous thinking-out-load discussion
between Kurt Baty, Steve Golson, Oren Rubenstein, David Bishop, and myself
about how this would work. We were eventually told to quiet down by some of
the Synopsys bigwigs, but it got me to thinking. Here's what I see:
1.) Synopsys has working clock tree synthesis. See ESNUG 393 #9.
2.) Aart also reported that he had 2 Route66 tape-outs. This
means he has a working detailed router.
3.) Synopsys mentioned a few months ago in EE Times that they had
created a new 2.5 RC extractor. This means they're not using
their Arcadia extractor -- which makes sense because PhysOpt
would need a screaming fast extractor for its crosstalk cost
function in it's synth runs.
Put this all together and you'll see that Aart didn't announce that PhysOpt
now simply handled crosstalk at all. With the exception of some power
planing and IR drop issues, Aart effectively announced that Synopsys now
has a full soup-to-nuts RTL2GDSII physical synthesis tool. In very
discrete terms, he was saying that PhysOpt now no longer needs to rely on
anyone else's backend tools because he has them already any they work.
This now begs the question: "So why is Aart buying Avanti, then?!"
I pondered this a bit and realized that acquiring Avanti's $62.5 million a
year 45% marketshare P&R customer base didn't fully justify the $830 million
Avanti purchase price -- not to mention the ugly legal hassles involved.
Why Aart wants to buy Avanti is because he wants to secure his place in
the 90 nm battleground. Sure, Avanti's tools work at 0.13 um; what's
more important is that Avanti's R&D *people* are extremely experienced in
developing tools for new process nodes. Let me say that another way. OK,
so PhysOpt, Route66, Enroute all now work at 0.18 or 0.15 um. Get to 0.13
or 0.09 and it'll be a new learning curve for the less experienced Synopsys
R&D staff. Whereas the Avanti R&D guys have been here before. They know
the gotchas shrinking processes throw at you. They also know what does and
does not work to get around them. Add veterans to the deal, and suddenly
$830 million becomes not such an expensive asking price for Avanti.
"People we concerned about the Synopsys/Avanti merger. Since the
general opinion is that Avanti has a far better router (Apollo), in his
speech, Aart got asked about the fate of Synopsys' own router. Aart
said that he planned to keep both teams co-existed. I guess in public
he ought to say that in order not to diminish the morale of his own
engineering team. Yet keeping the two teams doing the same stuff
obviously is a waste of resources. I don't believe he'll do that in
the long run, and many attendees shared my view."
- Andrew Cheng of Cisco
"Aart gave everyone a sneak peek of what's coming in the pipe from
Synopsys. The new PhysOpt includes:
Clock-Tree Synthesis
Extraction
Detailed Routing
Signal Integrity Optimization
Aart shared early results from a beta customer on how crosstalk noise
was addressed. Several paths had noise above their 3.3 VDC threshold.
Enroute plotted crosstalk noise against the slack on each path. 30%
of the nets analyzed were critical, failing timing (negative slack)
and showed significant crosstalk delta delay. The next slide showed
the results after using the new PhysOpt. Crosstalk induced delay had
been reduced quite a bit and almost all the paths met timing.
I talked to a few Synopsys people at R&D nite. Their cost function now
includes noise. PhysOpt uses a very fast 2.5D RC extractor. Not
sign-off. PhysOpt generates distributed RC networks for delay and
crosstalk calculation. The noise analysis engine then computes the
peak switching noise for each net to create arrival time windows. If a
victim net n1 is aggressed by another neighboring net n2, PhysOpt will
either :
1. size up the driver of n1
2. insert a buffer on n1/n2 to reduce the extent of
coupling capacitance
3. move the buffers on the net
4. introduce another routing track between n1 and n2 to
reduce coupling capacitance
End result is a low noise legal routed database that meets timing."
- an anon engineer
"Aart gave a sneak peek into PhysOpt's future capabilities to reduce
crosstalk delta delay. He said early results looked good, but they
were far from done."
- Bob Wiegand of NxtWave
"The PhysOpt-SI product was pretty cool. This one was thought out well
and looks like it should work as advertised."
- Pallab Chatterjee of SiliconMap
"The block consisted of 60 K instances of logic with 5 memories, and was
targeted for TSMC 0.18 um 7-layer metal. The biggest issues were
timing closure in the presence of its complex clock tree, design
congestion and the routability of the design after back-end place and
route. The RTL, area and port locations were fixed and couldn't be
changed. In addition the block had low utilization (35%) due to the
fixed area constraint. All the other flows within Vitesse failed to
get closure on this problem block. They gave us 2 weeks to get it
through PhysOpt / Clock Tree Compiler and tape-out.
Clock Tree Description:
- 4 sub clock trees driven by a top-level clock (the top level clock
is also driving 8800 FF's) plus 5 reset trees & one scan mode tree.
- Clocks specification 2.0 ns, 4.5 ns and 5.5 ns periods with 10%
uncertainty
Here is what we got.
Clock tree # of FF Latency(ns) Buffers Levels Skew (ps)
----------- ------- ----------- ------- ------ ---------
Sub clock 1 2200 1.3 600 6 55
Sub clock 2 320 0.8 24 2 40
Sub clock 3 5000 2.4 340 7 200
Sub clock 4 175 0.7 12 2 15
Top clock 8800 2.1 560 7 200
Reset 1 2200 1.2 120 3 60
Reset 2 320 0.8 18 2 20
Reset 3 5000 1.3 275 3 75
Reset 4 170 0.6 14 2 12
Top reset 8800 2.0 599 7 326
Scan Mode 16400 2.1 916 6 160
In 5 days we taped out and met our clock skew spec on this block with
room to spare."
- Jens Michelsen of Vitesse (in ESNUG 393 #9)
|
|
