[Question]: Post-Route DRC in SHELL clock nets.

[sajjadahmed677]

Hi all,

I am getting the following error on post-route drc stage and didn't find any relevant explanation for the error can someone guide me on what could be the possible reason for this.

ERROR: [Constraints 18-4640] HDPostRouteDRC-10: the clock net WRAPPER_INST/SH/kernel_clks_i/clkwiz_sys_clk/inst/CLK_CORE_DRP_I/clk_inst/clk_out1 does not honor routing containment requirement due to routing nodes: CMT_L_X72Y420/CLK_CMT_MUX_16_ENC_13_CLK_OUT CMT_L_X72Y420/CLK_CMT_MUX_2TO1_106_CLK_OUT CMT_L_X72Y420/CLK_CMT_MUX_2TO1_107_CLK_OUT RCLK_CLEM_CLKBUF_L_X71Y449/CLK_HROUTE_R13 RCLK_CLEM_CLKBUF_L_X80Y449/CLK_HROUTE_L13

Thanks,

[AWScsaralay]

Hello,

The WRAPPER_INST/SH/kernel_clks_i/clkwiz_sys_clk/inst/CLK_CORE_DRP_I/clk_inst/clk_out1 is in fact the clk_main_a0 provided from the Shell to the CL. Based on the error message, it looks like the clock route chosen by the tool during routing does not honor the Hierarchical Design Rule Checks.

Have you tried running the builds using different build strategies, or different placement/routing directives? https://github.com/aws/aws-fpga/blob/master/hdk/common/shell_v04261818/build/scripts/aws_build_dcp_from_cl.sh#L21

Thanks! Chakra

[sajjadahmed677]

Hi Chakra,

Thanks for your response. Yes i have tried different placement/routing directives. It looks like an issue with clock routing out side the pblock. would you please point me to the script where pblocks are created.

Thanks,

[AWScsaralay]

The pblocks for the Shell are already fixed. Users are not allowed to change the pblock definitions of the Shell, otherwise the CL design will not be compatible with AWS Shell.

The CL designs can have their own pblocks defined. For example, please refer to CL_DRAM_DMA example where the pblock constraints are defined in: https://github.com/aws/aws-fpga/blob/master/hdk/cl/examples/cl_dram_dma/build/constraints/cl_pnr_user.xdc

...and are read during build scripts here: https://github.com/aws/aws-fpga/blob/master/hdk/cl/examples/cl_dram_dma/build/scripts/create_dcp_from_cl.tcl#L248

Let me know if you need anything else. Will be happy to help.

Thanks! Chakra

[sajjadahmed677]

Alright, in that case if you could help me to localize the issue i am facing with clk_main_a0 routing.

in my design i have following clock structure.

clk_main_a0 --> BUFGCE_DIV (for dividing frequency by 8) --> BUFGCE (for clock gating)

Here the purpose of clock gating is not power optimization but it is a design requirement. so major part of the design runs on slower frequency and the part which communicates with SHELL runs on clk_main_a0.

with this clock structure and SSI placer directives i am facing the above mentioned error after routing. and didn't find any useful information to resolve this.

Thanks,

[AWScsaralay]

Hello, thanks for sharing these info. We will review this use case of using clk_main_a0 through clock divider and through clock gating primitive.

In the meantime, could you please try couple of items and let us know the behavior?

1. Does the routing go through successfully if you reduced resource utilization of the design (maybe build design with fewer logic but keep same clock tree?)
2. Try implementing an MMCM/PLL IP for slower clocks (instead of dividing clk_main_a0), and then synchronize the signals connecting to Shell interface using clk_main_a0?

Thanks! Chakra

[sajjadahmed677]

1. Yes i got the design routed successfully and the error i have mentioned is encountered at post-route DRC.
2. I have tried MMCM/PLL IP before using BUFGCE* for clock network but couldn't get the MMCM/PLL to place. i throws the following error. ERROR: [Place 30-718] Sub-optimal placement for an MMCM/PLL-BUFGCE-MMCM/PLL cascade pair.If this sub optimal condition is acceptable for this design, you may use the CLOCK_DEDICATED_ROUTE constraint in the .xdc file to demote this message to a WARNING. However, the use of this override is highly discouraged. These examples can be used directly in the .xdc file to override this clock rule.

I have tried bypassing this error but didn't get the design routed. I would appreciate the help for any of the case i.e for BUFGCE* clock network or with MMCM/PLL IP.

Thanks,

[AWScsaralay]

Hi,

We reached out to AMD/Xilinx for more recommendations to mitigate your issue:

For option#1 -- AMD/Xilinx has following suggestions:

• can the design work with just clk_main_a0 -> BUFGCE -> load/logic?
• For most customers who use the clock as-is, it routes seamlessly. I wonder if the issue is on running out of BUFG/clock resources due to 2 new clock nets from BUFGCE_DIV and BUFGCE. Reducing the number of clocks should help.

For option#2 -- where MMCM is instantiated to generate slower clocks, but runs into "Sub-optimal placement errors" -- AMD/Xilinx referred to the link below:
https://support.xilinx.com/s/article/70418?language=en_US

Thanks! Chakra

[sajjadahmed677]

Hi Chakra,

Thanks for your response i am looking into the MMCM/PLL option but for that i have a question.

When implementing an MMCM/PLL to generate our slower clocks what clock source is recommended to use for CLK IN?

Thanks,

[AWScsaralay]

Hi,

You should be able to use clk_main_a0 or any other clocks provided by the Shell as clk_in for your MMCM IP. Please make sure to select "No Buffer" in the GUI at the time of configuring the MMCM IP, since the clock coming from Shell is already buffered. Please let us know if you have any questions.

Thanks! Chakra

[sajjadahmed677]

Hi,

Thanks for your support i was able to build the design by following the provided suggestions.

Regards, Sajjad