Multi corner workaround with RC? > Forums

Forums

Subject: Multi corner workaround with RC?

Posting to forums is available to community members only.
Login or Register

Rate this topic:

Author

Messages

EngHan
Posts: 65
Online: User is Offline

8/01/2007 8:16 PM
Hi, I need advice related to WC and WCL corners. Thanks. At very small geometry, a std cell delay can be slower with decreasing temperature. As a result, we have a new corner named WCL. It is the same as WC except that temperature is at -40 degree and not 125 degree. Compare between WC and WCL, a std cell is not always slower or faster at one corner. As delays are modelled as 7x7 table for rise/fall/rise_transition/fall_tranisiton, a cell can be faster/slower in some of the entries at WC or WCL. My question is how do I get the best possible result in term of timing, leakage, dynamic power and area with RC. The easy answer is to use multi-corner approach that is available in SoC. But multi-corner is not available in RC and I think runtime will increase. Any workaround you can recommend ? Regards, Eng Han

grasshopper
Posts: 48
Online: User is Offline

8/01/2007 8:23 PM
Hi EngHan, I had a similar issue and used the power_library attribute to address this. The attribute allows you to specify a different corner library for the power analysis. This can be specially important when using multiVT libraries since some libraries show very little difference in leakage in such low temperatures. good luck, gh-

EngHan
Posts: 65
Online: User is Offline

8/02/2007 12:04 AM
Hi GH, Can you elaborate more? I cannot understand how you get around it. To explain my issue more, the main concern is timing opt. I cannot optimise at WC alone or WCL alone, as both are the the worst-case. There is a suggestion to merge these 2 corners into a "merged dotlib", but I think this approach will work for timing but will mess up area and power QOR. Regards, Eng Han

grasshopper
Posts: 48
Online: User is Offline

8/03/2007 4:00 AM
Hi EngHan, power should certainly not suffer. The power_library attribute should certainly guarantee that. It basically tells RC to use a different library to evaluate power. I also saw in the low power document that there is support for DVFS hence you could address your multi-mode issues that way. Seems that would be much cleaner than a merged dotlib. If you try that, I would be curious to hear how it goes. I suspect there is a runtime penalty but other than that, I think this would be quite powerful. good luck, gh-

EngHan
Posts: 65
Online: User is Offline

8/03/2007 9:08 PM
Hi GH, I think you misunderstood my problem. It has nothing to do with DVFS. I am not using DVFS, nor multi-voltage. I try to simplify my problem here again with a few lines. I hope it will be clearer to everyone. In 65nm and below, we have a new corner : WCL. Sometime a delay/transition in WCL is worst, sometime WC is worst. So I cannot synthesis with WC nor WCL as both are not the worst case. What should I use during RC synthesis? Regards, Eng Han

grasshopper
Posts: 48
Online: User is Offline

8/06/2007 6:21 AM
Hi EngHan, I realize you do not have a DVFS design. If you look carefully you will see that you can use the DVFS methodology in RC to address your issue. While it was probably meant to use libraries that are characterized to different voltages, there is nothing that prevents you from using it for libraries characterized to different whatever and get a concurrent that hits the toughest corner of every path. Sometimes the trick is to get creative with unintended uses of available technology. good luck, gh-

Posting to forums is available to community members only.
Login or Register

Forums > Digital IC > Synthesis and test > Multi corner workaround with RC?