The waiver mechanism provides the ability to waive CDC, DRC, and
Methodology violations. After a violation is waived, it is not reported anymore by the
report_cdc, report_drc, and report_methodology
commands. Waived DRCs are also filtered out from the mandatory DRCs which are run as a
prerequisite for the implementation commands such as opt_design, place_design, phys_opt_design, route_design or write_bitstream.
Waivers are XDC compatible and can be imported through the commands,
read_xdc or source. They can be included in any XDC file or Tcl script, in Project or
Non-Project modes. They can be created from the top-level or scoped to a hierarchical
module. After waivers are added to the design, they are automatically saved inside the
checkpoint and restored when the checkpoint is reloaded. The waivers can be written out
with the commands, write_xdc and write_waivers.
Waivers provide tracking capabilities. Vivado tools record the user who creates the waivers, the date and time of creation, as well as a short description. This information is important for tracking purposes. It is recommended that all the waivers applied to the design are reviewed and verified to ensure that they are valid.
Waivers are first class objects that can be created, queried, reported
on, and deleted. Waivers reference other first class objects returned by the Vivado
get_* commands, such as pins, cells, nets, Pblocks,
and sites. These objects must exist in the design prior to creating the waivers. Design
objects that do not exist at the time of waiver creation are not covered by the
waivers.
The waiver mechanism supports replication and deletion of netlist
objects. When an object involved in a waiver is replicated, the replicated object is
automatically added to the waiver. Similarly, when an object is deleted, any reference
to it is automatically removed from the waivers. When the deleted object results in a
waiver referencing an empty list of objects, the waiver is deleted from the in-memory
design and is not saved in the subsequent checkpoints. The same mechanism applies to
timing constraints and clock objects. When a clock gets deleted through logic
optimization or by removing the timing constraints (reset_timing), any waiver referencing the clock object gets deleted and is
not saved in the subsequent checkpoints.
rename_net, rename_cell,
rename_port, and rename_pin do not rename the
design elements inside the waiver. If a waiver refers to a netlist element renamed by
one of these commands, the waiver becomes invalid because it still refers to the design
element's original name.