Xilinx DCM Spread Spectrum feature

Kevin,

No, it does not work.

Basically it spread the spectrum by the FCC test method and reduced power by only 1.5 dB. Not enough to do anything. It was a case where I got too clever, and did not do an FFT during simulation. The feature makes the periods alternately longer and shorter (great for adding jitter to check to see if you have enough slack in your timing! 100,

200, up to 500 ps of jitter).

Unfortunately the modulation frequency is 1/21 the clock frequency, which makes the modulation at too high a frequency to spread the spectrum.

We do have an (internal)app note for really spreading the spectrum (better than 20 dB reduction in carrier). Ask your FAE about it. It uses one DCM as the master, tracking the clock. A second DCM is run in test mode as a tap controlled oscillator. The tap values of the first DCM are read out, and jammed into the second DCM. The second DCM is not phase or frequency locked, but does generate a spread spectrum clock. As a practical test (it looked too good to be true), I used a narrowband FM receceiver at 50.000 MHz, and was clearly able to get an S9 signal unspread, and could not break squelch when the spreading was enabled. The short term jitter added turns out to be relatively small (less than

200 ps p-p) as the modulation frequency is now very low (compared to the old every 21th clock). Basically, there is a low frequency 'wander' that is providing the spreading.

Future products may bring back the feature (working) once we have a 'best' method for doing it in an all digital fashion (using the DCM).

If you want more details, you may also just email me directly.

Aust> The Xilinx DCM was originally supposed to have a spreading feature which

Came accross this thread as I was looking for information regarding how and why ISE ties off the various mode inputs of the Virtex-II DCM module when it maps code originally written for Virtex-E instantiating DLL's from Unisim. In doing so the following control inputs are set:

DSSEN = 1 PSINCDEC = 0 PSEN = 0 PSCLK = 0

The following "MODE tick-boxes" are set:

CLKDIVIDE = 2 FACTORY_JF1 = 0XC0 FACTORY_JF2 = 0X80 DLL FREQUENCY MODE = LOW DFS FREQUENCY MODE = LOW DUTY CYCLE CORRECTION = TRUE CLKOUT PASE SHIFT = NONE CLK FEEDBACK = 1X STARTUP_WAIT = not ticked DSS_MODE = NONE CLKIN_DIVIDE_BY_2 = not ticked

The question is why the DSSEN input gets tied high and what possible side effect this could have? Can we rely on the spread spectrum feature to be idle just by assigning DSS_MODE to NONE and ignore DSSEN?

The problem that we are experiencing is (very) sporadic parity erors in a ZBT-SRAM interface where the RAM-clock is generated in a DCM in the Virtex-II, using the internal clock (generated in a different DCM) as a reference. All signals are completley IO-clocked and both reported and measuerd timing reveal no problems, but we still get these errors and are grasping for any possible explanation...

To the Newsgroup,

I answered Lars personally, but it looks like this may be a mapping bug from the older DLL primitive to the newer DCM. I have entered it into the hotline for study.

There are a number of control signals to the DSS block: DSSEN, as well as the number of tap jumps (1,3 or 5) which are set by memory cells. The FPGA editor maps these into a form that is 'easy' to see (but not actually what the cell is doing).

Best to use the new primitives, rather than rely on the proper mapping of older primitives when in doubt.

Aust> Came accross this thread as I was looking for information regarding how and why

effect

ZBT-SRAM