Partial configuration error on SH_DEBUG_BRIDGE

[ehudeliaz]

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:

And it ends in a flop sampling the tck wire:

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]

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]

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]

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]

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]

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]

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]

Hello Edu, Did you use the vivado ide gui to conduct the design, or with pure tcl command? I tried to open the vivado gui, but it takes a long time. I am not sure it is normal. 发自我的小米手机 在 ehudeliaz ***@***.***>，2023年10月24日 下午4:11写道： 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 — Reply to this email directly, view it on GitHub<#616 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AJ5KWMKJSRCS6R5VE745GEDYA5Z3FAVCNFSM6AAAAAAZVDJKIOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZWG4ZTAMJQGU>. You are receiving this because you commented.Message ID: ***@***.***>

[ehudeliaz]

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

[JamelRouahi]

Hi @ehudeliaz, I ran into the exact same problem but have had no success resolving it so far... Did you solve your issue? Especially, in your first attempt you mention "We removed the debug_bridge_ip from the flow and the issue disappeared". How exactly did you do that? On my side, I am keen to remove the ILAs and all JTAG features basically to gain space and densify my design to the maximum. I thought that by setting some verilog define (I set XSDB_SLV_DIS and DISABLE_VJTAG_DEBUG), that would do, but unfortunately I am still getting the error... Any hint on how you removed the faulty debug_bridge_ip would be appreciated. Thx!

[ehudeliaz]

Hi @JamelRouahi,

To remove it, you need to delete the XCI read IP command from the synthesis TCL.
I've attached a picture of the relevant part from the example design TCL.
You can also just grep in your files "cl_debug_bridge.xci"

Thanks,
Ehud

[JamelRouahi]

Many thx @ehudeliaz, I'll give it a try as soon as I can and leave a feedback when done. Thx for your help!