AR# 62136

Vivado Constraints - Understanding how hierarchy separator "/" works with wildcard * in XDC and UCF


In ISE, I can use the command below in the UCF  to query a register "a_inst/b_inst/c_inst/data_out_reg_r" in the design:

INST "*/data_out_reg_r" TNM = "group1";

However, when I use the same pattern to query the same register in Vivado (design hierarchy is preserved), I get the following:

%get_cells */data_out_reg_r
WARNING: [Vivado 12-180] No cells matched '*/data_out_reg_r'.
%get_cells -hier */data_out_reg_r
WARNING: [Vivado 12-180] No cells matched '*/data_out_reg_r'.

This register can be found in the design by querying its full name:

%get_cells a_inst/b_inst/c_inst/data_out_reg_r

What is the issue with the "get_cells" command in Vivado?


The hierarchy separator "/" in an objects name works differently in XDC and UCF. 

In Vivado, the wildcard character * does not resolve across hierarchies.
When querying an object in Vivado, the "/" characters in the objects hierarchical name that represent preserved hierarchy boundaries(1) cannot be replaced by a wildcard *.
In UCF, the hierarchy separator "/" in an objects hierarchical name is just part of name and can be replaced by a wildcard *.
This is just like the scenario in Vivado wherein all of the hierarchies are flattened and all design objects are in the same level.

In the example above, "get_cells */data_out_reg_r" searches cells named "data_out_reg_r"(2) in the first level submodule under top level.

"get_cells -hier */data_out_reg_r"  searches cells named "*/data_out_reg_r" in all levels of hierarchies.

So these two commands do not return any object.

To return the correct object, one of the following commands should be used.

get_cells */*/*/data_out_reg_r
get_cells -hier data_out_reg_r
get_cells -hier -filter {NAME =~ */data_out_reg_r }
get_cells -hier -regexp .*data_out_reg_r

To search the object in a similar way in UCF, you can use the NAME property of the object.

get_cells -hier -filter {NAME =~ */data_out_reg_r }

The hierarchy separator "/" in the NAME property is an ordinary character, just like in UCF.

One thing to note is that "/" in a pins hierarchical name in Vivado means two separate things.

For example, for a pin "a_inst/b_inst/c_inst/data_out_reg_r/Q", the last "/" is part of the pin name "data_out_reg_r/Q".

The other "/" are hierarchy separators.

Although the last "/" is not a hierarchy separator, it still cannot be replaced by wildcard *.

So, this pin can be returned by the following commands:
get_pins */*/*/data_out_reg_r/Q
get_pins -hier data_out_reg_r/Q
get_pins -hier data_out_reg_r/*
get_pins -hier */Q

The below commands does not capture "a_inst/b_inst/c_inst/data_out_reg_r/Q":

%get_pins *Q
WARNING: [Vivado 12-508] No pins matched '*Q'.
%get_pins a_inst/b_inst/c_inst/data_out_reg_r*
WARNING: [Vivado 12-508] No pins matched 'a_inst/b_inst/c_inst/data_out_reg_r*'.
%get_pins -hier Q
WARNING: [Vivado 12-508] No pins matched 'Q'.
%get_pins a_inst/b_inst/c_inst/*
---this command returns the hierarchical pins on the c_inst boundary (e.g. a_inst/b_inst/c_inst/I1) but not any pins inside this hierarchy.

(1) Hierarchy boundaries can be preserved by the following methods:
a. -flatten_hierarchy = none or rebuilt
b. "keep_hierarchy = true" on the module/entity level
c. "dont_touch = true" on the module/entity level
(2) Object's name and hierarchical name: "data_out_reg_r" is the object's name and "a_inst/b_inst/c_inst/data_out_reg_r" is the object's hierarchical name.
However, when design hierarchy is flattened, the object's name becomes "a_inst/b_inst/c_inst/data_out_reg_r" as all objects are in the same level.

AR# 62136
Date 11/25/2014
Status Active
Type General Article