0
\$\begingroup\$

I am following section "Baseline Vivado project" in page 165-170 of book "Architecting High-Performance Embedded Systems: Design and build high-performance real-time digital systems based on FPGAs and custom circuits" written by Jim Ledin, to build up the first stage of the oscilloscope FPGA development project. But I always get an error when generating bitstream: "[DRC RTRES-1] Backbone resources: 1 net(s) have CLOCK_DEDICATED_ROUTE set to BACKBONE but do not use backbone resources. The problem net(s) are design_1_i/clk_wiz_0/inst/clk_out1." I followed all steps exactly in Vivado 2022.2.2, including the board part and target language, but this error always shows up.

This book published the project source in github. However, the published source works without this error after upgrading to Vivado 2022.2.2. I compared the author's published project with mine, but could not find the difference that causes the error. Nor do I know how to fix it. The only difference is that the author was using an old version of Vivado, while I am using the most up-to-date Vivado 2022.2.2. I changed the wrapper language from VHDL to Verilog but the problem remains the same (the author's project has no error, but mine always have the error).

So, I ask here and I was wondering if you could please help me figure out why there is such an error and how to fix it in Vivado 2022.2.2. In order to reproduce the error, I extracted page 165-170 of the book and uploaded it to an online pdf host. The board part is Digilent Arty A7-100. Thank you very much for your help.

\$\endgroup\$
1
  • \$\begingroup\$ This happens to me all the time. FPGA vendor tool updates break example projects so much, that example projects are basically locked to a specific version. Unless you already know how to fix the issue, the path of least resistance is to download the matching version of Vivado and hope you don't have to apply particular patches. \$\endgroup\$ Commented Apr 5, 2023 at 17:35

3 Answers 3

1
\$\begingroup\$

With the assistance of an AMD engineer, the problem is solved. The solution is add a line

set_property CLOCK_DEDICATED_ROUTE TRUE [get_nets design_1_i/clk_wiz_0/inst/clk_out1]

into the constraint file arty.xdc.

Thank dsheils for his awesome help. A reference of this solution is here.

\$\endgroup\$
0
\$\begingroup\$

For Vivado 23.2 & Arty Board v1.1, if you follow Diligent Tutorial, add this to your arty_eth.xdc :

set_property -dict { PACKAGE_PIN G18    IOSTANDARD LVCMOS33 } [get_ports { eth_ref_clk }]; #         Sch=eth_ref_clk 

set_property CLOCK_DEDICATED_ROUTE TRUE [get_nets system_i/clk_wiz_0/inst/clk_out166];

set_property -dict { PACKAGE_PIN E3 IOSTANDARD LVCMOS33 } [get_ports { sys_clock }]; #IO_L12P_T1_MRCC_35 Sch=gclk[100]

create_clock -add -name sys_clk_pin -period 10.00 -waveform {0 5} [get_ports { sys_clock }];

References :

"ERROR: [DRC RTRES-1] Backbone resources: 1 net(s) have CLOCK_DEDICATED_ROUTE set to BACKBONE but do not use backbone resources." in newest Vivado

https://forum.digilent.com/topic/21124-usb104a7-ddr3-backbone-clock-error-issue/#comment-62976

\$\endgroup\$
-1
\$\begingroup\$

This answer is based on a root cause. The most up-to-date version of Vivado (like Vivado 2022.2.2 I am using) requires that MIG send clock signal to clock wizard, not the converse. The book is taking the converse, sending the clock from clock wizard to MIG. Although the author did not receive any error due to this from old version of Vivado, the most up-to-date version complains about it. After knowing the cause for the error, I changed the block design by sending clock from MIG to clock wizard, specifically, from ui_clk port of MIG to clk_in1 port of clock wizard, and I can generate the bit stream without any error. A few accompanying modifications are also needed. For example, we should connect ui_addn_clk_0 to clk_ref_i in MIG, and we should change the name of system clock into MIG to that defined in master xdf file to fix the error arsing from the original sys_clock having VCC (2.5V) incompatible with VCC of reset (3.3V). In addition, make sure the reset signal into ext_reset_in pin of Processor System Reset IP is from input reset signal directly, not from ui_clk_sync_rst pin out of MIG.

\$\endgroup\$
0

Not the answer you're looking for? Browse other questions tagged or ask your own question.