Clocking Debug Guide

This Clocking Debug Guide directs you through the clocking debug steps, and provides best practices and tips in using the DCM and PLL. This guide contains the following sections:

Overview

The purpose of this guide is to assist customers with common problems they face when using the clocking resources found in Xilinx FPGAs. Clicking on the hyperlinks will guide you through the debug steps. In addition, this guide provides best practices and tips in using the DCM and PLL. This is not meant as a replacement for the device User Guides (see Additional Resources). Each problem description has the following sections:

  • Applicability/Relevance: This section lists ways to verify whether the problem described is the same as the problem at hand.
  • Solutions or Work-Around: This section lists ways to resolve the problem at hand.
  • Next Step: This section points to resources outside of this Debug Guide when its contents do not help resolve the problem at hand.
List of Problem Descriptions

The problem descriptions covered in this document are:

  • DCM Not Locking: DCM LOCKED signal is Low (has never been High) or was asserted and has now been de-asserted.
  • LOCKED Remains High, but DCM Outputs are not Working: DCM initially achieved LOCKED and LOCKED has remained asserted even though the DCM outputs are incorrect.
  • DCM Phase Shifting Does Not Work: DCM fine phase shifting feature does not work.

Some best practices and tips in using the DCM are covered in the following sections of this debug guide:

  • Virtex-4 DCM NBTI: The Virtex®-4 FPGA is the only Xilinx FPGA that encountered the effects of NBTI.  This section discusses the issues and usage of the DCM macros and autocalibration blocks. It contains specific debugging steps for working with the autocalibration block.
  • DCM/PLL Setup: This section covers issues on how to generate the clocks internally in the FPGA, or how to setup the DCM/PLL in the software. It does not contain debugging steps, but is useful if you have any questions or concerns on how your DCM/PLL is set up.
Go to top   top
DCM Not Locking

The LOCKED output indicates when the DCM/DLL clock has obtained the proper initial frequency and phase alignment. The Spartan®-II and Virtex/-E devices contain DLLs (Delay Locked Loop) the newer architectures contain DCMs, the DCM incorporates the DLL with additional frequency synthesis and phase shifting capability. The information in the section covers both the DCM and DLL. After a reset, the DCM samples several thousand clock cycles to achieve lock. After the DCM/DLL achieves lock, the LOCKED signal is asserted High. Until the LOCKED signal is asserted High, the DCM/DLL output clocks are not valid and can exhibit glitches, spikes, or other spurious movement. In particular, the CLK2X output appears as a 1x clock with a 25/75 duty cycle.

It should be monitored as the DCM/DLL outputs are not valid until LOCKED as asserted HIGH.

DCM Not Locking: Applicability

This section applies when the DCM LOCKED signal is Low (has never been High), or was asserted and has now been de-asserted.

You can drive an LED with LOCKED or just an output you can monitor. If you do not have an output to monitor LOCKED, use ChipScope™ to monitor it while you are debugging.

If you are using multiple DCMs/DLLs in a design and are ANDing the LOCKED signals together before monitoring them, it is beneficial to separate them out while debugging so as to understand which DCM/DLL might be causing the problem.

It might be beneficial to monitor the status signals as well. The status signals indicate specific conditions for the DCM.

For example, in a Virtex-5 the Status bus is call DO and DO[0] = Phase-shift overflow, DO[1] = CLKIN stopped, DO[2] CLKFX stopped, and DO[3] = CLKFB stopped.

Details on the status bus can be found in the device user guide.

DCM Not Locking: Solutions

Assert the RST signal High for at least three CLKIN cycles. If you are using a Virtex-4 with the autocalibration macro, RST should be asserted for a minimum for 200 ms.

The RST signal is an active High asynchronous reset. Asserting the RST signal asynchronously forces all DCM outputs Low after some propagation delay.

In all designs, the DCM must be held in reset until the CLKIN is stable.

If a DCM is configured with internal or external feedback, applying a reset after configuration is strongly recommended to ensure consistent locking.

External Feedback Configuration

For an optimum locking process, a DCM with feedback configuration requires both CLKIN and CLKFB to be present and stable when the DCM begins to lock. It is not possible to provide CLKFB in the beginning of the locking process during configuration with external feedback. At the end of configuration, the DCM will begin to lock once the device enters the startup sequence. Because GTS (Global Tri-state ) is still asserted during this time, the output I/O pins are still in a 3-state condition. Therefore, the external feedback does not come out of the FPGA until GTS is released.

When CLKFB eventually appears (after GTS is de-asserted), the DCM will proceed with the lock. However, it might not lock at the optimal point and could introduce slightly more jitter (as well as greater clock cycle latency) through the DCM.

In addition, if CLKFB is coupling with another signal when it is put into a 3-state condition (a PCB signal integrity issue), the DCM might sense this invalid clock as CLKFB and use it to proceed with a lock. This second possibility might cause the DCM to not lock properly once GTS de-asserts and the true CLKFB signal is present. Use of reset after configuration guarantees that the locking process starts with a valid CLKIN and CLKFB signal and ensures consistent locking.

Internal Feedback Configuration

If the input clock oscillator cannot be guaranteed to be stable during configuration, and the feedback is internal, reset should be applied after configuration to ensure that proper locking occurs.

Notes:

  • If you alter the startup sequence (e.g., using the BitGen or ProjNav GUI option), do not place the “LCK_cycle” (wait for DCM to lock) before the “GTS_cycle” (de-assert GTS); otherwise, the DCM will never lock and configuration will not complete.
  • If you are using Project Navigator to generate your programming file, the options are set under the startup options tab in the Generate Programming File options. LCK_cycle is called Release DLL and GTS_cycle is called Enable Outputs.
  • The default value is “-g LCK_cycle:NoWait” and “-g GTS_cycle:5”. When these settings are used, the startup sequence is not held to wait for DCM to lock.
  • For external feedback, the GTS_cycle must be set before the GWE_cycle (Global Write Enable) in the BitGen options (this is the default). This ensures that DCM is reset after the I/O pins are activated.
  • If you are using a Virtex-4 device, please ensure that you meet the 200 ms reset requirement when AUTOCALIBRATION is set to TRUE.

Are you resetting the DCM?

Reset DCM

If you are not resetting the DCM and are experiencing problems with the DCM LOCKing, try resetting the DCM for the required amount.

If the DCM achieves LOCK after a reset, scope the input clock to the DCM and the power supplies during the initial LOCK attempt to see if there is noise causing the failure to LOCK.

DCM Not Locking: Next Step

If you are still experiencing problems, please proceed to the next section.

DCM Setup

Is the DCM in the correct Mode? Is the input clock driven by recommended resources or routed on global routing?

  • Yes
  • No
    • Check in the source code if the DLL_FREQUENCY_MODE, DFS_FREQUENCY_MODE and DCM_PERFORMANCE_MODE are set correctly
    • Check in the source code if the input clock is driven by the PLL (Virtex-5), the PMCD (Virtex-4), IBUFG, or routed on global routing
      • This can also be checked in FPGA Editor
The DCM can operate in two frequency modes, High and Low. The mode that is selected affects the acceptable range of input and output frequency. If you are only using DFS outputs, i.e., CLKFX and CLKFX180, then there is a different range. If you are using any DLL output as well as a DFS output (for example, CLK0 is used to deskew), then the tighter DLL range must be used.

Spartan-3 FPGA DCMs use FREQUENCY_MODE settings which must be set based on the frequency of the input clock. See the device data sheet for the proper ranges and settings. The DCMs in the Spartan-3E and Spartan-3A families do not use a FREQUENCY_MODE setting in software. Instead, the input frequency is detected by the hardware and the correct settings are automatically adjusted.

If the device used is a Virtex-4 or a Virtex-5, there is also a dependence on the DCM_PERFORMANCE_MODE. The DCM_PERFORMANCE_MODE can be set to MAX_RANGE or MAX_SPEED. This is documented in the device User Guide and the values of the ranges are in the device data sheet.

For example, in the Virtex-4 (-12 speed grade), if the input frequency is 100 MHz and you are using CLK0 and CLKFX is at 220MHz:

The allowed range of input frequencies for Low frequency mode when using DLL outputs in Max Speed Mode (default) is 32MHz to 150MHz, i.e., CLKIN_FREQ_DLL_LF_MS_MIN to CLKIN_FREQ_DLL_LF_MS_MAX.

The allowed range of frequencies for High frequency mode when using DFS outputs in Max Speed Mode (default) is 210MHz to 350MHz, i.e., CLKOUT_FREQ_FX_HF_MS_MIN to CLKOUT_FREQ_FX_HF_MS_MAX.
Therefore, DCM_PERFORMANCE_MODE = MAX_SPEED and DLL_FREQUENCY_MODE=LOW and DFS_FREQUENCY=HIGH

If the incorrect modes are selected, the operation of the DCM cannot be guaranteed.

Go to top   top
Incorrect Modes

If you are using the incorrect modes, you need to correct them in the source code and
re-implement. If you are still experiencing problems after the feedback path has been corrected, please proceed to the next section.

Feedback

Are you using feedback to deskew the clock?

Skew is the difference between the arrival time of clock edges and is caused by differences in the clock path delay at different points. Skew has a negative effect on setup and hold times, therefore, reducing system performance.

The DCM/DLL compares CLKIN and CLKFB, and aligns them by adjusting the synchronous taps. For the DCM/DLL to compensate correctly for the clock distribution delay in the FPGA, a feedback path must be used and the feedback must be routed on a global clock line (i.e., using a BUFG). For some device families, it is important that the BUFG be in the same half of the device as the DCM (see the device User Guide for details). If the feedback path is routed on local routing, the DCM/DLL will LOCK, but the clock will not be deskewed. If any of the DLL outputs on a DCM are used, feedback is required for the LOCK signal to go High, regardless of whether you want to deskew.

If you are using a DCM and select to deskew the clock, then the DLL portion of the DCM is used. The DCM in DFS only mode has a wider range of use, but if you choose to deskew your clock, then you must adhere to the tighter DLL specifications.

Internal Versus External Feedback

Are you using internal or external feedback?

To deskew the clock, a feedback clock must be inputted to the DLL/DCM CLKFB pin. Xilinx FPGAs have the flexibility to allow the user to deskew relative to either the internal path, or the external path.

If internal feedback is selected, the DLL/DCM will deskew the clock to ensure that the clock reaches the synchronous elements in the device at the same time that it reaches the external FPGA input pin.

If external feedback is selected, the DLL/DCM will deskew the clock to ensure that the clock reaches the downstream device at the same time that it reaches the external FPGA input pin.

When using external feedback, applying a reset pulse to the DCM immediately after configuration is recommended to ensure consistent locking.

The feedback path delay variance must also be within the CLKFB_DELAY_VAR_EXT limit. This limit only applies to an external feedback path as any on-chip variance is minimal when connected to a global clock line.

Internal Feedback

Is the CLK0 used for the feedback clock?
Is the CLK0 routed on a BUFG?
Is the BUFG used for the feedback path in the same half of the device as the DCM?

  • Yes
  • No
    • Check in the source code if CLK0 is routed on a BUFG back to the CLKFB input of the DCM
    • This can also be checked in FPGA Editor
    • Use FPGA Editor to check that the BUFG used for the feedback path is in the same half of the device as the DCM

It is important that the internal feedback path is set up correctly so that the DCM can compensate for the delays. If the path is incorrect, the DCM will not lock consistently.

Spartan-3 generation devices also allow you to use CLK2X for your feedback path, in addition to CLK0. Both have been tested and verified to work while in the specified limits of operation. There have been some instances observed that CLK2X feedback will not obtain LOCK, but CLK0 feedback will. This was found when input jitter was right at, or over, the specified maximum value. Since CLK0 has less manipulation, it has slightly lower jitter than CLK2X, so the deskew circuitry was able to lock to it better. As stated, though, both CLK0 and CLK2X will work as expected as feedback in the specified operation range.

Incorrect Internal Feedback Path

If the internal feedback path is incorrect, you must correct it in the source code. You can instantiate the BUFG using the code in the Instantiation Templates in ISE® (click on the Light Bulb Icon in ISE). The BUFG can be locked to the correct half of the device using a LOC constraint.
If you are still experiencing problems after the feedback path has been corrected, please proceed to the next section.

External Feedback

When using external feedback CLK0, is it forwarded out of the FPGA through either an OBUF or an ODDR? Does the Inputted Feedback clock get routed on dedicated routing (i.e., on an IBUFG)? Does the external feedback path adhere to the CLKFB_DELAY_VAR_EXT specification?

  • Yes
  • No
    • Check in the source code, if feedback clock input is routed on a IBUFG to the CLKFB input of the DCM
    • This can also be checked in FPGA Editor
    • Also, check if the CLK0 that is forwarded out of the FPGA is through a OBUF or an ODDR

It is important that the external feedback path is set up correctly so that the DCM can compensate for the delays. If the path is incorrect, the DCM will not lock consistently.

CLKFB_DELAY_VAR_EXT is specified in the device data sheet. If this specification is violated, the DCM might fail to achieve LOCK or lose LOCK. The user must measure/estimate this value for their board.

Incorrect External Feedback Path

If the internal feedback path is incorrect, you must correct it in the source code. You can instantiate the BUFG using the code in the Instantiation Templates in ISE (click on the Light Bulb Icon in ISE). The BUFG can be locked to the correct half of the device using a LOC constraint.

If you are still experiencing problems after the feedback path has been corrected, please proceed to the next section.

DCM Input Jitter

Is the jitter on the input clock of the DCM within the specified range?

If the DCM/PLL is not achieving LOCK, but it is set up correctly, input jitter might be the source of the problem. The device data sheet contains specifications on how much jitter the DCM/PLL can tolerate.

Excessive DCM/PLL Input Jitter

If the clock source to the FPGA has excessive jitter, then the behavior of the DCM/PLL cannot be guaranteed. It is up to the user to ensure that the clock inputted to the FPGA is satisfactory.

The White Paper, Jitter: Variations in the Significant Instants of a Clock or Data Signal (WP319), provides details on measuring and managing jitter in digital systems.

If you are measuring the input jitter, it is important to measure as close to the input pin as possible. You can also forward out the input clock to the DCM through a ODDR2, this will show the added jitter from the device.
Other helpful resources for assistance on measuring jitter are:

Specific articles that are useful are:

Additional PCB Design resources.

Go to top   top
External Factors

Are the power supplies to the FPGA clean? Is the FPGA properly decoupled?

It is possible that the power rails induce jitter on the DCM/DLL, if there is excessive jitter/noise in the system the DCM/DLL may not be able to achieve LOCK. The Delay lines are powered by VCCAUX, the control logic by VCCINT.

Take scope shots of the VCCINT, VCCAUX and GND planes to monitor if there is voltage noise on the power planes (save the scope shots in case a Technical Support case needs to be opened).

The Virtex-4 PCB Designer’s Guide (UG072) and the Virtex-5 PCB Designer’s Guide (UG203) cover the topic of decoupling. Please ensure that the FPGA is properly decoupled (XAPP623 covers this topic for other FPGAs).

Try creating a test case where the DCM/PLL only is used and see if the problematic behavior remains. Monitor the VCCINT, VCCAUX and GND planes with the reduced design to see if the there is any change in the voltage noise observed. If this method results in proper DCM/PLL operation, then you are getting added noise on the power or ground planes from somewhere in your design. Some things you can now try:

  • Check the Simultaneous Switching Outputs (SSO) numbers and make sure your design is not violating them.
  • Try moving the DCM and associated global buffers to a different location, perhaps away from intensive fabric switching.
  • If a large portion of your design (fabric and/or outputs) are clocked on the same clock edge, that can cause a spike in the power or ground plane do to an instantaneous current draw. Try clocking different portions of your design on phase shifted clocks to more evenly distribute the current demand.
  • Board level decoupling may need to be improved.

In XAPP689, there is a section on Differentiating Ground Bounce From Other Signal Integrity Issues. It explains how to perform Spyhole measurements to determine if there is ground bounce in the FPGA.

Power Supply Noise

If the power supplies to the FPGA have excessive noise this must be addressed at a board level. It is up to the user to ensure that the FPGA is satisfactorily decoupled.

Additional PCB Design resources.

Open a Technical Support Case With Following Info
  • Device and software details, i.e., XC5VLX50T-2C, using ISE 10.1.1.
  • What is the input frequency?
  • What DCM/DLL outputs are used?
  • What are the frequency modes of the DFS and DLL in? Also what is the deskew adjust attribute set to?
  • What state is the status bus of the DCM in?
  • If you are using the deskewing feature, how is the feedback set up?
  • Please enclose scope shots of the power and GND rails, the input clock and output clock(s) (if forwarded)?
  • Please also include the stripped down test case that demonstrates the problem
    (a project archive is best, a “.pcf” and “.ncd” will suffice).
Go to top   top
LOCKED Remains High, but DCM Outputs are not Working

There may be a condition where LOCKED remains High even though the outputs of the DCM are incorrect. The assertion of the LOCKED signal means that, initially, the outputs of the DCM are valid. However, the LOCKED signal might not de-assert when a problem occurs. It is therefore recommended that the user monitors the Status Bus of the DCM that contains flags for certain failures.

LOCKED Remains High: Applicability

For example in a Virtex-5 the Status bus is called DO and DO[0] = Phase-shift overflow, DO[1] = CLKIN stopped, DO[2] CLKFX stopped and DO[3] = CLKFB stopped.

If any of these Status signals are asserted, it is recommended to reset the DCM. There is no one solution to monitoring the status signals. It is up to the customer to design a monitoring circuit for their specific design.

LOCKED Remains High: Solutions

Monitoring Status bit 1 is recommended as this will indicate when the CLKIN has stopped (moved outside the acceptable CLKIN tolerances). The STATUS(1) is not a sticky bit; i.e., it will go Low once the CLKIN has returned. For the most robust indicator of the status of your DCM's output clock, monitoring both the LOCKED and STATUS(1) bits are recommended.

Here is additional information regarding the output clock signals relative to the input clock of the DCM:
When the input clock is being stopped (CLKIN remains High or Low for more than 1 clock cycle), one to eight more output clock cycles are still generated as the delay line is flushed. When the output clock stops, the CLKIN stopped (STATUS(1)) signal is asserted. When the clock is restarted, the output clock cycles are not generated for one to eight cycles while the delay line is filled. Similarly, the STATUS(1) signal is de-asserted once the output clock is generated.

One point to note when creating a monitoring circuit, Xilinx strongly recommends not using the STATUS[2] bit in your design if the CLKFX outputs of the DCM are unused. Xilinx has observed on silicon a default value of “1” when CLKFX is unused. However, Xilinx does not test STATUS[2] bit values when the CLKFX is not used and therefore cannot guarantee this value.

Also remember that if you are creating a monitoring circuit not to use an output of the DCM that you are monitoring, because if the outputs of the DCM are not working the monitoring circuit would be compromised.
If you are experiencing this symptom and currently are not monitoring the status bus it may be a useful exercise to connect the status bit(s) to a ChipScope core, again noting that the clock to the ILA must be valid (i.e., use CLKIN and monitor CLKIN with a scope to ensure it is functioning correctly).

The CLKIN may be stopped by the user for 100ms without the DCM losing functionality. During this time the CLKIN stopped bit of the Status bus will assert to indicate that the CLKIN has stopped and de-asserts once the CLKIN has resumed. In this case the monitoring circuit does not need to reset the DCM unless the CLKIN stops for more than 100ms.

LOCKED Remains High: Next Step

If after monitoring the status bus of the DCM you are still unable to diagnose the cause of the DCM LOCKED staying High while the outputs are incorrect, read the DCM Setup section of this debug guide.

Next open a Technical Support case providing the following information:

  • Device and software details, i.e., XC5VLX50T-2C, using ISE 10.1.1.
  • What is the input frequency?
  • What DCM/DLL outputs are used?
  • Enclose scope shots of the input clock and output clock (specifically the clock that is incorrect). Also scope shots of the relevant status bit of the DCM.
  • What are the frequency modes of the DFS and DLL in? Also what is the deskew adjust attribute set to?
  • If you are using the deskewing feature, how is the feedback set up?
  • Enclose scope shots of the power and GND rails (if forwarded).
  • Also, include the stripped down test case that demonstrates the problem
    (a project archive is best, a “.pcf” and “.ncd” will suffice).

For technical assistance, open a Webcase.

To discuss possible solutions, use the Xilinx User Community

Go to top   top
DCM Phase Shifting Does Not Work

Check the DO(0) Phase Shift Overflow status pin on the DCM to see if you have reached the end of the phase shifting limit of the DCM (for example, the limits for a Virtex-4/-5 are +- 255 in VARIABLE_CENTER, +255 in VARIABLE_POSITIVE, and 0 or 1023 in DIRECT). This will remain asserted for several clock cycles after the limit is reached.

If the DCM is operating near the FINE_SHIFT_RANGE limit, do not use the phase-shift overflow signal as a flag to reverse the phase shift direction. When the phase-shift overflow is asserted, deasserted, and then asserted again in a short phase shift range, it can falsely reverse the phase shift direction. Instead, use a simple counter to track the phase shift value and reverse the phase shift direction (PSINCDEC) only when the counter reaches a previously determined maximum/minimum phase shift value.

How long after I assert PSEN will PSDONE assert?

For the Virtex devices, we do not specify the exact number of clock cycles between the assertion of PSEN and PSDONE as this can vary. The recommendation is to wait for PSDONE to assert before performing another phase shift operation.

For Spartan-3 families (note there are differences between the Spartan-3 and
Spartan-3E/-3A DCM phase-shifting, please refer to the Spartan-3 User Guide, the phase adjustment might require as many as 100 CLKIN cycles plus 3 PSCLK cycles to take effect, at which point the DCM's PSDONE output goes High for one PSCLK cycle. This pulse indicates that the PS unit completed the previous adjustment and is now ready for the next request. Phase shifitng is not available in the Spartan-II/-IIE DLL.

DCM Phase Shifting Solutions / Work-Around

I am using variable fine grained phase shifting but I do not see the phase of the outputs changing. Why?

Ensure that you assert PSEN for one PSCLK cycle only and then wait for PSDONE to assert before performing another phase shift operation. Asserting PSEN for more than one PSCLK cycle can cause the DCM to phase shift in an unpredictable manner.

Figure 13: Recommended Variable Fine Phase Shifting Sequence

Additional Information

What is the difference between coarse and fine grained phase shifting and DIRECT mode?

Coarse phase shifting refers to the CLK90, CLK180, CLK270, CLK2X180 and CLKFX180 outputs of the DCM. These outputs are always available in Virtex-4 and Virtex-5 and will maintain their phase relationship with each other without feedback. In the Spartan-3 generation FPGAs, these clocks are referred to as the Quadrant Phase Shifted Outputs, and they are always available when using the DLL.

Fine grained phase shifting is achieved through the use of the CLKOUT_PHASE_SHIFT and PHASE_SHIFT parameters and/or the PSINCDEC, PSEN and PSCLK ports on the DCM. This method of phase shifting requires the use of feedback. When using fine grained phase shifting in FIXED, VARIABLE_POSITIVE and VARIABLE_CENTER modes, the phase shift value is a fraction of the clock period and is adjusted for temperature and voltage.

DIRECT fine grained phase shifting is accomplished through the Dynamic Reconfiguration Port (DRP) of the DCM. In this mode the user has access to the individual delay taps in the DCM and a phase shift value is equal to one tap. This method of phase shifting is not adjusted for temperature or voltage it also effects all DCM outputs. In the Spartan-3 families and the Virtex-II/-II Pro the available options for phase shifting are FIXED and VARIABLE.

DCM Phase Shifting: Next Step

For technical assistance, open a Webcase.

To discuss possible solutions, use the Xilinx User Community

Go to top   top
DCM/PLL Setup

In the following section we will set through the decisions that a designer should take when including a DCM/DLL/PLL in their design. A DCM/DLL/PLL can be designed using either the Architecture Wizard or by instantiation. The DCM/DLL/PLL instantiation templates are included in the Libraries Guide, the User Guide and the Language Templates in ISE.

The attributes that are affected by the decisions will be reflected in the How To sections. The Architecture Wizard will set these for the user. If you want to view the code that is produced by the Architecture Wizard, in ISE select the XAW file in the Source Window and double click on the View HDL Source the Process Window. If you are using instantiation you can change the attributes and connections as instructed in the how to sections.

DCM/DLL Versus PLL

Are you Using a Virtex-5 PLL or a DCM/DLL?

PLLs and DCMs complete the same basic functions such as frequency synthesis, clock conditioning, and phase shifting but achieve this with different architectures.

A DLL in its simplest form consists of a tap delay line and control logic. The control logic continuously samples the input clock as well as the feedback clock to properly adjust the delay line. Delay lines are constructed using discrete delay elements.

A PLL uses a voltage-controlled oscillator, which generates a clock signal that approximates the input clock. The control logic, consisting of a phase detector and filter, adjusts the oscillator frequency and phase to compensate for the clock distribution delay.

Why use a PLL over a DCM?

The advantages of a PLL are:

  1. PLLs can filter (reduce, not remove) reference clock jitter
  2. PLLs can be designed to allow very flexible configurations

The advantages of the DCM are:

  1. DCMs allow the user to do fine phase shifting
  2. Many Xilinx users are already familiar with DCMs
  3. Digital Frequency Synthesizer supports higher range of frequency
Deskew

Do you want to deskew the clock?

Skew is the difference between the arrival time of clock edges and is caused by differences in the clock path delay at different points. Skew has a negative effect on setup and hold times therefore reduces system performance.

The DCM/DLL compares CLKIN and CLKFB and aligns them by adjusting the synchronous taps. For the DCM/DLL to compensate correctly for the clock distribution delay in the FPGA, a feedback path must be used and the feedback must be routed on a global clock line i.e. using a BUFG. If the feedback path is routed on local routing the DCM/DLL will LOCK but the clock will not be deskewed. If any of the DLL outputs on a DCM are used CLKFB is required in order for the LOCKED signal to go High, regardless of whether you are deskewing or not.

If you are using a DCM and select to deskew the clock then the DLL portion of the DCM is used. The DCM in DFS mode has a wider range of use. If you choose to deskew your clock then you must adhere to the tighter DLL specs.

How To:

  • Set the CLK_FEEDBACK to “1X” if you want to deskew the clock and set it to NONE if you do not wish to deskew the clock (For Spartan-3 generation FPGAs 2X is also supported).
  • If you want to deskew the clock or to use any of the DLL portion of the DCM outputs you must also connect the CLKFB input of the DCM to the CLK0 output, either through a BUFG for internal feedback or via a PCB trace for external feedback. This is covered in more detail in the next section.

For further information on deskewing clocks see the device User Guides.

Deskew Adjust

Do you want to use System or Source Synchronous deskew adjust?

In order to compensate for the additional routing delay from the GCLK pad to the DCM input, the DCM adds a small amount of delay via an advanced attribute called DESKEW_ADJUST.

SYSTEM_SYNCHRONOUS: attempts to compensate all clock delay for 0 hold time. It is used when all the devices in a data path share a common clock source this is the default value. The DCM’s clock skew elimination function advances the clock, essentially dramatically shortening the worst-case clock path. However, if the clock path is advanced so far that the clock appears before the data, then a positive hold time results. The SYSTEM_SYNCHRONOUS setting injects enough additional skew on the clock path to guarantee zero hold times, but at the expense of a slightly longer clock-to-output time.

SOURCE_SYNCHRONOUS: is used when a clock is provided with data. The clock is usually edge aligned or center aligned with the data. SOURCE_SYNCHRONOUS mode is primarily in high-speed data communications interfaces. It essentially zeros out any phase difference between the incoming clock and the deskewed output clock from the DCM. In Source Synchronous applications, both the data and the clock are derived from the same clock source. The transmitting devices sends both data and clock to the receiving device. The receiving device then adjusts the clock timing for best data reception. High-speed Dual-Data Rate (DDR) and LVDS connections are examples of such systems.

How To:

Set the DESKEW_ADJUST attribute to either SYSTEM or SOURCE SYNCHRONOUS.

Example:

DESKEW_ADJUST => "SYSTEM_SYNCHRONOUS",

Feedback

Do you want to use Internal or External Feedback?

In order to deskew the clock a feedback clock must be inputted to the DLL/DCM/PLL. Xilinx FPGAs have the flexibility to allow the user to deskew relative to either the internal path or the external path.

If internal feedback is selected the DLL/DCM will deskew the clock to ensure that the clock reaches the synchronous elements in the device at the same time as it reaches the external FPGA input pin.

If external feedback is selected the DLL/DCM will deskew the clock to ensure that the clock reaches the downstream device at the same time as it reaches the external FPGA input pin.

When using external feedback, it is recommended apply a reset pulse to the DCM immediately after configuration to ensure consistent locking.

The feedback path delay variance must also be within the CLKFB_DELAY_VAR_EXT limit. This limit only applies to an external feedback path as any on-chip variance is minimal when connected to a global clock line.

How To:

  • Internal - If you want to use internal feedback the CLK0 must feed back to the CLKFB input via a BUFG.

Example:
   CLK0_BUFG_INST : BUFG
      port map
(I=>CLK0_BUF,
                    O=>CLKFB_IN);
-- edited section of DCM instantiation --
CLKFB=>CLKFB_IN,
CLK0=>CLK0_BUF,

  • External - If you want to use external feedback the following conditions must be met;
    • CLK0 must be routed off chip.
    • The feedback PCB trace path delay must match the forward path to the downstream device delay to guarantee skew elimination.
    • The feedback must be routed through an IBUFG (GCLK pin). Both CLK and CLKFB should have identical I/O buffers.

In addition if you are using external feedback and want to simulate the setup an external delay should be added to the test bench to emulate the external delay on the PCB trace.

Example:   

-- Instantiate the Unit Under Test (UUT)
    uut: ext_fb_top PORT MAP(
        clkin => clkin,
        clkfb => clkfb,
        din => din,
        qout => qout,
        rst => rst,
        locked => locked,
        clkout => clkout
    );
clkin <= not clkin after 5 ns;
clkfb <= transport clkout after 1 ns;

Frequency Mode

Should you use High or Low Frequency Mode?

The DCM can operate in two frequency modes, High and Low. The mode that is selected affects the acceptable range of input and output frequency. If you are only using DFS outputs i.e., CLKFX and CLKFX180 then there is a different range. If you are using any DLL output as well as a DFS output, for example CLK0 is used to deskew, then the tighter DLL range must be used.

Spartan-3 DCMs use FREQUENCY_MODE settings which must be set based on the frequency of the input clock.  See the device data sheet for the proper ranges and settings.  The DCMs in the Spartan-3E and Spartan-3A families do not use a FREQUENCY_MODE setting in software.  Instead, the input frequency is detected by the hardware and the correct settings are automatically adjusted.

For example in the Virtex-4 (-12 speed grade) the allowed range of input frequencies for Low frequency mode when using DLL outputs in Max Speed Mode (MS Mode is explained more fully in the next section) is 32 MHz to 150 MHz (i.e., CLKIN_FREQ_DLL_LF_MS_MIN to CLKIN_FREQ_DLL_LF_MS_MAX).

The allowed range in High Frequency mode when using DLL outputs in MS Mode is 150 MHz to 500 MHz  (i.e., CLKIN_FREQ_DLL_HF_MS_MIN to CLKIN_FREQ_DLL_HF_MS_MAX).

Before you decide upon what input / output frequency combinations to use it is important to understand with what frequencies the DCM is specified to work.

To select the frequency mode the DLL_FREQUENCY_MODE and the DFS_FREQUENCY_MODE attributes need to be set. The DLL_FREQUENCY_MODE attribute sets the frequency mode of the delay-locked loop (DLL). The DFS_FREQUENCY_MODE sets the frequency mode of the digital frequency synthesizer (DFS). Both attributes have allowed values of HIGH and LOW. Both default to LOW. The DFS_FREQUENCY_MODE determines the frequency range of CLKIN, CLKFX, and CLKFX180.

The DLL_FREQUENCY_MODE and DFS_FREQUENCY_MODE do not need to be set to the same value. For example (using the case above of a Virtex-4 -12 speed grade in MS Mode) if I input a clock at 200MHz and the required outputs are CLK0 at 200MHz and CLKFX at 125MHz. The DLL_FREQUENCY_MODE should to be set to HIGH and the DFS_FREQUENCY MODE should be set to LOW.

How To:

Set the DLL_FREQUENCY_MODE and DFS_FREQUENCY_MODE attributes to either HIGH or LOW.

Example:

DLL_FREQUENCY_MODE => HIGH,

Performance Mode

Are you using Max Range or Max Speed for the DCM Performance Mode?

Only the Virtex-4 and Virtex-5 DCMs have an additional performance mode. The DCM_PERFORMANCE_MODE attribute allows the choice of optimizing the DCM either for High frequency and Low jitter or for Low frequency and a wide phase-shift range.

Note: Spartan-3 generation devices do not have a DCM Performance Mode.

The attribute values are MAX_SPEED and MAX_RANGE. The default value is MAX_SPEED.

When set to MAX_SPEED, the DCM is optimized to produce High frequency clocks with Low jitter. However, the phase-shift range is smaller than when MAX_RANGE is selected.

When set to MAX_RANGE, the DCM is optimized to produce Low frequency clocks with a wider phase-shift range.

The DCM_PERFORMANCE_MODE affects the following specifications: DCM input and output frequency range, phase-shift range, output jitter, DCM_TAP, CLKIN_CLKFB_PHASE, CLKOUT_PHASE, and duty cycle precision. For most cases, the DCM_PERFORMANCE_MODE attribute should be set to MAX_SPEED (default). Consider changing to MAX_RANGE only in the following situations:

  • The frequency needs to be below the Low frequency limit of the MAX_SPEED setting.
  • A greater absolute phase-shift range is required.

How To:

Set the DCM_PERFORMANCE_MODE attribute to either MAX_SPEED or MAX_RANGE.

Example:

DCM_PERFORMANCE_MODE => "MAX_SPEED",

Cascading DCMs

Are you cascading DCMs?

Generally, Xilinx does not recommend cascading DCMs because jitter accumulates, as a result, the output clock jitter of the second-stage DCM is worse than the output clock jitter of the first-stage DCM. If possible, use two DCMs in parallel instead of in series. However, to generate the clock frequency required by the design, it may be necessary to cascade DCMs.

If it is necessary to cascade DCMs, the following rules must be observed:

  • The output jitter specifications for DLL outputs are provided in the data sheet. Use the Jitter Calculator in the Architecture Wizard to determine the jitter for CLKFX. If possible, avoid cascading CLKFX to CLKFX in High-frequency mode. In general, jitter accumulates based on the following equation:

  • The input and output frequency and jitter specifications for each DCM must be met. If the input clock frequency of both DCMs is within the allowable range use feedback for both DCMs.
  • Use the LOCKED output from DCM1 to create a Reset for DCM2. The recommended length of a Reset pulse is three CLKIN cycles. The LOCKED signal from DCM1 could be inverted to LOCKED and used as the input to an SRL16, with the output of the SRL16 providing the Reset input to DCM2. Connect the output of DCM1 to CLKIN of DCM2 through a BUFG.
  • It is recommended that R1 > R2, where:

R1 = M/D ratio for DCM1
R2 = M/D ratio for DCM2
The ranges of M and D values are given in the data sheet.

How To:

Please see the Virtex-4 FPGA User Guide for details on cascading DCMs that are using the autocalibration macro.

Virtex-5 PLL

Deskewing with a PLL

Skew is the difference between the arrival time of clock edges and is caused by differences in the clock path delay at different points. Skew has a negative effect on setup and hold times therefore reduces system performance.

The PLL compares CLKIN and CLKFBIN and aligns them by adjusting the synchronous taps. The PLL has dedicated feedback output and inputs ports, CLKFBIN and CLKFBOUT. For the PLL to compensate correctly for the clock distribution delay in the FPGA, a feedback path must be from CLKFBOUT to CLKFBIN through a BUFG.  If you don't need to maintain the phase relationship the BUFG is not needed in the CLKFBOUT to CLKFBIN path.

The controlling deskew in a PLL is done with the COMPENSTION attribute. The user allowed values are SYSTEM_SYNCHRONOUS and SOURCE_SYNCHRONOUS. SYSTEM_SYNCHRONOUS attempts to compensate all clock delay for 0 hold time.

SOURCE_SYNCHRONOUS is used when a clock is provided with data and thus phased with the clock.  There are four additional values that the ISE may choose INTERNAL, EXTERNAL, DCM2PLL, PLL2DCM. ISE decides which value is best for the user setup.

For example if you are using external feedback then you should set the COMPENSATION attribute to SYSTEM_SYNCHRONOUS and the tools will change this to EXTERNAL during the implementation phase.
If the PLL is used for stand alone frequency synthesis and it not deskewing the clock the ISE tool will choose INTERNAL, the user should leave the COMPENSATION attribute set to the default value of SYSTEM_SYNCHRONOUS.

How To:

Set the COMPENSATION attribute to either SYSTEM or SOURCE SYNCHRONOUS.

Example:

COMPENSATION => "SYSTEM_SYNCHRONOUS",

Do you want to use Internal or External Feedback?

If internal feedback is selected the PLL will deskew the clock to ensure that the clock reaches the synchronous elements in the device at the same time as it reaches the external FPGA input pin.

If external feedback is selected the PLL will deskew the clock to ensure that the clock reaches the downstream device at the same time as it reaches the external FPGA input pin.

The feedback path delay variance must also be within the CLKFB_DELAY_VAR_EXT limit. This limit only applies to an external feedback path as any on-chip variance is minimal when connected to a global clock line.

If you want to use external feedback, the following conditions must be met:

  • CLKFBOUT must be routed off chip.
  • The feedback PCB trace path delay must match the forward path to the downstream device delay to guarantee skew elimination.
  • The feedback must be routed through an IBUFG (GCLK pin).

In addition, if you are using external feedback and want to simulate the setup, an external delay should be added to the testbench to emulate the external delay on the PCB trace.

For  example:

    -- Instantiate the Unit Under Test (UUT)
    uut: ext_fb_top PORT MAP(
        clkin => clkin,
        clkfbin => clkfbin,
        din => din,
        qout => qout,
        rst => rst,
        locked => locked,
        clkfbout => clkfbout
    );
clkin <= not clkin after 5 ns;
clkfbin <= transport clkfbout after 1 ns

Frequency Considerations When Using a PLL

When choosing input and output frequencies of the PLL the user must adhere to the specifications for FVCO and FOUT which are defined as :

When choosing the values of the M, D and D0 for the PLL it is important to make sure that the resulting FVCO and FOUT are within the specification. The minimum and maximum VCO operating frequencies and the minimum and maximum CLKIN input frequency are defined in the electrical specification of the Virtex-5 Data Sheet.

The other consideration when using the Virtex-5 PLL is to select the correct BANDWIDTH attribute. The allowed values are HIGH, LOW, OPTIMIZED, the default is OPTIMIZED and the bandwidth is chosen n software. The PLL works as a jitter filter, greater jitter filtering is possible by using the PLL attribute BANDWIDTH set to Low. Setting the BANDWIDTH to Low can incur an increase in the static offset of the PLL.

Go to top   top
Virtex-4 DCM NBTI

NBTI Introduction

The Negative Bias Temperature Instability (NBTI) is described in full in WP224. To summarize the NBTI effect; on smaller processes there is the increased probability that if the PMOS gate is negatively biased for extended periods of time the thresholds are shifted.

Only Virtex-4 DCMs are affected by the NBTI phenomenon; therefore, it is important that the inputs to the DCMs are toggled.

If the DCM input clocks might stop for an extended time, a macro will be required (i.e., if CLKIN and CLKFB are stopped for anything more than 100 ms).

Early Silicon Requirements

Early Virtex-4 silicon is classified as Virtex-4 LX/SX ES and Step 1 devices, as well as Virtex-4 FX ES1, ES2 and ES3 devices. These devices have specific requirements of TCONFIG, DCM_INPUT_CLOCK_STOP and DCM_RESET.

TCONFIG: Maximum time to configure devices after VCCINT is applied (10 min).

DCM_INPUT_CLOCK_STOP: Maximum duration that CLKIN and CLKFB can be stopped (100 ms).

DCM_RESET: Maximum duration that RST can be held asserted (10 sec).

It was not permitted to power the device and to leave it unconfigured (as this could result in static device burn-in). If you required the device to be powered then the Null bitstreams should be downloaded to the device, this simply activates the DCMs and keeps them in a continuous calibration state.

For FX null bitstreams see Answer Record 22471.

The DCM_STANDBY macro is the work-around for Virtex-4 LX/SX ES and Step 1 and Virtex-4 FX ES devices. It will work with later stepping silicon. However, the DCM_STANDBY macro is much larger than the autocalibration block (100 slices vs. 15 slices). Consequently, if you are only targeting later stepping silicon, it is more efficient to let the software insert the macro instead of using the DCM_STANDBY macro.

For XST support:

For Synplify support:

Go to top   top

Latest Production Virtex-4 Requirements

Latest production Virtex-4 devices are classified as Virtex-4 LX/SX Step 2 and FX ES4 and higher. Since ISE 7.1.2 an AUTOCALIBRATION block is automatically inserted by the software. It is smaller than the DCM_STANDBY. The AUTOCALIBRATION block should never be turned off unless the user can guarantee that CLKIN and CLKFB (if external feedback is used) never stops. If DCM_AUTOCALIBRATION is set to false the reset requirement is 3 clock cycles.

To understand which stepping level of silicon you have, see “Part Marking” in the Device Package User Guide(UG112).

Macro Overview

The options are DCM_STANDY macro, Autocalibration block and the DFS standby macro.

For Virtex-4 LX/SX ES and Step 1 devices, as well as Virtex-4 FX ES1, ES2 and ES3 devices the DCM_STANDY macro should be used.

For Virtex-4 LX/SX Step 2 and FX ES4 devices the Autocalibration block.

This macro is not required for Step 1 and later XC4VLX and XC4VSX devices, and SCD1 and later XC4VFX devices.

Resetting Virtex-4 DCM

How long should the DCM be reset for?

If you are using the autocalibration or standby macro the DCM must be reset for 200ms. The reason for this is that these macros run on a 10KHz clock and need to be reset long enough over PVT variations.

If you are using the DFS macro or no macro then you should reset the DCM for 3+ cycles.

If you reset for less than 200 ms, the DCM may or may not come out of reset.

LOCKED Toggling While DCM is in Reset

In ISE design tool versions 7.1.03i and later, MAP automatically instantiates an autocalibration macro for each DCM in a design for the Virtex-4 LX/SX Production Step 2 and higher devices, and Virtex-4 FX ES4 and Production devices. If an active Low reset is used, the LOCKED signal toggles when the DCM is held in reset.

To work around this issue, change the reset to active High, if possible.
If this is not possible, you can work around the issue by manually inserting a LUT configured as an inverter. You will need to place KEEP constraints on the nets into and out of the LUT to prevent the tools from optimizing the LUT away.

Example:

Verilog;
assign RESET = ~RESET_N;
VHDL;
   LUT1_inst : LUT1
generic map (
      INIT => "01") -- Specify LUT to be an inverter
   port map (
      O => RESET, -- Output of LUT, route to reset port of DCM
      I0 => RESET_N  -- Active Low reset input to LUT
   );

The following constraints must be added to the ".ucf" file:

NET "RESET_N_IBUF" KEEP;

# The net coming from the active Low reset pad needs to be constrained
# check in FPGA Editor for the correct name of the net

Note: If you are using Synplify, you must apply the synthesis syn_keep = 1 constraint to the nets in HDL as well as to the ".ucf" file.

DFS Outputs Only Used

If you are only using the DFS portion of the DCM then you require a different solution. If you are using ANY of the DLL outputs (even CLK0 for deskewing purposes) then the Autocalibration / standby macro is required.

In the case where only DFS outputs are used, and when CLKIN of the DCM is outside of the range for DLL outputs, a macro must be used to properly monitor the LOCKED signal.

If you use the DFS only macro the autocalibration must be turned off. The autocalibration block monitors the activity on CLK0 and CLKFB as there is no activity on CLK0 or CLKFB when the DFS only is used it cannot be used. The DFS portion of the DCM is not susceptible to the effects of NBTI and therefore does not require the autocalibration block, however, it should not be used as a DLL after being as a DFS.

Turning Off Autocalibration

If the user can GUARANTEE that the clock in to the DCM will never be interrupted then a macro is not required. It is generally recommended that user use the autocalibration block that is inserted by ISE.

The extra logic insertion can be disabled using one of the following two methods:

  • If none of the DCMs in your design require the clock stop circuitry (i.e., the DCM source clocks will never stop), you can globally disable the logic insertion by setting the XIL_DCM_AUTOCALIBRATION_OFF environment variable.
  • You can also disable insertion on an individual basis by applying the DCM_AUTOCALIBRATION attribute to specific DCMs. Acceptable values are TRUE and FALSE, where TRUE (the default value) allows MAP to insert the clock stop circuitry, and FALSE disables the logic insertion. You can add this attribute to the HDL design source using the VHDL generic or Verilog defparam, or it can be entered as a synthesis attribute (check with your synthesis tool for the appropriate syntax).

When applying this attribute in the UCF file, the syntax is as follows:

INST DCM_INST DCM_AUTOCALIBRATION="FALSE";

Unused Virtex-4 DCMs

Unused DCMs in designs are automatically configured into continuous calibration mode by the ISE 7.1i SP1 and later software.

Problem not listed in this Debug Guide

To search the database of silicon and software questions and answers, or to create a technical support case create a WebCase.

To discuss possible solutions, use the Xilinx User Community Forums.

Additional Resources

The information disclosed to you hereunder is provided “AS-IS” with no warranty of any kind, express or implied; and is provided subject to our website Terms or Use, Notices, and Disclaimers found at http://www.xilinx.com/legal.htm.

 
/csi/footer.htm