cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
w.helsby@dl.ac.uk
Participant
Participant
4,416 Views
Registered: ‎10-15-2015

MMCMe2_ADV will not lock after multiple resets

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.

 

Thank you

William.

 

0 Kudos
5 Replies
w.helsby@dl.ac.uk
Participant
Participant
4,396 Views
Registered: ‎10-15-2015

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.

 

William.

0 Kudos
w.helsby@dl.ac.uk
Participant
Participant
4,391 Views
Registered: ‎10-15-2015

Screen dump of reload forced by software for a working MMCM

reload_working2.jpg

 

Screen dump of hung (not locked) MMCM. Note AXI cycle but no other activity.

reload_not_working2.jpg

 

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?

 

reload_not_working2.jpg
reload_working2.jpg
0 Kudos
ralfk
Xilinx Employee
Xilinx Employee
4,376 Views
Registered: ‎10-11-2007

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.

0 Kudos
w.helsby@dl.ac.uk
Participant
Participant
4,293 Views
Registered: ‎10-15-2015

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?

 

 

0 Kudos
w.helsby@dl.ac.uk
Participant
Participant
4,241 Views
Registered: ‎10-15-2015

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.

See:

reset_10x_slow.jpg

 

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,

 

And then:

process (dclk) -- Delay reset 1/2 a clock cycle to allow better hold time on reset from dclk.
BEGIN
IF dclk'EVENT AND dclk='0' THEN
reset_del <= reset;
END IF;
END PROCESS;
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.

 

 

 

 

P.S.

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. 

 

0 Kudos