How does LVF (Liberty Variation Format) distance-based derating let a library model POCV variation without needing a separate AOCV side file?

Short Answer

LVF lets a cell's own Liberty timing arcs carry distance-based derating factors directly in the library, alongside the ordinary POCV sigma tables, so the tool can look up a derate that depends on how far apart two timing points are in the clock network without loading a separate AOCV side file at all. Because the data lives in the library and can vary with slew and load like any other LVF table, it is functionally equivalent to a side file's distance-based table, but automatically tied to the cell characterization it came from.

Technical Explanation

• POCV normally uses LVF's ocv_std_dev_cell_rise and similar tables to model the standard deviation of a delay arc's variation, letting the tool compute a per-arc sigma instead of a single flat derate percentage.
• LVF distance-based derating extends this by letting the library provide the same kind of standard-deviation data as a function of distance between two points in the design, not just as a function of slew and load.
• This distance-dependent variation data is arc-dependent and can be modeled for delay timing arcs as well as setup and hold constraints — data of this shape cannot be represented in a side file, only directly in an LVF library.
• The unit of POCV LVF distance data is the library's own time unit, so the tool applies it consistently with every other timing number already coming from the same characterization, without a unit-conversion step a hand-built side file would need.
• Functionally, LVF distance-based derating produces the same kind of result a hand-authored AOCV side file would — less pessimism for cells or paths that are physically close together, more for cells that are far apart — but the data originates from the same silicon characterization as the rest of the library instead of a separately-maintained file.
• Because the data lives inside the library, updating the technology's process characterization automatically updates the distance-based derating along with every other timing number, whereas a side file has to be regenerated and requalified on its own schedule.
• What breaks: mixing an old AOCV side file with a newer library that also carries LVF distance-based data risks double-applying distance-based derating from two independent sources, unless the flow explicitly chooses one source and disables the other.

Follow-up Question & Model Response

"If a library now provides LVF distance-based data, is there ever a reason to still keep the old AOCV side file active alongside it?"

Candidate Model Response: Generally no, once the library's own distance-based LVF data is validated to cover the same cells and arcs the side file used to cover — carrying both is redundant and risks the double-derating described above. A side file might still earn a temporary place if it covers a specific structure the LVF characterization does not yet model, such as a newly added custom cell not yet re-characterized, but that should be a deliberate, scoped exception with the LVF data disabled for exactly those cells, not a blanket "keep both for safety" policy. Confirming coverage with report_timing_derate (PT) before deciding is the safest way to know exactly which arcs each source is touching.