UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Explorer
Explorer
1,285 Views
Registered: ‎04-12-2012

Annotation of XDC names to custom Top Level port names

Hello,

 

I have a rather large design with complex Xilinx IPs such as PCIe, DDR4 and DMA implemented.

Using the report_compile_order -constraints command shows that the design has 34 XDC files.

 

The ports of my top level hierarchy are given custom names.

Do I now have to go through all of the 34 XDC files and change the names so that they match my custom top level names ?

 

0 Kudos
5 Replies
Scholar hbucher
Scholar
1,268 Views
Registered: ‎03-22-2016

Re: Annotation of XDC names to custom Top Level port names

@shaikon why don't you just change your top level names?

vitorian.com --- We do this for fun. Always give kudos. Accept as solution if your question was answered.
I will not answer to personal messages - use the forums instead.
0 Kudos
Historian
Historian
1,260 Views
Registered: ‎01-23-2009

Re: Annotation of XDC names to custom Top Level port names

Do I now have to go through all of the 34 XDC files and change the names so that they match my custom top level names ?

 

No!

 

All the IP come with "scoped constraints". The constraints are written from the point of view of the IP - as if they were the top level of the design.

 

When an module with scoped constraints is included in a design, the tool propagates constraints connected to the ports of the IP to the ports of the design as long as there is a direct connection (with only hierarchy, nets and/or an IBUF/OBUF between the IP ports and the top design ports).

 

All of this stuff is carefully designed to be seamless - if the IP were created properly, then all the XDC files should be used as is. In fact, it is not recommended (or even easy) to change anything in the IP generated XDC files.

 

Avrum

Scholar hbucher
Scholar
1,255 Views
Registered: ‎03-22-2016

Re: Annotation of XDC names to custom Top Level port names

@avrumw I thought these XDC were HIS files....

vitorian.com --- We do this for fun. Always give kudos. Accept as solution if your question was answered.
I will not answer to personal messages - use the forums instead.
0 Kudos
Explorer
Explorer
1,228 Views
Registered: ‎04-12-2012

Re: Annotation of XDC names to custom Top Level port names

Good news!
Although this somewhat deviates from SDC rules...
I know that with SDC everything that follows "get ports" - MUST be a physical device pin.
Do you agree ?
0 Kudos
Highlighted
Historian
Historian
1,207 Views
Registered: ‎01-23-2009

Re: Annotation of XDC names to custom Top Level port names

Although this somewhat deviates from SDC rules...

 

So, it doesn't really...

 

The SDC rules for ports vs. pins have always been consistent:

  - a pin is a connection point on an instance

  - a port is a connection point of a module

 

The difference between them is based on your point of view with respect to hierarchy. If you are at a level of hierarchy and looking at an instance instantiated inside that level of hierarchy, then the connection points of that instance are pin objects. If you are at a level of hierarchy and are looking at the things that connect to the "outside world" of that level of hierarchy, then those are port objects.

 

So it all depends on where in the hierarchy your point of view is.

 

In the original version of Vivado, the only available point of view was the top level of your design - you were "in" the top level of the design. Therefore, the only thing "outside" that were the ports of your top level module; the things that would be assigned to PACKAGE_PINS and then become pins of the FPGA. So the early documentation and training equated the "port objects" with the ports of your top level design.

 

As more complex flows were introduced, including scoped constraints and out-of-context synthesis and implementation, there became more places where the "point of view" was inside a sub-module of the design (the module that has the scoped constraints or the module that is synthesized/implemented out-of-context). When you are doing these tasks, you are "inside" those modules, and hence the ports of those modules are port objects.

 

So the definition was always clear, but early on Vivado simplified it due to the fact that the point of view was always the top level of the design...

 

Avrum