Are Pll outputs in phase between different PLL when using the same reference clock

I will offer my thoughts on the subject but suggest you consider them in conjunction with any other responses you receive.

1) They are NOT likely to be in phase. Whether you feed both PLLs with the same clock source driven into the same pin OR feed the both PLLs with the same clock source routed to each PLLs respective clock input pin, the routing delays are going to be different, both internal and external. So, the PLL outputs are going to be out of phase as well.

2) My answer to question 1 aside, assume they are in phase. Theoretically, you now have identical clocks whose edges line up. Setup and hold times alone will ensure the transfer between domains works. However, now considering my first answer. With an indeterminate phase shift you clearly can't reliably transfer directly between domains.

3) Timequest should be able to pick up the post routed relationship between the two clock domains.

4) Yes. Releasing the resets as you suggest, or even simultaneously to both PLLs (remember routing delays), will result in further phase difference.

This feels like a slightly academic scenario. I'd suggest you shouldn't consider anything like this in the interests of reliability of a design. Given the relatively small amount of FPGA resource you need to take a signal from one domain to the other, you should just be putting that extra logic in.

Regards,

Alex

I don't understand the reasoning behind answer 4. When the PLL locks after releasing the reset, the phase relation between reference and output clocks is etablished. Presuming an output frequency that's an integer multiple of reference, the phase won't depend on the reset time and is kept as long as the PLL stays locked.

As a result, we can expect the discussed timing skew between same frequency outputs of different PLLs, but no addon due to reset timing.

Thanks for your replies

It seems like there will be a phase shift due to internal routing but they won't be out by nanoseconds. Timequest should analyse these paths and highlight them if they don't pass timing.

If they pass then everything is ok.

It is a dumbed down scenario for ease of explanation but it is a real issue of a more complex system with a bunch of constraints that has forced me down this line. I just wanted to make sure timequest was not hiding something from me.

Josyb, Yes that is what would happen in this simple scheme ;-)

There's actually advantages to using clock-crossing logic regardless of whether the different clock domains are an integer multiples or not;

1. It allows Quartus to consider them separate entities, so they can be placed-and-routed in isolation, eg., you can use LogicLock regions to help "encourage" the fit.

2. It allows you to change the clock frequencies of the different domains as your design evolves.

This scheme is useful in DSP processing pipelines, where high-speed data is filtered and transferred to the next processing blocks, where those processing blocks have different levels of parallelism.

It can sometimes make your head spin trying to think about it ... but it does make the P&R easier, and provides fine control of the timing.

Clock-domain crossing logic is not particular "expensive" in terms of logic resources. For example, 10 ALMs can be configured into dual-ported dual-clock 640-bit memory (32 x 20-bits or 64 x 10-bits). That is not much of a price to pay, when you gain separation of clock domains.

Cheers,

Dave

--- Quote Start ---

4) Could the PLLs get out of phase with each other if their async resets are released at different times?

--- Quote End ---

I would not count on the outputs of two independent PLLs to be in phase after simultaneous release of the async reset. When the async resets are released, each charge pump will start charging at slightly different rates. Remember that this is an analog circuit, and filter components will vary within tolerances. During this period, the oscillators are not locked to the final frequency, and certainly not to each other.