LP Macros 2

What works and what doesn’t in workarounds, and when it’s all going to get better.

popularity

By Luke Lang
Last month, I compared the CPF macro model with LP attributes in the Liberty model. The CPF macro model was developed when Liberty had very little LP attributes to support LP designs. Even today, Liberty still lacks LP attributes to describe some of the common power intent in LP designs.

One example is an LP IP block with internal power switches and shutoff domains. Because most of the SoCs have LP design requirements, it is not surprising that the IP blocks within the SoC also need to be LP. LP memory is a common example of this kind of LP IP. The figure below is a simple illustration of such a block.

Screen-Shot-2012-06-14-at-8.10.57-AM

The SLEEP pin controls the power switch, and the IN and OUT data pins are related to the internally switched power net, which is not visible outside of the IP block. Because CPF is based on a logical representation of power domain, it is very easy to define a virtual domain (PDv) outside of the IP block and establish a relationship with PD1 inside the IP block through the concept of domain mapping. Therefore, the IN and OUT data pins are related to PDv, a switchable virtual domain.

UPF/1801 are based on physical power nets. Because the switched power net is not visible outside of the IP block, it is not possible to define a power state table (pst). A workaround that is often used is to bring the switched power net out of the block and connect a dummy power net to it. Here is what it looks like:

Screen-Shot-2012-06-14-at-8.11.23-AM

This works okay if your IP is developed internally by teams within your company. What happens if your IP is purchased and it does not have VDDsw brought out to a pin? You will have to look for another workaround.

EDA should be about tools enabling design. It seems somewhat backward that this workaround calls for design change to enable EDA tools.

Another popular feature of the CPF macro model is floating ports. More and more analog and mixed-signal IPs are integrated into an LP SoC. A designer inevitably will encounter analog nets that should not be digitally isolated or level-shifted. In CPF 1.1, these analog ports can be designated as floating ports of analog macros. CPF 2.0 added the set_analog_port command to enhance support for analog mixed-signal designs.

Because Liberty does not have LP analog attributes, some designers have resorted to using fictitious set_related_supply_net commands to override Liberty definition. Some designs can have 10,000 of these commands. Each command must carefully identify the design pin and relate it to an appropriate power and ground pair to satisfy LP check and avoid unintended LP cell insertion. This just seems like a lot of tedious work that the A in EDA should take care of.

The last CPF macro model feature that I will mention is feedthrough. Feedthrough nets are commonly used to route a signal through a block rather than around a block. For LP designs, a feedthrough net has the special property that it is not related to the power domain of the block that it feeds through. Feedthrough nets can be easily identified in a netlist because they do not fan out to other logic in the block. But when a block is hardened and black-boxed, how do we recognize feedthrough pins? It is easy to specify feedthroughs in CPF macro models but not possible in Liberty models.

To conclude this month’s blog, I want to acknowledge that a casual reader may get the impression that I’m merely touting CPF and bashing UPF/1801. That is not quite true. I have tried to make the case that the CPF macro model is a better way to describe the LP intent of a macro cell or block. Si2 has donated the CPF technology to IEEE. I hope the macro model concept will be incorporated into 1801 so that we will soon have converging standards for LP design.

—Luke Lang is engineering director at Cadence.



Leave a Reply


(Note: This name will be displayed publicly)