cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
zvs
Adventurer
Adventurer
614 Views
Registered: ‎04-08-2017

7-Series QPLL power-down and reset behavior

Jump to solution

Hi!

I have questions regarding 7-Series QPLL.

1. Does QPLL requires a stable ref clock at the input in order to respond to the QPLLPD signal? Or, is the QPLLPD signal is absolutelly asynchronous, irrespective to the ref clock (i.e. QPLLPD = '1' -> QPLL in power-down; QPLLPD = '0' -> normal operation)?

2. Should the QPLLPD be asserted if the ref clock is accidentally missed (external pll got out of lock, for example)?

3. Does QPLL require a stable ref clock at the input in order to respond to the QPLLRESET signal? Or, is the QPLLRESET signal is absolutelly asynchronous, irrespective to the ref clock (i.e. QPLLRESET = '1' -> QPLL is kept in reset; QPLLRESET = '0' -> normal operation)?

4. The above in other words: Is the ref clock required for the reset operation to be executed? Or, can the reset be executed when the ref clock is missed?

5. Are a low to high EDGE AND than a high to low EDGE required for the reset to be executed? Or, is QPLL kept in reset while QPLLRESET is kept high? I.e. is the reset circuit of QPLL EDGE-sensitive or LEVEL-sensitive?

6. When go into the power-down state, is QPLLRESET required to be asserted first? If so, what time before QPLLPD should QPLLRESET be asserted?

7. When go out of the power-down state, is QPLLRESET required to be de-asserted last. If so, what time after QPLLPD should QPLLRESET be de-asserted?

8. I want to use QPLL in the following scenario.

After the FPGA configuration I want to have QPLL in the power-down state. Than, some time later (on certain conditions), I want QPLL to get run. After some time, I want QPLL to get power down, and so forth. As I understood, in the above scenario, the QPLLPD and QPLLRESET diagrams should be the following.

Immediately after the configuration and until after 500ns both QPLLPD and QPLLRESET must be kept LOW. After 500ns, QPLLRESET is asserted and, after some time, QPLLPD is asserted. Now QPLL is in the power-down state.

Some time later I want to bring QPLL out of power-down. So, QPLLPD is de-asserted and, after some time, QPLLRESET is de-asserted. Now QPLL is trying to lock.

The same pattern can continue.

So, is my understanding correct?

 

Can you answer my questions? Every question is important to me.

 

Regards,

Victor.

0 Kudos
1 Solution

Accepted Solutions
roym
Moderator
Moderator
563 Views
Registered: ‎07-30-2007

The QPLL is async. One refclk period was used as a guideline since there is a minimum time needed to rule out too-short or glitch pulses.  Your first method is fine.




----------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution
Be sure to visit the Resources post periodically to keep up with the latest
https://forums.xilinx.com/t5/Serial-Transceivers/Serial-Transceiver-Forum-Guidelines-and-Useful-Resources/td-p/1173590
----------------------------------------------------------------------------


View solution in original post

0 Kudos
4 Replies
roym
Moderator
Moderator
589 Views
Registered: ‎07-30-2007

1. Does QPLL requires a stable ref clock at the input in order to respond to the QPLLPD signal? Or, is the QPLLPD signal is absolutelly asynchronous, irrespective to the ref clock (i.e. QPLLPD = '1' -> QPLL in power-down; QPLLPD = '0' -> normal operation)?

It is asynchronous but has some unusual requirements:  https://www.xilinx.com/support/answers/61875.html

2. Should the QPLLPD be asserted if the ref clock is accidentally missed (external pll got out of lock, for example)?

No

3. Does QPLL require a stable ref clock at the input in order to respond to the QPLLRESET signal? Or, is the QPLLRESET signal is absolutely asynchronous, irrespective to the ref clock (i.e. QPLLRESET = '1' -> QPLL is kept in reset; QPLLRESET = '0' -> normal operation)?

A stable clock is required for a successful reset. 

4. The above in other words: Is the ref clock required for the reset operation to be executed? Or, can the reset be executed when the ref clock is missed?

You need a stable clock for a guaranteed successful reset.

5. Are a low to high EDGE AND than a high to low EDGE required for the reset to be executed? Or, is QPLL kept in reset while QPLLRESET is kept high? I.e. is the reset circuit of QPLL EDGE-sensitive or LEVEL-sensitive?

The UG says Level sensitive.

6. When go into the power-down state, is QPLLRESET required to be asserted first? If so, what time before QPLLPD should QPLLRESET be asserted?

No,  Page 61 UG476 says assert them both high.  If there was a timing requirement it would have stated it.

7. When go out of the power-down state, is QPLLRESET required to be de-asserted last. If so, what time after QPLLPD should QPLLRESET be de-asserted?

No but a reset is required for proper operation.  The UG says the QPLLRESET should be high for 1 clock cycle to ensure proper operation.  I would interpret that to be 1 clock cycle after power up.  The signal is async and there is an internal reset that will be asserted for a longer time.

8. Is my understanding correct.

What you have in mind is OK.  I recommend you follow the GT wizard's example design handling of these signals.  There are many designs using the example design processing as is.  Check what is done at power up and for a reset all.  There are also diagrams in UG476 for PCIe handling of these signals.




----------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution
Be sure to visit the Resources post periodically to keep up with the latest
https://forums.xilinx.com/t5/Serial-Transceivers/Serial-Transceiver-Forum-Guidelines-and-Useful-Resources/td-p/1173590
----------------------------------------------------------------------------


0 Kudos
zvs
Adventurer
Adventurer
570 Views
Registered: ‎04-08-2017

Hi, Roym!

Thanks for the fast reply!

 

To leave with the thorough understanding of the question, I'd like to consider one key example.

Suppose we have a stable reference and a QPLL, which is already locked. I.e. all is running fine. At some point the reference is lost. To handle it, we can go two ways:

 

First (which I'd prefer)

After the loss of reference, we assert QPLLRESET in order to bring QPLL into a known state, namely in reset. At this point I expect QPLLRESET DOES bring QPLL into the reset and KEEP it into that state (as QPLLRESET is said asynchronous in the UG) even though the reference is absent.

But! While reading the UG it seems that QPLLRESET has some connection with the reference clock. So, it's not obvious if the QPLLRESET will actually keep QPLL in reset while the reference is absent.

Ok, we go ahead. We keep QPLLRESET asserted until the reference is become available. Next, we wait at least one clock cycle and then de-assert QPLLRESET. After that, QPLL tries to get locked again.

 

Second

After the loss of the reference (or while the reference is unstable), we don't change QPLLRESET (i.e. it stays de-asserted all the time while the reference is unavailable/unstable) and QPLL runs unpredictably all the time while the reference is absent.

After the reference becomes available again (stabilizes again), we assert QPLLRESET for a minimum of one clock cycle and then de-assert it. After that, QPLL tries to get locked again.

 

The second approach, obviously, will work. But! It has one drawback (which bothers me) - unpredictably running QPLL while the reference is absent. Looks kind of sloppy.

The first approach is free of mentioned drawback and looks fine to me. But, it's really not obvious from the UG if the QPLLRESET will do the job in the absence of the reference.

So, here's the question. Will the first approach work?

 

Regards,
Victor.

0 Kudos
roym
Moderator
Moderator
564 Views
Registered: ‎07-30-2007

The QPLL is async. One refclk period was used as a guideline since there is a minimum time needed to rule out too-short or glitch pulses.  Your first method is fine.




----------------------------------------------------------------------------
Don't forget to reply, kudo, and accept as solution
Be sure to visit the Resources post periodically to keep up with the latest
https://forums.xilinx.com/t5/Serial-Transceivers/Serial-Transceiver-Forum-Guidelines-and-Useful-Resources/td-p/1173590
----------------------------------------------------------------------------


View solution in original post

0 Kudos
zvs
Adventurer
Adventurer
557 Views
Registered: ‎04-08-2017

Thanks a lot for the reply, Roym.

 

Best regards,

Victor

0 Kudos