Public service announcement: PLL locking

[xc6lx45]

"Due to recent events":

Please be aware that by default, the FPGA (Xilinx 7 series) wakes up with PLLs possibly still unlocked. This is explicitly stated in UG908 p. 70 and shouldn't surprise anyone who has read the manual ? See "BITSTREAM.STARTUP.LCK_CYCLE" option.

"Recent events" means that yesterday, I found that my design (which started from the first clock cycle), worked 100 % reliably on one board but failed with 100 % certainty on the other board. Identical RTL with initial delay in SW did work reliably on both boards so this is a shy little bug ...

Adding simple reset logic based on the .locked signals from the PLLs solved the issue, now both boards are functional.

 

[D@n]

@xc6lx45,

Thank you for pointing that out.  That explains some things I've seen on a recent design of mine.  Here I just thought it was because I was cascading so many PLL's together--you know, typical Voodoo design methodologies ...

Dan

[asmi]

You can force config logic to wait for PLL/MCMM locks before GSR deassertion and design startup. RTFM: UG472 table 3-7, parameter STARTUP_WAIT. But you've got to be careful with this option as design will never start if one of clocks is not present at startup - typical case being HDMI input, or just about any non-MGT high-speed input for that matter. So it's fine to use it for system clock(s), but it's a definitely "NO" for IO clocks.

[zygot]

12 hours ago, xc6lx45 said:

Adding simple reset logic based on the .locked signals from the PLLs solved the issue, now both boards are functional.

You knew that there was a reason for this MMCM or PLL output right?

[xc6lx45]

Yes but I had already proven that it works

[zygot]

3 hours ago, xc6lx45 said:

Yes but I had already proven that it works

Well that brought a chuckle to my completely humorless day. Reality is so inconvenient... there must be a way to get along without it. Corporate officers do SOP. Accountants just make the books more complicated to avoid it.

Simulating 100 us or so of nothing waiting for an MMCM to lock is annoying enough to sear the question of start-up into one's mental sensitivity list. I've never tried simulating configuration start-up though... still simulating has pointed out more than a few 'oversights' in my preparation on many an occasion.