( ESNUG 541 Item 5 ) -------------------------------------------- [05/23/14]
Subject: Anirudh quietly tells users of "Project Novus" to nullify ICC II
> - SCOOP II: Multiple spies report that on Monday, Aart de Geus is
> going to announce "Project Newton" IC Compiler II (ICC II) in
> his upcoming keynote at SNUG'14 in Santa Clara.
>
> From what I've heard, "Project Newton" was a 5 year undertaking
> involving 80 SNPS R&D as a re-engineering of ICC for problems
> unique to sub 20 nm P&R -- but it ran into organizational issues
> I can't get a good fix on. Rumor was ICC II was to be launched
> at DAC'13 in Austin, but it wasn't ready then.
>
> - from http://www.deepchip.com/items/0537-10.html
Hi John,
Not too long (two weeks later maybe) after Aart announced IC Compiler II at
his SNUG meeting, Cadence came by my company and presented plans for their
next gen RTL2GDS flow. The CDNS guys are calling it "Project Novus" and
they claim that it's better than ICC2.
We do a lot of high performance ARM-based design. We design from 40 nm
down to 16/14FF. We produce designs for consumer and automotive.
Currently we use Synopsys for our digital designs, RTL throught to signoff.
(We use Calibre for DRC/LVS, but doesn't everybody?) We're pretty happy
with DC, ICC, PrimeTime, and StarRC -- I mean nothing is perfect -- but no
major complaints. They get the job done. We have taped out several very
large designs, 20-50 M instances using ICC.
We plan to look at ICC II later this year, when SNPS says it's ready, and
possibly give this new EDI a look, too.
- [ An Anon Engineer ]
---- ---- ---- ---- ---- ---- ----
Hi John,
After SNPS announced ICC2 we were paid a visit from Cadence. Cadence asked
for a meeting to give us a product update on Encounter EDI. We last looked
at EDI back in late 2011.
EDI was not competitive on several levels back then. I don't remember the
exact details, but EDI not only ran slower than ICC, it also had problems
handling our routing rules and meeting our performance requirements. EDI
needed to run in taxicab mode with several of the Cadence best and brightest
AE's to get near acceptable results.
Even with the experts, EDI took several special R&D builds to make that
happen. One of the biggest problems was correlation between pre- and post-
route EDI DBs. They struggled with that. In the end CDNS R&D had admitted
that it was a problem. They promised to fix in the next release. Right.
Their front-end also had its troubles. Their RTL Compiler tool (which they
bought from Get2Chip) lacked the speed and robustness of DC. It didn't
support CCS models and struggled handling SDC constructs and syntax.
RTL Compiler correlation to their EDI back flow wasn't good either. Could
be off by as much as 50%. They also promised to fix this back in 2011, too.
So needless to say that when Cadence asked to come in to show us their "new"
and improved RTL2GDS flow -- I was a bit skeptical.
Their presentation was by Anirudh Devgan, their new VP of Digital P&R. He
started talking about how Cadence has done a good job of developing some
good optimization technology, but their overall flow needed to improve.
I wanted call BS on that. They're known for buying technology likes Azuro
and maybe even Plato, but I don't believe for a minute that CDNS R&D has
developed anything revolutionary.
Anirudh also claimed that their current performance in 2013 has improved by
2X and is better than standard ICC (not ICC II) for high performance cores.
He also claimed 75 tape outs at 20 nm and below.
Then he started talking about "Project Novus" -- how he has restructured
Cadence R&D to focus on optimizing the CDNS EDI flow and its core engines
for massively parallel architectures for all phases of the design flow.
He says they're re-writing the EDI placer and EDI global router and both
should be ready by 2015.
Anirudh seemed confident that Project Novus will beat both ICC 2 and
AtopTech. He showed some customer benchmark results of his latest EDI code
doing well on 28 nm and 16 nm designs showing better PPA against ICC and
Atop. (He wouldn't say where these benchmarks were done, though.)
Although Anirudh can be very convincing, I'm still very skeptical of his
claims and Cadence's ability to deliver without acquiring new technology.
But if his claims are true, then there may be an EDA version of "Clash of
the Titans" brewing -- and the winner may be the one who got the best
people from Magma!! :)
- [ An Anon Engineer ]
---- ---- ---- ---- ---- ---- ----
Hi, John,
Please keep me and my company anonymous for this post.
This is an update on the info we received regarding Cadence's new P&R plans
since Synopsys announced ICC II. My group has used mostly Cadence P&R for
the past few years although we also use Calibre, PrimeTime, and Redhawk.
We anticipated this roadmap update ever since Cadence reorganized their
digital group last year.
First Anirudh gave us an assessment of his own EDI tool: Out of the 4 major
engines in their P&R tool (placement, routing, data optimization, clock
optimization), he admitted the EDI placer and EDI router has problems and
needed work. The main problem is that neither are tightly integrated with
the timer/optimization engines. Their global router also needs better
integrated with the data and CTS optimization engines (GigaOpt and CCOpt)
to guide accurate route optimization.
Anirudh believes his optimization engines are solid:
1. that they can handle large numbers of MCMM scenarios,
2. that they can optimize data and clock simultaneously,
3. and are fast.
He says this allows CDNS to do well on new 16/14 nm designs despite their
other problems.
Anirudh's assessment seems about right, although we haven't looked closely
at FinFET. We've had a lot of timing problems in the past because of bad
EDI placement. Trying to optimize on a placement just leads to bad
congestion. We've spent too much time giving the EDI placer "guides" to
help it along. The problem is you never know for sure how to give the
right guidance until you run a few trials. It's a big time sink.
They are calling their roadmap "Project Novus" which has a lot of new stuff
for RTL synthesis and P&R for quality and throughput:
- GigaPlace is their new placer that works with the timer. It will
now be their 'golden' engine in the flow
- NanoRoute now has a fast global route which is supposed to be
tightly integrated with GigaOpt and CCOpt
- One common UI for the synthesis, P&R, and signoff tools
- MCMM speed-ups.
- Massive Parallelism being used everywhere possible.
That last one caught our attention. We looked forward to this ever since
the Tempus guys took over the rest of the digital tools group at Cadence
last year. They promised a throughput improvement and in design frequency,
power, and area improvements (10-20%).
TWO Novus CAE CUSTOMER PRESENTATIONS
Customer "A"
Last year this customer struggled with a design in EDI and could not get it
to converge until they got the new GigaOpt update. It was a 28 nm block of
2.2 M instances, ~200 memories/hard macros, and uses 4 scenarios. The block
had both timing and congestion problems. The customer played whack-a-mole
chasing the hotspot around the EDI floorplan with each design change but was
never getting it done.
After the customer got the GigaOpt update, they were able to converge timing
and congestion within a couple of months, making steady progress.
This customer continues to make derivatives of this block, with each spinoff
requiring a different variation of this block.
A few weeks ago this customer received the latest Project Novus build so he
could test it. Performance and congestion for his 2.2 M inst block:
TNS WNS Util
old EDI 2013 release: - 75.833 nsec - 0.931 nsec 74.23 %
Project Novus EDI 2014 release: - 1.326 nsec - 0.044 nsec 73.92 %
The number of routing cells with horizontal congestions (the bottleneck in
this design) dropped by around 25%. The number of LVT/SVT cells dropped by
almost 15%. These timing improvements are from Project Novus EDI's improved
layer optimization for long routes. Because it makes much better layer and
topology choices, it also improves congestion.
Customer "B"
The first installment of "Massive Parallelism" came in this recent Project
Novus EDI build with the new multi-CPU acceleration approach in the router.
This customer had a 28 nm SOC of 4.6 M cells at the top-level, with several
memory and large IP macros throughout. Their top-level placement space was
very strange and it was hard to converge routing without significantly
growing their die area.
They settled on flattening a few of the blocks as a "semi-flat" approach,
but this put their final routing -- and an ECO -- of a large top-level in
their critical path for design closure iterations. Getting one route done
used to take them about 10 hours on 4 CPUs. That route-and-ECO became the
bottleneck in this customer's flow.
Here's the Project Novus EDI multi-CPU results from their standard LSF farm:
# of CPU's: 4 8 16 32 64
detailed route
elapsed time: 8:31:06 4:47:33 2:48:08 1:45:00 0:52:11
detailed route
CPU time: 33:03:34 35:30:28 36:28:12 36:48:06 37:22:35
It took the customer 39 min to route a 28 nm 4.6 M cell design! This 9x
speedup is comparing the 4-CPU to the 64-CPU runs. This customer can now
do a fully-detailed route in the time he would expect a prototype route
to run. (Novus EDI uses a mix of distributed and threaded approaches.)
Novus does not require all the CPUs in the same box. For this customer the
max-CPUs-per-machine on our farm was 10. His 64-CPU results were generated
with a six 9-CPU machines and one 10-CPU machine.
The DRC and total metal length quality were roughly the same on each run.
The CDNS CAE says this customer has started on 16 nm trials.
- [ An Anon Engineer ]
---- ---- ---- ---- ---- ---- ----
Related Articles
Readers on ICC II, ATOP, CDNS EDI, upcharges, Z-Route, 24 months
Join
Index
Next->Item
|
|
