²ÝÁñÉçÇø

As a long time designer, ASIC flows amaze me and making them better is my goal. Although a very complex and intricate process, each part of the ASIC flow abstracts the complexity underneath it to ultimately create silicon that could end up in your smartwatch, your electric vehicle, or the latest cell phone ¨C how amazing! Consumers concerns include product reliability and robustness, which brings me to the topic of power integrity and how to best build robustness into silicon ¨C a very beautiful thing.

The Evolution of ASIC Design Flows

ASIC design flows continue to get more complex and schedule pressures continue to mount with no end in sight. Power-related considerations are becoming less of an afterthought. In the older days, when achieving design goals, meeting performance and area goals were usually the primary targets in the earlier stages of the design cycle. Once met with some confidence, power planning details became more important, typically much later in the process. In fact, it used to be that the chip¡¯s power integrity and reliability were taken care of at the last stages of the design cycle because it could be done that way ¨C there was more time and power problems could be fixed easily ¨C no big deal. Thus power integrity was left to the ¡®power signoff¡¯ expert. Unfortunately, times have changed. With the increasing need for high power devices and with the advent of continuing shrinking geometries and support for aggressive advanced processes, there is a growing need for power integrity and reliability to be designed into the design flow much earlier. Empowering designers to address these concerns as early as possible has become paramount.

The Rising Importance of Early Power Integrity Checks

ASIC design flows continue to get more complex and schedule pressures continue to mount with no end in sight. Power-related considerations are becoming less of an afterthought. In the older days, when achieving design goals, meeting performance and area goals were usually the primary targets in the earlier stages of the design cycle. Once met with some confidence, power planning details became more important, typically much later in the process. In fact, it used to be that the chip¡¯s power integrity and reliability were taken care of at the last stages of the design cycle because it could be done that way ¨C there was more time and power problems could be fixed easily ¨C no big deal. Thus power integrity was left to the ¡®power signoff¡¯ expert. Unfortunately, times have changed. With the increasing need for high power devices and with the advent of continuing shrinking geometries and support for aggressive advanced processes, there is a growing need for power integrity and reliability to be designed into the design flow much earlier. Empowering designers to address these concerns as early as possible has become paramount.

Just the other day, I was visiting one of my customers and they shared their power integrity concerns with me. They mentioned that they usually performed power integrity checks at the end of the design cycle. However, there was a problem in their last design, so they needed to rethink and optimize their design flow. They missed their tapeout deadline and required a chip restart because the power integrity issues found related to IR drop made the almost-finished ASIC design non-functional. Horrified, they concluded that they needed to find a way to do earlier power analysis and fixing. The reason they didn¡¯t do it before? It was because there was no good practical solution to easily do in-design rail analysis.

The Problem with Traditional User Flows

Traditional users¡¯ flows are broken. In a flow where there is no in-design power integrity analysis and results are dependent on standalone power integrity checking, there is too much pain that can be attributed to two components.

First, the analysis step is painful because the required data needs to be output from the backend tool and then fed into the standalone power signoff tool. The setup is painful. The second issue is related to taking those results and feeding them back into the backend tool in a meaningful manner. Why is that painful? Based on customers¡¯ complaints, what they end up doing is a combination of writing scripts to parse and make use of that information to do something meaningful mixed with some manual work after extracting and processing information from logs and reports. What users have consistently said is that this pain is so great ¨C ¡®please create an in-design solution.