Except for ports, constraints scoping relies on the
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_generated_clock. They are visible throughout the design regardless of the current instance setting. The
get_clockscommand can query clocks that are not present in the current instance, or that propagate beyond the current instance. Xilinx 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_portscommand when the scope is set to a lower level instance with the
current_instancecommand. But when reading an XDC file scoped to a lower-level instance with the
-cellscommand or when loading a design after setting the SCOPED_TO_REF/SCOPED_TO_CELLS file properties, the
get_portscommand behavior is different:
- The port names to be used with
get_portsare 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_portscommand 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_portscommand becomes a
get_pinscommand and returns the hierarchical scoped instance pin.
- The port names to be used with
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
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.
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.
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 will return errors. For example, the following constraints can only be applied to top-level ports, and not hierarchical pins of your design: