02-22-2021 02:07 AM
We are using a DLL in the Spartan 2 with the following instantiation.
The input clock is 32 Mhz, therefore the clk0 signal is 32 Mhz and the clkdv signal is 16 Mhz.
We have discovered a situation when power cycling and reloading the device after each power on that the clkdv signal
fails to run after a few hundred times. After the Reset is released, in the bad case, the clkdv signal goes after 44,4 us to low and 5 us later, the LOCKED Signal goes high (Locked shows, everything is okay, but the outputsignal is not activ). Pleas see the attached Oszilloscope Screenshot: Signal 3 shows the clkdv signal and Signal 4 shows the DLL-LOCKED signal.
Has anyone seen this condition or know of this?
CLKDLL_inst : CLKDLL
CLKDV_DIVIDE => 2, -- Divide by: 1.5,2.0,2.5,3.0,4.0,5.0,8.0 or 16.0
STARTUP_WAIT => TRUE) -- Delay config DONE until DLL LOCK, TRUE/FALSE
CLK0 => clk0, -- 0 degree DLL CLK ouptput
CLK180 => open, -- 180 degree DLL CLK output
CLK270 => open, -- 270 degree DLL CLK output
CLK2X => open, -- 2X DLL CLK output
CLK90 => open, -- 90 degree DLL CLK output
CLKDV => clkdv, -- Divided DLL CLK out (CLKDV_DIVIDE)
LOCKED => dcm_locked, -- DLL LOCK status output
CLKFB => clk, -- DLL clock feedback
CLKIN => clkin, -- Clock input (from IBUFG, BUFG or DLL)
RST => pwr_on_rst -- DLL asynchronous reset input
03-26-2021 10:57 AM
This is not something I've come across before.
You said in your post that "clkdv signal fails to run after a few hundred times" does this mean that DLL CLKDIV had been working for a while and it is no longer working?
If that is correct it would be useful to understand what kind of operating conditions the device/board has been exposed to? Is it possible that some environmental factors has lead to damage, EOS/EIPD?
Looking at the scope shot I am not sure I understand the LOCKED signal, is the signal 4 looks like there is oscillation on the signal, assuming it starts at 0V then it is oscillating below GND (hard to tell by the scale but it looks like more than -1V) and later it is oscillating above 5V (again hard to read the scale but looks to be nearly 6V).
Looking at CLK1 it also appears to going below GND as well.
Is the label on Channel 2 correct that it the DONE signal because that also looks to be oscillating/switching which you do not expect to see on done.
Can you confirm that the CLK0 drives a BUFG which is used as the source for the CLKFB => clk?
When you see the problem with the CLKDV does the CLK0 operate as expected?
If the DLL is reset after the Configuration does the behaviour change? This article may be of interest to you : https://www.xilinx.com/support/answers/52806.html
03-26-2021 12:06 PM
Is this a new board / chip or one that's been out in "the wild" for a while.
My gut feeling is that this is going to be a new chip,
and what you have is a grey market one,
in which case the most likely is that its a bad chip, There are very few good ones for sale now days ,
03-29-2021 11:55 PM
In our test case, the FPGA will reboot every few seconds. After a few hundreds of reboots, the CLKdiv will show this behavior. After a new reboot, the CLKdiv works correct. So nothing is damaged. The test are made in a normal lab (~20°C).
The oscillation of the Locked signal is a side effect of the CLK1 signal in the oscilloscope. If I only measure the LOCKED signal, it looks fine. Same for the FPGA Done signal.
„Can you confirm that the CLK0 drives a BUFG which is used as the source for the CLKFB => clk?“
Yes, first the input Clock is driven by an IBUFG and goes to the CLKIN of the DLL. CLK0 drives a BUFG and the Output of the BUFG is connected to CLKFB. CLKDV drives also a BUFG and is connected to the rest of the FPGA modules.
„When you see the problem with the CLKDV does the CLK0 operate as expected?“
Yes, we checked the Signal direct before the DLL, everything looks correct.
„If the DLL is reset after the Configuration does the behavior change?“
Yes, if we reset the DLL again, it works correct for the next approx. hundreds of resets.
03-30-2021 02:30 AM
when you say you have purchased from Xilinx, was that via a distributor or direct ?
If a distributor, are they an approved Xilinx Distributor ?
From the info you have provided , this is my gut feeling is the problem,