How do you swap a cell to a faster drive strength with size_cell during a PrimeTime ECO?

Short Answer

When a path fails setup because one cell along it is too slow, replacing that cell with a stronger drive-strength version of the same function is often the cheapest fix, since it changes delay without touching placement or routing. size_cell (PT) does exactly this inside an ECO session, swapping a named instance to a different library cell while PrimeTime checks the new cell fits the same footprint and pin function.

Technical Explanation

• size_cell U234 BUFX4 (PT) replaces the cell at instance U234 with the BUFX4 library cell, provided the two cells share the same logical function and pin order.
• PrimeTime re-times the affected paths immediately after the swap so the designer can see the slack change before deciding whether to keep it.
• A stronger drive strength typically reduces cell delay on a loaded net but adds a small amount of extra capacitance seen by the driving stage before it, so the fix must be checked both ways.
• size_cell (PT) operates only on the timing model inside PrimeTime; the actual physical placement and routing are unchanged until a downstream physical tool re-implements the ECO.
• Because the swap is a same-footprint substitution, it usually avoids re-running full placement, which is why it is preferred over more disruptive fixes when a suitable stronger cell exists in the library.
• After sizing, the fix still needs write_changes (PT) to hand the netlist edit to the physical design tool for legalization and re-extraction, since PrimeTime's own timing model does not update parasitics on its own.

Follow-up Question & Model Response

Why might size_cell fail to fix a hold violation even when it clearly improves the setup slack on the same path?

Candidate Model Response: A stronger drive strength usually speeds up a path by reducing cell delay, which helps setup by leaving more time before the next clock edge, but that same speed-up hurts hold by making the data arrive even sooner after the launch edge. If the path already had marginal hold slack, sizing up the cell for setup can push it into a hold violation instead. This is why an ECO session re-checks both -delay_type max and -delay_type min (PT) after any sizing change, rather than only confirming the check the fix was aimed at. A path with both checks tight sometimes needs a different fix, such as buffering elsewhere, instead of resizing the shared cell.