aws / aws-fpga

Official repository of the AWS EC2 FPGA Hardware and Software Development Kit
Other
1.51k stars 517 forks source link

Partial configuration error on SH_DEBUG_BRIDGE #616

Open ehudeliaz opened 1 year ago

ehudeliaz commented 1 year ago

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 1 year ago

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 1 year ago

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 1 year ago

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 1 year ago

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 1 year ago

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 1 year ago

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 1 year ago

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 GitHubhttps://github.com/aws/aws-fpga/issues/616#issuecomment-1776730105, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AJ5KWMKJSRCS6R5VE745GEDYA5Z3FAVCNFSM6AAAAAAZVDJKIOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZWG4ZTAMJQGU. You are receiving this because you commented.Message ID: @.***>

ehudeliaz commented 1 year ago

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 commented 1 month ago

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 commented 1 month ago

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

image

JamelRouahi commented 1 month ago

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

JamelRouahi commented 1 month ago

Arghh… I’m afraid the error still pops up. And unfortunately this happens at the very end of the implementation process with no hint of the error before which makes it difficult to debug given the time it requires to get there. I have set the DISABLE_VJTAG_DEBUG with the -verilog_define option in the synth_design command, I have commented out the read_ip command in the synth tcl script as you suggested but it is not successful… I’m running out of ideas so if you any other hint I take it! Thx for the help.

ehudeliaz commented 1 month ago

Hi,

Did you removed all the XCIs from the read IP list? i.e., also the ila_vio_counter, etc. Also, if you are using their given files RTL, then I would also suggest to double check you set all DEBUG defines IN THE RTL ITSELF, or delete all the parts from the code that uses them. e.g.: ifndef DISABLE_CHIPSCOPE_DEBUG define DISABLE_VJTAG_DEBUG

for example, if you are using the hello_world, then I would change the next file accordingly: hdk/cl/examples/cl_hello_world/design/cl_hello_world_defines.vh

If you do all this, and nothing helps, then I would suggest to open a ticket here to get an official help from aws people...

JamelRouahi commented 1 month ago

Thx very much for these hints. I'll try more in depth and explore further as soon as I have time. If stuck I'll follow your advice and open a ticket to AWS. I'll send a post anyway to close this thread and let you know if successful or not.