aws/aws-fpga

Partial configuration error on SH_DEBUG_BRIDGE

ehudeliaz opened this issue · 14 comments

ehudeliaz commented

Hi,

During some trials on F1, I get this error, which doesn't seem to be related at all to our logic in the CL:

ERROR: [Constraints 18-4430] On the boundary net static_sh/SH_DEBUG_BRIDGE/inst/bsip/inst/tck, the routing branch between node INT_X72Y4/CTRL_E5 and node CMT_L_X72Y240/CLK_BUFGCE_82_CLK_OUT does not contain Part
Pin LOC. In Dynamic Function eXchange (DFX) flow, the routing branch between static logic and reconfigurable logic must have PartPin LOC.

Looking in the device, we see that the net which goes from the SHELL ends in the CL:

image

And it ends in a flop sampling the tck wire:

image

I couldn't find any way in online documentation how to bypass this error.
Is this error familiar to you?
What should we do to resolve it?

Thanks!

jimmy-adams commented

Hi,
I want to ask if you inster the debug_bridge ip into your own design script?
or the debug_bridge ip stays with the cloud FPGA side

AWScsaralay commented

Hi,

This looks like an error occurring due to debug bridge IP routes not honoring AWS Shell's partition pin LOCs. Couple of follow up questions:

  1. Did you instantiate the cl_debug_bridge IP provided by AWS in your CL design? https://github.com/aws/aws-fpga/blob/master/hdk/docs/Virtual_JTAG_XVC.md#embedding-debug-cores-in-the-cl

  2. Could you try building your design using different build strategies to ensure 100% routing success? https://github.com/aws/aws-fpga/blob/master/hdk/common/shell_v04261818/build/scripts/aws_build_dcp_from_cl.sh#L21

Please reach out to us if you have any questions.

Thanks!
Chakra

ehudeliaz commented

Hi,

Thank you for the response!
Following your query, I've noticed that we indeed instanced the cl_debug_bridge_ip, by mistake.
This was taken as is from the example design.
We removed the debug_bridge_ip from the flow and the issue disappeared.

Thanks!

ehudeliaz commented

Hi,

Re-opening this issue.
In the past, this error appeared since I accidently instanced the DEBUG_BRIDGE in our CL. There was nothing even connected to it. So when I've removed it, it was solved.

But now, I do need this debug bridge IP, since I want to use an ILA.
I've instanced the DEBUG_BRIDGE, and the ILA, according to the guidelines in your documentation:
https://github.com/aws/aws-fpga/blob/master/hdk/docs/Virtual_JTAG_XVC.md#embedding-debug-cores-in-the-cl

And I ran the flow.
It fails again on this issue, which is reported on the SHELL debug bridge:

ERROR: [Constraints 18-4430] On the boundary net static_sh/SH_DEBUG_BRIDGE/inst/bsip/inst/tck, the routing branch between node INT_X78Y166/CTRL_W5 and node CMT_L_X72Y240/CLK_BUFGCE_82_CLK_OUT does not contain PartPin LOC. In Dynamic Function eXchange (DFX) flow, the routing branch between static logic and reconfigurable logic must have PartPin LOC.

I believe that since you have your own SH_DEBUG_BRIDGE, and you perform automatic routing for the JTAG pins, the router creates this path.
Do you have a partpin LOC constraint on the debug bridge tck (and other JTAG wires)?
Is there any way to disable the SHELL debug bridge?

I don't think switching routing strategies is a valid solution, since nothing guarantees that it will never happen again in a different strategy. As well, my design might not converge well in a different strategy.

Thanks,
Ehud

czfpga commented

Hi Ehud,

How didyou you instantiate the CL_DEBUG_BRIDGE in your CL design, are you using the CL Debug Bridge provided by AWS? OR you're instantiate one from the IP catalog?

Thanks,

Chen

ehudeliaz commented

Hi Chen,

I am using the CL debug bridge provided by AWS, the one that is used in the hello world example design (and the ILA).
This is from the TCL script:

##Read IP for virtual jtag / ILA/VIO
set_param chipscope.enablePRFlow true
read_ip [ list
$HDK_SHELL_DESIGN_DIR/ip/cl_debug_bridge/cl_debug_bridge.xci
$HDK_SHELL_DESIGN_DIR/ip/ila_0/ila_0.xci
]

This is the debug bridge instance, in my top level:

// Debug Bridge
cl_debug_bridge CL_DEBUG_BRIDGE (
.clk(clk_main_a0),
.S_BSCAN_drck(drck),
.S_BSCAN_shift(shift),
.S_BSCAN_tdi(tdi),
.S_BSCAN_update(update),
.S_BSCAN_sel(sel),
.S_BSCAN_tdo(tdo),
.S_BSCAN_tms(tms),
.S_BSCAN_tck(tck),
.S_BSCAN_runtest(runtest),
.S_BSCAN_reset(reset),
.S_BSCAN_capture(capture),
.S_BSCAN_bscanid_en(bscanid_en)
);

This is the ILA instance, in some unit inside the CL:

ila_0 ila_0_u (
.clk(clk), // input wire clk
.probe0(u_pci_axi_arvalid), // input wire [0:0] probe0
.probe1(u_pci_axi_araddr), // input wire [63:0] probe1
.probe2(u_pci_axi_arready), // input wire [0:0] probe2
.probe3(u_pci_axi_arsize[0]), // input wire [0:0] probe3
.probe4(64'(u_pci_axi_arid)), // input wire [63:0] probe4
.probe5(u_pci_axi_arsize[1]) // input wire [0:0] probe5
);

Thanks,
Ehud

jimmy-adams commented
ehudeliaz commented

Pure tcl command.
The DCP that is created is opened just fine afterwards.

@czfpga,
If there is any more information I can provide you with, please let me know.

Thanks,
Ehud