Based on the violation, the designer should verify whether the path is intended to carry functional information during the indicated power state. If it is not function in the given power state, then no further action is needed. On the other hand, if the path was functional, then the indicated buffer/inverter/combo needs to be powered on and the supply connection to the combo needs to be fixed. Identifying these issues through simulation is time-consuming but with VC LP, you can now catch these issues early in your design cycle and save time in simulation.
Although the main motivation of VC UPF is an early cleanup of UPF, it can also be used for UPF management for an SoC. Complex SoCs have UPF files for IP blocks from different vendors/groups, which often results in late UPF modifications and delayed schedules and re-verification. To avoid this, CAD teams may enforce some guideware rules to comply with UPF deliverables for IP vendors to enable smooth SoC Integration. VC UPF can help perform such guideware UPF construct checks using disallow_* commands or allow_* commands.
Similarly, during SoC integration, you might not want a particular IP-level UPF TCL variable to be overwritten from the top. A standard UPF with design checking tool will never recognize this as a problem. But with VC UPF, you can specify the list of such protected variables and quickly find out if any of them have been overridden from a top-level UPF. You can also verify the compatibility of the UPF version of an IP with respect to the SoC UPF. Depending on the user guidance regarding which UPF version combinations are allowed and disallowed, VC UPF can perform IP versus SoC consistency checks. Note that otherwise, VC LP is UPF version-agnostic and “upf_version” has no consequence.