UltraScale+ MPSoC CSI-2 - No routable loads

[pablo.leyva]

Hi everyone,

We are developing an FMC board with 4 CSI-2 Lanes which will be used in conjunction with the XZCU102 development board and Xilinx CSI-2 IPs using the UltraScale+ D-PHY buffers.

To check the feasibility of the proposed FMC pinout I want to run a test bitstream generation with the proposed pin location, but I am facing always the same kind of output warning:

[DRC RTSTAT-10] No routable loads: 118 net(s) have no routable loads. The problem bus(es) and/or net(s) are design_1_i/axis_data_fifo_0/inst/gen_fifo_generator.fifo_generator_inst/inst_fifo_gen/gaxis_fifo.gaxisf.axisf/grf.rf/gntv_or_sync_fifo.gl0.rd/gr1.gr1_int.rfwft/aempty_fwft_i
design_1_i/mipi_csi2_tx_subsystem_0/inst/mipi_dphy_0/inst/bd_1d96_mipi_dphy_0_0_tx_support_i/master_tx.dphy_tx_fab_top/u_tx_clk_lane/cl_status_reg_bit_2
design_1_i/mipi_csi2_tx_subsystem_0/inst/mipi_dphy_0/inst/bd_1d96_mipi_dphy_0_0_tx_support_i/master_tx.dphy_tx_fab_top/gen_tx_data_lane[3].u_tx_data_lane/u_tx_hs_datapath/data_hs[7:0]
design_1_i/mipi_csi2_tx_subsystem_0/inst/mipi_dphy_0/inst/bd_1d96_mipi_dphy_0_0_tx_support_i/master_tx.dphy_tx_fab_top/gen_tx_data_lane[2].u_tx_data_lane/u_tx_hs_datapath/data_hs[7:0]
design_1_i/mipi_csi2_tx_subsystem_0/inst/mipi_dphy_0/inst/bd_1d96_mipi_dphy_0_0_tx_support_i/master_tx.dphy_tx_fab_top/gen_tx_data_lane[0].u_tx_data_lane/u_tx_hs_datapath/data_hs[7:0]
design_1_i/mipi_csi2_tx_subsystem_0/inst/mipi_dphy_0/inst/bd_1d96_mipi_dphy_0_0_tx_support_i/master_tx.dphy_tx_fab_top/gen_tx_data_lane[1].u_tx_data_lane/u_tx_hs_datapath/data_hs[7:0]
design_1_i/mipi_csi2_tx_subsystem_0/inst/mipi_dphy_0/inst/bd_1d96_mipi_dphy_0_0_tx_support_i/master_tx.dphy_tx_fab_top/gen_tx_data_lane[1].u_tx_data_lane/u_tx_hs_datapath/hs_dp_quadtrature_r[15:0]
design_1_i/mipi_csi2_tx_subsystem_0/inst/mipi_dphy_0/inst/bd_1d96_mipi_dphy_0_0_tx_support_i/master_tx.dphy_tx_fab_top/gen_tx_data_lane[2].u_tx_data_lane/u_tx_hs_datapath/hs_dp_quadtrature_r[15:0]
design_1_i/mipi_csi2_tx_subsystem_0/inst/mipi_dphy_0/inst/bd_1d96_mipi_dphy_0_0_tx_support_i/master_tx.dphy_tx_fab_top/gen_tx_data_lane[3].u_tx_data_lane/u_tx_hs_datapath/hs_dp_quadtrature_r[15:0]
design_1_i/mipi_csi2_tx_subsystem_0/inst/mipi_dphy_0/inst/bd_1d96_mipi_dphy_0_0_tx_support_i/master_tx.dphy_tx_fab_top/gen_tx_data_lane[0].u_tx_data_lane/u_tx_hs_datapath/hs_dp_quadtrature_r[15:0]
design_1_i/mipi_csi2_tx_subsystem_0/inst/mipi_csi2_tx_ctrl_0/inst/line_buffer/U0/inst_fifo_gen/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.gl0.wr/gwss.wsts/p_15_out, design_1_i/mipi_csi2_tx_subsystem_0/inst/mipi_csi2_tx_ctrl_0/inst/generic_fifo/U0/inst_fifo_gen/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.gl0.wr/gwss.wsts/p_15_out
design_1_i/mipi_csi2_tx_subsystem_0/inst/mipi_csi2_tx_ctrl_0/inst/dist_fifo/U0/inst_fifo_gen/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.gl0.wr/gwss.wsts/p_15_out, design_1_i/axis_data_fifo_0/inst/gen_fifo_generator.fifo_generator_inst/inst_fifo_gen/gaxis_fifo.gaxisf.axisf/grf.rf/gntv_or_sync_fifo.gl0.rd/gras.rsts/ram_empty_i
design_1_i/mipi_csi2_tx_subsystem_0/inst/mipi_csi2_tx_ctrl_0/inst/clock_cross_fifo/U0/inst_fifo_gen/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.gl0.wr/gwas.wsts/ram_full_i... and (the first 15 of 28 listed).

The write_bitstream is complete and inspecting the implemented design all the externals connections seems to be there. I am generating the design with a hardware evaluation license in Vivado 2017.1

I have tried with different pins locations and always the same results.

• Are these warnings related to the evaluation license?
• Am I configuring something wrong?

Another question regarding the D-PHY buffers (I didn't find this information in any document)

• Are the +/- pins of the D-PHY buffers swappable? (to simplify PCB routing)

Thanks in advance for your time :)

Regards,

Pablo

[florentw]

Hi @pablo.leyva,

Could you share a test case? I might help to understand.

Are these warnings related to the evaluation license?

It is very unlikely. If there is a warning because of evaluation license, the tool will tell you

Am I configuring something wrong?

Maybe. It is hard to say only from the log. This is why I am asking for a test case.

On US+, the placement should be done using the GUI. Make sure this is what you are doing

Are the +/- pins of the D-PHY buffers swappable? (to simplify PCB routing)

I am not sure about this as I am not silicon expert. But I would say that if you swap the pin when connected the IP it might work (this is not GTs). However, this needs to be confirmed. As a general advice, you should always try to respect the polarity. It is easier :)

Regards,

Florent

[nikorenic]

Hi @florentw,

Any update on this?
I'm facing a similar issue with MIPI CSI-2 Tx Subsystem on my Ultrascale+ design (Vivado 2020.2). The issue can be easily reproduced with minimal design for the kcu116 (see images in an attachment). 
Despite the DRC warning below, bitstream will generate successfully.

[DRC RTSTAT-10] No routable loads: 103 net(s) have no routable loads. The problem bus(es) and/or net(s) are 
design_1_i/mipi_csi2_tx_subsyst_0/U0/mipi_dphy_0/inst/inst/bd_d70b_mipi_dphy_0_0_tx_support_i/master_tx.dphy_tx_fab_top/u_tx_clk_lane/cl_status_reg_bit_1, 
design_1_i/mipi_csi2_tx_subsyst_0/U0/mipi_dphy_0/inst/inst/bd_d70b_mipi_dphy_0_0_tx_support_i/master_tx.dphy_tx_fab_top/u_tx_clk_lane/cl_status_reg_bit_2, 
design_1_i/mipi_csi2_tx_subsyst_0/U0/mipi_dphy_0/inst/inst/bd_d70b_mipi_dphy_0_0_tx_support_i/master_tx.dphy_tx_fab_top/u_tx_clk_lane/cl_status_reg_bit_4, 
design_1_i/mipi_csi2_tx_subsyst_0/U0/mipi_dphy_0/inst/inst/bd_d70b_mipi_dphy_0_0_tx_support_i/master_tx.dphy_tx_fab_top/gen_tx_data_lane[0].u_tx_data_lane/u_tx_hs_datapath/data_hs[7:0], 
design_1_i/mipi_csi2_tx_subsyst_0/U0/mipi_dphy_0/inst/inst/bd_d70b_mipi_dphy_0_0_tx_support_i/master_tx.dphy_tx_fab_top/gen_tx_data_lane[3].u_tx_data_lane/u_tx_hs_datapath/data_hs[7:0], 
design_1_i/mipi_csi2_tx_subsyst_0/U0/mipi_dphy_0/inst/inst/bd_d70b_mipi_dphy_0_0_tx_support_i/master_tx.dphy_tx_fab_top/gen_tx_data_lane[1].u_tx_data_lane/u_tx_hs_datapath/data_hs[7:0], 
design_1_i/mipi_csi2_tx_subsyst_0/U0/mipi_dphy_0/inst/inst/bd_d70b_mipi_dphy_0_0_tx_support_i/master_tx.dphy_tx_fab_top/gen_tx_data_lane[2].u_tx_data_lane/u_tx_hs_datapath/data_hs[7:0], 
design_1_i/mipi_csi2_tx_subsyst_0/U0/mipi_dphy_0/inst/inst/bd_d70b_mipi_dphy_0_0_tx_support_i/master_tx.dphy_tx_fab_top/gen_tx_data_lane[3].u_tx_data_lane/gen_tx_esc_datapath.u_tx_esc_datapath/esc_stopstate_reg_0, 
design_1_i/mipi_csi2_tx_subsyst_0/U0/mipi_dphy_0/inst/inst/bd_d70b_mipi_dphy_0_0_tx_support_i/master_tx.dphy_tx_fab_top/gen_tx_data_lane[0].u_tx_data_lane/gen_tx_esc_datapath.u_tx_esc_datapath/esc_stopstate_reg_0, 
design_1_i/mipi_csi2_tx_subsyst_0/U0/mipi_dphy_0/inst/inst/bd_d70b_mipi_dphy_0_0_tx_support_i/master_tx.dphy_tx_fab_top/gen_tx_data_lane[2].u_tx_data_lane/gen_tx_esc_datapath.u_tx_esc_datapath/esc_stopstate_reg_0, 
design_1_i/mipi_csi2_tx_subsyst_0/U0/mipi_dphy_0/inst/inst/bd_d70b_mipi_dphy_0_0_tx_support_i/master_tx.dphy_tx_fab_top/gen_tx_data_lane[1].u_tx_data_lane/gen_tx_esc_datapath.u_tx_esc_datapath/esc_stopstate_reg_0, 
design_1_i/mipi_csi2_tx_subsyst_0/U0/mipi_dphy_0/inst/inst/bd_d70b_mipi_dphy_0_0_tx_support_i/master_tx.dphy_tx_fab_top/gen_tx_data_lane[1].u_tx_data_lane/u_tx_hs_datapath/hs_dp_quadtrature_r[15:0], 
design_1_i/mipi_csi2_tx_subsyst_0/U0/mipi_dphy_0/inst/inst/bd_d70b_mipi_dphy_0_0_tx_support_i/master_tx.dphy_tx_fab_top/gen_tx_data_lane[2].u_tx_data_lane/u_tx_hs_datapath/hs_dp_quadtrature_r[15:0], 
design_1_i/mipi_csi2_tx_subsyst_0/U0/mipi_dphy_0/inst/inst/bd_d70b_mipi_dphy_0_0_tx_support_i/master_tx.dphy_tx_fab_top/gen_tx_data_lane[0].u_tx_data_lane/u_tx_hs_datapath/hs_dp_quadtrature_r[15:0], 
and design_1_i/mipi_csi2_tx_subsyst_0/U0/mipi_dphy_0/inst/inst/bd_d70b_mipi_dphy_0_0_tx_support_i/master_tx.dphy_tx_fab_top/gen_tx_data_lane[3].u_tx_data_lane/u_tx_hs_datapath/hs_dp_quadtrature_r[15:0].

[florentw]

HI @nikorenic 

There is no update as I never received any reply from the initial user.

Please create a new topic for your issue. As you are saying that this is easily reproducible you might want to add a test case.