05-10-2017 05:27 AM
We have a design with a MMCME2 buffering and phase shifting a data stream clock from an ADC board.
The clock is 100 MHz. To allow synchronisation across boards the clock can be selected externally (by a CDCLVP1212) from a per board or central clock source.
The output clocks are all 100 MHz, but at 3 different phases to allow from varying track lengths. The design uses the Clocking Wizzard with AXI DRP using the write DRP register version. I only use the DRP functionality to varying the phase to investigate the setup/hold margin on our external data input. It is not used for reconfiguration in normal use, though allows various tests.
My understanding is that I should reset the MMCM when I switch the external clock.
However, I noticed that occasionally the MMCM was not locked after selecting the clock source.
Investing using the AXI port to reset the MMCM shows that after a random number of order 10 tests applying the reset (from software), the MMCM stops locking after reset.
Subsequent resets will not cause it to lock.
Forcing a reload of the DRP registers to the clocking wizard values (write 1 to 0x35C) does not make the MMCM lock
Forcing a reconfiguration of the FPGA is required to make the MMCM lock again.
The Clocking wizard shows CLKFBOUT_MULT_F 9. So my understanding is that the VCO frequency is 900 MHz (well in range)
Bandwidth = Optimised.
The clock source in LMK61E2, buffered by CDCLVP1212 followed by another CDCLVP1212 followed by DS10BR150TSD LVPECL to LVDS
We will investigate the clock input quality, though I don't understand why this changes with reseting the MMCM.
The Vivado logic analyser has been use to confirm that the reset reaches the MMCME2 primitive.
I am building an ila core to study more of the DRP signals, though I don't know what I am looking for .. to check the drp control logic has not got confused.
Has anyone any suggestions as to how I get the MMCM confused to the point it needs a reconfiguration to recover?
I can remove my firmware reset to the MMCM, though this does not seem the right think to do. Reseting after a clock changes seems correct.
05-10-2017 07:53 AM
We have measured the clock to the FPGA and see a minimum period 9.998 ns, maximum 10.002 ns.
So source clock jitter does not appear to be issue.
05-10-2017 08:49 AM
Screen dump of reload forced by software for a working MMCM
Screen dump of hung (not locked) MMCM. Note AXI cycle but no other activity.
I assume that the IP is deliberately not doing a reload because the MMCM is not locked. The data sheet does refer to checking for locked first. .. This may be a deadlock if the core cannot be made to return to locked?
Does anyone know why it is is not acceptable to reload the DRP if the MMCM is not locked?
05-10-2017 11:21 AM
I think you are correct. No DRP changes are made when the MMCM is not LOCKED. This safeguards against problems when the DRP clock comes from the very same MMCM you are trying to change via the DRP.
05-11-2017 09:12 AM
I have made a version of the design (IF .. GENERATE) which does not use drp, but allows me to reset to MMCM from a software register (clocked by the same 100 MHz clock as I was using for the AXI DRP interface)
This has passed 10000 passes of reseting the MMCM.
So I suggest that some timing of the reset relative to the DRP clock can cause the MMCM to hang?
05-12-2017 03:32 AM
I have made a local copy of the Clocking wizard IP and modified the design to increase the timing separation from dclk to reset.
Externally I have used a 10 MHz axi_aclk, from another output of a MMCM which makes my main 100 MHz axi_aclk. I have supplied the 10 MHz clock to the appropriate m<n>_aclk pin of the AXI interconnect IP to generate clock domain crossing.
Within the local copy of the IP I have delayed the reset signal to the MMCM by 1/2 a clock cycle by feeding it through a register clocked by the falling edge of the 10 MHz clock. The result is approximately 50 ns hold and 50 ns reset recovery time between reset dclk.
Only one file needs modified <ip_name>_drp_clk_wiz.vhd
signal reset_del : std_logic;
In clk_inst: adc_clk_mmcm_drp_clk_wiz
-- Status and control signals
reset => reset_del,
process (dclk) -- Delay reset 1/2 a clock cycle to allow better hold time on reset from dclk.
IF dclk'EVENT AND dclk='0' THEN
reset_del <= reset;
end architecture imp;
This has passed 100,000 passes of reseting the MMCM successfully.
I think it is very likely that this should be regarded as solved and Xilinx should update their IP to be similar and/or recommend a slower fmax for dclk, though I have not tested whether it is the lower frequency or extra 1/2 cycle delay which makes the difference.
I now plan to test in closely related design which is in a Zynq.
I still don't understand why re-configuring a MMCM which is not locked it actively prevented.
Generally a reconfigure will assert reset, so as far as I understand it will stop the output clock, so it is impossible to use the output of an MMCM to drive the s_axi_aclk input of the same MMCM. The only exception I see could be the MMCME3 using the cddcreq input.