Power Management Requirements
Electricity usage may not be seen as a significant factor in a car, but that could change as power-hungry smart electronics play a larger role in modern vehicles than ever before. Infotainment, sensors and sensor fusion, cameras and radar are a good example. Next, local AI provides quick responses for early collision detection, while automotive Ethernet connects everything to the central processing unit—all of which consume a lot of power, which could drain the battery or reduce the electric vehicle's range. Even if the driver turns off the engine and walks away, some features must remain on at low standby power; for example, proximity detection that automatically unlocks the doors or receives a signal from an app to remotely start the engine.
Outside of the automotive space, some IoT devices are expected to run on coin cells for 10 years. Drones that may run on larger batteries require a lot of power to stay in the air. Streaming high-resolution video consumes a lot of power, so it needs to be turned off when not needed. All of these examples require low-power designs. This takes the form of application-specific power management, ranging from dynamic voltage and frequency scaling (DVFS), switching within a domain, to shutting down the domain completely on demand. In the case of shutting down and leaving the car, this means shutting down everything except the always-on domain for viewing and processing remote events of interest.
Is it enough to know the standard power tricks?
Engineers understand standard approaches to power management: clock domain switching, scalable voltage and voltage domains, and switchable power domains. All of this applies to intellectual property (IP) power management, but obviously requires additional interconnect support.
Interconnects tie together many IPs. Some may be on, some may be on but run at a lower voltage and frequency, some may be off. In this case, how is power managed in the interconnect? For crossbar based connections, which typically exist in a single clock and power domain, the arbiter must continue to operate if any connected device is turned on. Pushing a new interconnect hierarchy into each domain might be a solution, but it would become cumbersome to handle all the necessary handshakes between domains.
Figure 1 The NoC approach facilitates clean transition and handshake communication with the power manager
Alternatively, use NoC technology to support partitioning inside and outside of the NoC, with hardware support for clean transitions and handshake communication with the power manager, including wake-on-demand. Supporting complex DVFS enables low-power management within the network as effectively as within and around IP. NoCs are smart enough to know that if there is no data to send on a network path, they can automatically power down that path.
Bottom line: Designers can use the NoC to push the average active and standby power to lower levels than using a crossbar-based interconnect, and let the NoC handle all adaptations between clock and power domains in an efficient manner .
Functional Safety Requirements
To be safe, the pictures are similar. Engineers consider IP's mitigation techniques -- error-correcting codes, parity, lockstep, and triple modular redundancy -- when running security analysis -- but what about interconnects? Advanced NoC technologies support the same mitigation options, enabling engineers to meet failure mode, impact, and diagnostic analysis goals in NoC as in IP and subsystems.
There is an even more interesting feature for advanced ASIL D designs that require fault-running performance. A quick reminder here: a failing device must not only monitor for low-level issues, but must also be able to verify the correct performance of the IP within the device while it's "on the fly." If it detects a persistent problem and reports it to the driver, it should be able to take the misbehaving feature offline while still allowing the drive home despite the malfunction. This is the new level of safety expectations required by advanced driver assistance systems (ADAS) and autonomous driving technologies, where ASIL D compliance is a must.
Figure 2 NoC technology provides hardware-based data protection to improve SoC reliability and functional safety
Arteris IP NoC supports this stricter requirement. The IP in the design can be isolated from the NoC at each network interface unit (NIU) that connects the IP to the network. This uses the same mechanism provided for power isolation. After isolation, an ASIL D-rated safety controller can trigger a Logic Built-In Self-Test (LBIST) check on this IP to verify proper operation. If a problem is detected, the IP will remain isolated and the security controller will report the problem.
If the IP passes the LBIST test, it can be re-enabled and participate in full operation again. This capability provided by NoC enables this level of isolation and testing. The distributed nature of a NoC makes it naturally more robust and resilient to failures, everything is intertwined and the failure of one connected component can lead to more difficult recovery than a centralized interconnect like a crossbar .
