cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
byusean
Observer
Observer
3,275 Views
Registered: ‎01-25-2017

BUFG in OOC module cannot be routed from

Jump to solution

I have a module that is composed of 402 nets and 354 cells, three of which are a BUFG and two BSCANE2s. I am using the scripts from UG946 and UG905 to synthesize and implement this module. I run into two problems during this:

 

1. When I run oocSynth and oocImpl with the xdc lines below:

create_pblock pblock_ahbjtag_0
add_cells_to_pblock [get_pblocks pblock_ahbjtag_0] -top
resize_pblock [get_pblocks pblock_ahbjtag_0] -add {SLICE_X12Y66:SLICE_X53Y104}
set_property CONTAIN_ROUTING 1 [get_pblocks pblock_ahbjtag_0]
set_property EXCLUDE_PLACEMENT 1 [get_pblocks pblock_ahbjtag_0]
set_property HD.PARTITION true [current_design]
set_property HD.PARTPIN_RANGE {SLICE_X12Y66:SLICE_X53Y104} [get_ports]

I get the following error:

 

	HDOOC-4#1: 3 Cells are found with no placement constraints. Failure to control placement of logic with either a Pblock or a LOC constraint may result in placement conflicts if the out-of-context implementation results are reused in a top-level design. The following is a list of cells (up to the first 15) with no placement constraints:
 	gtckbuf.tckbuf/xil.xil0/buf2.buf (BUFG)
	tap0/ac7v.u0/u0 (BSCANE2)
	tap0/ac7v.u0/u1 (BSCANE2)
gtckbuf.tckbuf/xil.xil0/buf2.buf, tap0/ac7v.u0/u0, tap0/ac7v.u0/u1

 

2. To fix this I try to add the sites that those cells are on, by using the following xdc lines:

create_pblock pblock_ahbjtag_0
add_cells_to_pblock [get_pblocks pblock_ahbjtag_0] -top
resize_pblock [get_pblocks pblock_ahbjtag_0] -add {SLICE_X12Y66:SLICE_X53Y104 BSCAN_X0Y0:BSCAN_X0Y1 BUFGCTRL_X0Y16:BUFGCTRL_X0Y16}
set_property CONTAIN_ROUTING 1 [get_pblocks pblock_ahbjtag_0]
set_property EXCLUDE_PLACEMENT 1 [get_pblocks pblock_ahbjtag_0]
set_property HD.PARTITION true [current_design]
set_property HD.PARTPIN_RANGE {SLICE_X12Y66:SLICE_X53Y104} [get_ports]

I get the following error:

	RTSTAT-1#1: 1 net(s) are unrouted. The problem bus(es) and/or net(s) are tapo_tck.

This net is the net that is being driven by the BUFG. The BUFG drives 74 pins: 73 are C pin on an FDRE and 1 is a LUT pin that inverts it. In the image below you can see the BUFG on the top right and the two BSCANE2s on the bottom left.

ahbjtag_BUFG_routing.png

 

When I try and route that net with nothing else routed by entering:

route_design -unroute
route_design -nets [get_nets tapo_tck]

I get the following error:

Starting Interactive Router Task

Phase 1 Build RT Design
WARNING: [Route 35-197] Clock port "clk" does not have an associated HD.CLK_SRC. Without this constraint, timing analysis may not be accurate and upstream checks cannot be done to ensure correct clock placement.
Phase 1 Build RT Design | Checksum: 290aea32a

Time (s): cpu = 00:00:17 ; elapsed = 00:00:13 . Memory (MB): peak = 7211.098 ; gain = 0.000 ; free physical = 3019 ; free virtual = 26128
INFO: [Route 35-47] Routing for 1 net will be attempted.

Phase 2 Router Initialization
Phase 2 Router Initialization | Checksum: 290aea32a

Time (s): cpu = 00:00:17 ; elapsed = 00:00:13 . Memory (MB): peak = 7211.098 ; gain = 0.000 ; free physical = 2999 ; free virtual = 26108
 Number of Nodes with overlaps = 0
CRITICAL WARNING: [Route 35-276] Interactive router failed to route 1  net.
Resolution: Run report_route_status and review the logfile to identify routing failures.

Unroutable connection Types:
----------------------------
Type 1 : BUFGCTRL.O->SLICEM.CLK
-----Num Open nets: 5
-----Representative Net: Net[14] tapo_tck
-----BUFGCTRL_X0Y16.O -> SLICE_X38Y83.CLK
-----Driver Term: gtckbuf.tckbuf/xil.xil0/buf2.buf/O Load Term [84]: gupdff.updff/y1.q_reg/C
Type 2 : BUFGCTRL.O->SLICEL.C6
-----Num Open nets: 1
-----Representative Net: Net[14] tapo_tck
-----BUFGCTRL_X0Y16.O -> SLICE_X40Y82.C6
-----Driver Term: gtckbuf.tckbuf/xil.xil0/buf2.buf/O Load Term [105]: tapo_tckn_INST_0/I0
Type 3 : BUFGCTRL.O->SLICEL.CLK
-----Num Open nets: 16
-----Representative Net: Net[14] tapo_tck
-----BUFGCTRL_X0Y16.O -> SLICE_X37Y83.CLK
-----Driver Term: gtckbuf.tckbuf/xil.xil0/buf2.buf/O Load Term [85]: newcom.jtagcom0/tpr1_reg[datashft0]/C
Ending Interactive Router Task | Checksum: 290aea32a

Report route status gives the following:

report_route_status
Design Route Status
                                               :      # nets :
   ------------------------------------------- : ----------- :
   # of logical nets.......................... :         402 :
       # of nets not needing routing.......... :         126 :
           # of internally routed nets........ :         125 :
           # of implicitly routed ports....... :           1 :
       # of routable nets..................... :         276 :
           # of unrouted nets................. :         276 :
       # of nets with routing errors.......... :           0 :
   ------------------------------------------- : ----------- :

I've attatched the route_design.log file.

 

Why can't that net be routed?

 

Thanks for your help!!!

 

0 Kudos
1 Solution

Accepted Solutions
austin
Scholar
Scholar
4,374 Views
Registered: ‎02-27-2008

Not my area of expertise,

 

But, as I do not see anyone replying, I will offer this:  I always thought BUFG, IO, MMCM, PLL, etc. must be at the top level, and cannot be part of a lower level construct?

 

Again, just trying to be a help -- I could be totally wrong on this.

Austin Lesea
Principal Engineer
Xilinx San Jose

View solution in original post

0 Kudos
7 Replies
austin
Scholar
Scholar
4,375 Views
Registered: ‎02-27-2008

Not my area of expertise,

 

But, as I do not see anyone replying, I will offer this:  I always thought BUFG, IO, MMCM, PLL, etc. must be at the top level, and cannot be part of a lower level construct?

 

Again, just trying to be a help -- I could be totally wrong on this.

Austin Lesea
Principal Engineer
Xilinx San Jose

View solution in original post

0 Kudos
byusean
Observer
Observer
3,248 Views
Registered: ‎01-25-2017

Austin,

 

Thanks for the reply. What you have said makes sense, for sure. I believe that they are supposed to be supported in Hierarchical Design, so maybe it's a bug? Below is a quote from UG905: Vivado Hierarchical Design:

 

"Global Clock Buffers – Global buffers are supported inside an OOC module. When a BUFG is inside an OOC instance the clock net is routed on global routing in the OOC implementation. 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." (Page 8 of the 2014.3 version).

 

I'm using script version 2014.3 and vivado version 2016.2.

 

--Sean

0 Kudos
austin
Scholar
Scholar
3,205 Views
Registered: ‎02-27-2008

...

 

The devil is in the details.  The "driven by a top level net" must be the trick.  I will ask the board expert to respond.

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
byusean
Observer
Observer
3,194 Views
Registered: ‎01-25-2017

Thanks for doing some networking for me Austin. The I pin on the BUFG is driven by the TCK pin on one of the BSCANE2s. 

0 Kudos
austin
Scholar
Scholar
3,190 Views
Registered: ‎02-27-2008

That may be the problem,

 

BSCAN TCLK may not be a valid global clock source in the tool flow for OOC blocks (it is the first time I have ever heard of that use model, so it just may not be supported).  Try an input pin as source, and see what happens?

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
byusean
Observer
Observer
3,181 Views
Registered: ‎01-25-2017

It seems like it's a valid global clock source because it routes the net sourcing the BUFG just fine (the picture below shows the net sourced by the BSCANE2 and sinked by the BUFG).

ahbjtag_ltck.png

 

As you suggest, I'm going to try to bring the BUFG into the top module and source the 74 pins by means of an input port on the OOC module. I have many designs I'm working with and none of them have a BUFG in the OOC module.

0 Kudos
byusean
Observer
Observer
3,138 Views
Registered: ‎01-25-2017

Yeah, I got the design to work when I moved the BUFG up to the higher level of hierarchy. It's a little frustrating that I can't have a BUFG in my OOC module, but it could be that I'm reading the User Guide wrong. It didn't matter that the BUFG was outside of the OOC module for this use case, but I hope that there is a way to be able to use a BUFG in an OOC module in the future.

0 Kudos