Deos the plls of a fpga exactly same?

[Altera_Forum]

Hi, 

I have questions about pll.  1. If I use one clock source(27MHz) driving two plls in one fpga, and the parameter of plls is the same(generate 135MHz, but phase is same or different), Can I treat the two generate 135MHz clock as the same one? 2. If I use one clock source(27MHz) driving two plls in different fpgas, one cyclone II, another cyclone III, and the parameter of plls is the same(generate 135MHz, but phase is same or different), Can I treat the two generate 135MHz clock as the same one?  3. Why?  Thanks.

[Altera_Forum]

Hello, 

 I think, you are unable to treat the second clock as the same clock, alt least not in timing analysis, cause the analyzer knows as well as you that it isn't. You either could treat it as unrelated (asynchronous) or as related clock with known timing. If both are derived from the same input clock in one FPGA, the timing analyzer knows the nominal timing and could consider it. If the PLL looses lock (or in case of two PLLs, one is reset), then the nominal timing would invalid, but most designs with mutiple clock domians ore multi-phase clocks are based on the assumption, that nominal phase relation is kept from startup.  In case of an external clock derived from the same reference clock, you could also assume a nominal timing relation, but with larger tolearances. For timing analyzes, you have to describe the phase relation of external clock ("constrain" it), cause the timing analyzer can't know about. This is obviously different from treating it as the same clock.  As an alternative, you could treat signals based on the external clock as unrelated, using appropriate synchronisation techniques. But you get an issue with multi-bit signals that should be processed consistently.  Regards,  Frank

[Altera_Forum]

If driving multiple PLLs with the same clock, you can't ever consider divided clocks as the same, as the PLLs may create them on different phases. (I can explain it if it doesn't make sense, and have a design to get around this issue.) Your cases are all multiplies(5x) so it won't be a problem. 

 So can you treat them as the same clock? The most exact answer I know is, not exactly. The PLLs are not perfect(what is?) and so they can have different affects on the clocks. For example, there will be some jitter. Now, for something like a hold analysis, jitter can be ignored within a single clock domain because the hold edge is the same. But when going between two different PLL outputs, this is no longer the case and they will have different jitter affects. So what can you do? The best thing is to add setup/hold uncertainty in TimeQuest between the clock domains(set_clock_uncertainty is the command), and try to minimize the number of paths going between them. A number I've seen thrown about is 300ps of uncertainty, which many argue is way to high, but under extreme conditions is probably possible. (Every configuration of the PLL, and design/board environment, behaves a little different, which makes this difficult to put an exact number on.)  Example: set_clock_uncertainty -from PLL1_clk1 -to PLL2_clk1 -setup 0.3 set_clock_uncertainty -from PLL1_clk1 -to PLL2_clk1 -hold 0.3 set_clock_uncertainty -from PLL2_clk1 -to PLL1_clk1 -setup 0.3 set_clock_uncertainty -from PLL2_clk1 -to PLL1_clk1 -hold 0.3 If there are multiple clock crossings, do it for all of them, but again, I would try to minimize crossings. Anyway, with two PLLs within a part, the setup will be rather straightforward(your paths going between the two domains will now have to make timing by 300ps), but they will also have a 300ps hold requirement, so they can't be too close. If you get hold violations, there are ways around it which can be discussed later. Between two devices, the hold issue will probably never be a problem(hold issues come when your path is too short, and going between two devices is never short).  I've heard of users doing both of these(more often the first to get more taps out of the PLLs) and had them work without adding any uncertainty(at least as far as I know).

[Altera_Forum]

--- Quote Start ---  If driving multiple PLLs with the same clock, you can't ever consider divided clocks as the same, as the PLLs may create them on different phases. (I can explain it if it doesn't make sense, and have a design to get around this issue.)  --- Quote End ---    Would you mind elaborating on this? Is it possible to phase align the output of two different PLLs driven by the same clock, when using division?

[Altera_Forum]

There is no "start" with the PLL. So if the clock you drive them with has edges at 0ns, 10, 20, 30, 40, 50, 60... When you create a divided down PLL, say a divide by two, it might have edges at time 0ns, 20, 40, 60... or at 10ns, 30ns, 50ns... 

 Now technically, the clock is a continuously running thing, so there isn't any difference between these two scenarios in the system. But if two different PLLs are creating divide by two clocks, they may create clocks whose edges are aligned, or clocks who are off by 10ns. It will be different every time you power-up the PLL.   Here's the design that will synchronize them. (It's a trick, but it will work...) http://www.alteraforum.com/forum/showthread.php?t=1473&highlight=divide+pll

[Altera_Forum]

Thanks Rysc. Very interesting post and design, as usual. 

 Unfortunately it's useless in my case. I need to use the dedicated PLL output pins. That's the reason I wanted to use two different PLLs in my case. Otherwise, I could simply use a single PLL. I guess I would need to use a single PLL and compensate the delay and jitter manually.

[Altera_Forum]

I found that applying areset released synchronously to inclk was sufficient to achieve equal phase for divided outputs of two Cyclone II PLLs. Also delaying areset for a PLL by one clock cycle resulted in a reproducable phase shift. 

 Further investigation could be necessary to confirm that the reported behaviour is stable and not affected by minimal routing delays. In an optimistic interpretation the behaviour is by design and reproducable under usual conditions.

[Altera_Forum]

FvM, 

 Very interesting idea, but seems dangerous to use without confirmation from Altera this is by design and reliable.  I think I will have to live without using the dedicated PLL output pins. Not that bad as long as I can constrain the routing delay. Is it possible to constrain the routing delay between the PLL output and a specific pin? The alternative would be to use back-annotated routing, but this is something I'd really like to avoid.

[Altera_Forum]

I reviewed PLL areset operation and can't dissipate your doubts regarding reliable synchronisation of multiple PLLs. Cause areset is apllied to all PLL counters, not only postscaler, a loss of lock is forced. The VCO is started on areset release with an arbitrary frequency. Depending on dynamic behaviour of the individual PLLs, a different number of clock pulses could be skipped before synchronisation. This suggests, that my results may be only by chance. 

 With Cylone III, PLL dynamic phase align can be used to synchronize divided clocks. With Cyclone II areset could be asserted repeatedly with varying delay to a single PLL until synchronisation is achieved.  Timing constraints can kept only within the capabilities of the hardware to my opinion. When routing a PLL output to pin, no logic cells are involved except for the output cell. Also the GLCK path has probably no routing alternatives in this case. So the variable small output pin delay would be the only means to adjust timing.  On the other hand, I wouldn't expect large delay variations for clock output from regular I/O. Quartus Megafunctions, e. g. DDR2 controller are intentionally using clock output from I/O pins to reduce clock to datapath skew.

[Altera_Forum]

--- Quote Start ---  Timing constraints can kept only within the capabilities of the hardware to my opinion. When routing a PLL output to pin, no logic cells are involved except for the output cell. Also the GLCK path has probably no routing alternatives in this case. So the variable small output pin delay would be the only means to adjust timing.  --- Quote End ---    I think you are right. I was thinking in the possibility of not using the global clock network, which might be even better in this case because there would be a single fanout. But I see it is forced, the PLL can only drive a clock control block, it can't drive the interconnect. Then routing would be always the same. The only variable would be exactly which clock control block is used, but this shouldn't be too significant for a specific PLL.  I guess the right thing to do would be to contraint the skew between both output pins.