DCM on S3A problem

[aleksa]

ISE Webpack 12.2 project is here:
http://www52.zippyshare.com/v/86894412/file.html

This should be a simple test: get an external clock (20MHz),
multiply it by 2, then use that clock to toggle a pin.

I've checked with the scope - the input clock is there,
but output pin is not toggling.

I admit that I didn't read the docs much, I just did
what seemed logical - created a new project, added
the code to toggle a pin, run coregen to create a DCM,
and paste&edit the generated vhdl.

Maybe someone could take a quick glimpse?

 

[aleksa]

Here is the ZIP file
http://www24.zippyshare.com/v/26054846/file.html

 

[Gabor]

On Saturday, February 26, 2011 4:29:03 PM UTC-5, aleksa wrote:

ISE Webpack 12.2 project is here:
http://www52.zippyshare.com/v/86894412/file.html

This should be a simple test: get an external clock (20MHz),
multiply it by 2, then use that clock to toggle a pin.

I've checked with the scope - the input clock is there,
but output pin is not toggling.

I admit that I didn't read the docs much, I just did
what seemed logical - created a new project, added
the code to toggle a pin, run coregen to create a DCM,
and paste&edit the generated vhdl.

Maybe someone could take a quick glimpse?

I'd look at it, but my stupid Win7 computer doesn't
know how to open a .rar file. Anyway things to check:

1) Input range of the DCM. For many devices
the minimum is 24 MHz.

2) DCM reset signal. Most devices require at least
3 input clock cycles of reset assertion. Also note
that the output clocks don't toggle while reset is
asserted, so you need to use another clock to
generate the reset.

3) Input clock jitter. If the source has high cycle
to cycle jitter a DCM won't lock. They are much
more sensitive to input jitter than PLL's

-- Gabor

 

[aleksa]

Its the RESET thing, thanks.

In the final app the FPGA will receive the input clock
all the time, even during configuration, so I've removed
the RES input from a DCM.

However, in this test I didn't apply the input clock right away,
but seconds later. After adding the RES input, it popped to life.

Depending on the activity of the main CPU, the DCM seems
to stop working, but thats probably due to bad grounding.
(the PCB is made out of wires)

 

[Gabor]

On Sunday, February 27, 2011 9:11:18 AM UTC-5, aleksa wrote:

Its the RESET thing, thanks.

In the final app the FPGA will receive the input clock
all the time, even during configuration, so I've removed
the RES input from a DCM.

However, in this test I didn't apply the input clock right away,
but seconds later. After adding the RES input, it popped to life.

Depending on the activity of the main CPU, the DCM seems
to stop working, but thats probably due to bad grounding.
(the PCB is made out of wires)

As I said, the DCM is sensitive to jitter on the input
clock. One source of jitter is noise on the power
supply or ground return. The noise causes a shift
in the effective threshold voltage. This in turn
shows up as timing jitter because the rise and fall
of the input clock is not instantaneous. In the old
days when I was working with wire-wrapped prototypes
we generally used a board with at least a ground plane
and usually also a +5V plane (those were the simpler
days of all 5V logic). Only the signals were routed
with wires. Hopefully a proper board layout with
power and ground planes will clean up your design.

-- Gabor