The right approach to get pins/cells in deep hierarchy design.

Question

I always have hard time to get a pin or a cell in deep hierarchy. E.g. I have module "A", I instatiaed it as "a_inst", inside it has a submodule B, inside B I has a submodule C, I also instantiated them as "b_inst", "c_inst". Then I try to get a pin from C for my constrain like "get_pins a_inst/b_inst/c_inst/D". But in some cases, I can't get it.
This problem is especially worse when I try to get pins from a Xilinx IP. Somethimes, I try to follow the hierarchy path but Vivado always report there is no that pin or cell. 
I just wonder what is the right approach to get pins/cells in deep hierarchy module? Is there any standard approach that will work for all (at least most) cases?
Thanks very much.

Answer 1

The "best" way is to do what you described, but do it right... If the hierarchy isn't flattened, then the full hierarchical path to a pin is consistently named as a_inst/b_inst/c_inst/D.
In Vivado, it is important to note, though, that the pin's name is not a_inst/b_inst/c_inst/D. Vivado is aware of the hierarchy, and the hierarchy is real. The pin name is actually "c_inst/D", inside the hierarchical object b_inst, which is inside the hierarchical object a_inst (assuming hierarchy hasn't been flattened). So the / means two separate things; the final / is a character - part of the name c_inst/D. The other / are hierarchy separations, which are not characters.
This is important to understand for wildcarding... This pin will NOT be captured by [get_pins *c_inst/d], since the slashes before c_inst are not characters. It would be matched by [get_pins */*/c_inst/d], since that is saying "look for c_inst/d two levels of hierarchy down".  However, since the last / is a character [get_cells a_inst/b_inst/c_in*d] would match it.
You could also use [get_pins -hier c_inst/d]; this means look for a net named c_inst/d anwhere in the hierarchy. But this is sloppy, since there may be other things named c_inst/d somewhere else in the hierarchy. You cannot, however, mix the -hier option with a partial hierarchical path; for example [get_nets -hier b_inst/c_inst/d] will not work.
It is important to note that this is very different from how UCF worked. In UCF, the hierachy separator was just a character, and you could use PIN *c_inst/D to match the pin anywhere in the hierarchy, since the * would match "a_inst/b_inst/". You can (but should try to avoid) mimic this behaviour by using the -filter option 
[get_pins -filter {NAME =~ *c_inst/D}]
will match your pin in a UCF like style - but, this should be avoided.
Note: If hierarchy is flattened, the rules change. If hierarchy is rebuilt, then this should work, but I don't trust it (which is why I always use flatten_hierarchy set to none).
As for IP, you shouldn't reach down into Xilinx IP. From version to version of the core, the structure can change - so the hierarchical path could change. I am not sure why you would need to do this; you should restrict yourself to using the pins of the IP (and use things like all_fanin and all_fanout if you need to get to the startpoint/endpoint of static timing paths that start/end in the IP).
Avrum