cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
LichengGuo-UCLA
Visitor
Visitor
583 Views
Registered: ‎02-19-2021

Manipulate Global Clock Routing

Jump to solution

Hi everyone,

 

I'm trying to hack the routing of clock nets.

I want to place & route a subset of my design in isolation, which is floorplanned in a pblock of, for example, 4 clock regions. 

Meanwhile, the location of the global clock buffer is known.

Then, is it possible that I manipulate the routing of the clock net such that the entry point to my pblock is fixed (for example, to a certain switch box or something else)?

 

Or, in general, can I add the constraint to the router that a net must go through a certain point?

 

Thanks a lot!

 

Best,

Licheng

0 Kudos
1 Solution

Accepted Solutions
avrumw
Expert
Expert
348 Views
Registered: ‎01-23-2009

Maybe HD.CLK_SRC could help, but I don't know what it does exactly.

You need to tell us what device you are using. What you are describing is (at least sort of) possible with the 7 series, but not with UltraScale/UltraScale+ (and also not with any family earlier than the 7 series, since ISE doesn't have this capability).

Vivado has a concept of "out-of-context" (OOC) synthesis and implementation. OOC synthesis is used throughout the design flow in all device families - all IP is synthesized OOC (unless you change the default), and you can even choose a module for OOC synthesis.

OOC implementation was also originally supported in the 7 series. The mechanism for doing it was documented in UG905 and UG946, and "mostly" works (there were still some kinks in the flow to work out). However (largely because the clock distribution mechanism is so different), it would have required significant rework to use in UltraScale/UltraScale+, and therefore is not supported for these devices.

If you are using the 7 series, you can give it a try. But, beware...

  • It only works in non-project mode, so you will have to learn that flow
  • It still has some "kinks" (mostly around integrating the constraints from the OOC run into the top level design - these can be worked around by having different constraint files)
  • It isn't really supported by Xilinx anymore
    • Any problems you run into will not be fixed
  • It was never commonly used so you will find very few people who can help you with it

But, back to your original question. In the 7 series, the clock routing is mostly fixed - a single clock buffer drives one and only one clock distribution tree. Simply specifying which clock buffer is used for a net (using the HD.CLK_SRC) is mostly sufficient to tell the tool everything it knows about the clock tree. This is true (as @jemk said) of clocks driven by the BUFIO/BUFR and BUFH. However for clocks driven by a BUFG, there is (I am pretty sure) still one unknown - as the global clock enters a region, it does so through one of the 12 BUFHs in the clock region (the 12 horizontal spines of the global clock network for that clock region) - it can choose any one of the 12. UG905 states 

If an OOC port is driven by a clock net in the top-level, the clock
net will not be routed during the OOC implementation, and timing estimations will be
used to determine clock delays/skew. The HD.CLK_SRC constraint should be used to
help improve timing estimations in this case.

So (I suspect, but am not 100% certain), that if you use a BUFH, then the clocking will be 100% fixed. But a "named" (manually instantiated) BUFH can only be used in one clock region. If you use a BUFG, then the routing is not 100% fixed - it still has the ability to use any one of the 12 BUFHs (which remain unnamed for a global clock, and hence can enter multiple regions). However, the timing of the 12 different horizontal spines within a region are almost identical (they probably differ by a couple of picoseconds) - so from the point of view of timing, the results will be virtually identical regardless of which one it ends up using when the OOC module is instantiated in a different design.

Avrum

View solution in original post

6 Replies
syedz
Moderator
Moderator
502 Views
Registered: ‎01-16-2013

@LichengGuo-UCLA 

 

Vivado has an option of manual routing where user will have more control on net connection. complete Lab in Chapter 3 in below tutorial:

https://www.xilinx.com/support/documentation/sw_manuals/xilinx2020_2/ug986-vivado-tutorial-implementation.pdf 

 

Also check page 147 at: https://www.xilinx.com/support/documentation/sw_manuals/xilinx2020_2/ug904-vivado-implementation.pdf#page=147   

 

--Syed

---------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.

Did you check our new quick reference timing closure guide (UG1292)?
---------------------------------------------------------------------------------------------
0 Kudos
LichengGuo-UCLA
Visitor
Visitor
468 Views
Registered: ‎02-19-2021

Hi @syedz ,

Thanks for your response!

However, I'm looking for a constraint-based solution. I cannot do the routing manually. Instead, I hope to give the router a constraint that the net must pass through a certain node. Is this possible?

Thanks,

Licheng

0 Kudos
syedz
Moderator
Moderator
404 Views
Registered: ‎01-16-2013

@LichengGuo-UCLA 

 

I don't think it is possible. You need to use the FIXED_ROUTE constraint to control the routing of the specific net. The details can be obtained from find_routing_path command. 

 

--Syed

---------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.

Did you check our new quick reference timing closure guide (UG1292)?
---------------------------------------------------------------------------------------------
0 Kudos
jemk
Visitor
Visitor
374 Views
Registered: ‎02-21-2021

Hi Licheng,

if your design-subset uses OOC (Out-of-Context / Hierarchical Design) you could look at the HD.PARTPIN_LOCS or HD.PARTPIN_RANGE constraints. These constraints define a specific interconnect tile to use as 'port' to the sub-design. See UG905 for more information.

These constraints are however not applicable for dedicated routes like clocks. If you use them for clocks, you would force local clock routing, which is most likely not what you want. I don't think it would make any sense for clocks either, since they always enter the clock region the same way as far as I know. Maybe HD.CLK_SRC could help, but I don't know what it does exactly.

At least on 7 Series the BUFG/BUFH combination used defines the entry-point to a clock-tree of the region as far as I know. So maybe you want to constraint the BUFH placement?

avrumw
Expert
Expert
349 Views
Registered: ‎01-23-2009

Maybe HD.CLK_SRC could help, but I don't know what it does exactly.

You need to tell us what device you are using. What you are describing is (at least sort of) possible with the 7 series, but not with UltraScale/UltraScale+ (and also not with any family earlier than the 7 series, since ISE doesn't have this capability).

Vivado has a concept of "out-of-context" (OOC) synthesis and implementation. OOC synthesis is used throughout the design flow in all device families - all IP is synthesized OOC (unless you change the default), and you can even choose a module for OOC synthesis.

OOC implementation was also originally supported in the 7 series. The mechanism for doing it was documented in UG905 and UG946, and "mostly" works (there were still some kinks in the flow to work out). However (largely because the clock distribution mechanism is so different), it would have required significant rework to use in UltraScale/UltraScale+, and therefore is not supported for these devices.

If you are using the 7 series, you can give it a try. But, beware...

  • It only works in non-project mode, so you will have to learn that flow
  • It still has some "kinks" (mostly around integrating the constraints from the OOC run into the top level design - these can be worked around by having different constraint files)
  • It isn't really supported by Xilinx anymore
    • Any problems you run into will not be fixed
  • It was never commonly used so you will find very few people who can help you with it

But, back to your original question. In the 7 series, the clock routing is mostly fixed - a single clock buffer drives one and only one clock distribution tree. Simply specifying which clock buffer is used for a net (using the HD.CLK_SRC) is mostly sufficient to tell the tool everything it knows about the clock tree. This is true (as @jemk said) of clocks driven by the BUFIO/BUFR and BUFH. However for clocks driven by a BUFG, there is (I am pretty sure) still one unknown - as the global clock enters a region, it does so through one of the 12 BUFHs in the clock region (the 12 horizontal spines of the global clock network for that clock region) - it can choose any one of the 12. UG905 states 

If an OOC port is driven by a clock net in the top-level, the clock
net will not be routed during the OOC implementation, and timing estimations will be
used to determine clock delays/skew. The HD.CLK_SRC constraint should be used to
help improve timing estimations in this case.

So (I suspect, but am not 100% certain), that if you use a BUFH, then the clocking will be 100% fixed. But a "named" (manually instantiated) BUFH can only be used in one clock region. If you use a BUFG, then the routing is not 100% fixed - it still has the ability to use any one of the 12 BUFHs (which remain unnamed for a global clock, and hence can enter multiple regions). However, the timing of the 12 different horizontal spines within a region are almost identical (they probably differ by a couple of picoseconds) - so from the point of view of timing, the results will be virtually identical regardless of which one it ends up using when the OOC module is instantiated in a different design.

Avrum

View solution in original post

LichengGuo-UCLA
Visitor
Visitor
199 Views
Registered: ‎02-19-2021

Thanks a lot for your detailed explanation!

0 Kudos