Low-power SoC design

The engineering objective

Coordinate power states, hardware architecture and software policy.

The work starts from use cases, duty cycles, power budgets and retention requirements. The team should identify the authoritative revision of each input and record any assumptions needed to proceed. This prevents a later result from being interpreted against a different specification or configuration.

What needs technical attention

Leakage, active energy and wakeup cost need to be considered over the real usage cycle.

The review centres on isolation, retention, wakeup latency and state-dependent functionality. Each finding should identify the input revision, observed behaviour and supporting evidence. Distinguish a confirmed defect from a configuration issue, an unsupported case or an open engineering question before deciding how to resolve it.

How the work is reviewed

The practical sequence is: partition domains; define transitions; implement power intent; validate state changes. Intermediate reviews allow the client to resolve decisions while changes are still manageable. If an input changes, identify the affected activities and repeat the checks that depend on it.

The expected package comprises power architecture, intent files, transition tests and analysis reports. Acceptance criteria should specify what the receiving team needs to reproduce, inspect or integrate these artifacts. Include known limitations and outstanding actions in that package, rather than assuming that delivery of a file implies acceptance.

Separate implementation estimates from release evidence

Physical implementation starts with consistency between the logical design, constraints and technology views. Review clock definitions, generated clocks, I/O delays, operating modes and exceptions before interpreting timing. A missing constraint can make a report appear healthier while leaving a real path unevaluated. Record the library and extraction corners used so results from different stages can be compared on the same basis.

Floorplan decisions influence routing, clock distribution and power delivery together. Reserve space for macro access, power connections, congestion relief and the paths that need predictable delay. A local timing improvement may add buffering, increase switching power or create routing pressure elsewhere. Review these effects across the agreed modes and corners instead of accepting an improvement in one summary number.

As the design moves from placement through clock construction and routing, replace estimates with the appropriate extracted evidence. Classify violations by cause and ownership. An ECO should carry its logical intent, the affected paths, implementation changes and the checks that must be repeated. The release checklist should identify required reports and any formally accepted exceptions; the presence of a layout file alone is not a signoff decision.

An illustrative review scenario

An added pipeline register may improve a setup path while creating short hold paths and changing clock-tree loading. Compare both setup and hold at the agreed corners, review new buffering and check routing and power effects. Retain before-and-after reports from a controlled baseline. This illustrative example explains review scope; it does not promise a particular power, performance or area result.