How are the SPI-4.2 cores affected by the new Virtex-4 DCM parameter requirements?
The new Virtex-4 DCM parameters and requirements are explained in (Xilinx Answer 21127).
If you are using the SPI-4.2 Lite (v2.1) Core, see (Xilinx Answer 21696).
If you are using the SPI-4.2 (v7.x) Core, see the information below.
The current versions of the SPI-4.2 Core for Virtex-4 (v7.0, v7.1, v7.2) all contain DCMs embedded within the SPI-4.2 Core when global clocking option is used.
- The Sink Core contains one DCM used for creating RDClkDiv_GP.
- The Source Core contains two DCMs, one for SysClkDiv_GP and one for TSClk_GP.
(Sink and Source cores using a regional clocking option do not use any DCMs, and hence, are not affected by the new DCM parameter requirements.)
To address the requirement:
TCONFIG: Maximum time to configure devices after VCCINT is applied (10 min),
use the Null Bitstream solution as indicated in (Xilinx Answer 21127).
To address the other two requirements:
DCM_INPUT_CLOCK_STOP: Maximum duration that CLKIN and CLKFB can be stopped (100 ms), and
DCM_RESET: Maximum duration that RST can be held asserted (10 sec),
(Xilinx Answer 21127) recommends to incorporate a DCM_STANDBY Macro for each DCM used. However, since the DCMs used in SPI-4.2 Cores are embedded within the core, it is not feasible for a user to incorporate a DCM_STANDBY macro into the SPI-4.2 Core. Please use the SPI-4.2 v7.3 Core, which will have a DCM_STANDBY macro option available with the core. SPI-4.2 v7.3 is currently scheduled to be available at the end of August 2005.
If you need a solution prior to August 2005, open a WebCase at:
and provide the following information to the tech support engineer:
1. Target Device and speed grade.
2. SPI-4.2 clock frequency (both ingress and egress).
3. SPI-4.2 alignment scheme; if static, is this DCM or IODELAY clock shifting?
4. Time frame for platforms to leave the lab environment (production schedule).
5. Mention this Answer Record (Xilinx Answer 21685) to the tech support engineer.