Virtex-4 VLX25 DCM problem

Grubi,

So, 24 MHz in, CLKFX is 32 MHz out (M=3, D=2), with a CLKDV out, with DIV=3?

The CLKFB should be connected to CLK0 (for least jitter on the feedback).

What is the source of the 24 MHz? Has it changed from the last build?

Then the CLKFX runs for awhile,and than stops working, that is usually excessive jitter on the input, or a missing pulse on the input (a glitch). Have you looked at the status bits (CLKIN_STOPPED, LOCKED, etc)?

Austin

Hi Austin, I will check connected pins and come back. The worst thing is I am not very familiar with FPGA and I am trying to fix everything from hardware side, since software is accepted as working one...

24MHz are coming from C-MAC CFPS-73 oscillator(6ns rising time, no data for start up but it is usual 1-10ms). Trace on PCB is around 3inch long, no termination on it. There is no change from the last build. Strange thing is some boards work, some not, and some switching from time to time. Since the boys build the device, put two Atmega microcontrollers and FPGA on same external reset circuit, I doubt that FPGA trying to start before 24MHz oscillator is up completely, and that lead to these 6MHz... These 8MHz going from from FPGA through 51ohm to clock input of Atmega. Hope it is not sound as complete mess...

-- Message posted using

More information at

Hi Austin, I will check connected pins and come back. The worst thing is I am not very familiar with FPGA and I am trying to fix everything from hardware side, since software is accepted as working one...

24MHz are coming from C-MAC CFPS-73 oscillator(6ns rising time, no data for start up but it is usual 1-10ms). Trace on PCB is around 3inch long, no termination on it. There is no change from the last build. Strange thing is some boards work, some not, and some switching from time to time. Since the boys build the device, put two Atmega microcontrollers and FPGA on same external reset circuit, I doubt that FPGA trying to start before 24MHz oscillator is up completely, and that lead to these 6MHz... These 8MHz going from from FPGA through 51ohm to clock input of Atmega. Hope it is not sound as complete mess...

-- Message posted using

More information at

Here is more - 24MHz coming from the oscillator through 68ohm terminating resistor and goes to pin B10 and 8MHz goes out from T17 through 51 ohms to clock input of Atmega. This track is less than half inch. Hope this helps, somehow.

Clock for configuration memory (17fxxx series, serial Flash) also going out through 51 ohm resistor - and there are also problems sometimes.

Probably you are talking me about internal connections, but I don't know much about them. Will check and read about these, too. Thanks again reading my looong explanations.

-- Message posted using

More information at

Grubi,

Since some parts work, and some don't:

-check when the DCM is reset(too soon, and that may be the issue)

-look at the clock in pin on passing and failing units (is there a difference)?

Debugging this without looking inside is going to be extremely difficult. I suggest you look at how you can observe the DCM reset signal first.

Austin

.arch.fpga/

If you are completely in the dark: Change the temperature with hairdryer and cold-spray, and note any different behavior. change the Vccint 10 percent up and down ( used to be simple, but more tricky nowadays) Load the oscillator frequency input with a 50 ohm resistor to either ground or Vcco. Put your finger or a small capacitor on the oscillator input. Those were the "debugging methods" used decades ago, before logic analyzers and sampling scopes. The idea is to increase the likelihood of failure, and then deduce the most likely cause. Good luck Peter Alfke

e A

mp.arch.fpga/

Another "trick": Make sure the oscillator is running before the FPGA is being turned on. That eliminates some reset timing problems. Peter Alfke

using

Hi Austin, This discussion triggers a question in my mind about an issue related to DCM that I faced a few years ago.

I was working with Xilinx Spartan-3 Kit employing XC3S1500 FPGA for interfacing on PCI-Bus using a custom core. I used a DCM (connected to PCI-clock) in my design and the logic always stopped working after running for a few minutes due to unavailability of clock. I contacted Xilinx support but could not get any satisfactory answer to the issue.

I thought that perhaps PCI-clock does not allow any phase locked loop to be attached to it.

I then tried the on board oscillator, and even though I had three clocks in my logic and I had to address some minor issues related to multiple clock domains, the logic seems to be working so far.

Does PCI-clock allow Xilinx DCM to be attached (as clock multiplier) ? Again, as posted by the original poster, Can a DCM get halted after some time due to excessive internal errors ?

/MH

The PCI spec is not compatible with the DCMs. If you control the entire bus, you can make it compatible. If you are designing a PCI card to go into any PCI system, you need to avoid using the PCI clock as an input to a DCM.

The PCI spec allows the PCI clock frequency to be changed. I do not know what percentage of systems actually do this, but the DCMs would not be able to stay locked if this happened.

The PCI spec also allows the clock to be a spread spectrum clock to help with EMI compliance. I do not have the PCI spec with me now, but I think that the the amount and rate of frequency change was within the DCM spec on the Virtex-II and Virtex-4 FPGAs that I have implemented PCI on. I do not know if it is within spec for the Spartan series. However, even if the spread spectrum clocking is compatible with the DCM, it reduces your jitter tolerance and jitter can cause a DCM to lose lock.

On a Virtex-II 3000, we were able to just run the PCI clock through a BUFG and use that directly for a 66MHz PCI interface. On a Virtex-4 FX 40/60/100, we use the BUFIO and BUFR clocks for the PCI clock domain for a 66 MHz PCI interface.

From your post, I get the impression that you wanted to use the PCI clock as the main clock in your design. I would suggest that you only use IO clocks for IO, and have your own clock source for your main clock.

Regards,

John McCaskill

mh,

John has answered your question of PCIDCM.

-snip-

The DCM "stops" and drops the LOCKED signal if the tap address runs over, or under, the length of the delay line. That happens when the clock changes frequency, or has drop-outs (missing pulses).

A PLL would "tolerate" such clocks, but the DCM being a digital state machine, does not.

If the clock stops altogether, LOCKED will not drop (it is synchronous with CLKIN), thus we have a CLOCK_STOPPED status bit that has to be monitored (to know what is going on). This status bit is asynchronously set, so no CLKIN is required.

Austin

Until I am waiting for work place to be free (one of the boards running OK and going for test), I want to ask for another old problem. VLX25, configuration memory AT17F16, loading trough FT245. From 6 boards

100% was working fine, and after some testing to customers more than 50% come back with similar fail - FPGA stop to load up from config memory, there is higher power consumption more than usual for unload chip(but not excessive) and JTAG can not found FPGA. Holding reset of flash and even remove the flash from board does not help in any way. There is also some ADC's and ASIC outside which also can be a problem, but it will be different to remove them without destroyng board... Any idea?

-- Message posted using

More information at

Thanks Peter. By touching reference oscillator output during power up I can force FPGA DCM to work incorrectly (not work actually). The interesting thing was that simple power cycle dows not solve the problem, u

-- Message posted using

More information at

Uf, I touch submit message before I finish... So, I successfully simulate failing of DCM by touching output of reference oscillator. Typically power cycle and 20 seconds in between was enough(even there is not big decoupling capacitors in the power supply) DCM to start work correctly when it is untouched. So, I think the problem is early releasing of FPGA reset, which I will test tomorrow and all the boards actually work on the edge - if oscillator start-up time is small everything is OK, but otherwise DCM stop working. Thanks again to all.

-- Message posted using

More information at