Skip to Main Content
white paper

Primary, anonymous, or what?

The destiny of ports from design top that ultimately are driven from off-chip

Illustration of four test scenarios used to analyze and record the impact of using set_port_attribute commands to specify driver/receiver supplies or related power/ground/bias pins
Top level primary IOs remain mysterious in the verification world, specifically when you consider UPF-based low power designs. In real silicon, they are usually driven by off-chip supplies; however, verification complications are multifold for RTL and gate level simulations of them. This paper studies the “simulation-impacting” features of design top IOs and the effect of each feature on verification results.

The Unified Power Format

Unified Power Format (UPF) is the ultimate abstraction of low power methodologies today. It provides the concepts and the artifacts for “Power Management Architecture”, “Power Aware Verification Methodologies” and “Low Power Implementation Mechanism” for any design. When we integrate design components in a bottom-up manner in the UPF-based design verification and implementation (DVI) flow, we carefully consider driver and receiver supplies – specifically for soft and hard IPs — whether they are in a named or anonymous (UPF 3.1 semantics for hard macros) PD and/or even for just any RTL hierarchical instances in a PD or even non-PD RTL hierarchical instances. Let us collectively term these macros’ RTL hierarchical instances (PD or non-PD) as design blocks.

UPF provides a well-defined and cautiously usable syntax and semantics “set_port_attribute” (SPA) to attribute the primary IOs – with driver-receiver or related powerbias-ground supply perspectives. Now steering these driver- receiver instances or supplies of primary IOs for such design blocks in sub-hierarchical surfaces in DVI flow are rather straightforward and conventionally based on the principle of source-sink analysis. From the parent perspective, usually the ports at a design block boundary are either driven by the primary supply of these blocks, or inputs are driven by the driver supply while outputs are driven by the receiver supply. On the contrary, it’s the opposite for soft and hard IPs, i.e. receiver supplies drive inputs and driver supplies drive output ports—and SPA syntax and semantics are highly exonerated. The perspective of external vs internal depends on the verification scope.

Share