( ESNUG 570 Item 3 ) -------------------------------------------- [04/04/17]
Subject: ST used Nitro-SoC for full PnR on ultra-low power IoT chips
Seeing that the Mentor U2U'17 is happening this morning, plus the fact that
MENT Sierra/Oasys has made the news lately (ESNUG 568 #1) I figured out this
would be a great time to publish my Sierra/Oasys U2U notes from last year.
(Just under the deadline, I'd say!)
- http://www.deepchip.com/items/0570-01.html
From: [ John Cooley of DeepChip.com ]
The ST guys do IoT chips. They're in a big battle with Renesas for this
market. The big headache they faced was the complexity of the Multi-VDD
architecture and getting the lowest possible power from a PnR perspective.
Mhz wasn't important; power was everything. I heard these ST guys used
to use Synopsys ICC/ICC2 and then they switched over to Nitro-SoC.
Design stats:
- 1.5M instances
- 6 power domains
- 2 switchable domains
- 2 high voltage domains (3.3V)
- Mixed-Vt libraries
- UPF with a very complex power state table defining the
interaction between them.
In a nutshell, Nitro-SoC does low power by:
1.) capture the power intent for multi-voltage in the UPF 2.2 syntax.
This is carried throughout their physical design flow.
2.) Analyze domains and power connectivity with Tcl queries to the
Nitro database. (It's not OpenAccess db. "OA is good for full
custom layout, but crap for digital."
3.) Designers trace connectivity on power pins just like on signal
pins. Here you verify the power applied to a given pin. This
is important because multivoltage designs have tons of different
power domains. You have to manually check that the right
voltage is given to the right domain -- and no messed up cell
connection for long power nets.
4.) Check power domain isolation cells, level shifters, switches,
and retention cells. The ST guy talked about using Nitro to
manage the cell spacing requirements of different types of
library Vt cells. He said it was seamless; no custom flows
nor scripting needed.
---- ---- ---- ---- ---- ---- ----
This pic is showing how the ST guy used Nitro to check cell spacing rules
for different Vt classes: HVT, LVT, ... In my day there were only 3 Vt
classes (SVT, LVT, HVT), and now it's common to have chips with 10 to 15
Vt classes to get the best leakage/speed tradeoff. The Nitro-SoC tool
does VT spacing automatically, but the ST guy also likes to look in to
see himself for sure. "It's all scattered. Good."
(I missed taking a pic of his next slide, so I stole this from the MENT
web site.) The ST guy was all gushy about Nitro-SoC getting kickass power
placement results. That was all he really cared about. (Which makes
sense for an IoT chip.) They used tons of ARM cores and had to be sure
they were placed for the best power-speed tradeoff.
One power placement problem is when you have a signal going from one (on)
power domain to a 2nd (on) power domain and it routes across a 3rd (off)
power domain. Common in multi-voltage flows. The ST guy loved how
Nitro-SoC did automatic feedthrough buffering for messy top level nets
like this -- where the tool was using the always-on buffers when routing
nets over switchable domains.
The MENT AE next to me whispered: "Our router also automatically handles
high voltage nets. It honors these types of ugly DRC rules."
This is showing how Nitro handles different nets with different voltage
levels and different spacing requirements. Notice that 8th vertical wire
from the left? See how it's spaced from the others? That's because it's
a high Vt wire. The spacing between all of the high voltage nets is
based on their spacing rules.
POWER VS. SPEED CELL CHOOSING: During optimization, Nitro was able to keep
low leakage cell use down by consistently picking high-vt cells (~80%).
Nitro did this all the way from pre-CTS through to post route stages.
That is, Nitro's leakage optimization didn't steal clock frequency to get
lower power.
---- ---- ---- ---- ---- ---- ----
WHAT ABOUT OLYMPUS?: Since I knew ST was an old Olympus user, I of course
asked what he saw was the difference between it and Nitro-SoC? He said
he took the same design and did a replay with Nitro-SoC and got a 2x runtime
speedup with the same quality of results (timing, area and power). Nitro
is 100% compatible with Olympus. (Unlike the ICC to ICC2 migration where
there was a massive script rewrites needed.) He also yarped up Nitro's
fast CTS compile and new clock tree cockpit GUI "for easy debug". The
MENT AE whispered: "We use lots of parallelization to get faster runtime."
WHAT ST DIDN'T LIKE: The ST guy did gripe about feedthrough buffering
needed to "support gas stations", which I didn't quite understand. He
also wanted better custom wire editing & automatic multivoltage mesh
generation.
Overall, though, the ST guy seemed gushy about Nitro because he got
really good low power PnR for IoT from it.
- John Cooley
DeepChip.com Holliston, MA
---- ---- ---- ---- ---- ---- ----
Related Articles
How Samsung uses Oasys-RTL inside their IC Compiler II flow
Nvidia uses MENT Nitro physical floorplanning for ICC/ICC2
ST used Nitro-SoC for full PnR on ultra-low power IoT chips
Join
Index
Next->Item
|
