TE630 LX75-3

[Acam]

Hello!

In a design of mine I started out using the 24MHz clock connected at FPGA pin G3 an noticed an unusual very slow startup of the FPGA when programming it via JTAG with Xilinx Impact. At first I had a very small design when I started the project and connected the 24MHz clock to an PLL and generated two smaller frequencies from this base clock. I noticed that sometimes after a successful configuration it could take up to 5 minutes for the FPGA to start up and then after that it worked perfectly fine. Anyone else noticed this behaviour? There shouldn't be anything unusual with the 24MHz clock and it is connected just in the same manner as the 100MHz, is this correct?

The problem then disappeared when I added another PLL to my design which uses the 100MHz clock and after that the FPGA starts up completely normally.

The reason why I'm using two clock domains and the 24MHz clock in my design is because I need to get a rather unusual frequency to a microphone that is connected to my board, which cannot be easily derived from 100MHZ (even with PLL).

Thanks in advance,
Jonas

[Oleksandr Kiyenko]

Hello Acam,

I suppose that your system, after reload, waiting for PLL to lock and by some reason it take long time. At first please check your PLL settings and then check input clock signal quality.

Best regards
Oleksandr Kiyenko

[Acam]

Ok, thanks for your advice!

I was wondering if the option "input jitter" could affect this somehow, as there now is a default value of 0.01 UI in the clocking wizard but I don't have any specs of the oscillators on the TE0630?
Or I don't know if this value is only used to calculate the output jitter of the generated clocks and then included in the timing analysis when running map,par and so forth.
Are there any particular other settings that you know of that could affect this?

Kind regards,
Jonas

[Oleksandr Kiyenko]

Hello Acram,

Normally oscillator have pretty good parameters to lock PLL. But in some cases it can be damaged and lose stability. If you have ability please use oscilloscope to see output of this oscillator. If it damaged you will see it.

Best regards
Oleksandr Kiyenko

[Acam]

Thanks again for your help!

This could definitively be the problem, I don't have an oscilloscope at hand now, but I found a way to get rid of the 24MHz clock domain in my design and all my weird glitches seemed to go away at the same time. I now simply use a single high-frequency clock in my design and derive all the lower frequencies from this one. This further on simplifies the routing and timing and so forth, which is very good.
Alternatively I could have made some mistakes in my design when crossing two asynchronous clock domains but that would not explain the situation with the very long startup times when using just the 24MHz clock.

Jonas

[JS]

The Spartan 6 PLLs do have problems during startup phase and when the clock was lost, this is a common issue. Do you apply a reset to the PLL?

For an industrial design it had to implement a built in automatic reset to make it operating under all circiumstances.

[Acam]

Ok, thanks that was good to know! This could definitely be the problem.
No, I didn't apply any kind of reset circuit to the PLL, just fed the input clock directly to it.
Could of course try to keep the reset active for a short amount of time after the board and FPGA has powered up.

Jonas

[JS]

ok, then let's hope this help. Basically it is just a counter starting from "111...1" created by Xilinx' INIT definition and  running down to zero. I usually use such a curciut to also create "boot signals" for other hardware outside the chip just as ower amplifiers which are first switched "on" after the FPGA is loaded, did the board check and produces valid SDR-data to avoid strange peaks in the antenna (or glitches in the speakers with sound data). Controlling power regulators helps to define a strict boot sequence for power demanding devices (other FPGAs) to minimize start up power requirements and EMI noise. In some cases it is though necessary to implement a power reset circuit.

[Acam]

Thanks for the hints!

Although, I now stayed with the solution to just use one main high-frequency clock thorough the whole design and then using counters to drive the CE-pins whenever a lower frequency is needed. This gives a little cleaner look to the design although there are many available clock newtorks that could be used. This of course when I had fortune enough to find a frequency that can be divided so that it gives accurate enough lower frequencies for my design.

Jonas