( ESNUG 552 Item 6 ) -------------------------------------------- [10/26/15]
Subject: ICC2 patch rev, Innovus penetration, and the 10nm layout problem
MY "AHA!" MOMENT: It's always fun when I start out looking for one thing and
during that search I discover something even more interesting along the way.
It happened to me 2 months ago when I wrote about the Cadence 2Q15 earnings
where Lip-bu bragged about adding Qualcomm, Nvidia, ST, and Faraday to his
nice little happy list of ARM, Freescale, Juniper, Renesas, LG, Maxlinear,
and Spreadtrum as customers who are openly endorsing Innovus.
On the private front, every time I spoke to any Synopsys people about
Innovus they'd scold me like I was on Santa's naughty list:
"Oh, that's just made up B.S.! Innovus is only in limited use and
in small pockets in those companies. ICC2 is where all the heavy
hitters are. Ask around. You'll see. You really should stop
shilling for Cadence, Cooley!"
And their Cadence counterparts would talk to me as if it's totally
natural for a grown man to believe in the tooth fairy:
"Innovus is conquering the PnR world! We're the wave of the future,
baby! ICC2 is old technology that's been 8 years in the making and
they still can't get it to work. We're the new stuff that works.
Ask around! Ask around!"
While on the public front, I wrote:
"Now the pregnant questions are: is Innovus replacing ICC/ICC2 at
Qualcomm/Nvidia/ST? Or is Innovus in one tiny group in these user
companies? Or is Innovus used in 10%/50%/90% of their chips? Or
for "test" blocks only??? Inquiring minds want to know! :)"
- from http://www.deepchip.com/items/0551-07.html
I thought to myself: "Wouldn't it make for a fun follow-up if I chased down
some 16/14nm PnR users to answer that Innovus 10%/50%/90% use question???".
After all, 16/14nm is where the Back To The Future of chip design is.
My first call was to a foundry guy I knew. He gave me the scoop:
"I do implementation support for advanced node (sub-28nm) customers
in our foundry. We got ambushed by customers asking us for Innovus
and Tempus PDKs and for general support. It caught us by surprise.
We didn't plan on Cadence PnR having much traction.
Synopsys tried to do open heart surgery on ICC to fix the fact that
the ICC data model wasn't scaling. A vestige from acquisitions.
It's been a painful slow phased rollout of ICC2. Over the past 12
months SNPS would turn on parts of ICC2, but not the full flow,
because the full ICC2 flow wasn't working. Their problem is ICC2
routing isn't fully integrated. Placement is not talking to routing.
This forces users to mix ICC/ICC2 block-by-block. In some cases
having to jump between ICC and ICC2; which is really painful. It
involves exporting and rebuilding the block all over again.
To their credit, the Synopsys AEs recognixed the problem and have now
delivered a working full-flow ICC2. That cost SNPS almost a year.
Big IDM's like Qualcomm, Broadcom, Marvell, Nvidia, and Apple will
not sit for a full year. Even ARM and Imagination won't wait.
But this new ICC2 flow is untested. We're looking at it right now.
I'm foundry. If I put myself in my customers shoes, that's pretty
damned risky. ICC2 forces a lot of retooling. New data models.
New library scenarios. New commands. If you take your "run.tcl"
from ICC, it's not going to work in ICC2. The upside is it runs
3X faster than ICC.
I also don't know if this new ICC2 build has fixed its convergence
and repeatability problems.
In contrast, when Cadence did open heart surgery on EDI's underlying
algorithms, they left their UI and db alone. It's been remarkable
how easy a bring-up in Innovus has been. Anirudh was clever having
his R&D create a pin-compatible EDI replacement and not forcing his
customers to change commands nor scripts.
Block size between ICC2 and Innovus might be comparable, but I
don't have the data now.
Looking at my customer status chart, for sub 28nm, roughly 60% are
on Innovus in some way.
- 30% are pure ICC/ICC2/PrimeTime
- 30% mix ICC/ICC2/PrimeTime with Innovus/Tempus
- 30% are pure Innovus/Tempus
- 15% use Atoptech or Olympus-SoC with PrimeTime
ICC/ICC2 users use PrimeTime. Innovus users use mostly Tempus with
some PrimeTime. Not one customer uses Tempus with ICC/ICC2.
The places where we see customers using Innovus/Tempus, they're
betting on it. It's not an experiment. It's not like their
technology group is doing PD trials. They're 100% committed.
Neither PD tool flow is totally safe. This new ICC2 build
might still have non-determinism or convergence problems. If
that means falling back onto the old ICC, you won't have enough
time. The runtimes in ICC are just too slow. If Aart can get
wheels on ICC2, this next year will be interesting. ICC2 is much
faster than ICC. Right now, from where I sit, SNPS has lost PD
marketshare since its launch."
- [ sub-28nm Foundry Guy ]
SWEET! The mothership says 16nm is both 60% CDNS Innovus and 60% SNPS ICC2!
I love crazy stats like that. Stats like this appear wrong at first, but
they're actually right when you look into them.
I called another 16nm PD designer:
"We do networking chips. Used to be all IC Compiler PnR. Mgmt
unhappy when Synopsys Sales wanted twice ICC license price for
each new ICC2 license. To not be locked into one vendor, on
our 16FF+ chips we do 50% ICC2 and 50% Innovus. We get much
better pricing that way.
Both give us great support. Some ICC2 partitions had runtime
problems that the SNPS AEs cleaned up. Saw Innovus DRC issues
that the CDNS AEs cleaned up.
Policy is to feed blocks to the PnR tool that'll do best with it.
Don't like block iterations between Innovus and ICC2. We just
choose one and go with it. So far this has worked well.
Overall we use mostly PrimeTime because it's what our team is
used to. We have others who run Tempus.
For legacy designs, we're ICC only. No interest to migrate any
28nm chips to Innovus.
Total PITA to run both PD flows. Good for my resume I guess."
- [ 16nm Networking Chips Guy ]
OK, that's an even 50-50 split vote for both CDNS and SNPS PD tools.
WHERE "AHA" HAPPENED: I next called who I thought was a yet another 16nm
designer, but he wasn't. And that's where my 10%/50%/90% story unexpectedly
started morphing on me when I called a Korean PD engineering friend...
"Uhh, we've moved to 10nm, John. Before 10nm, we used around
30% Innovus, 50% IC Compiler II, and 20% legacy PnR. But now
at 10nm, it's probably something like 50% to 60% Innovus.
ICC2 stalls on 10nm. With coloring, congestion comes up. The ICC2
router sees the DRC violations. It fixes them and creates 2 more
problems. It fixes those 2 problems to create 4 more problems.
ICC2 ICV catches all of this, but ICC2 can't fix it.
Innovus has color-aware placement and color-aware routing. It uses
color from the beginning. ICC2 doesn't do color placement. They
just put DRC rules in to make sure cell coloring is clean. For 10nm
coloring is critical. Synopsys tells us they've taken care of it,
but we have no way to be sure. 20 and 16 and 14 didn't have coloring
as manditory. Calibre would just fix it. Calibre can fix color
issues there. But at 10nm color-aware PnR is manditory. This is
why we've swung 60% to Innovus.
If we have IP done in ICC, we aim it at ICC2. We've moved blocks
between ICC/ICC2. Dump out DEF/LEF, netlist, get constraints. We
had to write a lot of scripts to clean up the export/import.
We use Tempus in our CDNS blocks, but for final signoff in Innovus
or ICC2 it is both still PrimeTime. Extraction is Star-RC.
We love Calibre. It cleans up coloring problems better than Clorox
bleach. It's the duct tape of 10nm."
- [ The First 10nm Guy ]
And then another PD engineer went all 16nm/10nm on me:
"Most of my company does 28nm and 16nm with Synopsys. My group used to
do ICC. At 16nm we changed over to Innovus, but only for PnR -- after
we qualified it. Everything else stayed the same. Same SNPS VCS,
Design Compiler, PrimeTime frontend. Same Star-RC and Calibre for
signoff. Don't believe in changing more than one variable at a time.
Since our people distrust new SW, to qualify Innovus, we gave CDNS R&D
a massive ugly block to lay out. EDI got mostly there, but could not
fully close. Innovus closed slightly better QoR with 3X faster TAT.
We don't use Tempus. Our people evalued it a year ago. Correlates with
PrimeTime, but others in my company wanted to stay PT. We do use a bit
of Tempus inside Innovus, but not for signoff. We don't have separate
Tempus licences.
At 16nm, Innovus is about TAT and some improvements in design density.
Hold closure and buffer additions. Use some CTS. We limit it, though.
Innovus color routing and color placement works. Critical at 10nm, but
only nice at 16nm. (We're looking at TSMC 10FF+)
We've found color placement and vias in the std cells can be difficult
with the power grid. You're remapping cells, changing flop types on
your timing critical path, and when you try to legalize the coloring
rules force cells to move! Coloring Rules and Power Grid and Legalizing
double height cells all fight each other at 16nm; even worse at 10nm.
We're happy that Innovus understands coloring, but we're forced to do
design changes from this threeway fight.
Anyway, we seen PrimeTime and Calibre are happy with Innovus 16nm, so
we're happy. Haven't tried Calibre on 10nm. In 16, extraction decks
are done in Star-RC after Innovus, then we generate SPEF for PrimeTime
for 16nm. Plan to do the same for 10nm.
So to answer your question, we're 100% Innovus in my group. We're maybe
15% to 20% if you're counting my entire company.
Our group doesn't have time (nor engineers) to try out the 3 other PnR
tools for 10nm. So far we're happy with Cadence because of how it
handles coloring DRC rules, so we'll use them for 10nm. We like
changing only one variable at a time."
- [ Doing 16FF+, Looking At 10FF+ ]
WTF IS COLOR LAYOUT?: With my friend, Google, I took a break to read up on
this 10nm double-patterning (DP) color layout problem.
Basically to make stuff 14nm and 10nm, you have to spilt your litho mask
into 2 parts -- or two patterns -- with half the etches on each pattern that
are shown as two colors. It's made Litho/Etch/Litho/Etch (LELE) where you
litho/etch one color, and then litho/etch the other color.
But for 10nm, it gets even trickier with a 3rd color to eliminate conflicts
between your first 2 colors, block masks, sidewall depositions, TPT, relief
patterns, yada, yada, yada....
From the PnR perspective, all these colors/patterns for 10nm create a whole
new boatload of new DRC rules that your placer and router has to be aware
of. That is, your 10nm cell spacing can be mysteriously mushed about, and
your 10nm routing has weird invisible things pushing your wires around in
ways you can't anticipate. After PnR, Calibre can generally detect these
new DRC/LVS problems after the fact -- but your life is much better if
your 10nm layout has somehow managed these problems before the fact.
If your 10nm PnR isn't truly color-aware, this can spiral out of control.
I called my original foundry guy again to ask: "Why the heck didn't you
mention anything about this crazy ass color stuff???". His answer:
"Well, you never asked! Of course, coloring is a big issue. All
the PD tools working at 10nm have to handle color. You didn't
know this?"
Grrr! To stay the course on my original 10%/50%/90% story, I contacted one
more 16nm PD guy:
"We're not using Innovus, but there's a 16nm group here that does. And
two other 16nm groups looking at Innovus. We're Atoptech users in my
group. We do 28nm.
We get pretty good results from Atop. It does 1 million instances
flat that's pretty clean. Not many violations in DRC/LVS. Only get
some end of line spacing rules violations that we have to clean up by
hand. Atop does well with PrimeTime, Star-RC, and Calibre.
Our team has been very happy with Atop, so we won't change. Looking
at a new PnR tool takes a lot of man-hours."
- [ Happy 28nm Atop User ]
Which I'll chalk up as a "there's a 16nm group here that does" Innovus vote.
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
---- ---- ---- ---- ---- ---- ----
THE PNR HORSE RACE SO FAR: So over these past 2 months I've come to learn a
few insights on this 4-way horse race called digital PnR.
As of Oct. 18th, 2015 the current status is:
- Innovus is "real" at 16/14nm. I got 60%, 50%, 30%, 50% to 60%, 100%,
15% to 20%, "there's a 16nm group here that does" from my own research.
That is, at 16/14nm Innovus is NOT an "experiment" NOR is it only being
used for test chips; it's being used in ~50% of the chips at that node.
- In August, Aart released a patch rev of ICC2. Although, ICC2 has had
a checkered past with non-deterministic PnR runs, new commands that
require users to rewrite their Tcl scripts, block by block convergence
issues, "placement is not talking to routing", and an incompatible-
with-old-ICC database model that bites you when you have to rerun your
failed ICC2 block in old ICC -- the SNPS folk are touting a limited
August rev of ICC Compiler II that they claim has solved all these
prior "bad acts" -- especially that moving-blocks-between-ICC-and-ICC2
problem. This new patch ICC2 is currently being tested.
- There's a pesky new double-/triple-/quadruple-patterning digital color
layout problem at 10nm that, so far, Aart's ICC2 can't seem to handle
well, but Anirudh's Innovus seems to thrive on. (I have no PnR user
data on how Atoptech nor Olympus-SoC handle color layout yet.)
- Mentor Calibre is the only other PD design tool that everyone agrees
is universally thriving at 16/14nm and 10nm. And where DRC/LVS is
critical.
PRESENT STATUS: Currently Anirudh is Aart's 16/14nm nightmare. But if this
ICC2 patch rev actually gets ICC2 to be fully functional, Aart might become
Anirudh's 16/14nm nightmare.
But that's only at 16/14nm. Right now it appears that because of the pesky
coloring rule layout issues, at 10nm it will be Anirudh on top!
Other than some fun EDA shop talk, my other big takeaway from chatting with
5 PD engineers is that this ugly multi-coloring digital PnR problem is
going to be everyone's nightmare once we move from 16/14nm to 10nm -- yet no
one seems to be openly talking about it?
- John Cooley
DeepChip.com Holliston, MA
Join
Index
Next->Item
|
|
