What is the counter for in this synchronous reset circuit (SOLVED)

[Dmeads]

Hello! trying to understand this circuit which uses the "locked" output on a xilinx PLL as a reset. trouble is, the locked output isn't releases synchronously, and the OSERDESE2 blocks in the 7 series FPGAs need the reset de-assertion to be synchronous. I thought it would be interesting to use the "locked" output from the PLL and the circuit below.

It comes from this forum post: https://forums.xilinx.com/t5/Virtex-Family-FPGAs-Archived/How-to-synchronize-LOCKED-output-of-PLL-for-use-as-reset/td-p/561924

I am new to reset logic (I just do hobbyist stuff that usually doesnt require resets) and I am wondering what the purpose of the counter is for, and if anyone has a guess which clock the author is running it off of?

Thanks,

-Dom

[Daixiwen]

This looks awfully complicated. It looks from the forum post that he wants the reset to be released when all his clocks are aligned.
In most cases it is enough to synchronize the locked signal to the clock you are using, which means use the "locked_sync" signal in the figure. If you are using several clocks, generate a synchronized locked signal for each clock.
As for the need to generate a reset signal that gets released when all clocks are aligned, I don't really see the point. When using several clocks, each module that has a clock domain crossing logic should tolerate having each domain reset at a slightly different time.

[SiliconWizard]

This looks awfully complicated. It looks from the forum post that he wants the reset to be released when all his clocks are aligned.
In most cases it is enough to synchronize the locked signal to the clock you are using, which means use the "locked_sync" signal in the figure. If you are using several clocks, generate a synchronized locked signal for each clock.
As for the need to generate a reset signal that gets released when all clocks are aligned, I don't really see the point. When using several clocks, each module that has a clock domain crossing logic should tolerate having each domain reset at a slightly different time.

I second all of those points.

[NorthGuy]

The slower cock is 1/5 of the faster clock. Without the circuit, when the logic comes out of reset, the first edge of the faster clock may be anywhere in the slower clock cycle. I think he wanted to synchronize the reset with the rising edge of the slower clock, so the phase relationship between clocks would always be the same after reset. This might have been important to him, for example if he wanted to pass information between these clock domains.

Your needs are likely different from his, so do not worry about what he's doing. Instead, do what your design requires.

[Dmeads]

In most cases it is enough to synchronize the locked signal to the clock you are using, which means use the "locked_sync" signal in the figure.

Yes, after doing some more research, I found UG471 https://www.xilinx.com/support/documentation/user_guides/ug471_7Series_SelectIO.pdf
which states: "Prior to use, a reset must be applied to the OSERDESE2. The OSERDESE2 contains an internal counter that controls dataflow. Failure to synchronize the reset deassertion with the CLKDIV will produce an unexpected output." -pg. 161

I wanted to use the circuit above because I had multiple clocks, and I thought the reset had to be released synchronously with each one when they are both on a rising edge. Not sure why I was making things more complicated, but the "locked_sync" signal will definitely work for my reset.

Thanks.

[BrianHG]

What if you have synchronous reset logic in your design.  Then you will need to hold the reset active for a complete additional clock cycle.  This means using the PLL locked as a reset might not be seen by your logic.

[Dmeads]

What if you have synchronous reset logic in your design.  Then you will need to hold the reset active for a complete additional clock cycle. This means using the PLL locked as a reset might not be seen by your logic.

True, but the "locked" signal isn't a pulse, it just stays high after the outputs are in phase, so wouldn't the logic then be able to see the reset?

[BrianHG]

What if you have synchronous reset logic in your design.  Then you will need to hold the reset active for a complete additional clock cycle. This means using the PLL locked as a reset might not be seen by your logic.

True, but the "locked" signal isn't a pulse, it just stays high after the outputs are in phase, so wouldn't the logic then be able to see the reset?

I do not know about Xilinx, but with Altera, the PLL outputs are 'undefined' except for the external reference and feedback until the locked signal goes high.  I like to play it safe.  And since I may be using multiple cores from multiple vendors/developers, all I need is one or more of them to have synchronous reset instead of async, where the project seems to work by luck just because the setup of all the logic cells are in their power-up default state instead of authentically being software reset.

My rule of thumb is make sure the reset stays high for at least 2 full clock cycles of the slowest set divider PLL output in the case of designs with multiple clocks.

[Daixiwen]

The slower cock is 1/5 of the faster clock. Without the circuit, when the logic comes out of reset, the first edge of the faster clock may be anywhere in the slower clock cycle. I think he wanted to synchronize the reset with the rising edge of the slower clock, so the phase relationship between clocks would always be the same after reset. This might have been important to him, for example if he wanted to pass information between these clock domains.

Yes this can be a problem. In that case what I typically do is synchronize the signal with the slowest clock first. If the faster clock is a multiple of the slower one, and synchronized with it (if it comes from the same pll, for example) then the "slow reset" can also be used with the faster clock. If not then I additionally synchronize the synchronized "slow reset" with the faster clock.

[Daixiwen]

What if you have synchronous reset logic in your design.  Then you will need to hold the reset active for a complete additional clock cycle.  This means using the PLL locked as a reset might not be seen by your logic.

This is of course vendor dependent, but usually you can specify an initial value for your registers at power up. The flip flops that you use to synchronize the lock signal can have an initial value '0' after power up, and then you'll have as many clock cycles at 0 as you have register stages in your synchronizer before the locked signal goes through all of them. You may want to add a pair extra registers if you need to account for metastability.

[NorthGuy]

Yes, after doing some more research, I found UG471 https://www.xilinx.com/support/documentation/user_guides/ug471_7Series_SelectIO.pdf
which states: "Prior to use, a reset must be applied to the OSERDESE2. The OSERDESE2 contains an internal counter that controls dataflow. Failure to synchronize the reset deassertion with the CLKDIV will produce an unexpected output." -pg. 161

I wanted to use the circuit above because I had multiple clocks, and I thought the reset had to be released synchronously with each one when they are both on a rising edge. Not sure why I was making things more complicated, but the "locked_sync" signal will definitely work for my reset.

Just synchronize your reset to CLKDIV.

If you use BUFR for your CLKDIV, you can clear BUFR while in reset then use CE pin of BUFR for synchronization, asserting CE and releasing OSERDES' reset with the same signal sinchronous to CLK.

[asmi]

I'll just add that some times you will need to have reset pulse last for a minimum of certain cycles in order to properly reset. Think about the case when your module has a BRAM and you want to pre-set it to some contents during reset - you can't possibly do that in a single cycle. For that you will need a counter in your reset circuit.

[fourfathom]

Rant:  Perhaps I'm the only one who feels like this, but I really don't like the design technique of relying on reset timing to establish clock phase relationships.  If these clocks need to be synchronized then use your highest-frequency clock and derive the other frequencies / phases logically.  This way the random glitch won't create a persistent error condition.  Sure, you can perhaps detect the failure or marginality and automatically re-reset, but this seems clumsy at best.

I come at this from a background in telecom / datacom AISC design, where we need to pass data and timing through multiple asynchronous and plesiochronous domains, but during design reviews I've also seen the "reset" technique used in completely synchronous designs.

[Dmeads]

I'll just add that some times you will need to have reset pulse last for a minimum of certain cycles in order to properly reset. Think about the case when your module has a BRAM and you want to pre-set it to some contents during reset - you can't possibly do that in a single cycle. For that you will need a counter in your reset circuit.

Ah, this is also what I was looking for and makes sense. thank you.