Terminal Boundary Dictates Power Aware Macros

This paper identifies and resolves the fundamental problems of integrating, hardening and verifying soft and hard macros in larger systems with a power aware DVIF perspective.

Low power perspective of soft macros

Soft macros are generally designed in synthesizable RTL. In UPF perspective, a soft macro model is represented in RTL and associated with the UPF attribute {UPF_is_soft_macro TRUE}, which is the soft macro identification directive used in DVIF for verification, integration, soft macro hardening etc. Furthermore, the UPF accompanied with a soft macro must be complete within its entity, i.e. a self-contained UPF that will define its own top level power domain with create_power_domain -elements {.} commands. It’s obvious for the system integrator to ensure that the macro is connected to proper supplies and that the boundary of IP are properly protected with respect to the parent and between other power domains that have signal crossing.

The protection may specify isolation strategies with specific clamping requirements. It may also specify retention hence it is require to ensure backup supplies for the critical registers to retain the data during the power down. In addition, IP integrator must ensure that these constraints (isolation with clamp value, retention registers, etc.) are not violated when the soft macro is integrated into the entire system and configured according to their requirement. For verification, the soft macro power intents or UPF should be complete, independent and must not reference any object to its parent scope so that the verification tools can readily validate and catch any scenarios that fail to honor any of these constraints.

Also the primary IO ports of the macro will not rely on the visibility of real driver and receiver supplies. That is, when driver and receiver supply attributes are present, IO ports will be annotated with these attributed supplies accordingly. However when these supply attributes are absent, the driver and receiver supply will reference to the primary supply set of its own top level power domain. It is also important to know that the driver and receiver supply contexts for soft macro IO ports reveal that they are regarded as the terminal points or terminal boundaries with respect to the ancestor power domain instances for all verification and implementation tools. Such boundary conditions obviously paved the way to reuse same macros over and over again across multiple projects.