LP Macros

By Luke Lang
Many designers have asked why CPF has the macro model commands while UPF/1801 does not. I will try to answer this question and explain the differences in both approaches.

First, let’s briefly review CPF macro model. A CPF macro model describes the power interface of a macro cell, which could be a complex cell (pad cell), an IP block (memory), or a hardened block (ARM core). For example, a macro input port is expected to interface with a 1.0 V always-on driver. Or a macro output port has built-in isolation so that no isolation cells are needed outside of the macro. These power intents primarily deal with the interface of the macro with the surrounding logic.

There are actually two parts to the original question.

1) Why does UPF/1801 not support the macro concept? UPF/1801 relies on the LP attributes in the Liberty model to describe the power interface of macro cells.

2) Why does CPF have macro model commands? Liberty is not an open standard. There is not a Liberty standards committee for feature requests. Therefore, CPF had to include commands to deal with LP macro cells. Also, timing and power tables are sometimes not needed, especially for LP verification. Therefore, coding a Liberty model just to describe the power interface would be too difficult, even if Liberty had all the necessary LP attributes.

Simple power interfaces are well supported by both the CPF macro model and Liberty. The most common power interface is the power domain of each macro port. In the CPF macro model, this is supported by defining boundary ports as part of power domains. In Liberty, this is supported by related_power_pin and related_ground_pin attributes. Both work well for simple macro cells with multiple power and/or ground pins.

A slightly more complex macro cell could contain built-in isolation cells. These cells are quite convenient for LP designers. They eliminate the need to insert isolation cells around the macro. The CPF macro model supports this with the standard create_isolation_rule command. Liberty does not have official support for this—not in the 2011.09 documentation. However, many designers have reported seeing the is_isolated attribute used to describe built-in isolation cells.

An even more complex macro cell could contain built-in power switches. This is very common for LP RAM. For large SoC designs, some internal blocks are hardened and treated as macro cells during various steps in the flow. (This is motivated by instance count and runtime reduction.) These macro cells often have ports that are related to the internally switched power domain. An accurate description of these power interfaces is essential for LP structural verification.

The CPF macro model supports internal power switches with the same commands as a CPF design model. Virtual domains and boundary ports are defined inside the macro model. When a virtual domain is switched off, the corresponding boundary ports are also off. 2008.09 Liberty spec mentions pg_type attributes of internal_power and internal_ground to describe these boundary ports. 2011.09 Liberty spec changed pg_type attributes to nal_power and nal_ground. Neither spec describes how these pg_type attributes should be used to model these internally switched boundary ports. I don’t really understand them but can only assume that there is a way.

I know lots of people who can code CPF, UPF, or 1801. But I don’t know too many people that can code Liberty. Adding LP attributes to the Liberty model for LP library cells seems reasonable. However, coding Liberty to model complex macro cells or hierarchical blocks is just about an impossible task. Coding aside, Liberty does not have key features that are absolutely essential for LP design. I will continue this discussion next month.

—Luke Lang is engineering director at Cadence Design Systems.