The waiver for a specific DRC and Methodology violation is unique. A violation is an aggregation of strings and/or various device and design objects, such as pins, cells, nets, Pblocks, sites, and tiles. Some DRC, Methodology, and CDC violations could just have one of those elements while others can have multiple elements. The order and content of all the strings and objects is important and must be preserved. When a waiver is created with the arguments specified in the wrong order, the waiver either never waives any violation or it could waive the wrong violation.
Before manually creating a waiver for a specific violation (for example, TIMING-14#1) or a class of violations (for example, TIMING-14), it is recommended to first create an example waiver from the GUI or from a violation object. Use the write_waiver or write_xdc commands to export the waiver. You can then relate the content of the waiver created by the system to the original violation and understand the order of strings and objects that need to be specified. You can extrapolate this information for other waivers with the same CDC, DRC, or Methodology ID (for example, TIMING-14).
There are two mandatory arguments for any CDC, DRC, and Methodology waiver:
- ID: The violation or check ID that is waived. The id is specified with
-id. For example, CDC-1, TIMING-14, or PDRC-1569. Only one id can be specified at a time. - Description: Support multi-lines string. Must provide enough information to be reviewed by the team. The description is specified with
-description.
You can use the command line option -type to force the waiver type, CDC, DRC, or Methodology. A waiver created with the wrong type does not match any violation. For instance, to waive a CDC violation, the waiver type must be set as CDC. When the type is not specified, the system infers the type from the check id specified with -id. The user name can be overridden using the -user option. By default, the system uses the user id running Vivado Design Suite.
The waivers support the XDC scoping mechanism and the current instance can be changed before creating a waiver. In this case, the current instance information is saved along with the waiver and restored when the waivers are exported as XDC. When scoped waivers are created, it is recommended to use the command line option -scope to ensure that the wildcards are scoped.
A waiver is considered by the system as a duplicate if another waiver already exists with all the exact same arguments. To reduce the memory footprint and runtime, duplicate waivers are not saved and result in a message similar to the following:
WARNING: [Vivado_Tcl 4-935] Waiver ID 'CDC-13' is a duplicate and will not be added
again.Some DRC/Methodology checks such as RTSAT-* are read-only and cannot be waived. The list of DRC/Methodology checks that can be waived can be filtered by checking the property IS_READ_ONLY on the DRC/Methodology check objects. For example:
set allWaivableChecks [get_drc_checks -filter {!IS_READ_ONLY}]
set allWaivableChecks [get_methodology_checks -filter {!IS_READ_ONLY}]The following message is an example of an error message generated by create_waiver when waiving a read-only check such as DRC RTSTAT-12:
ERROR: [Vivado_Tcl 4-934] Waiver ID 'RTSTAT-12' is READONLY and may not be waived.