XDC Scoping Mechanism - 2023.2 English

Vivado Design Suite User Guide: Using Constraints (UG903)

Document ID
Release Date
2023.2 English

Except for ports, constraints scoping relies on the current_instance mechanism, which is part of the Synopsys Design Constraints (SDC) standard. When setting the scope to a lower level of the design hierarchy with the current_instance command, only the objects included in that level or below can be returned by the object query commands.

The only exceptions are with timing clock objects and netlist ports:

  • Timing clocks are defined by create_clock or create_generated_clock. They are visible throughout the design regardless of the current instance setting. The get_clocks command can query clocks that are not present in the current instance, or that propagate beyond the current instance. AMD does not recommend defining timing exceptions on clocks when creating scoped constraints unless they are fully contained in the current instance. For a clock to be available for reference in an XDC, the clock must have already been defined. This might require changing the order of the XDC files in the project.
  • Top-level ports are returned by the get_ports command when the scope is set to a lower level instance with the current_instance command. But when reading an XDC file scoped to a lower-level instance with the read_xdc -ref/-cells command or when loading a design after setting the SCOPED_TO_REF/SCOPED_TO_CELLS file properties, the get_ports command behavior is different:
    • The port names to be used with get_ports are the port names of the scoped instance interface, not the top-level port names.
    • If a scoped instance port is directly connected to a top-level port through the hierarchy of the design, the top-level port is returned by the get_ports command and the constraint is applied to the top-level port.
    • If there is any leaf cell, including IO and clock buffers, between the scoped instance port and the top-level ports, the get_ports command becomes a get_pins command and returns the hierarchical scoped instance pin.

The XDC scoping mechanism is used for reading all Vivado Design Suite IP constraint files. Figure 1, and Figure 2, show the two examples of how the get_ports commands are treated when reading in the IP-level XDC using this methodology.

In Figure 1, the I/O buffer is instantiated inside the IP and the IP interface pin is directly connected to a top-level port (regardless of the hierarchy). When the XDC for the IP is applied, the argument of the get_ports replaced with the top-level port.

This enables setting physical properties such as a LOC or IOSTANDARD at the IP level and having them be placed on the top-level port where they need to be. This is accomplished without the IP knowing the name of the top-level ports of the design. command is automatically replaced with the top-level port.

Figure 1. IP Port Migration to the Corresponding Top-Level Port

The following figure, the IP does not contain an I/O buffer, so the synthesis engine infers one between the IP interface pin and the top-level port. Consequently, the get_ports is converted to a get_pins of the IP interface pin (for example, a hierarchical pin) when the XDC is applied.

Figure 2. IP Port Migration to a Hierarchical Pin

This capability is very useful for creating constraints on the interface of an IP or a sub-level module without knowing the names of the top-level design.

If the scoped XDC file includes constraints that can only be applied to top-level ports but the IP instance is not directly connected to top-level ports, the Vivado Design Suite XDC reader returns errors. For example, the following constraints can only be applied to top-level ports, and not hierarchical pins of your design:

  • set_input_delay/set_output_delay
  • set_property IOSTANDARD