BerkeleyLab / Marble

Dual FMC FPGA carrier board developed for general purpose use in particle accelerator electronics instrumentation.
22 stars 8 forks source link

CLK20_VCXO_T line doesn’t drive a clock-capable pin. #4

Closed norumwe12 closed 3 years ago

norumwe12 commented 4 years ago

The CLK20_VCXO_T line doesn’t connect to a clock-capable pin. This generates an error when driving an MMCM.

gkasprow commented 4 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.

norumwe12 commented 4 years ago

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.

ldoolitt commented 4 years ago

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.)

norumwe12 commented 4 years ago

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.)

norumwe12 commented 4 years ago

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 wrote:

The workaround is to use the CLOCK_DEDICATED_ROUTE constraint.

norumwe12 commented 4 years ago

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.

ldoolitt commented 4 years ago

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.

michalgaska commented 3 years ago

Can be closed