Xilinx S3 late arriving DCM clkin

Hello Xilinx folks,

I have an issue recently developed when changing an oscillator input from a oscillator package to a clock generated from a Cypress FX2 chip, both running at the same frequency. With the oscillator package I was having no trouble at all but the Cypress chips has to enumerate and renumerate and the oscillator signal arrives at the Xilinx DCM much later, causing the Xilinx S3 to lock out. A pushbutton reset to the DCM reset pin or a JTAG reload of the Xilinx S3 will bring the S3 back to life, however, the power up sequence does not work. This brings up a number of questions that a proper reset for the DCM requires:

First, it states in XAPP462, that a failed lock situation should reset the DCM. Do you do this by simply inverting the LOCKED signal and putting it into the DCM RESET pin? Or do you need some sort of external circuit to detect the lock signal and do a hard pin reset?

Second, XAPP462 suggest a SLR16 in the reset of the DCM. I assume this is only necessary if you are using the external feedback path. Yes?

Third, XAPP462 mentions a STARTUP_WAIT attribute (pg.15). Where is this setting in the newer 6.2 Project Navigator release?

Forth, there is an FPGA Startup Clock option with CCLK, User Clock, or JTAG Clk option. What is the CCLK? And if you select User Clk, how do you indicate which pin or which VHDL signal you intend to use with it?

Thanks,

Brad Smallridge b r a d @ a i v i s i o n . c o m

Reply to
Brad Smallridge
Loading thread data ...

Brad,

The problem with using a DCM with an external signal, and relying on the internal reset on start-up is that the start-up affects the externals signals, and reset is not always good.

So, the recommendation is to also have an effective way to reset the DCM specifically when it does not operate the way it is expected to.

A simple inversion from LOCKED is perhaps a bit rough (I wouldn't do that - and I helped design it!). But, to read the LOCKED status bit, and the CLKIN_STOPPED status bit, OR them, and then set a bit to be clocked out to reset the DCM (clocked from some other clock source) is a good idea.

formatting link

is but one of a number of answers on this very subject.

Type dcm reset into the search of the answers database on:

formatting link

(upper left hand corner)

Aust> Hello Xilinx folks,

Reply to
Austin Lesea

I can see where this approach can lead to a better powerup because the shift register will keep the DCM in reset until a few clock pulses arrive and pushes the reset signal off. However, I don't see how DCM will reset if clkin stops, or the DCM loses lock, since the LOCKED signal will fail and then that will hold the RESET and keep the DCM in permanent reset. The only thing that makes sense to me is to have the LOCKED fail signal start a counter, clocked by clkin, to generate a periodic short reset pulse that resets the DCM and hopefully clears the LOCKED failed condition. My only concern with this approach is that the clkin signal could fail on the exact count or clock cycle whereby the reset pulse was being generated, and this again would generate a situation where the DCM was bieing held in a permanent reset condition, hmmm, on second thought, I suppose that having the DCM in reset isn't so bad if clkin fails, it would just wait until clkin reappears, so I think I have my answer, thanks.

Reply to
Brad Smallridge

Works great, heres the code:

-- coregen dcm component dcm port( rst_in : in std_logic; clkin_in : in std_logic; locked_out : out std_logic; clkfx_out : out std_logic; clkfx180_out : out std_logic; clk0_out : out std_logic); end component;

-- coregen 20 bit binary counter with threshold0 component bc20 port ( q : out std_logic_vector(19 downto 0); clk : in std_logic; q_thresh0 : out std_logic); end component;

begin

inst_dcm: dcm port map( rst_in => dcm_reset, clkin_in => oscin, locked_out => dcm_lock, clkfx_out => clk, clkfx180_out => sramclk, clk0_out => open );

dcm_reset_counter : bc20 port map ( q => open, clk => oscin, q_thresh0 => reset_cnt_pulse);

dcm_reset

Reply to
Brad Smallridge

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.