Cadence.com will be under maintenance from Friday, Oct. 3rd at 6pm (PST) thru Sunday, Oct 5th at 11pm (PST).
Cadence.com login, registration, community posting and commenting functionalities will be disabled.
Home > Community > Blogs > Logic Design > Dont let power kill your project
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more convenient.

Register | Membership benefits
Get email delivery of the Logic Design blog (individual posts).
 

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

Don't Let Power Kill Your Project

Comments(2)Filed under: Low power , Logic Design, CPF, logic low power design, low power design, low power design chip estimate inCyte, RTL compiler, TeamFED, Diego HammerschlagBy Diego Hammerschlag
Sr. Technical Leader
Team FED

Power has gone from an imminent threat to the cause of multiple projects across several vendors going under. I have heard of multiple projects that had working RTL prototypes and were far into the backend flow only to find out that the power used would be exorbitant or that the cost of the package would kill all chances of the product competing in the marketplace. More and more, these and other power related issues, are preventing projects and products from seeing the light of day.

One of the challenges of optimizing for power is that 'worst-case power' libraries are commonly not the same as 'worst-case timing' libraries. The latter are traditionally used for synthesis resulting in designs that, even when run through power optimization steps, are incorrectly optimized for power with potential dire consequences. So what is the appropriate way to address this library dilemma then ? Or is there a way to address it ?

The good news is that RTL Compiler provides a clever mechanism to address this issue by using the power_library attribute. The power_library attribute allows users to specify a set of  synthesis libraries to look at power characteristics that is different from the timing libraries configured using native RC syntax (library or library_domain attributes) or the library information from Common Power Format (CPF) constraint file. The power_library attribute can be applied to a library_domain thus specifying that the libraries on that domain should use the libraries specified in the power_library attribute to perform power analysis. This mechanism allows users to concurrently optimize a design for worst-case power and worst-case timing avoiding the consequences of only optimizing for one of them. 

The following example shows the use of the power_library attribute when library information has been read through a CPF file:

Given a CPF file with the following contents

 define_library_set -name wct -libraries {
                       worst_case_tim_stdcells.lib    \
                       worst_case_tim_128x32.lib    \
                     }
 define_library_set -name wcp -libraries {
                       worst_case_pwr_stdcells.lib    \
                       worst_case_pwr_128x32.lib    \
                     }

in the RC script, the user would have to add the following lines before synthesis and after the CPF library information has been read

set_attribute power_library [find / -library_domain wcp]  [find / -library_domain wct]

If the user is not using CPF but using RC syntax, then the RC script would have the following lines at any point before synthesis

create_library_domain wcp   # worst-case power libraries
create_library_domain wct    # worst-case timing libraries      
set_attribute library_domain { worst_case_pwr_stdcells.lib worst_case_pwr_128x32.lib } [find / -library_domain wcp]    
set_attribute library_domain { worst_case_tim_stdcells.lib worst_case_tim_128x32.lib } [find / -library_domain wct]
set_attribute power_library  [find / -library_domain wcp]   [find / -library_domain wct]    
set_attribute default  [find / -library_domain wct]      # This ensure the worst-case timing corner is used on all subdesigns for timing optimization

 As you can see, the use model is quite simple and flexible allowing the user to avoid costly issues. Expect to hear more ways to prevent power from killing your project and let us know of your power concerns and questions.

Good luck and happy power savings,

Diego-

Comments(2)

By Sudhir on December 1, 2009
Diego,
For leakage optimization, does RC have commands to force it to use lower VT cells for pre defined set of modules (which are timing critical) and use high VT cells for rest of the design?

By grasshopper on December 5, 2009
Hi Sudhir,
the recommended methodology in RC is to make all libraries available to the tool and let the tools take advantage of them and select the appropriate architectures for each block. library_domains can certainly be used for what you are asking but it is not the preferred methodology. In such an approach you would do something like
create_library_domain HP   # high performance domain
create_library_domain LP    # low power domain
set_attribute library_domain { LVT.lib } [find / -library_domain HP]    
set_attribute library_domain { HVT.lib } [find / -library_domain LP]
and finally apply the corresponding domain to the appropriate blocks
As you can see, library_domains are a very powerful feature. The reason why it is not the favored flow is that this is saying that you can do a better job choosing the cells for the tool than the tool can do by itself. In doing so, you could involuntarily force the tool to pick different datapath architectures that may lead to HVT cells but much larger area so in the end you could have low performance and higher power if you are not careful. As you may imagine, I am not a big advocate of %LVT as a metric since it is not a real metric. User should look at real metrics like performance and overall power IMHO.
hope this helps

Leave a Comment


Name
E-mail (will not be published)
Comment
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.