Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Configurable IP interface at SOC level for Power-Performance optimization / Power savings

IP.com Disclosure Number: IPCOM000225685D
Publication Date: 2013-Feb-26
Document File: 5 page(s) / 62K

Publishing Venue

The IP.com Prior Art Database

Abstract

Memory IPs are typically delivered by either a in-house specialized group or a specialist IP provider company with a pre agreed spec. In many incidents, small refinements or updates are required to the IP specification when integrated to a SOC environment. As of today very less options are available for in-place incremental update to hardened IP behavior. In this invention literature, a set of techniques are proposed to have IP level knobs to have SOC level configurability and also on the fly characterization mechanism to support this dynamic behavior.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 42% of the total text.

Page 01 of 5

Configurable IP interface at SOC level for Power -Performance optimization / Power savings

Register files are designed as Intellectual Property (IP) and are reused in different parent blocks as embedded IP. In some cases one register file is instantiated in many functional units. As different parents units have different interfacing scenarios in terms of timing, power, congestion etc; small to medium range customization are often necessary to the baseline IP with a particular hardening. In typical engagement model between IP design companies and OEM which uses these IP designs, stringent contract is in place in terms of design spec at beginning of IP design. It involves significant monetary and time-cum-logistical overhead to place a request for IP modification once design interface behavior is stable just few weeks before the tape-out between the IP and SOC design teams across different companies. Even if, it is possible to get support from IP Design Company with updated requirements, getting the new IP re-validated inside SOC is another challenge.

To address this issue, a configurable IP interface is proposed as a part of original IP delivered which can be adapted to parent block requirement in terms of performance-power customization (leading to power savings) without requiring to update the IP exhaustively with the help of IP design house. This is implemented by a set of flexible and configurable "knobs" in IP-SOC interface which can be tweaked by OEM design team with minimal interaction with remote IP design team and thus saving major financial, time and design resource overhead. Also, an illustrative process is outlined to write new timing / power view generation (LIB) without requiring going through full-blown characterization effort for actual customization performed. The proposed method offers reasonable power savings without impacting design TAT.

The current register file design methodology doesn't address tunable interface for timing or

power optimization.

In a complex multi-million gate designs, many functional units require register files for various operations. In some cases one register file is instantiated in many functional units across different designs. Interface drivers and receivers can not be optimized or fine-tuned from power and timing point of view in current register file design approach as different parent units have different timing and power requirements and the current methodology can't meet all these criteria for all the parent units. In many cases critical paths related to register file cannot be fixed at

parent unit level and the timing paths need to be fixed inside the register file. As the same register file is instantiated in different parent units, upsizing or downsizing interface drivers may result in timing violations in some different parent block. So to mitigate timing violations, they have to design a new register file. This process becomes very tedious and cumbersome and also might not b...