The DRV holds a higher priority to DRC at any given stage of VLSI PD flow.
DRV is basically the set of factors based on which the design is characterized. All the standard cell/ macro/ any physical only cell library characterization/ selection is done with DRV kept in mind.
Main DRV are max_transition, max_capacitance, max_fanout. These generally characterize the input speed/slew, output load, driving capacity, routing, congestion and many other factors which affect the quality of the design.
Stages checked: Every stage and have to be solved if exceeding the specified target.
How to fix DRV?
The best approach to fix DRV’s is through implementation tool. One should try to get fixed as many as possible at implementation time only so that there is minimum work to be done manually. However, since, all the modes are not visible at the implementation tool, there are still a few of DRVs left to be fixed manually.
Not only modes, there are DRV violations observed across corners. Since, setup optimization is carried only for WCS corner, the DRV violations of BCS corner are not taken care of by implementation tool.
A general approach to DRV fixing (as we approach tape-out to minimize the disturbance due to cell movement/sizing and/or addition) can include the following steps:
- Make a list of all the DRV violations and find out the unique nets for transition /capacitance violations. Also, prepare a list for unique driver and load for all these nets.
- Run a regression across all your timing modes and corners and find out the setup and hold slack across the unique driver nets.
- We are left with a list of unique nets and their driver/load pins. Try to fix the violations in the below preference order:
- First, make all the cells to lower Vt’s i.e if HVT, make them SVT or SVT to LVT provided the cells have sufficient hold slack across modes and corners. As we know that ON current through the transistor is proportional to (V-Vt) , hence by lowering the Vt , current increases which will give a better output transition. By swapping the Vt of driver cells, timing /congestion should NOT be impacted much, hence this is the easiest way.
- Utilize other flavors with same cell footprint/area Some libraries have a number of cells with same area/footprint specifically for the purpose of cell swapping for timing optimization close to tape-out. For instance, one library might have buffers of drive strength 2 and 4 implemented with same area. The library might also have different channel length flavors for same cell with same footprint. We can utilize these so as to take a step forward to DRV closure without any overhead on congestion due to cell movement/sizing. However, here also, we have to be sure that we are not introducing any hold violation due to the cell swap.
- Increase the Drive strength. Previous steps allow to minimize the number of DRVs without any impact on congestion close to tape-out. However, almost always we are left with a lot of DRVs that cannot be done away with cell swaps without disturbing the design. The first thing, then is to analyze for each of the DRVs is if the DRV can be done away with cell sizing. Since, current is directly proportional to the W/L ratio, hence by increasing the width, it will enhance the output transition and better output load driving capacity. Drive strength should increase in accordance with the violation. Choose proper drive strength of the driving cell so as to compensate the DRV violation. If the magnitude of DRV is small, choose to increase the drive strength by a small factor.
- Load Splitting (Also called BUS splitting). There are two possible scenarios for this:If the driver has only a single fanout, then the solution is pretty simple. We just have to add a repeater buffer at a strategic location on the net so as to distribute the net load between the driver and newly inserted buffer. The sizes of the current driver and newly inserted buffer have to be decided keeping in mind the load seen by each of these after the new connections will be made.On the other hand, if the driver of DRV net has more than one fanout, then the process is more complex. The solution to the problem requires timing and congestion feedbacks. We should add a buffer strategically after the driver so that the loads are equally distributed between these two cells.
- The most important thing to do after each step is to verify the timing slack and revert the ones resulting in timing degradation. Almost every time, fixing a DRV can result in a hold violation. If it happens, one should revert the fix for the same DRV and add buffers strategically placed so as to distribute the load as discussed later in this text. Doing so, there will be DRV fixed as well as the delay of the buffer will help fixing the hold violation. By repeating the multiple iterations of the above approach we can fix our DRV violations.
Special careabouts/heuristic approach to fix DRVs
If all the DRVs are not fixed, one can try the following steps. First thing to find is the main reason behind the occurring of DRV. There may be many reasons for this, some of the prominent reasons being congestion or timing impact due to fixing the DRV.
- If congestion is the reason, we should try to distribute the less timing critical logic to other regions. One should re-distribute the cells in other regions (with timing iterations) so that the congestion of particular area is gone and one can fix the DRVs in that area.
- If the timing is affected by the Vt swaps / drive strength / buffer insertion, we should back trace the timing path manually and find out a particular node where the slew can be improved and its positive effect is propagated to the culprit cell and improve the input transition of that cell. But one should remember to check the timing slack after every change at any stage.
One of the most important thing to be checked beforehand. One should verify the scaling of tran and cap limit across the timing corners. In some designs, the limits are not scaled properly in a particular PVT corner, hence there are huge no. of violations in that corner. For example – Due to improper scaling of tran and cap limit in best case we saw 10000 drv violations in best corner in comparison to 100 in worst corner.
Slack based Approach: This is the step which we can use in the last stage for the leftover DRV’s. For example, if we have left over DRVs in best case and also hold timing is more critical in this corner than worst.
So, If we can ensure that the hold slack of the timing path is more than the load pin (output load of the DRV net) cell delay, then even if the delay of that cell tends to zero still the hold timing of that path is met.
Hence if this condition is met, we can consider to waive off the DRVs which are not getting fixed.
Approach to fix DRV in PD
- Modify the Driver Cell in different ways.
- Upsize Cell to higher drive strength
- Swap Cell to lower channel length
- Swap Cell to Lower Vt
- Fixing it physically in implementation tool
- Deploy similar approach (as applied for driver cell) for the logic in driver fan-in cone
- Load Splitting (Adding Buffers)
- Try to de-congest the congested area by the movement of spare cells / less timing critical logic