New Net properties and methods to generating these properties during virtual timing optimization for early planning of VT, area and layer congestion
Publication Date: 2014-Dec-01
The IP.com Prior Art Database
A method for net properties and methods to generating these properties during virtual timing (VT) optimization for early planning of VT, area and layer congestion is disclosed.
Page 01 of 3
New Net properties and methods to generating these properties during virtual timing
New Net properties and methods to generating these properties during virtual timing optimization for early planning of VT ,
area and layer congestion
area and layer congestion
Disclosed is a method for net properties and methods to generating these properties during virtual timing (VT) optimization for early planning of VT, area and layer congestion.
A set of new properties of a net is defined during VT environment (or design planning) to improve the accuracy of planning, and enable prediction of power, area and congestion. It also enables a better buffering strategy to handle multiple VT libraries, and slew/delay algorithm with the different area/runtime tradeoff and layers at the same time. Heuristic and Integrates Linear Programming can be used to solve the problem. Based on the initial result, this method can get better power usage.
Previously, for a net, only PLANE and WIRECODE are properties of a net, to reflect different delay values. However, no keywords are defined for VT keyword (VT is only a property of a gate), and no keywords are allowed to define which buffering algorithm one can choose.
Without a VT keyword for a net, existing methods of buffering with VT has problems, including overall design. For example, when there are multiple VT levels:
Previous method 1: Set a native VT level for the design, generally the lowest or highest VT, and then use that for the buffering. Can change the VT level later after buffering. Problems: If using highest VT as native VT, then all buffering solutions
will be bad, and needs lots of VT switching to low VT, but then the buffer spacing is
wrong. Waste runtime and buffer areas/powers. If use lowest VT as native, the buffer spacing is good, but then can not recover much. More leakage.
Previous method 2: A VT titration recipe that performs gradually VT recovery and tuning in the flow, enable multi-VT based buffering. However, lots of switching needs to happen, and buffering will run with a big buffer library and very slow. One can not predict the power earlier as well. Also, even an uplift percentage is specified and when designers insert more buffers, this percentage keeps changing, and one can not predict and plan the VT usage early in the flow
When there are multiple slew and delay algorithms:
Previous method 1: One just perform delay based buffering on all nets, which is slow and sometimes over-buffering.
Previous method 2: First do slew based buffering, and then slack based buffering. This is fast if slew based buffering solves all problems. But in latest technology needs to rip-up many buffering trees from slew based buffering, which may be slow and causes more congestion.
There is one previous method to perform layer assignment planning earlier, but can not extend to VT and buffering algorithm choice.
Two net set of net properties are defined, where each keyword will also impact the net