( ESNUG 554 Item 4 ) --------------------------------------------- [12/10/15]
Subject: User on new Atoptech PASS ECO, FAST FLOW, 28/16/10nm, and Calibre
We use ATOP exactly like Magma. Feed it blocks. 9 out of 10 are no
problem. On the few the Aprisia does not like we feed to ICC.
Once ICC2 is working, we'll them feed to it. We like ATOP as a
workload reducer. ICC/ICC2 blocks require a lot of handling.
- from http://www.deepchip.com/items/dac15-03.html
From: [ I Am Sparticus ]
Hi, John,
Thought I'd follow up with more details from my earlier ATOP comment in your
DAC Trip Report'15.
As we are existing Atoptech users, there isn't a lot new for us to learn
from ATOP at DAC as we work with them throughout the year. Unlike Synopsys,
Cadence, and Mentor, ATOP didn't rewrite their PnR tool this year -- so I
guess it's not as interesting. What I can share is what we've done with
ATOP over the past year.
I saw from ESNUG 552 #6 that much has been made about the PnR difficulty
transitioning to 16nm. Our first 16nm chip was the easiest process node
transition we've had since 130nm. The Atoptech double patterning worked
fine. ATOP timing correlated reasonably well with PrimeTime. The ATOP
router produced DRC-clean results without a major effort on our side. The
runtimes were manageable. We had the occasional corner cases failures, but
in general ATOP appeared to do a good job getting it right the first time.
Fig 1) Running Calibre inside Atoptech Aprisa
(True story: after we ran our first few blocks through ATOP PnR and then ran
Calibre, we were worried the TSMC DRC deck was broken, because the Calibre
error report was so small we didn't believe it.) Transitioning from 28nm to
16nm in Atoptech was a non-issue for us.
ATOP R&D is already releasing tech files for 10nm, but 16nm to 10nm appears
to be a much more incremental jump than 28nm to 16nm was, so we don't expect
significant issues.
To handle the correlation to PrimeTime signoff issue ATOP has developed what
they call "PASS ECO". It uses the timing reports from your signoff timing
tool (either PrimeTime or Tempus) to help drive a final timing cleanup and
optimization. We're currently using PASS ECO for area recovery, leakage
reduction, and timing closure. Area/leakage recovery are block dependent.
Typically leakage tends to be around 10-15% less after one loop of PASS ECO.
PASS ECO is working so nicely we're also looking into removing certain
in-the-loop optimizations and moving them to PASS ECO (where we think we
can get similar QOR but improve our overall turn time.)
Besides the overall PnR runtime improvement efforts in the last two releases
(~25%), ATOP is working on what they call "FAST FLOW", which targets very
large blocks (>5M instances or 16-20M gates) and trying to make big runtime
cuts with minor QoR degradation. We're looking to move "FAST FLOW" into
production on our current round of 16nm chips. With it, we are seeing some
of our larger blocks have our overall PnR runtime cut 50% while still having
a QOR in the realm of what we'd want going into ECOs and final closure.
- [ I Am Sparticus ]
---- ---- ---- ---- ---- ---- ----
Related Articles
Aart's lawyers get trounced in judge's SNPS vs. ATOP ruling
Aart's SUE RIVALS policy backfires horribly on core SNPS patents
User benchmarks new CDNS Innovus vs. SNPS ICC/ICC2 workaround
Join
Index
Next->Item
|
|
