PLL problem after power on reset

[Altera_Forum]

Hi, 

 I'm sending data from an arriagx using the lvds block to a stratix fpga, looped through the stratix and back out to the arriagx. There are four lvds blocks involved and each has it's own pll.  I've had to alter the phase of the sclkout in order to get the data correctly from one device to another. However, what I find is that every time I power the board, this data can change. I'm using signal tap to view the results. This is data from the alt2gxb block - local looback in the arriagx works perfectly every time - so I know it's got something to do with the lvds blocks.  Is this an issue with how the pll's startup? In the stratix I've set the pll's with the 'reset on lock of loss' option but this doesn't exist in the arriagx. I've tried to re-sync the reset going to a pll with the clock that drives it to ensure that it has a clean reset.  Everything runs at 156.25MHz but there are different clock domains in that the phase of the clocks will change. So, I've used dcfifo's.  Is there anything that I need to do on the constraints side to pin things downs during place and route? I've put the various clocks in seperate groups to keep the paths on each side of the fifo's seperate. Not sure what else to try.  Regards  MT

[Altera_Forum]

Hi Motah, 

 I had come across somewhat similar problem. I had a PLL in startix II that was used tol receive a clock from DAC then its output clock(rotated) used to clock data out of fpga to DAC. It caused power-up problems. The phase was unpredictable. I contacted altera but eventually removed the PLL reset altogether and it was fine. I must also tell you that I didn't depend on signaltap but on actual signal spectrum after DAC. I don't give too much weight to signaltap in these circumstances.  kaz

[Altera_Forum]

I guess, it may be a problem of startup order. An Altera PLL is guaranteed to lock at a reproducable phase defined in the PLL parameters, if a stable input clock is present at startup and not interrupted afterwards. This condition may be easily violated when connecting multiple PLLs in bidirectional source synchronous LVDS transmission.  

 However, you didn't exactly tell the used LVDS clocking scheme.

[Altera_Forum]

Hi, 

 Iam sorry but I don't agree with the "guarantee". My system would either get the clock right or not depending on power-up. If the phase was wrong it will never recover until I either power-cycled or if I reapplied reset to PLL indicating that that my ref clock was not to blame.  kaz

[Altera_Forum]

Hi, 

 Thanks for all your responses. I'm running the ALT2GXB in XAUI mode. So, in the arriagx, the tx pll/rx pll's generate a 625MHz serial clock and a 156.25MHz enable for the lvds blocks. It's the same on the stratix side. Local loopback always works in the arria's.  In the arria's, the reset is kept on the pll's until there is a stable clock. There is a state machine that generates the resets in the correct sequence for the GXB and I use the same state machine to extend the reset to the rest of the logic, including the pll's. When the pll's come out of reset, there would have been a clock present for quite some time. In the stratix, I don't think it's quite organised that way.  Does a clock source need to be preset at a pll during power-up or is it after it comes out of reset? Or as Kaz says, remove the resets altogether.  I have switch which understands xaui protocol, so I use that for testing. I can never be sure if signal tap is telling me the truth or not.  Regards  MT

[Altera_Forum]

Hi Motah, 

 It might be worth doing further teting before commiting yourself. I mean, you depend on signaltap. I did as well but it could easily mislead due to clock-slip... I sugget you remove signaltap then test your data in a firmware algorithm, check that you receive what you send directly in firmware and raise a flag if not. Your external loop may be as correct as the local.  Kaz

[Altera_Forum]

--- Quote Start ---  I am sorry but I don't agree with the "guarantee".  --- Quote End ---   I didn't experience such strange PLL behaviour up to now and also haven't a plausible explanation. But it apparently can happen. In this case, Stratix/Arria dynamic phase allign would be the only way to get a reliable LVDS connection. I prefer it anyway, but of course it implies some software overhead, e. g. to signal a calibration phase.

[Altera_Forum]

I have made some progress in that the PLL's seem to be stable now - I'm still in the process of testing just to make sure it's going to hold. 

 I do have DPA switched on the LVDS in the Stratix and I don't have it switched on in the Arria. What I noticed was that with the Stratix you can choose the edge but with the Arria it uses both edges. Does this make any difference? With the Stratix, all I've don is enable DPA and that's it really. I know there are other things you can enable but I don't if they are needed to control it.  How does the calbration phase actually work? What's the best way to implement it? Right now, I don't think we would mind the software overhead of setting it up in order to make sure it's all working right.  Thanks

[Altera_Forum]

The DPA logic has two elements, phase alignment and but alignment. The phase alignment requires edges to be present in the data stream, the bit alignment needs a calibration pattern that allows to determine the bit position unequivocally. Unless you don't use a protocol like 8B/10B coding with embedded sync pattern, you need to indicate the calibration phase to the receiver by an auxilary channel.

[Altera_Forum]

We're using 8b/10b with xaui. I read in a document that on power-up you want to supply x number of clocks with a pattern so that it aligns - I think it was 256 or something like that. Apart from that, does the dpa need to be reset if it falls out of lock? 

 Thanks