Hi, 
Guest
Pic
Sign In

discuss@lists.opencpi.org

OpenCPI Discussion

View all threads

Vivado Multiple Instantiation Debug Cores

BP
Brian Padalino
Tue, Aug 4, 2020 7:19 PM

I have a design I am trying to debug the AD9361 ADC interface.  I am
following the guide here:

https://opencpi.gitlab.io/releases/v1.7.0/docs/Debugging_Tools_Guide.pdf

For 3.1.2 - inserting the debug cores into the EDIF netlist.  I save off
the netlist and debug probe file and things seem OK.

My platform has two AD9361 devices in it.  When I try to build a target
assembly with both of them instantiated, I get an error regarding the debug
cores.  Specifically that there are duplicates.

I am going to attempt to debug my design slightly differently, but is this
expected in the way that the debug core is created and attached to the EDIF
netlist?  Will both try to attach to JTAG instead of chaining appropriately?

Does anyone else have experience debugging OpenCPI netlists that have the
same debug instrumented core instantiated multiple times?

Thanks,
Brian

I have a design I am trying to debug the AD9361 ADC interface. I am following the guide here: https://opencpi.gitlab.io/releases/v1.7.0/docs/Debugging_Tools_Guide.pdf For 3.1.2 - inserting the debug cores into the EDIF netlist. I save off the netlist and debug probe file and things seem OK. My platform has two AD9361 devices in it. When I try to build a target assembly with both of them instantiated, I get an error regarding the debug cores. Specifically that there are duplicates. I am going to attempt to debug my design slightly differently, but is this expected in the way that the debug core is created and attached to the EDIF netlist? Will both try to attach to JTAG instead of chaining appropriately? Does anyone else have experience debugging OpenCPI netlists that have the same debug instrumented core instantiated multiple times? Thanks, Brian
JD
Jerry Darko
Tue, Aug 4, 2020 7:53 PM

Davis and I have run into this. One way around it is to open up the container or assembly .edif (sorry I forget which one at the moment) and then use the write_debug_probes command to generate the .ltx file and use that .ltx file instead.

  • Jerry

From: discuss discuss-bounces@lists.opencpi.org on behalf of Brian Padalino bpadalino@gmail.com
Sent: Tuesday, August 4, 2020 3:19 PM
To: discuss@lists.opencpi.org discuss@lists.opencpi.org
Subject: [Discuss OpenCPI] Vivado Multiple Instantiation Debug Cores

I have a design I am trying to debug the AD9361 ADC interface.  I am
following the guide here:

https://opencpi.gitlab.io/releases/v1.7.0/docs/Debugging_Tools_Guide.pdf

For 3.1.2 - inserting the debug cores into the EDIF netlist.  I save off
the netlist and debug probe file and things seem OK.

My platform has two AD9361 devices in it.  When I try to build a target
assembly with both of them instantiated, I get an error regarding the debug
cores.  Specifically that there are duplicates.

I am going to attempt to debug my design slightly differently, but is this
expected in the way that the debug core is created and attached to the EDIF
netlist?  Will both try to attach to JTAG instead of chaining appropriately?

Does anyone else have experience debugging OpenCPI netlists that have the
same debug instrumented core instantiated multiple times?

Thanks,
Brian

Davis and I have run into this. One way around it is to open up the container or assembly .edif (sorry I forget which one at the moment) and then use the write_debug_probes command to generate the .ltx file and use that .ltx file instead. - Jerry ________________________________ From: discuss <discuss-bounces@lists.opencpi.org> on behalf of Brian Padalino <bpadalino@gmail.com> Sent: Tuesday, August 4, 2020 3:19 PM To: discuss@lists.opencpi.org <discuss@lists.opencpi.org> Subject: [Discuss OpenCPI] Vivado Multiple Instantiation Debug Cores I have a design I am trying to debug the AD9361 ADC interface. I am following the guide here: https://opencpi.gitlab.io/releases/v1.7.0/docs/Debugging_Tools_Guide.pdf For 3.1.2 - inserting the debug cores into the EDIF netlist. I save off the netlist and debug probe file and things seem OK. My platform has two AD9361 devices in it. When I try to build a target assembly with both of them instantiated, I get an error regarding the debug cores. Specifically that there are duplicates. I am going to attempt to debug my design slightly differently, but is this expected in the way that the debug core is created and attached to the EDIF netlist? Will both try to attach to JTAG instead of chaining appropriately? Does anyone else have experience debugging OpenCPI netlists that have the same debug instrumented core instantiated multiple times? Thanks, Brian
BP
Brian Padalino
Tue, Aug 4, 2020 8:03 PM

On Tue, Aug 4, 2020 at 3:53 PM Jerry Darko jerry.darko@cnftech.com wrote:

Davis and I have run into this. One way around it is to open up the
container or assembly .edif (sorry I forget which one at the moment) and
then use the write_debug_probes command to generate the .ltx file and use
that .ltx file instead.

My failure is at placement of the assembly, not at the debug time which I
think is where the ltx file would come into play.

Are you able to get through and place your design successfully with
multiple EDIF netlists instrumented for debug?

Thanks,
Brian

On Tue, Aug 4, 2020 at 3:53 PM Jerry Darko <jerry.darko@cnftech.com> wrote: > Davis and I have run into this. One way around it is to open up the > container or assembly .edif (sorry I forget which one at the moment) and > then use the write_debug_probes command to generate the .ltx file and use > that .ltx file instead. > My failure is at placement of the assembly, not at the debug time which I think is where the ltx file would come into play. Are you able to get through and place your design successfully with multiple EDIF netlists instrumented for debug? Thanks, Brian
JD
Jerry Darko
Tue, Aug 4, 2020 8:22 PM

From: Brian Padalino bpadalino@gmail.com
Sent: Tuesday, August 4, 2020 4:03 PM
To: Jerry Darko jerry.darko@cnftech.com
Cc: discuss@lists.opencpi.org discuss@lists.opencpi.org
Subject: Re: [Discuss OpenCPI] Vivado Multiple Instantiation Debug Cores

On Tue, Aug 4, 2020 at 3:53 PM Jerry Darko <jerry.darko@cnftech.commailto:jerry.darko@cnftech.com> wrote:
Davis and I have run into this. One way around it is to open up the container or assembly .edif (sorry I forget which one at the moment) and then use the write_debug_probes command to generate the .ltx file and use that .ltx file instead.

My failure is at placement of the assembly, not at the debug time which I think is where the ltx file would come into play.

Are you able to get through and place your design successfully with multiple EDIF netlists instrumented for debug?
Sorry I misread. Some months back I was debugging some framework infrastructure such as the wsi_width_clock_adapters and a design had multiple of them and it was able to place the design successfully.

Can you please post the error message?

Thanks,
Brian

________________________________ From: Brian Padalino <bpadalino@gmail.com> Sent: Tuesday, August 4, 2020 4:03 PM To: Jerry Darko <jerry.darko@cnftech.com> Cc: discuss@lists.opencpi.org <discuss@lists.opencpi.org> Subject: Re: [Discuss OpenCPI] Vivado Multiple Instantiation Debug Cores On Tue, Aug 4, 2020 at 3:53 PM Jerry Darko <jerry.darko@cnftech.com<mailto:jerry.darko@cnftech.com>> wrote: Davis and I have run into this. One way around it is to open up the container or assembly .edif (sorry I forget which one at the moment) and then use the write_debug_probes command to generate the .ltx file and use that .ltx file instead. My failure is at placement of the assembly, not at the debug time which I think is where the ltx file would come into play. Are you able to get through and place your design successfully with multiple EDIF netlists instrumented for debug? Sorry I misread. Some months back I was debugging some framework infrastructure such as the wsi_width_clock_adapters and a design had multiple of them and it was able to place the design successfully. Can you please post the error message? Thanks, Brian
BP
Brian Padalino
Tue, Aug 4, 2020 9:45 PM

On Tue, Aug 4, 2020 at 4:22 PM Jerry Darko jerry.darko@cnftech.com wrote:

From: Brian Padalino bpadalino@gmail.com
Sent: Tuesday, August 4, 2020 4:03 PM
To: Jerry Darko jerry.darko@cnftech.com
Cc: discuss@lists.opencpi.org discuss@lists.opencpi.org
Subject: Re: [Discuss OpenCPI] Vivado Multiple Instantiation Debug Cores

On Tue, Aug 4, 2020 at 3:53 PM Jerry Darko jerry.darko@cnftech.com
wrote:

Davis and I have run into this. One way around it is to open up the
container or assembly .edif (sorry I forget which one at the moment) and
then use the write_debug_probes command to generate the .ltx file and use
that .ltx file instead.

My failure is at placement of the assembly, not at the debug time which I
think is where the ltx file would come into play.

Are you able to get through and place your design successfully with
multiple EDIF netlists instrumented for debug?

Sorry I misread. Some months back I was debugging some framework
infrastructure such as the wsi_width_clock_adapters and a design had
multiple of them and it was able to place the design successfully.

Can you please post the error message?

I am placing the ILA in the ad9361_adc_sub on:

dev_data_ch0_out_out[adc_data_I]
dev_data_ch0_out_out[adc_data_Q]
dev_data_ch1_out_out[adc_data_I]
dev_data_ch1_out_out[adc_data_Q]

And there are two instances of that device.

During placing, I get this error:

Phase 1.2 IO Placement/ Clock Placement/ Build Placer Device
INFO: [Timing 38-35] Done setting XDC timing constraints.
ERROR: [Place 30-174] Unroutable Placement! The following clock source
components are placed too far from each other.  These clocks drive common
load instances. This requires them to be placed in a relative way such that
both clocks can drive the common load instances. Please refer to the
clocking user guide for more details on which clock regions these clock
sources can drive.
ftop/pfconfig_i/afe0_adc_sub_i/worker/clk_in_lvds.BUFR_inst (BUFR.O) is
provisionally placed by clockplacer on BUFR_X1Y7
ftop/pfconfig_i/afe1_adc_sub_i/worker/clk_in_lvds.BUFR_inst (BUFR.O) is
provisionally placed by clockplacer on BUFR_X1Y11
ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[0].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM18.ram
(RAMB18E1.CLKARDCLK) cannot be placed
ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[0].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM18.ram
(RAMB18E1.CLKBWRCLK) cannot be placed
ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[1].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram
(RAMB36E1.CLKARDCLK) cannot be placed
ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[1].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram
(RAMB36E1.CLKBWRCLK) cannot be placed
ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[2].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram
(RAMB36E1.CLKARDCLK) cannot be placed
ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[2].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram
(RAMB36E1.CLKBWRCLK) cannot be placed
ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[3].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram
(RAMB36E1.CLKARDCLK) cannot be placed
ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[3].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram
(RAMB36E1.CLKBWRCLK) cannot be placed
ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[4].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram
(RAMB36E1.CLKARDCLK) cannot be placed
ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[4].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram
(RAMB36E1.CLKBWRCLK) cannot be placed
ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[5].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram
(RAMB36E1.CLKARDCLK) cannot be placed
ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[5].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram
(RAMB36E1.CLKBWRCLK) cannot be placed

Following this, there is a statement about the clocks associated with this:

The above error could possibly be related to other connected instances.
Following is a list of
all the related clock rules and their respective instances.

Clock Rule: rule_bufh_bufr_ramb
Status: PASS
Rule Description: Reginal buffers in the same clock region must drive a
total number of brams less
than the capacity of the region
ftop/pfconfig_i/afe0_adc_sub_i/worker/clk_in_lvds.BUFR_inst (BUFR.O) is
provisionally placed by clockplacer on BUFR_X1Y7

Clock Rule: rule_bufr_IoClkLds
Status: PASS
Rule Description: A BUFR driving any number of IOBs must be placed within
the same clock region
ftop/pfconfig_i/afe0_adc_sub_i/worker/clk_in_lvds.BUFR_inst (BUFR.O) is
provisionally placed by clockplacer on BUFR_X1Y7
ftop/pfconfig_i/afe0_adc_sub_i/worker/supported_so_far.buf_data_loop[0].data_ddr
(IDDR.C) is locked to ILOGIC_X1Y92
ftop/pfconfig_i/afe0_adc_sub_i/worker/supported_so_far.buf_data_loop[1].data_ddr
(IDDR.C) is locked to ILOGIC_X1Y88
ftop/pfconfig_i/afe0_adc_sub_i/worker/supported_so_far.buf_data_loop[2].data_ddr
(IDDR.C) is locked to ILOGIC_X1Y84
ftop/pfconfig_i/afe0_adc_sub_i/worker/supported_so_far.buf_data_loop[3].data_ddr
(IDDR.C) is locked to ILOGIC_X1Y90
ftop/pfconfig_i/afe0_adc_sub_i/worker/supported_so_far.buf_data_loop[4].data_ddr
(IDDR.C) is locked to ILOGIC_X1Y86
ftop/pfconfig_i/afe0_adc_sub_i/worker/supported_so_far.buf_data_loop[5].data_ddr
(IDDR.C) is locked to ILOGIC_X1Y82
ftop/pfconfig_i/afe0_adc_sub_i/worker/supported_so_far.rx_frame_p_ddr
(IDDR.C) is locked to ILOGIC_X1Y74

Clock Rule: rule_iotile_bufr
Status: PASS
Rule Description: An IO driving a BUFR must both be placed in the same
clock region
ftop/pfconfig_i/afe0_data_sub_i/worker/mode7.data_clk/UNSPECIFIED_gen.differential_prim.buf_generic.buf
(IBUFDS.O) is locked to IOB_X1Y76
ftop/pfconfig_i/afe0_adc_sub_i/worker/clk_in_lvds.BUFR_inst (BUFR.I) is
provisionally placed by clockplacer on BUFR_X1Y7

Clock Rule: rule_bufh_bufr_ramb
Status: PASS
Rule Description: Reginal buffers in the same clock region must drive a
total number of brams less
than the capacity of the region
ftop/pfconfig_i/afe1_adc_sub_i/worker/clk_in_lvds.BUFR_inst (BUFR.O) is
provisionally placed by clockplacer on BUFR_X1Y11

Clock Rule: rule_bufr_IoClkLds
Status: PASS
Rule Description: A BUFR driving any number of IOBs must be placed within
the same clock region
ftop/pfconfig_i/afe1_adc_sub_i/worker/clk_in_lvds.BUFR_inst (BUFR.O) is
provisionally placed by clockplacer on BUFR_X1Y11
ftop/pfconfig_i/afe1_adc_sub_i/worker/supported_so_far.buf_data_loop[0].data_ddr
(IDDR.C) is locked to ILOGIC_X1Y142
ftop/pfconfig_i/afe1_adc_sub_i/worker/supported_so_far.buf_data_loop[1].data_ddr
(IDDR.C) is locked to ILOGIC_X1Y138
ftop/pfconfig_i/afe1_adc_sub_i/worker/supported_so_far.buf_data_loop[2].data_ddr
(IDDR.C) is locked to ILOGIC_X1Y134
ftop/pfconfig_i/afe1_adc_sub_i/worker/supported_so_far.buf_data_loop[3].data_ddr
(IDDR.C) is provisionally placed by clockplacer on ILOGIC_X1Y132
ftop/pfconfig_i/afe1_adc_sub_i/worker/supported_so_far.buf_data_loop[4].data_ddr
(IDDR.C) is provisionally placed by clockplacer on ILOGIC_X1Y136
ftop/pfconfig_i/afe1_adc_sub_i/worker/supported_so_far.buf_data_loop[5].data_ddr
(IDDR.C) is provisionally placed by clockplacer on ILOGIC_X1Y140
ftop/pfconfig_i/afe1_adc_sub_i/worker/supported_so_far.rx_frame_p_ddr
(IDDR.C) is locked to ILOGIC_X1Y124

Clock Rule: rule_iotile_bufr
Status: PASS
Rule Description: An IO driving a BUFR must both be placed in the same
clock region
ftop/pfconfig_i/afe1_data_sub_i/worker/mode7.data_clk/UNSPECIFIED_gen.differential_prim.buf_generic.buf
(IBUFDS.O) is locked to IOB_X1Y126
ftop/pfconfig_i/afe1_adc_sub_i/worker/clk_in_lvds.BUFR_inst (BUFR.I) is
provisionally placed by clockplacer on BUFR_X1Y11

If I open the xpr and try the implementation, the following warning stands
out to me:

[Shape Builder 18-119] Failed to create BSCAN shape for instance
ftop/pfconfig_i/afe1_adc_sub_i/dbg_hub/inst/BSCANID.u_xsdbm_id/SWITCH_N_EXT_BSCAN.bscan_inst/SERIES7_BSCAN.bscan_inst.
Found overlapping instances within the shape:
ftop/pfconfig_i/afe1_adc_sub_i/dbg_hub/inst/BSCANID.u_xsdbm_id/SWITCH_N_EXT_BSCAN.bscan_inst/SERIES7_BSCAN.bscan_inst
and
ftop/pfconfig_i/afe0_adc_sub_i/dbg_hub/inst/BSCANID.u_xsdbm_id/SWITCH_N_EXT_BSCAN.bscan_inst/SERIES7_BSCAN.bscan_inst.

It's just a critical warning, but it seems potentially problematic.  Later
on there are also some warnings regarding a file called
xsdbm_cc_late_late.xdc complaining about no such variables.

Any help or insight would be very helpful.

Thanks,
Brian

On Tue, Aug 4, 2020 at 4:22 PM Jerry Darko <jerry.darko@cnftech.com> wrote: > > > ------------------------------ > *From:* Brian Padalino <bpadalino@gmail.com> > *Sent:* Tuesday, August 4, 2020 4:03 PM > *To:* Jerry Darko <jerry.darko@cnftech.com> > *Cc:* discuss@lists.opencpi.org <discuss@lists.opencpi.org> > *Subject:* Re: [Discuss OpenCPI] Vivado Multiple Instantiation Debug Cores > > On Tue, Aug 4, 2020 at 3:53 PM Jerry Darko <jerry.darko@cnftech.com> > wrote: > > Davis and I have run into this. One way around it is to open up the > container or assembly .edif (sorry I forget which one at the moment) and > then use the write_debug_probes command to generate the .ltx file and use > that .ltx file instead. > > > My failure is at placement of the assembly, not at the debug time which I > think is where the ltx file would come into play. > > Are you able to get through and place your design successfully with > multiple EDIF netlists instrumented for debug? > > Sorry I misread. Some months back I was debugging some framework > infrastructure such as the wsi_width_clock_adapters and a design had > multiple of them and it was able to place the design successfully. > > Can you please post the error message? > I am placing the ILA in the ad9361_adc_sub on: dev_data_ch0_out_out[adc_data_I] dev_data_ch0_out_out[adc_data_Q] dev_data_ch1_out_out[adc_data_I] dev_data_ch1_out_out[adc_data_Q] And there are two instances of that device. During placing, I get this error: Phase 1.2 IO Placement/ Clock Placement/ Build Placer Device INFO: [Timing 38-35] Done setting XDC timing constraints. ERROR: [Place 30-174] Unroutable Placement! The following clock source components are placed too far from each other. These clocks drive common load instances. This requires them to be placed in a relative way such that both clocks can drive the common load instances. Please refer to the clocking user guide for more details on which clock regions these clock sources can drive. ftop/pfconfig_i/afe0_adc_sub_i/worker/clk_in_lvds.BUFR_inst (BUFR.O) is provisionally placed by clockplacer on BUFR_X1Y7 ftop/pfconfig_i/afe1_adc_sub_i/worker/clk_in_lvds.BUFR_inst (BUFR.O) is provisionally placed by clockplacer on BUFR_X1Y11 ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[0].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM18.ram (RAMB18E1.CLKARDCLK) cannot be placed ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[0].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM18.ram (RAMB18E1.CLKBWRCLK) cannot be placed ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[1].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram (RAMB36E1.CLKARDCLK) cannot be placed ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[1].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram (RAMB36E1.CLKBWRCLK) cannot be placed ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[2].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram (RAMB36E1.CLKARDCLK) cannot be placed ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[2].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram (RAMB36E1.CLKBWRCLK) cannot be placed ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[3].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram (RAMB36E1.CLKARDCLK) cannot be placed ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[3].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram (RAMB36E1.CLKBWRCLK) cannot be placed ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[4].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram (RAMB36E1.CLKARDCLK) cannot be placed ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[4].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram (RAMB36E1.CLKBWRCLK) cannot be placed ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[5].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram (RAMB36E1.CLKARDCLK) cannot be placed ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[5].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram (RAMB36E1.CLKBWRCLK) cannot be placed Following this, there is a statement about the clocks associated with this: The above error could possibly be related to other connected instances. Following is a list of all the related clock rules and their respective instances. Clock Rule: rule_bufh_bufr_ramb Status: PASS Rule Description: Reginal buffers in the same clock region must drive a total number of brams less than the capacity of the region ftop/pfconfig_i/afe0_adc_sub_i/worker/clk_in_lvds.BUFR_inst (BUFR.O) is provisionally placed by clockplacer on BUFR_X1Y7 Clock Rule: rule_bufr_IoClkLds Status: PASS Rule Description: A BUFR driving any number of IOBs must be placed within the same clock region ftop/pfconfig_i/afe0_adc_sub_i/worker/clk_in_lvds.BUFR_inst (BUFR.O) is provisionally placed by clockplacer on BUFR_X1Y7 ftop/pfconfig_i/afe0_adc_sub_i/worker/supported_so_far.buf_data_loop[0].data_ddr (IDDR.C) is locked to ILOGIC_X1Y92 ftop/pfconfig_i/afe0_adc_sub_i/worker/supported_so_far.buf_data_loop[1].data_ddr (IDDR.C) is locked to ILOGIC_X1Y88 ftop/pfconfig_i/afe0_adc_sub_i/worker/supported_so_far.buf_data_loop[2].data_ddr (IDDR.C) is locked to ILOGIC_X1Y84 ftop/pfconfig_i/afe0_adc_sub_i/worker/supported_so_far.buf_data_loop[3].data_ddr (IDDR.C) is locked to ILOGIC_X1Y90 ftop/pfconfig_i/afe0_adc_sub_i/worker/supported_so_far.buf_data_loop[4].data_ddr (IDDR.C) is locked to ILOGIC_X1Y86 ftop/pfconfig_i/afe0_adc_sub_i/worker/supported_so_far.buf_data_loop[5].data_ddr (IDDR.C) is locked to ILOGIC_X1Y82 ftop/pfconfig_i/afe0_adc_sub_i/worker/supported_so_far.rx_frame_p_ddr (IDDR.C) is locked to ILOGIC_X1Y74 Clock Rule: rule_iotile_bufr Status: PASS Rule Description: An IO driving a BUFR must both be placed in the same clock region ftop/pfconfig_i/afe0_data_sub_i/worker/mode7.data_clk/UNSPECIFIED_gen.differential_prim.buf_generic.buf (IBUFDS.O) is locked to IOB_X1Y76 ftop/pfconfig_i/afe0_adc_sub_i/worker/clk_in_lvds.BUFR_inst (BUFR.I) is provisionally placed by clockplacer on BUFR_X1Y7 Clock Rule: rule_bufh_bufr_ramb Status: PASS Rule Description: Reginal buffers in the same clock region must drive a total number of brams less than the capacity of the region ftop/pfconfig_i/afe1_adc_sub_i/worker/clk_in_lvds.BUFR_inst (BUFR.O) is provisionally placed by clockplacer on BUFR_X1Y11 Clock Rule: rule_bufr_IoClkLds Status: PASS Rule Description: A BUFR driving any number of IOBs must be placed within the same clock region ftop/pfconfig_i/afe1_adc_sub_i/worker/clk_in_lvds.BUFR_inst (BUFR.O) is provisionally placed by clockplacer on BUFR_X1Y11 ftop/pfconfig_i/afe1_adc_sub_i/worker/supported_so_far.buf_data_loop[0].data_ddr (IDDR.C) is locked to ILOGIC_X1Y142 ftop/pfconfig_i/afe1_adc_sub_i/worker/supported_so_far.buf_data_loop[1].data_ddr (IDDR.C) is locked to ILOGIC_X1Y138 ftop/pfconfig_i/afe1_adc_sub_i/worker/supported_so_far.buf_data_loop[2].data_ddr (IDDR.C) is locked to ILOGIC_X1Y134 ftop/pfconfig_i/afe1_adc_sub_i/worker/supported_so_far.buf_data_loop[3].data_ddr (IDDR.C) is provisionally placed by clockplacer on ILOGIC_X1Y132 ftop/pfconfig_i/afe1_adc_sub_i/worker/supported_so_far.buf_data_loop[4].data_ddr (IDDR.C) is provisionally placed by clockplacer on ILOGIC_X1Y136 ftop/pfconfig_i/afe1_adc_sub_i/worker/supported_so_far.buf_data_loop[5].data_ddr (IDDR.C) is provisionally placed by clockplacer on ILOGIC_X1Y140 ftop/pfconfig_i/afe1_adc_sub_i/worker/supported_so_far.rx_frame_p_ddr (IDDR.C) is locked to ILOGIC_X1Y124 Clock Rule: rule_iotile_bufr Status: PASS Rule Description: An IO driving a BUFR must both be placed in the same clock region ftop/pfconfig_i/afe1_data_sub_i/worker/mode7.data_clk/UNSPECIFIED_gen.differential_prim.buf_generic.buf (IBUFDS.O) is locked to IOB_X1Y126 ftop/pfconfig_i/afe1_adc_sub_i/worker/clk_in_lvds.BUFR_inst (BUFR.I) is provisionally placed by clockplacer on BUFR_X1Y11 If I open the xpr and try the implementation, the following warning stands out to me: [Shape Builder 18-119] Failed to create BSCAN shape for instance ftop/pfconfig_i/afe1_adc_sub_i/dbg_hub/inst/BSCANID.u_xsdbm_id/SWITCH_N_EXT_BSCAN.bscan_inst/SERIES7_BSCAN.bscan_inst. Found overlapping instances within the shape: ftop/pfconfig_i/afe1_adc_sub_i/dbg_hub/inst/BSCANID.u_xsdbm_id/SWITCH_N_EXT_BSCAN.bscan_inst/SERIES7_BSCAN.bscan_inst and ftop/pfconfig_i/afe0_adc_sub_i/dbg_hub/inst/BSCANID.u_xsdbm_id/SWITCH_N_EXT_BSCAN.bscan_inst/SERIES7_BSCAN.bscan_inst. It's just a critical warning, but it seems potentially problematic. Later on there are also some warnings regarding a file called xsdbm_cc_late_late.xdc complaining about no such variables. Any help or insight would be very helpful. Thanks, Brian >
DH
Davis Hoover
Wed, Aug 5, 2020 4:41 PM

The error suggests you are routing clock signals from multiple regions
(each region corresponding to an adc_sub instance) to a single location,
which is not possible. Assuming you inserted an ILA into the worker EDF,
I'm not sure why the placement algorithm would be considering the
routability of a BUFR from a separate worker instance... but it may be
worth double checking that the signals in your ILA include those from only
a single adc_sub.

The "Clock Rule" sections don't seem relevant since they all have "Status:
PASS".

Some background info:
BUFRs were originally chosen due to their high performance on Zynq 7 Series

  • performance which was necessary for the >240MHz data I/O clock for AD936x
    LVDS mode. The output of BUFRs can only be routed within a single clock
    region (7 series die is separated into 6 regions).

---------- Forwarded message ---------
From: Brian Padalino bpadalino@gmail.com
Date: Tue, Aug 4, 2020 at 5:46 PM
Subject: Re: [Discuss OpenCPI] Vivado Multiple Instantiation Debug Cores
To: Jerry Darko jerry.darko@cnftech.com
Cc: discuss@lists.opencpi.org discuss@lists.opencpi.org

On Tue, Aug 4, 2020 at 4:22 PM Jerry Darko jerry.darko@cnftech.com wrote:

From: Brian Padalino bpadalino@gmail.com
Sent: Tuesday, August 4, 2020 4:03 PM
To: Jerry Darko jerry.darko@cnftech.com
Cc: discuss@lists.opencpi.org discuss@lists.opencpi.org
Subject: Re: [Discuss OpenCPI] Vivado Multiple Instantiation Debug Cores

On Tue, Aug 4, 2020 at 3:53 PM Jerry Darko jerry.darko@cnftech.com
wrote:

Davis and I have run into this. One way around it is to open up the
container or assembly .edif (sorry I forget which one at the moment) and
then use the write_debug_probes command to generate the .ltx file and use
that .ltx file instead.

My failure is at placement of the assembly, not at the debug time which I
think is where the ltx file would come into play.

Are you able to get through and place your design successfully with
multiple EDIF netlists instrumented for debug?

Sorry I misread. Some months back I was debugging some framework
infrastructure such as the wsi_width_clock_adapters and a design had
multiple of them and it was able to place the design successfully.

Can you please post the error message?

I am placing the ILA in the ad9361_adc_sub on:

dev_data_ch0_out_out[adc_data_I]
dev_data_ch0_out_out[adc_data_Q]
dev_data_ch1_out_out[adc_data_I]
dev_data_ch1_out_out[adc_data_Q]

And there are two instances of that device.

During placing, I get this error:

Phase 1.2 IO Placement/ Clock Placement/ Build Placer Device
INFO: [Timing 38-35] Done setting XDC timing constraints.
ERROR: [Place 30-174] Unroutable Placement! The following clock source
components are placed too far from each other.  These clocks drive common
load instances. This requires them to be placed in a relative way such that
both clocks can drive the common load instances. Please refer to the
clocking user guide for more details on which clock regions these clock
sources can drive.
ftop/pfconfig_i/afe0_adc_sub_i/worker/clk_in_lvds.BUFR_inst (BUFR.O) is
provisionally placed by clockplacer on BUFR_X1Y7
ftop/pfconfig_i/afe1_adc_sub_i/worker/clk_in_lvds.BUFR_inst (BUFR.O) is
provisionally placed by clockplacer on BUFR_X1Y11
ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[0].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM18.ram
(RAMB18E1.CLKARDCLK) cannot be placed
ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[0].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM18.ram
(RAMB18E1.CLKBWRCLK) cannot be placed
ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[1].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram
(RAMB36E1.CLKARDCLK) cannot be placed
ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[1].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram
(RAMB36E1.CLKBWRCLK) cannot be placed
ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[2].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram
(RAMB36E1.CLKARDCLK) cannot be placed
ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[2].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram
(RAMB36E1.CLKBWRCLK) cannot be placed
ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[3].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram
(RAMB36E1.CLKARDCLK) cannot be placed
ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[3].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram
(RAMB36E1.CLKBWRCLK) cannot be placed
ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[4].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram
(RAMB36E1.CLKARDCLK) cannot be placed
ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[4].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram
(RAMB36E1.CLKBWRCLK) cannot be placed
ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[5].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram
(RAMB36E1.CLKARDCLK) cannot be placed
ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[5].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram
(RAMB36E1.CLKBWRCLK) cannot be placed

Following this, there is a statement about the clocks associated with this:

The above error could possibly be related to other connected instances.
Following is a list of
all the related clock rules and their respective instances.

Clock Rule: rule_bufh_bufr_ramb
Status: PASS
Rule Description: Reginal buffers in the same clock region must drive a
total number of brams less
than the capacity of the region
ftop/pfconfig_i/afe0_adc_sub_i/worker/clk_in_lvds.BUFR_inst (BUFR.O) is
provisionally placed by clockplacer on BUFR_X1Y7

Clock Rule: rule_bufr_IoClkLds
Status: PASS
Rule Description: A BUFR driving any number of IOBs must be placed within
the same clock region
ftop/pfconfig_i/afe0_adc_sub_i/worker/clk_in_lvds.BUFR_inst (BUFR.O) is
provisionally placed by clockplacer on BUFR_X1Y7
ftop/pfconfig_i/afe0_adc_sub_i/worker/supported_so_far.buf_data_loop[0].data_ddr
(IDDR.C) is locked to ILOGIC_X1Y92
ftop/pfconfig_i/afe0_adc_sub_i/worker/supported_so_far.buf_data_loop[1].data_ddr
(IDDR.C) is locked to ILOGIC_X1Y88
ftop/pfconfig_i/afe0_adc_sub_i/worker/supported_so_far.buf_data_loop[2].data_ddr
(IDDR.C) is locked to ILOGIC_X1Y84
ftop/pfconfig_i/afe0_adc_sub_i/worker/supported_so_far.buf_data_loop[3].data_ddr
(IDDR.C) is locked to ILOGIC_X1Y90
ftop/pfconfig_i/afe0_adc_sub_i/worker/supported_so_far.buf_data_loop[4].data_ddr
(IDDR.C) is locked to ILOGIC_X1Y86
ftop/pfconfig_i/afe0_adc_sub_i/worker/supported_so_far.buf_data_loop[5].data_ddr
(IDDR.C) is locked to ILOGIC_X1Y82
ftop/pfconfig_i/afe0_adc_sub_i/worker/supported_so_far.rx_frame_p_ddr
(IDDR.C) is locked to ILOGIC_X1Y74

Clock Rule: rule_iotile_bufr
Status: PASS
Rule Description: An IO driving a BUFR must both be placed in the same
clock region
ftop/pfconfig_i/afe0_data_sub_i/worker/mode7.data_clk/UNSPECIFIED_gen.differential_prim.buf_generic.buf
(IBUFDS.O) is locked to IOB_X1Y76
ftop/pfconfig_i/afe0_adc_sub_i/worker/clk_in_lvds.BUFR_inst (BUFR.I) is
provisionally placed by clockplacer on BUFR_X1Y7

Clock Rule: rule_bufh_bufr_ramb
Status: PASS
Rule Description: Reginal buffers in the same clock region must drive a
total number of brams less
than the capacity of the region
ftop/pfconfig_i/afe1_adc_sub_i/worker/clk_in_lvds.BUFR_inst (BUFR.O) is
provisionally placed by clockplacer on BUFR_X1Y11

Clock Rule: rule_bufr_IoClkLds
Status: PASS
Rule Description: A BUFR driving any number of IOBs must be placed within
the same clock region
ftop/pfconfig_i/afe1_adc_sub_i/worker/clk_in_lvds.BUFR_inst (BUFR.O) is
provisionally placed by clockplacer on BUFR_X1Y11
ftop/pfconfig_i/afe1_adc_sub_i/worker/supported_so_far.buf_data_loop[0].data_ddr
(IDDR.C) is locked to ILOGIC_X1Y142
ftop/pfconfig_i/afe1_adc_sub_i/worker/supported_so_far.buf_data_loop[1].data_ddr
(IDDR.C) is locked to ILOGIC_X1Y138
ftop/pfconfig_i/afe1_adc_sub_i/worker/supported_so_far.buf_data_loop[2].data_ddr
(IDDR.C) is locked to ILOGIC_X1Y134
ftop/pfconfig_i/afe1_adc_sub_i/worker/supported_so_far.buf_data_loop[3].data_ddr
(IDDR.C) is provisionally placed by clockplacer on ILOGIC_X1Y132
ftop/pfconfig_i/afe1_adc_sub_i/worker/supported_so_far.buf_data_loop[4].data_ddr
(IDDR.C) is provisionally placed by clockplacer on ILOGIC_X1Y136
ftop/pfconfig_i/afe1_adc_sub_i/worker/supported_so_far.buf_data_loop[5].data_ddr
(IDDR.C) is provisionally placed by clockplacer on ILOGIC_X1Y140
ftop/pfconfig_i/afe1_adc_sub_i/worker/supported_so_far.rx_frame_p_ddr
(IDDR.C) is locked to ILOGIC_X1Y124

Clock Rule: rule_iotile_bufr
Status: PASS
Rule Description: An IO driving a BUFR must both be placed in the same
clock region
ftop/pfconfig_i/afe1_data_sub_i/worker/mode7.data_clk/UNSPECIFIED_gen.differential_prim.buf_generic.buf
(IBUFDS.O) is locked to IOB_X1Y126
ftop/pfconfig_i/afe1_adc_sub_i/worker/clk_in_lvds.BUFR_inst (BUFR.I) is
provisionally placed by clockplacer on BUFR_X1Y11

If I open the xpr and try the implementation, the following warning stands
out to me:

[Shape Builder 18-119] Failed to create BSCAN shape for instance
ftop/pfconfig_i/afe1_adc_sub_i/dbg_hub/inst/BSCANID.u_xsdbm_id/SWITCH_N_EXT_BSCAN.bscan_inst/SERIES7_BSCAN.bscan_inst.
Found overlapping instances within the shape:
ftop/pfconfig_i/afe1_adc_sub_i/dbg_hub/inst/BSCANID.u_xsdbm_id/SWITCH_N_EXT_BSCAN.bscan_inst/SERIES7_BSCAN.bscan_inst
and
ftop/pfconfig_i/afe0_adc_sub_i/dbg_hub/inst/BSCANID.u_xsdbm_id/SWITCH_N_EXT_BSCAN.bscan_inst/SERIES7_BSCAN.bscan_inst.

It's just a critical warning, but it seems potentially problematic.  Later
on there are also some warnings regarding a file called
xsdbm_cc_late_late.xdc complaining about no such variables.

Any help or insight would be very helpful.

Thanks,
Brian

The error suggests you are routing clock signals from multiple regions (each region corresponding to an adc_sub instance) to a single location, which is not possible. Assuming you inserted an ILA into the worker EDF, I'm not sure why the placement algorithm would be considering the routability of a BUFR from a separate worker instance... but it may be worth double checking that the signals in your ILA include those from only a single adc_sub. The "Clock Rule" sections don't seem relevant since they all have "Status: PASS". Some background info: BUFRs were originally chosen due to their high performance on Zynq 7 Series - performance which was necessary for the >240MHz data I/O clock for AD936x LVDS mode. The output of BUFRs can only be routed within a single clock region (7 series die is separated into 6 regions). ---------- Forwarded message --------- From: Brian Padalino <bpadalino@gmail.com> Date: Tue, Aug 4, 2020 at 5:46 PM Subject: Re: [Discuss OpenCPI] Vivado Multiple Instantiation Debug Cores To: Jerry Darko <jerry.darko@cnftech.com> Cc: discuss@lists.opencpi.org <discuss@lists.opencpi.org> On Tue, Aug 4, 2020 at 4:22 PM Jerry Darko <jerry.darko@cnftech.com> wrote: > > > ------------------------------ > *From:* Brian Padalino <bpadalino@gmail.com> > *Sent:* Tuesday, August 4, 2020 4:03 PM > *To:* Jerry Darko <jerry.darko@cnftech.com> > *Cc:* discuss@lists.opencpi.org <discuss@lists.opencpi.org> > *Subject:* Re: [Discuss OpenCPI] Vivado Multiple Instantiation Debug Cores > > On Tue, Aug 4, 2020 at 3:53 PM Jerry Darko <jerry.darko@cnftech.com> > wrote: > > Davis and I have run into this. One way around it is to open up the > container or assembly .edif (sorry I forget which one at the moment) and > then use the write_debug_probes command to generate the .ltx file and use > that .ltx file instead. > > > My failure is at placement of the assembly, not at the debug time which I > think is where the ltx file would come into play. > > Are you able to get through and place your design successfully with > multiple EDIF netlists instrumented for debug? > > Sorry I misread. Some months back I was debugging some framework > infrastructure such as the wsi_width_clock_adapters and a design had > multiple of them and it was able to place the design successfully. > > Can you please post the error message? > I am placing the ILA in the ad9361_adc_sub on: dev_data_ch0_out_out[adc_data_I] dev_data_ch0_out_out[adc_data_Q] dev_data_ch1_out_out[adc_data_I] dev_data_ch1_out_out[adc_data_Q] And there are two instances of that device. During placing, I get this error: Phase 1.2 IO Placement/ Clock Placement/ Build Placer Device INFO: [Timing 38-35] Done setting XDC timing constraints. ERROR: [Place 30-174] Unroutable Placement! The following clock source components are placed too far from each other. These clocks drive common load instances. This requires them to be placed in a relative way such that both clocks can drive the common load instances. Please refer to the clocking user guide for more details on which clock regions these clock sources can drive. ftop/pfconfig_i/afe0_adc_sub_i/worker/clk_in_lvds.BUFR_inst (BUFR.O) is provisionally placed by clockplacer on BUFR_X1Y7 ftop/pfconfig_i/afe1_adc_sub_i/worker/clk_in_lvds.BUFR_inst (BUFR.O) is provisionally placed by clockplacer on BUFR_X1Y11 ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[0].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM18.ram (RAMB18E1.CLKARDCLK) cannot be placed ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[0].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM18.ram (RAMB18E1.CLKBWRCLK) cannot be placed ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[1].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram (RAMB36E1.CLKARDCLK) cannot be placed ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[1].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram (RAMB36E1.CLKBWRCLK) cannot be placed ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[2].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram (RAMB36E1.CLKARDCLK) cannot be placed ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[2].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram (RAMB36E1.CLKBWRCLK) cannot be placed ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[3].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram (RAMB36E1.CLKARDCLK) cannot be placed ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[3].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram (RAMB36E1.CLKBWRCLK) cannot be placed ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[4].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram (RAMB36E1.CLKARDCLK) cannot be placed ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[4].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram (RAMB36E1.CLKBWRCLK) cannot be placed ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[5].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram (RAMB36E1.CLKARDCLK) cannot be placed ftop/pfconfig_i/afe0_adc_sub_i/u_ila_0/inst/ila_core_inst/ila_trace_memory_inst/SUBCORE_RAM_BLK_MEM_1.trace_block_memory/inst_blk_mem_gen/gnbram.gnativebmg.native_blk_mem_gen/valid.cstr/ramloop[5].ram.r/prim_noinit.ram/DEVICE_7SERIES.NO_BMM_INFO.SDP.SIMPLE_PRIM36.ram (RAMB36E1.CLKBWRCLK) cannot be placed Following this, there is a statement about the clocks associated with this: The above error could possibly be related to other connected instances. Following is a list of all the related clock rules and their respective instances. Clock Rule: rule_bufh_bufr_ramb Status: PASS Rule Description: Reginal buffers in the same clock region must drive a total number of brams less than the capacity of the region ftop/pfconfig_i/afe0_adc_sub_i/worker/clk_in_lvds.BUFR_inst (BUFR.O) is provisionally placed by clockplacer on BUFR_X1Y7 Clock Rule: rule_bufr_IoClkLds Status: PASS Rule Description: A BUFR driving any number of IOBs must be placed within the same clock region ftop/pfconfig_i/afe0_adc_sub_i/worker/clk_in_lvds.BUFR_inst (BUFR.O) is provisionally placed by clockplacer on BUFR_X1Y7 ftop/pfconfig_i/afe0_adc_sub_i/worker/supported_so_far.buf_data_loop[0].data_ddr (IDDR.C) is locked to ILOGIC_X1Y92 ftop/pfconfig_i/afe0_adc_sub_i/worker/supported_so_far.buf_data_loop[1].data_ddr (IDDR.C) is locked to ILOGIC_X1Y88 ftop/pfconfig_i/afe0_adc_sub_i/worker/supported_so_far.buf_data_loop[2].data_ddr (IDDR.C) is locked to ILOGIC_X1Y84 ftop/pfconfig_i/afe0_adc_sub_i/worker/supported_so_far.buf_data_loop[3].data_ddr (IDDR.C) is locked to ILOGIC_X1Y90 ftop/pfconfig_i/afe0_adc_sub_i/worker/supported_so_far.buf_data_loop[4].data_ddr (IDDR.C) is locked to ILOGIC_X1Y86 ftop/pfconfig_i/afe0_adc_sub_i/worker/supported_so_far.buf_data_loop[5].data_ddr (IDDR.C) is locked to ILOGIC_X1Y82 ftop/pfconfig_i/afe0_adc_sub_i/worker/supported_so_far.rx_frame_p_ddr (IDDR.C) is locked to ILOGIC_X1Y74 Clock Rule: rule_iotile_bufr Status: PASS Rule Description: An IO driving a BUFR must both be placed in the same clock region ftop/pfconfig_i/afe0_data_sub_i/worker/mode7.data_clk/UNSPECIFIED_gen.differential_prim.buf_generic.buf (IBUFDS.O) is locked to IOB_X1Y76 ftop/pfconfig_i/afe0_adc_sub_i/worker/clk_in_lvds.BUFR_inst (BUFR.I) is provisionally placed by clockplacer on BUFR_X1Y7 Clock Rule: rule_bufh_bufr_ramb Status: PASS Rule Description: Reginal buffers in the same clock region must drive a total number of brams less than the capacity of the region ftop/pfconfig_i/afe1_adc_sub_i/worker/clk_in_lvds.BUFR_inst (BUFR.O) is provisionally placed by clockplacer on BUFR_X1Y11 Clock Rule: rule_bufr_IoClkLds Status: PASS Rule Description: A BUFR driving any number of IOBs must be placed within the same clock region ftop/pfconfig_i/afe1_adc_sub_i/worker/clk_in_lvds.BUFR_inst (BUFR.O) is provisionally placed by clockplacer on BUFR_X1Y11 ftop/pfconfig_i/afe1_adc_sub_i/worker/supported_so_far.buf_data_loop[0].data_ddr (IDDR.C) is locked to ILOGIC_X1Y142 ftop/pfconfig_i/afe1_adc_sub_i/worker/supported_so_far.buf_data_loop[1].data_ddr (IDDR.C) is locked to ILOGIC_X1Y138 ftop/pfconfig_i/afe1_adc_sub_i/worker/supported_so_far.buf_data_loop[2].data_ddr (IDDR.C) is locked to ILOGIC_X1Y134 ftop/pfconfig_i/afe1_adc_sub_i/worker/supported_so_far.buf_data_loop[3].data_ddr (IDDR.C) is provisionally placed by clockplacer on ILOGIC_X1Y132 ftop/pfconfig_i/afe1_adc_sub_i/worker/supported_so_far.buf_data_loop[4].data_ddr (IDDR.C) is provisionally placed by clockplacer on ILOGIC_X1Y136 ftop/pfconfig_i/afe1_adc_sub_i/worker/supported_so_far.buf_data_loop[5].data_ddr (IDDR.C) is provisionally placed by clockplacer on ILOGIC_X1Y140 ftop/pfconfig_i/afe1_adc_sub_i/worker/supported_so_far.rx_frame_p_ddr (IDDR.C) is locked to ILOGIC_X1Y124 Clock Rule: rule_iotile_bufr Status: PASS Rule Description: An IO driving a BUFR must both be placed in the same clock region ftop/pfconfig_i/afe1_data_sub_i/worker/mode7.data_clk/UNSPECIFIED_gen.differential_prim.buf_generic.buf (IBUFDS.O) is locked to IOB_X1Y126 ftop/pfconfig_i/afe1_adc_sub_i/worker/clk_in_lvds.BUFR_inst (BUFR.I) is provisionally placed by clockplacer on BUFR_X1Y11 If I open the xpr and try the implementation, the following warning stands out to me: [Shape Builder 18-119] Failed to create BSCAN shape for instance ftop/pfconfig_i/afe1_adc_sub_i/dbg_hub/inst/BSCANID.u_xsdbm_id/SWITCH_N_EXT_BSCAN.bscan_inst/SERIES7_BSCAN.bscan_inst. Found overlapping instances within the shape: ftop/pfconfig_i/afe1_adc_sub_i/dbg_hub/inst/BSCANID.u_xsdbm_id/SWITCH_N_EXT_BSCAN.bscan_inst/SERIES7_BSCAN.bscan_inst and ftop/pfconfig_i/afe0_adc_sub_i/dbg_hub/inst/BSCANID.u_xsdbm_id/SWITCH_N_EXT_BSCAN.bscan_inst/SERIES7_BSCAN.bscan_inst. It's just a critical warning, but it seems potentially problematic. Later on there are also some warnings regarding a file called xsdbm_cc_late_late.xdc complaining about no such variables. Any help or insight would be very helpful. Thanks, Brian >
BP
Brian Padalino
Wed, Aug 5, 2020 5:15 PM

On Wed, Aug 5, 2020 at 12:42 PM Davis Hoover dhoover@geontech.com wrote:

The error suggests you are routing clock signals from multiple regions
(each region corresponding to an adc_sub instance) to a single location,
which is not possible. Assuming you inserted an ILA into the worker EDF,
I'm not sure why the placement algorithm would be considering the
routability of a BUFR from a separate worker instance... but it may be
worth double checking that the signals in your ILA include those from only
a single adc_sub.

I am using method 3.1.2 as described here:

https://opencpi.gitlab.io/releases/v1.7.0/docs/Debugging_Tools_Guide.pdf

Your statement about double checking that the signals in my ILA include
only a single adc_sub sounds difficult for me to do.  I imagine there are
going to be 2 ILA's instantiated since there are 2 adc_sub's instantiated
which are instrumented for debug.

The "Clock Rule" sections don't seem relevant since they all have "Status:
PASS".

Agreed.

Some background info:
BUFRs were originally chosen due to their high performance on Zynq 7 Series

  • performance which was necessary for the >240MHz data I/O clock for AD936x
    LVDS mode. The output of BUFRs can only be routed within a single clock
    region (7 series die is separated into 6 regions).

So it seems that maybe the way the ILA was resolved got Vivado confused
regarding clocks and what is actually accessing the ILA?

Do you think I should try a BUFG instead of a BUFR?  Or do you think I
should modify the adc_sub to include a DEBUG parameter and modify the build
that has the DEBUG parameter that is true for usage?

As an aside, is there a better way to do this?  Would it be easier to mark
the signals in the code using a generic or something?  I'd love to be able
to work from all source and not worry about all these EDIF netlists, but I
know that isn't feasible.

Brian

On Wed, Aug 5, 2020 at 12:42 PM Davis Hoover <dhoover@geontech.com> wrote: > The error suggests you are routing clock signals from multiple regions > (each region corresponding to an adc_sub instance) to a single location, > which is not possible. Assuming you inserted an ILA into the worker EDF, > I'm not sure why the placement algorithm would be considering the > routability of a BUFR from a separate worker instance... but it may be > worth double checking that the signals in your ILA include those from only > a single adc_sub. > I am using method 3.1.2 as described here: https://opencpi.gitlab.io/releases/v1.7.0/docs/Debugging_Tools_Guide.pdf Your statement about double checking that the signals in my ILA include only a single adc_sub sounds difficult for me to do. I imagine there are going to be 2 ILA's instantiated since there are 2 adc_sub's instantiated which are instrumented for debug. > > The "Clock Rule" sections don't seem relevant since they all have "Status: > PASS". > Agreed. > > Some background info: > BUFRs were originally chosen due to their high performance on Zynq 7 Series > - performance which was necessary for the >240MHz data I/O clock for AD936x > LVDS mode. The output of BUFRs can only be routed within a single clock > region (7 series die is separated into 6 regions). > So it seems that maybe the way the ILA was resolved got Vivado confused regarding clocks and what is actually accessing the ILA? Do you think I should try a BUFG instead of a BUFR? Or do you think I should modify the adc_sub to include a DEBUG parameter and modify the build that has the DEBUG parameter that is true for usage? As an aside, is there a better way to do this? Would it be easier to mark the signals in the code using a generic or something? I'd love to be able to work from all source and not worry about all these EDIF netlists, but I know that isn't feasible. Brian
BP
Brian Padalino
Wed, Aug 5, 2020 8:39 PM

On Wed, Aug 5, 2020 at 1:15 PM Brian Padalino bpadalino@gmail.com wrote:

On Wed, Aug 5, 2020 at 12:42 PM Davis Hoover dhoover@geontech.com wrote:

The error suggests you are routing clock signals from multiple regions
(each region corresponding to an adc_sub instance) to a single location,
which is not possible. Assuming you inserted an ILA into the worker EDF,
I'm not sure why the placement algorithm would be considering the
routability of a BUFR from a separate worker instance... but it may be
worth double checking that the signals in your ILA include those from only
a single adc_sub.

I am using method 3.1.2 as described here:

https://opencpi.gitlab.io/releases/v1.7.0/docs/Debugging_Tools_Guide.pdf

Your statement about double checking that the signals in my ILA include
only a single adc_sub sounds difficult for me to do.  I imagine there are
going to be 2 ILA's instantiated since there are 2 adc_sub's instantiated
which are instrumented for debug.

The "Clock Rule" sections don't seem relevant since they all have "Status:
PASS".

Agreed.

Some background info:
BUFRs were originally chosen due to their high performance on Zynq 7
Series

  • performance which was necessary for the >240MHz data I/O clock for
    AD936x
    LVDS mode. The output of BUFRs can only be routed within a single clock
    region (7 series die is separated into 6 regions).

So it seems that maybe the way the ILA was resolved got Vivado confused
regarding clocks and what is actually accessing the ILA?

Do you think I should try a BUFG instead of a BUFR?  Or do you think I
should modify the adc_sub to include a DEBUG parameter and modify the build
that has the DEBUG parameter that is true for usage?

Note that I was able to get around the error by using a BUFG instead of a
BUFR in the ad9361_adc_sub.  I looked through the DC and Switching
Characteristics for the Zynq family and it seemed that BUFR's were more
limited in maximum clock frequency than BUFG's, but it was still 400MHz or
better depending on the speed grade.

Brian

On Wed, Aug 5, 2020 at 1:15 PM Brian Padalino <bpadalino@gmail.com> wrote: > On Wed, Aug 5, 2020 at 12:42 PM Davis Hoover <dhoover@geontech.com> wrote: > >> The error suggests you are routing clock signals from multiple regions >> (each region corresponding to an adc_sub instance) to a single location, >> which is not possible. Assuming you inserted an ILA into the worker EDF, >> I'm not sure why the placement algorithm would be considering the >> routability of a BUFR from a separate worker instance... but it may be >> worth double checking that the signals in your ILA include those from only >> a single adc_sub. >> > > I am using method 3.1.2 as described here: > > https://opencpi.gitlab.io/releases/v1.7.0/docs/Debugging_Tools_Guide.pdf > > Your statement about double checking that the signals in my ILA include > only a single adc_sub sounds difficult for me to do. I imagine there are > going to be 2 ILA's instantiated since there are 2 adc_sub's instantiated > which are instrumented for debug. > > >> >> The "Clock Rule" sections don't seem relevant since they all have "Status: >> PASS". >> > > Agreed. > > >> >> Some background info: >> BUFRs were originally chosen due to their high performance on Zynq 7 >> Series >> - performance which was necessary for the >240MHz data I/O clock for >> AD936x >> LVDS mode. The output of BUFRs can only be routed within a single clock >> region (7 series die is separated into 6 regions). >> > > So it seems that maybe the way the ILA was resolved got Vivado confused > regarding clocks and what is actually accessing the ILA? > > Do you think I should try a BUFG instead of a BUFR? Or do you think I > should modify the adc_sub to include a DEBUG parameter and modify the build > that has the DEBUG parameter that is true for usage? > Note that I was able to get around the error by using a BUFG instead of a BUFR in the ad9361_adc_sub. I looked through the DC and Switching Characteristics for the Zynq family and it seemed that BUFR's were more limited in maximum clock frequency than BUFG's, but it was still 400MHz or better depending on the speed grade. Brian >
DH
Davis Hoover
Wed, Aug 5, 2020 8:57 PM

Agreed replacement w/ BUFG is a sensible workaround to allow you to debug
your problem using ILAs. I'd recommend glancing at the timing report to see
if there are any violations.

Note that limitations due to switching characteristics/FMAX are independent
of limitations due to placability and routability. I seem to remember the
clock skew caused by long IOB-BUFG-IOB/DDR routes would cause timing
failure. IOB-BUFR-IOB resulted in routes that were much shorter, and closer
in value to the data route delays (thereby reducing skew).

---------- Forwarded message ---------
From: Brian Padalino bpadalino@gmail.com
Date: Wed, Aug 5, 2020 at 4:39 PM
Subject: Re: [Discuss OpenCPI] Vivado Multiple Instantiation Debug Cores
To: Davis Hoover dhoover@geontech.com
Cc: discuss@lists.opencpi.org

On Wed, Aug 5, 2020 at 1:15 PM Brian Padalino bpadalino@gmail.com wrote:

On Wed, Aug 5, 2020 at 12:42 PM Davis Hoover dhoover@geontech.com wrote:

The error suggests you are routing clock signals from multiple regions
(each region corresponding to an adc_sub instance) to a single location,
which is not possible. Assuming you inserted an ILA into the worker EDF,
I'm not sure why the placement algorithm would be considering the
routability of a BUFR from a separate worker instance... but it may be
worth double checking that the signals in your ILA include those from only
a single adc_sub.

I am using method 3.1.2 as described here:

https://opencpi.gitlab.io/releases/v1.7.0/docs/Debugging_Tools_Guide.pdf

Your statement about double checking that the signals in my ILA include
only a single adc_sub sounds difficult for me to do.  I imagine there are
going to be 2 ILA's instantiated since there are 2 adc_sub's instantiated
which are instrumented for debug.

The "Clock Rule" sections don't seem relevant since they all have "Status:
PASS".

Agreed.

Some background info:
BUFRs were originally chosen due to their high performance on Zynq 7
Series

  • performance which was necessary for the >240MHz data I/O clock for
    AD936x
    LVDS mode. The output of BUFRs can only be routed within a single clock
    region (7 series die is separated into 6 regions).

So it seems that maybe the way the ILA was resolved got Vivado confused
regarding clocks and what is actually accessing the ILA?

Do you think I should try a BUFG instead of a BUFR?  Or do you think I
should modify the adc_sub to include a DEBUG parameter and modify the build
that has the DEBUG parameter that is true for usage?

Note that I was able to get around the error by using a BUFG instead of a
BUFR in the ad9361_adc_sub.  I looked through the DC and Switching
Characteristics for the Zynq family and it seemed that BUFR's were more
limited in maximum clock frequency than BUFG's, but it was still 400MHz or
better depending on the speed grade.

Brian

Agreed replacement w/ BUFG is a sensible workaround to allow you to debug your problem using ILAs. I'd recommend glancing at the timing report to see if there are any violations. Note that limitations due to switching characteristics/FMAX are independent of limitations due to placability and routability. I seem to remember the clock skew caused by long IOB-BUFG-IOB/DDR routes would cause timing failure. IOB-BUFR-IOB resulted in routes that were much shorter, and closer in value to the data route delays (thereby reducing skew). ---------- Forwarded message --------- From: Brian Padalino <bpadalino@gmail.com> Date: Wed, Aug 5, 2020 at 4:39 PM Subject: Re: [Discuss OpenCPI] Vivado Multiple Instantiation Debug Cores To: Davis Hoover <dhoover@geontech.com> Cc: <discuss@lists.opencpi.org> On Wed, Aug 5, 2020 at 1:15 PM Brian Padalino <bpadalino@gmail.com> wrote: > On Wed, Aug 5, 2020 at 12:42 PM Davis Hoover <dhoover@geontech.com> wrote: > >> The error suggests you are routing clock signals from multiple regions >> (each region corresponding to an adc_sub instance) to a single location, >> which is not possible. Assuming you inserted an ILA into the worker EDF, >> I'm not sure why the placement algorithm would be considering the >> routability of a BUFR from a separate worker instance... but it may be >> worth double checking that the signals in your ILA include those from only >> a single adc_sub. >> > > I am using method 3.1.2 as described here: > > https://opencpi.gitlab.io/releases/v1.7.0/docs/Debugging_Tools_Guide.pdf > > Your statement about double checking that the signals in my ILA include > only a single adc_sub sounds difficult for me to do. I imagine there are > going to be 2 ILA's instantiated since there are 2 adc_sub's instantiated > which are instrumented for debug. > > >> >> The "Clock Rule" sections don't seem relevant since they all have "Status: >> PASS". >> > > Agreed. > > >> >> Some background info: >> BUFRs were originally chosen due to their high performance on Zynq 7 >> Series >> - performance which was necessary for the >240MHz data I/O clock for >> AD936x >> LVDS mode. The output of BUFRs can only be routed within a single clock >> region (7 series die is separated into 6 regions). >> > > So it seems that maybe the way the ILA was resolved got Vivado confused > regarding clocks and what is actually accessing the ILA? > > Do you think I should try a BUFG instead of a BUFR? Or do you think I > should modify the adc_sub to include a DEBUG parameter and modify the build > that has the DEBUG parameter that is true for usage? > Note that I was able to get around the error by using a BUFG instead of a BUFR in the ad9361_adc_sub. I looked through the DC and Switching Characteristics for the Zynq family and it seemed that BUFR's were more limited in maximum clock frequency than BUFG's, but it was still 400MHz or better depending on the speed grade. Brian >
Empathy v1.0   2024 ©Harmonylists.com