PPA optimisation needs a system boundary

Define what “better” means

Power, performance and area are linked, but they are not a single objective. A design can become smaller and consume more energy per operation. It can run at a higher clock frequency while delivering less useful throughput. It can look efficient in isolation and force additional buffering or software work elsewhere.

I start optimisation by defining the system boundary and the workload. What useful work must be completed? At what rate? Under which traffic, numeric precision, operating conditions and resource constraints? Which requirement is hard, and which metric can be traded? Without that context, the comparison is vulnerable to selecting the most flattering number.

For a real-time controller, worst-case response may dominate. For a continuously active accelerator, energy per completed operation may matter most. For a low-duty-cycle sensor, idle power and wake-up cost can outweigh active efficiency. The same RTL transformation can help one application and hurt another.

Separate frequency, latency and throughput

Pipelining divides a long combinational path into shorter stages. It may increase achievable frequency and allow more operations in flight, but it also adds registers and can increase the latency measured in cycles. Resource sharing reduces replicated arithmetic but introduces scheduling and multiplexing. Parallelism increases peak throughput while placing more demand on memory and interconnect.

The relevant unit is completed useful work. A pipeline accepting one item each cycle cannot sustain that rate if its input memory provides one item every four cycles. Improving the arithmetic stage then changes little at the system boundary.

Use realistic activity and operating modes

Dynamic switching power is often introduced through a relationship proportional to activity, capacitance, voltage squared and frequency. That relationship is useful for reasoning, but a credible estimate also needs the implemented design, clocking, routing, operating conditions and workload. Leakage and other static contributions remain relevant, especially when useful activity is low.

An activity file from a simulation can improve power estimation only if the simulation represents the intended operation and maps correctly onto the implemented design. Review how much of the design has annotated activity, how resets and enables behaved, and whether long idle or burst periods were included.

For an FPGA, use supported clock-enable and clock-management resources. Combinationally gating a clock in ordinary logic can introduce hazards and timing problems. ASIC flows have their own clock-gating cells, checks and constraints. An optimisation technique must fit the target implementation technology.

Compare energy as well as power. If a design draws less power but takes much longer to finish, total energy may rise. Conversely, a faster burst followed by a low-power state can be attractive when the system can exploit the idle interval. Measure the whole operating cycle.

Run controlled, reproducible experiments

Keep the baseline fixed: source revision, constraints, target device or process, tool version, implementation settings and workload. Change one architectural factor at a time when practical. Record both the expected mechanism and the measured effect. If results move unexpectedly, inspect the critical paths, resource mapping and activity rather than accepting the headline report.

Use early estimates to reject weak alternatives, then compare finalists at a similar implementation stage. A post-synthesis area estimate and a routed area result are not interchangeable. Wire delay, congestion, buffering and clock distribution can reverse an early conclusion.

Preserve alternatives that lie on the trade-off boundary: one may offer less area, another lower latency, another better energy. The final choice belongs to the product requirements. A single weighted score can be useful, but its weights should be explicit and its sensitivity understood.

Good optimisation produces an explanation that survives review: this change improves this metric under these conditions, at this cost to the others. The value is not simply a smaller number. It is a better engineering decision with a known operating envelope.

Further reading

• AMD — Vivado power analysis: switching activity
• OpenROAD — Physical implementation and design exploration