( ESNUG 560 Item 6 ) -------------------------------------------- [05/06/16]
Subject: User happier with Oasys/Nitro-SoC instead of ICC/DC-Graphical
ICC2 SCOOP: Sources say that for the last 18 months MENT's Sierra group
has had an R&D initiative called "Project Nitro" to directly counter
Aart's big IC Compiler 2 push -- just like how CDNS "Project Novus" did.
Apparently this "new" Olympus-SoC PnR will have a new placer that does
concurrent clock-data tuning, and a new optimizer that can supposedly
do 100 MCMM corners -- a lot!-- and a new abutted floorplanner, too.
I also hear that they're trying to pass off Oasys RTL synthesis as new,
but I'm not believing that. :)
- from http://www.deepchip.com/items/0550-04.html
From: [ Run, Forrest, Run! ]
Hello John,
Please keep me anonymous.
Our design group is responsible for delivering semi-hard macros to our much
larger SoC team. The concept is to physically pre-implement the awkward IP
(think either performance or routability) ahead of SOC start. This gives us
the opportunity to find optimal configurations of circuits ahead of time for
a given function before it is integrated into a chip.
The video decoder IPs have high performance PnR issues focused on Ghz, mW's,
and/or utilization/area. The modem/router IPs have routability issues that
are focused on congestion, open shorts, and/or too many DRC violations.
NOT GETTING BURNED
The primary focus of our team is to determine whether the RTL of a specific
macro can be physically implemented in the SoC context to avoid any rude
surprises downstream in PnR. Reason being we have been burnt a lot by some
expensive Synthesis <---> PnR loops in the past with timing and congestion
blowups happening in PnR which required massive RTL re-writes.
We have been using traditional synthesis tools (DC/DC-Ultra/DC-Graphical)
for years and wanted to establish a new flow to eliminate such surprises.
In DAC'15, we attended the MediaTek presentation on Oasys-RTL floorplanning
and synthesis at Mentor booth. The tool caught our attention. In addition
to automatic RTL Floorplanning and faster synthesis runtimes (vs. SNPS DC),
we liked its strong hooks into their PnR. We like the philosophy of having
a single RTL2GDS flow done by same engineer.
We got in touch with Mentor in the latter half of 2015 to evaluate their
Oasys-RTL floorplanning/synthesis plus Nitro-SoC PnR. Just to share, we
first heard of MENT's Project Nitro from your Deepchip rumor in May 2015 ;)
OASYS RTL RUNTIME DESIGNER
Here's our flow:
read in RTL code of IP(s)
do automatic RTL floorplan creation (OASYS)
do physical synthesis (OASYS)
do analysis and feedback for RTL
then do P&R validation (NITRO)
The first thing that impressed us about Oasys is runtimes and memory usage.
It only took 3 hours to synth & floorplan a 2 million inst design in 4G mem
and this was on just one thread.
The Oasys support guys tell me that they have a customer who ran a 6 million
inst design flat in a 10G linux box running Redhat 6.0.
That coupled with its RTL-floorplanning let us rapidly cycle through Verilog
RTL changes multiple times in a day with confidence that these changes will
impact the final physical timing and congestion. This speed let us generate
multiple macro placements for our blocks and evaluate physical performance
in just a few hours -- something that would have taken multiple days in our
traditional DCG/ICC flow.
The ability to properly floorplan & synthesize in one tool is a killer app.
Oasys RTL cross probing works wonders as both congestion and timing issues
can be directly correlated to our SystemVerilog source code. It lets us do
various What-If scenarios that were impossible to run at that stage before!
FOUND PNR CONGESTION AT THE RTL LEVEL
The RTL cross-probe between the physical & the RTL databases helped us
immensely to resolve RTL bottlenecks and physical congestion issues much
earlier in our design cycle. For example, in one of our designs, Oasys
reported a major congestion hotspot, and its cross probing helped us to
quickly zoom down to the the "culprit" RTL module. Once the exact module
was found, we used Oasys again only on that "culprit" module and we were
easily able to find the exact sub-module (line of RTL code) that needed to
change in RTL to resolve the congestion issue.
After this one RTL change, the flow went absolutely fine through the Nitro
PnR validation cycle.
We have been asking for such capabilities for years and finally we have a
synthesis tool that can enable us to do this! Physical Synthesis working
at the RTL level for floorplanning/probing instead of the post-gate level
is long overdue. There is no reason RTL synthesis is not just another PnR
process step in physical design.
MENTOR SIERRA NITRO-SOC
Moving to Nitro-SoC, we really wanted to see how the congestion and timing
metrics survive through the classic PnR churning. Does the congestion
predicted in Oasys correlate with final Nitro PnR? Does the performance
correlate?
WNS was either zero or pretty small for our two MCMM corners.
Look at the blue areas in the left pic. That's where Oasys predicted the
spots were congestion would be -- after 3 hours with the source RTL.
Look at the yellow areas in the right pic. That's where Nitro-SoC found
congestion post-CTS in the chip.
Overall for our 2 million inst design, Nitro matched Oasys.
GOTCHAS IN THE NITRO-SOC FLOW
We were pleased to see a good integration between the two tools, but ideally
I would prefer one integrated solution (but I am sure this is very close).
- MXDB format: This is Mentor's solution to pass data from Oasys
to Nitro in a single file format.
- The format brings the entire Oasys database into Nitro PnR system
that can then be pushed all the way to post-CTS without any
additional env setup (think zero setup file). This is good for
a frontend loaded flow to validate IP behavior in a short time.
- On the other hand, a BE loaded env (full tech libs/rules etc)
can be done in Nitro and MXDB can be used to exchange only the
netlist/placement data to run through a full signoff flow.
Congestion and Timing correlation experience: most of the blocks we had good
correlation between the two tools. However, one of our ARM processor
blocks demonstrated bad timing correlation in the pre-CTS stage. We worked
with the Mentor support team, and got a new set of configs that brought the
pre-CTS correlation with Oasys back on track. Additionally, some updates
made it into their RTL floorplan interface bringing it very close to a
traditional PnR floorplan interface.
CONCLUSION
Using these Mentor tools, we have now been able to create a "physical" RTL
synthesis flow where floorplan activity is pulled prior to RTL synthesis
(avoiding a loopback which is very painful). This flow uses Oasys-RTL
synthesis that does automatic Floorplanning (with enough hooks for user
inputs) followed by physical synthesis and then analysis of key metrics.
After that, based on the analysis results we either push the design towards
a quick P&R validation flow in Nitro-SoC, or we make RTL changes based on
the timing and congestion feedback from Oasys.
We had a big gap in our previous SoC build model where the unpredictability
of our IP's timing and routing behavior created big headaches for tapeout
with a SNPS DC-Graphical/IC Compiler flow.
Our new Oasys/Nitro-SoC IP qualification model ensures that these problems
are now foreseen and optimized out well ahead of time.
- [ Run, Forrest, Run! ]
---- ---- ---- ---- ---- ---- ----
Related Articles
We switched from CDNS EDI/PT flow to MENT Olympus-SoC/PT flow
Join
Index
Next->Item
|
|
