How NoCs ace power management and functional safety in SoCs

The previous blog explained why network-on-chip (NoC) technology is displacing crossbar switch architectures at scale. This is especially obvious in very large system-on-chips (SoCs), the kind seen in data centers, artificial intelligence (AI) training accelerators and wireless communication infrastructure. But it’s also becoming important in smaller technologies: Internet of Things (IoT), wearables, and sensors at the “edge.” These devices retain many of the same complexities as their bigger cousins, but in a smaller footprint with low power and functional safety demands.

Power management demands

In a car, power usage may not be considered an important factor, but this may change as power-hungry smart electronics devices play a bigger role than ever in modern automobiles. Infotainment, sensors and sensor fusion, cameras, and radars are a case in point. Next, local AI provides a fast response for early collision detection while automotive Ethernet connects everything into a central processor—all burning significant power, which can drain a battery or reduce the range of an electric vehicle. Even when the driver turns off the car and walks away, some features must stay on at low standby power; for example, proximity detection automatically unlocks doors or receives a signal from an app to start the engine remotely.

Outside of the vehicle realm, some IoT devices are expected to run for 10 years on a coin cell battery. A drone that may run on a larger battery needs a great deal of power to remain in the air. Streaming high-resolution video consumes significant amounts of energy and therefore needs to be shut off when not needed. All these examples demand design for low power. This takes the form of application-specific power management, ranging from dynamic voltage and frequency scaling (DVFS), switching within a domain to completely shutting down domains on demand. In the key-off and walk-away case for the car, it means turning off everything except for an always-on domain for watching and processing remote events of interest.

Is knowing standard power tricks enough?

Engineers know the standard approaches for power management: clock domain switching, scalable voltage and voltage domains, and switchable power domains. All work well for intellectual property (IP) power management but obviously requires additional support in the interconnect.

The interconnect ties together many IPs. Some may be on, some may be on but running at lower voltage and frequency, and some may be off. How is power managed in the interconnect in that case? For crossbar-based connectivity, typically existing in a single clock and power domain, the arbiter must continue running if any connected device is on. Pushing new interconnect hierarchies into each domain could be a solution, but it starts getting messy to handle all the necessary handshaking between domains.

Figure 1 The NoC approach facilitates clean transitions and handshake communication with the power manager. Source: Arteris IP

Alternatively, the use of NoC technology supports partitioning inside and outside the NoC with hardware support for clean transitions and handshake communication with the power manager, including wake-up on demand. Supporting sophisticated DVFS allows low-power management inside the network just as effectively as in and around IPs. And NoCs are smart enough to know that if no data is pending to be sent on a network path, they can automatically turn off power to that path.

Bottom line: Designers can push average operating power and standby power to even lower levels using an NoC than with a crossbar-based interconnect and let the NoC deal with all the adaptation between clock and power domains in an efficient way.

Functional safety demands

The picture is similar for safety. Engineers run safety analyses considering mitigation techniques for IPs—error-correcting code, parity, lockstep, and triple modular redundancy—but what about the interconnect? Advanced NoC technology supports the same mitigation options, enabling engineers to meet failure modes, effects, and diagnostic analysis goals within the NoC, just as in IPs and subsystems.

There is an even more interesting capability for advanced ASIL D designs, where fail-operational performance is demanded. A quick reminder here: a fail-operational device must not only monitor for low-level problems but also be able to verify the correct performance of the IP within the device while “in flight.” It should be able to take misbehaving functions off-line if a persistent problem is detected and report issues to the driver, while still allowing the ability to drive home despite the failure. It’s a new level of safety expectation that is required in advanced driver-assistance systems (ADAS) and autonomous driving technologies where ASIL D compliance is essential.

Figure 2 The NoC technology provides hardware-based data protection for increased SoC reliability and functional safety. Source: Arteris IP

The Arteris IP NoC supports this more stringent demand. IPs within the design can be isolated from the NoC at each network interface unit (NIU) connecting an IP to the network. This uses the same mechanism provided for power isolation. Once isolated, an ASIL D–rated safety controller can trigger logic built-in self-test (LBIST) checking on that IP to validate correct operation. If a problem is detected, the IP remains isolated, and the safety controller reports the issue.

If the IP passes LBIST testing, it can be re-enabled and again participate in full operation. This capability provided by NoCs makes this level of isolation and testing possible. The distributed nature of the NoC makes it naturally more robust and more resilient to failures, compared to a centralized interconnect like a crossbar where everything is intertwined, and the failure of one attached component leads to a significantly more difficult recovery.

Dominating the SoC interconnect

It is easy to see why the network-on-chip is dominating the SoC interconnects. The first article of this series explained why the growing market for commercial IP created a control point where the NoC interconnect provides the “knobs and dials” for creating and configuring differentiable SoCs. This led to my not-so-bold claim that “The NoC is the SoC.” The second article titled “Why network-on-chip has displaced crossbar switches at scale” dove into the technology to show how NoC technology outperforms crossbar-based interconnects within SoCs of any size or complexity.

Next, this article highlights how NoC technology provides capabilities like power management and functional safety that are not possible with older crossbar-based interconnect technologies. For design teams creating modern SoCs, whether large datacenter AI accelerators or power-sipping IoT sensors, NoC interconnect technology is key to implementing these SoC architectures and optimizing the dataflow within them.

Benoit de Lescure is chief technology officer (CTO) at Arteris IP.

Other articles in this series:

Related Content

Source link