Closed norumwe12 closed 3 years ago
It does not need to be CC pin in White Rabbit application. It is used by the DDMTD phase detector as a helper signal.
O.K. So the correct choice for a non-White Rabbit Marble µBlaze system reference is U8 instead? What frequency does it provide? Or is the preferred choice Y2/U20?
On Sep 10, 2020, at 1:50 AM, Greg Kasprowicz notifications@github.com wrote:
It does not need to be CC pin in White Rabbit application. It is used by the DDMTD phase detector as a helper signal.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/BerkeleyLab/Marble/issues/4#issuecomment-690090987, or unsubscribe https://github.com/notifications/unsubscribe-auth/AECM3GGAQCNQ7GX6KMICAK3SFCHO5ANCNFSM4RD6CKGA.
The workaround is to use the CLOCK_DEDICATED_ROUTE constraint. Xilinx's concern is that the phase between the pin and fabric (MMCM) is not deterministic in this configuration (will vary with every place&route run). That's not a problem for a frequency input like this. Nothing else on the board uses that signal. You really don't want to use a non-CC pin for a clock input with associated data pins.
The CLK20 signal is a perfectly valid choice for operation. Y2/U20 is intended as the communications master clock, since it can drive all of the GTX, RGMII PHY, and fabric. (Actually we switched, and now populate Y1 instead of Y2, just due to availability of parts.)
Thanks for the clarification. I’m curious still about the frequency that you plan for U8.
On Sep 10, 2020, at 8:12 AM, Larry Doolittle notifications@github.com wrote:
The workaround is to use the CLOCK_DEDICATED_ROUTE constraint. Xilinx's concern is that the phase between the pin and fabric (MMCM) is not deterministic in this configuration (will vary with every place&route run). That's not a problem for a frequency input like this. Nothing else on the board uses that signal. You really don't want to use a non-CC pin for a clock input with associated data pins.
The CLK20 signal is a perfectly valid choice for operation. Y2/U20 is intended as the communications master clock, since it can drive all of the GTX, RGMII PHY, and fabric. (Actually we switched, and now populate Y1 instead of Y2, just due to availability of parts.)
I’m still missing some step.
Constraints:
set_property -dict {PACKAGE_PIN W11 IOSTANDARD LVCMOS15} [get_ports CLK20_VCXO] set_property CLOCK_DEDICATED_ROUTE true [get_nets CLK20_VCXO]
But: ERROR: [Place 30-575] Sub-optimal placement for a clock-capable IO pin and MMCM 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. < set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets bd_i/clk_wiz_1/inst/clk_in1_bd_clk_wiz_1_0] >
bd_i/clk_wiz_1/inst/clkin1_ibufg (IBUF.O) is locked to IOB_X1Y97
bd_i/clk_wiz_1/inst/mmcm_adv_inst (MMCME2_ADV.CLKIN1) is provisionally placed by clockplacer on MMCME2_ADV_X1Y2
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_mmcm_bufg
Status: PASS
Rule Description: An MMCM driving a BUFG must be placed on the same half side (top/bottom) of the device
bd_i/clk_wiz_1/inst/mmcm_adv_inst (MMCME2_ADV.CLKFBOUT) is provisionally placed by clockplacer on MMCME2_ADV_X1Y2
bd_i/clk_wiz_1/inst/clkf_buf (BUFG.I) is provisionally placed by clockplacer on BUFGCTRL_X0Y0
On Sep 10, 2020, at 8:12 AM, Larry Doolittle notifications@github.com wrote:
The workaround is to use the CLOCK_DEDICATED_ROUTE constraint.
Please ignore — I read the error message a little more closely — the answer is there.
I’m still missing some step.
Constraints:
20 MHz from Y3
The CLOCK_DEDICATED_ROUTE is acceptable here since
the pin drives only the clock input of an MMCM.
set_property -dict {PACKAGE_PIN W11 IOSTANDARD LVCMOS15} [get_ports CLK20_VCXO] set_property CLOCK_DEDICATED_ROUTE true [get_nets CLK20_VCXO]
But: ERROR: [Place 30-575] Sub-optimal placement for a clock-capable IO pin and MMCM 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. < set_property CLOCK_DEDICATED_ROUTE FALSE [get_nets bd_i/clk_wiz_1/inst/clk_in1_bd_clk_wiz_1_0] >
bd_i/clk_wiz_1/inst/clkin1_ibufg (IBUF.O) is locked to IOB_X1Y97 bd_i/clk_wiz_1/inst/mmcm_adv_inst (MMCME2_ADV.CLKIN1) is provisionally placed by clockplacer on MMCME2_ADV_X1Y2 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_mmcm_bufg Status: PASS Rule Description: An MMCM driving a BUFG must be placed on the same half side (top/bottom) of the device bd_i/clk_wiz_1/inst/mmcm_adv_inst (MMCME2_ADV.CLKFBOUT) is provisionally placed by clockplacer on MMCME2_ADV_X1Y2 bd_i/clk_wiz_1/inst/clkf_buf (BUFG.I) is provisionally placed by clockplacer on BUFGCTRL_X0Y0
On Sep 10, 2020, at 8:12 AM, Larry Doolittle <notifications@github.com mailto:notifications@github.com> wrote:
The workaround is to use the CLOCK_DEDICATED_ROUTE constraint.
I’m curious still about the frequency that you plan for U8.
No plan. Application-dependent. Anything for which the on-chip MMCM/PLL features are inadequate. For power and EMI reasons, it should be disabled when not used.
Can be closed
The CLK20_VCXO_T line doesn’t connect to a clock-capable pin. This generates an error when driving an MMCM.