Managing 1,000+ Thermal States in a Mobile Device

When I was ten years old, my grandparents warned me not to play with fire outside. “You can burn the house down”. I ignored them, lit up dry grass, and within minutes the fire was out of control. My grandmother had to run out with buckets of water to stop it.

The house survived. But the lesson stayed with me: the problem was never whether someone could put out the fire later. The problem was preventing it in the first place.

That memory comes back to me when I think about thermal management in modern SoC design. Thermal issues do not catch experienced teams by surprise. Engineers know heat is there. They manage it. But the question that matters is when they manage it — and what it costs when the answer is “after silicon.”

As the organizer of this year’s Hardware-Assisted Verification track at Synopsys Converge 2026 Silicon Valley, I got to hear how leading semiconductor teams tackle exactly this kind of challenge. One presentation that brings the thermal question into sharp focus came from Google, describing how the team approaches power, performance, and thermal validation for its next-generation Tensor SoC — the processor inside Pixel phones.

The story resonated because thermal optimization is one of the clearest examples of a system-level readiness question that can be answered at two very different moments — and the moment you choose changes everything. Read below how doing it pre-silicon will save you 3 weeks in post-silicon bring-up time.

No modern SoC ships without thermal management. Power gating, dynamic voltage and frequency scaling, thermal throttling policies, and firmware-level thermal controls are standard practice. Engineering discipline exists. The tools exist. Expertise exists.

The question is not whether thermal issues get solved. The question is when in the development timeline they get solved — and what that choice costs.

When thermal behavior is first observed on real silicon, the design is frozen. Floorplan decisions are final. Power distribution is fixed. Clock tree structure is locked. The only degrees of freedom left are in software: throttling policies, workload scheduling, power state management, and firmware thermal controls. Those are valuable tools, but they are reactive tools. They manage heat. They do not remove the root cause.

That is the engineering equivalent of my grandmother’s buckets of water. Effective, necessary in the moment, but fundamentally a response to a problem that could have been addressed earlier.

When thermal behavior is visible pre-silicon — when realistic workloads run long enough to expose sustained power profiles, hotspot accumulation, and compute-memory thermal interaction — the team has a different set of options. Floorplan changes. Power domain restructuring. Architectural tradeoffs between performance and thermal headroom. Software thermal policies designed for the actual thermal profile, not reverse-engineered from post-silicon measurement.

Pre-silicon thermal insight does not eliminate the need for post-silicon thermal management. But it shifts the balance from reactive firefighting to deliberate design.

Arun Prasad Tambrahalli from Google has been living end-to-end DVFS and thermal validation for a next-generation edge AI SoC. The design is a Google Tensor processor — the kind of chip that powers features like Live Translate, on-device Gemini AI, and 100x camera zoom in Pixel phones. Each of these features places unique demands on power and performance, and all of them compete for thermal headroom inside a thermally constrained mobile device.

What makes the thermal challenge interesting here is not just heat. It is the interaction between heat, power, performance, and software — all moving at the same time. A modern Tensor SoC integrates diverse IP blocks, each with independent power rails and the ability to dynamically switch frequencies based on workload demands. Balancing high performance for AI workloads while maintaining optimal thermal levels is a critical design requirement — and it depends on hardware, firmware, power management, and thermal control working together as a system.

Diverse IP integration: Modern SoCs like Google Tensor integrate diverse IPs for features like Live Translate and on-device Gemini AI, where each feature has unique power and performance requirements that must be managed independently.

Independent Power Rales: The PMIC supplies multiple independent rails powering different IPs, enabling granular power control across the SoC for optimal efficiency.

Dynamic Power and Performance Management for Edge AI: Each IP dynamically switches frequencies and toggles power rails for features like 100x Zoom, balancing performance and power in real-time based on workload demands.

Tensor SoC Power Performance & Thermals Requirement: Balancing high-performance for AI workloads while maintaining optimal thermal levels is a critical requirement for Tensor SoCs in Pixel Phones.

Shift Left to Accelerate Time-to-Market: With innovative methodologies and rich feature sets, hardware emulation platforms provide unmatched capabilities for a reliable product with accelerated TTM opportunities.

At the center of the Tensor SoC’s thermal strategy is dynamic voltage and frequency scaling. DVFS dynamically adjusts voltage and frequency to optimize the balance between power consumption and performance, adapting in real time to workload demands. Across a complex multi-IP SoC, this coordination spans independent power rails and IP domains.

Thermal sensors embedded near IP blocks continuously monitor temperature and feed that data back to the power management unit. The PMU uses thermal data to adjust DVFS settings proactively — preventing overheating while maintaining performance. This creates a closed-loop thermal management system that protects the SoC from thermal runaway while keeping the design operating as close to its performance ceiling as the thermal envelope allows.

The power management IC communicates with the SoC through a dedicated interface, enabling the PMU to command the PMIC to switch rails on and off and adjust voltages precisely per IP demand. During typical chip operation, the system progressively activates different components — memory controllers, CPUs, GPUs, accelerators — each with its own power rail, frequency state, and thermal contribution. As applications launch and workloads shift, the chip heats up, frequencies throttle, and the thermal loop responds. (see Figure 2)

This is the system behavior that matters for thermal readiness. It is not a single signal or a single IP block. It is the full interaction between power sequencing, DVFS transitions, thermal feedback, firmware control, and workload activity — all running together.

The sheer complexity of the Tensor SoC’s power and thermal landscape explains why pre-silicon validation is essential.

Google’s <insert presenter here> shared that the Tensor SoC supports more than 1,100 different frequency states across its various IP domains. Fourteen distinct low-power scenarios require validation. Tens of temperature sensors are distributed across the chip. The power management firmware, the one-time programmable configuration for the PMIC, and the DVFS coordination across all rails and domains all need to be exercised together — not in isolation, not with simplified models, but as a complete system.

That is the kind of complexity where post-silicon discovery becomes expensive. If the team waits until silicon to validate DVFS transitions across 1,100 frequency states, or to verify that the PMIC programming matches the SoC specification, or to test whether the thermal feedback loop responds correctly under realistic workload conditions, the debug cycle is long and the design is frozen. Every issue found post-silicon can only be addressed in firmware or software — the architectural options are gone.

Google’s approach moves that entire validation effort into the pre-silicon phase. The team models the SoC, the power management IC, the thermal sensors, the firmware, and the software drivers together in emulation. Full boot sequence, power rail activation, DVFS transitions, and thermal feedback loop can all be observed and validated before silicon exists. What is striking is how little overhead the thermal and power modeling adds — the model complexity increases by less than two percent and emulation performance remains nearly unchanged. The thermal validation capability comes almost for free in terms of infrastructure cost.

The impact is concrete and measurable, with user feedback on the impact of pre-silicon thermal and power validation

• “This model successfully enabled end-to-end pre-silicon testing, facilitating the completion of ~50% of SOD (silicon bring-up) power test cases”
• “By achieving this in a ~5-hour execution post-silicon bring-up window, we have significantly pulled forward validation timelines that were previously dependent on later-stage hardware”
• “Enabled pull-in of power correlation of post-silicon measurement to pre-silicon estimates by 3 weeks”
• “End-to-end multi-hop sequence and multiple specifications from JEDEC for DVFS H/B/L were brought up in a few hours on silicon, as they were entirely developed on the emulation platform”

Google’s pre-silicon thermal and power validation successfully enables end-to-end testing that completes approximately 50 percent of silicon bring-up power test cases before silicon arrives. When actual silicon does arrive, the team achieves this coverage within a five-hour post-silicon bring-up window — a timeline that would not be possible without pre-silicon preparation.

Power correlation between pre-silicon estimates and post-silicon measurement is pulled forward by approximately three weeks. The end-to-end DVFS sequences and multi-specification compliance checks are brought up in hours on silicon, because they are entirely developed and validated on the emulation platform first. Critical issues — including power interface, reset, and isolation problems — are identified and resolved during the pre-silicon phase, before they can impact the silicon schedule. And the one-time programmable content in the PMIC is validated against the SoC specification pre-silicon, providing a high degree of certainty before the PMIC is committed.

For me, the most telling feedback from inside Google is the statement that this approach “successfully enabled end-to-end pre-silicon testing” and delivered “significant pull-forward of timelines that were previously dependent on later-stage hardware.” That is not incremental improvement. That is a fundamental change when the team knows whether the thermal and power behavior of the SoC is ready.

What stays with me after this presentation is how naturally thermal optimization fits into the broader shift toward software-defined hardware-assisted verification. Compliance readiness, workload validation, software productivity, and thermal behavior — each of these is a system-level question that teams once answered only after silicon. Each one benefits from being answered earlier using software-defined technologies.

As AI workloads grow more power-dense, as chiplet architectures create new thermal boundaries, and as software-defined power management becomes more central to product differentiation, the ability to observe and optimize thermal behavior pre-silicon becomes a competitive advantage, not just a verification milestone.

The best way to protect the house is not to have faster buckets. It is to never start the fire.

Find the Google-Synopsys success story here.

1. High-Performance End-to-End DVFS and Thermal Validation on Pre-Silicon ZeBu Platforms: A Technical Deep-Dive, Arun Prasad Tambrahalli, Hari Maruboyina, Pradeep Reddy Molugu, Synopsys Converge Silicon Valley, 2026.
2. Software-Defined Hardware-Assisted Verification: A New Benchmark for AI-Era Chip Design, Frank Schirrmeister, Tom De Schutter.