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). F... » read more

Shoot The Engineer


By Luke Lang Many years ago as a junior engineer right out of college, my manager explain to me the concept of “shoot the engineer.” Engineers are trained to be perfectionists. We want to design the best mouse trap ever. However, the engineer that designs the first working mouse trap takes home the money. Given another day, another week, or another month, we can always improve upon our cur... » read more

Virtual LP


By Luke Lang Several months ago, I introduced the concept of virtual domain in association with hierarchical CPF. It is a relatively simple concept with a concise definition. It is powerful and flexible in supporting large designs with complex power architecture and hierarchical power intent. However, to the UPF coders, virtual domain is sometimes a mystery. I hope this blog will clear up any ... » read more

Power Intent Formats: Reality Check


By Luke Lang It is January once again. In addition to wishing everyone a Happy New Year, I would like to wish everyone a lower-power 2012. This month, I will continue with the CPF/UPF power format discussion and examine more complex power architectures. Also, the focus will be only on CPF 1.1 and UPF 1.0. These are what the current tools support. IEEE 1801 is up and coming, but there is n... » read more

Power Intent Formats


The October blog about CPF, UPF 1.0, and IEEE 1801 power domain definitions resulted in some reader feedback and suggestions. Several points are worthy of further discussion and clarification. Let me start with the toughest questions. What is my motivation behind the blog? Am I trying to make CPF look better than UPF/IEEE 1801? My preferred choice of power intent should not be a surprise ... » read more

Power Intent Formats: Isolation


By Luke Lang Last month, I discussed power domain for all three power formats: CPF, UPF 1.0, and IEEE 1801. I mentioned isolation but mainly used it to explain power domain. This month’s blog will address isolation in detail. First, isolation cells are required at off-to-on domain crossings. When a domain is shut off, all of its output nets become undriven. If these floating nets drive direct... » read more

Power Intent Formats: Power Domain


By Luke Lang Starting this month, I will be writing a series of blogs inspired by “Dueling Power Formats”. The article correctly points out that there are currently three power formats: CPF, UPF 1.0, and IEEE 1801. Some designers will find themselves in a position of having to choose a format. Others will need to work with both formats. Regardless of which position one is in, these LP desi... » read more

Hierarchical LP Design 3


By Luke Lang Last month, I wrote in favor of top-down approach to coding the power intent. This month, let’s take a look at the bottom-up approach. With the top-down approach, we code the full-chip power intent without having to worry about all the nets that cross power domain boundaries. Then we issue a few commands, and a tool writes out the block-level CPF. Pretty simple and straightfo... » read more

Hierarchical LP Design 2


By Luke Lang Last month, I discussed two key features of the Common Power Format (CPF) that support hierarchical design methodology: boundary port and macro model. These are commands that need to be written to describe the power intent and drive the tools. Without these commands, it is extremely difficult to do hierarchical design. But with these commands, hierarchical power intent files are n... » read more

Hierarchical LP Design


By Luke Lang The rapidly shrinking process geometry is a double-edged sword. It allows unprecedented integration of circuits. But it also produces leakier transistors, which is one of the main reasons behind the need for low-power design techniques. Therefore, a good low-power design flow must not only automate low-power design, verification, and implementation, it must also support hierarchic... » read more

← Older posts Newer posts →