UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor flitch@home
Visitor
6,588 Views
Registered: ‎03-09-2010

V5 DCM / PLL / CMT reset and lock problem

Jump to solution

Hi,

 

I have a problem with a FX130T design.

 

Basically, following configuration (via any method JTAG  or select MAP CFI FLASH) the FPGA configures OK but the processors do not run. The problem appears to be that the DCM_LOCK signal is slow to establish.

 

Reading the status registers with IMPACT suggests that the DCM_LOCK output changes state several times before it eventually goes high. I assume that this is just too late for the processors to boot properly.

 

Our architecture is as follows.

 

Using only the PLL function from the CMT. We input a 100MHz clock and use all 6 of the PLL outputs (400MHz to 100MHz) to run the PPC clocks and user logic. These should be edge aligned therefore.

 

The PLL LOCK output is used in the processor reset IP blocks.

 

I have spent a couple of days reading the documentation and searching the answers database and forum for relevant answers.

 

Based on a distillation of this understanding can anyone confirm please;

 

1. Does the PLL need a reset, and if so how long?

 

2. The processors will stay in reset until PLL LOCK goes active, but this appears to act as an inhibit (i.e holding reset on) rather than applying the reset. If the PLL LOCK is pulsing it could let the processor go before the PLL is stable. I think it would be better to connect the PLL LOCK to the other (spare) asynchronous reset input on the processor reset IP.

 

Does this seem sensible?

 

3. Would you expect the PLL LOCK to pulse anyway?

 

4.  I don't believe that the problem is related to DONE, but would making DONE wait for PLL LOCK make things better or worse?

 

Any help approeciated. Basically we need a reliable method to ensure that the processors always come up. Worryingly this problem appears to be build dependent as some versions do not exhibit the problem and some do (with no changes in this area).

 

Thanks in anticipation.

 

Best wishes

Pete

0 Kudos
1 Solution

Accepted Solutions
Scholar austin
Scholar
7,995 Views
Registered: ‎02-27-2008

Re: V5 DCM / PLL / CMT reset and lock problem

Jump to solution

Pete,

 

1.  Resetting the PLL is required if the clock input changes (once the PLL has locked, the first time, after it starts coming out of the startup after DONE went high).  A good practice is to recognize that clocks typically don't start perfect, and continue perfect forever, so resetting is something you should always have, just in case.  Starup clock problems may vary from one oscillator supplier to the next, or even oscillator to oscillator.  It is for this reason that not allowing DONE to go high until the PLL (and/or DCM) LOCK is high may result in the device never coming out of the startup state (DONE doesn't go high).  Often, a simple delay (counter) on the input clock itself is used, along with a simple loss of clock detctor in logic (perhaps using the built in CCLK from the STARTUP block as a reference) may be used to wait N cycles, check that the clock is "OK", and then reset the PLL/DCM.

 

http://www.xilinx.com/support/documentation/data_sheets/ds202.pdf

 

page 55 gives the min RST, or 5ns.

 

2.  I suggest that you use some more logic to qualify the LOCK signal as a reset to the processor sub-system:  specifically, the processor should be held reset if the input clock is lost, or bad (by the previously described logic), not enough clock cycles have been counted (oscillator still stabalizing after power ON), OR the PLL is not locked.  This way, the processor starts cleanly after all conditions are met for the clock system being OK.

 

3.  Generally speaking, any LOCK detector signal, from any PLL, is a compromise on recognizing an analog condition, and ascibing a digital value:  it can be any sequence of 1's and 0's, at any time, depending on how wild the clock input is (while starting up, or any other noisy condition).

 

4.  If the part is held off from being DONE until the DCM or PLL locks, you may have much better behavior, as long as the clock input is well-behaved, and the feedback to the PLL/DCM does not rely on the logic running in the FPGA (which it won't be as long as DONE is not asserted).  If you have a reasonable quality external cyrstal oscillator, and no external feedback to the PLL/DCM, try it.  You may be very happy.  If this works well, you may need no other clock reset logic as described earlier.  But then again, you may still wish to have a "clock lost" detector to restart things if there is any possibility of the clock being lost, and then returning.  This solution often works best when the clock source, and everything else, is all on one board, running from one supply.  This solution is not a good choice when there are multiple boards in a system, and the clock may be switched, or come from "somewhere" else.

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose

View solution in original post

3 Replies
Scholar austin
Scholar
7,996 Views
Registered: ‎02-27-2008

Re: V5 DCM / PLL / CMT reset and lock problem

Jump to solution

Pete,

 

1.  Resetting the PLL is required if the clock input changes (once the PLL has locked, the first time, after it starts coming out of the startup after DONE went high).  A good practice is to recognize that clocks typically don't start perfect, and continue perfect forever, so resetting is something you should always have, just in case.  Starup clock problems may vary from one oscillator supplier to the next, or even oscillator to oscillator.  It is for this reason that not allowing DONE to go high until the PLL (and/or DCM) LOCK is high may result in the device never coming out of the startup state (DONE doesn't go high).  Often, a simple delay (counter) on the input clock itself is used, along with a simple loss of clock detctor in logic (perhaps using the built in CCLK from the STARTUP block as a reference) may be used to wait N cycles, check that the clock is "OK", and then reset the PLL/DCM.

 

http://www.xilinx.com/support/documentation/data_sheets/ds202.pdf

 

page 55 gives the min RST, or 5ns.

 

2.  I suggest that you use some more logic to qualify the LOCK signal as a reset to the processor sub-system:  specifically, the processor should be held reset if the input clock is lost, or bad (by the previously described logic), not enough clock cycles have been counted (oscillator still stabalizing after power ON), OR the PLL is not locked.  This way, the processor starts cleanly after all conditions are met for the clock system being OK.

 

3.  Generally speaking, any LOCK detector signal, from any PLL, is a compromise on recognizing an analog condition, and ascibing a digital value:  it can be any sequence of 1's and 0's, at any time, depending on how wild the clock input is (while starting up, or any other noisy condition).

 

4.  If the part is held off from being DONE until the DCM or PLL locks, you may have much better behavior, as long as the clock input is well-behaved, and the feedback to the PLL/DCM does not rely on the logic running in the FPGA (which it won't be as long as DONE is not asserted).  If you have a reasonable quality external cyrstal oscillator, and no external feedback to the PLL/DCM, try it.  You may be very happy.  If this works well, you may need no other clock reset logic as described earlier.  But then again, you may still wish to have a "clock lost" detector to restart things if there is any possibility of the clock being lost, and then returning.  This solution often works best when the clock source, and everything else, is all on one board, running from one supply.  This solution is not a good choice when there are multiple boards in a system, and the clock may be switched, or come from "somewhere" else.

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose

View solution in original post

Adventurer
Adventurer
4,548 Views
Registered: ‎08-17-2009

Re: V5 DCM / PLL / CMT reset and lock problem

Jump to solution

Austin,

 

we have a very similar issue on an V5FX70T. We are using an Avnet Minimodule Plus and were using their .xbd, which in turn uses the Xilinx proc_sys_reset IP core (3.00.a, ISE 13.1).

Occasionally the PPC does not start up after a power on, after manually applying sys_rst (or reconfiguring the FPGA) in that state the PPC will reliably boot.

 

Now the datasheet for the proc_sys_reset specifies a DCM_Locked input which is meant to be connected to the DCM_lock signal of the CLK generator, and I would have assumed that the proc_sys_reset core takes care of the incertainties involved with any PLL lock signal. But from what you wrote here, this seems not to be the case?

 

Thank you for clarifying,

Stefan

 

0 Kudos
Scholar austin
Scholar
4,545 Views
Registered: ‎02-27-2008

Re: V5 DCM / PLL / CMT reset and lock problem

Jump to solution

s,

 

I don't know.  Look at the design (with FPGA_editor).

 

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos