CASTalk.com

Brad Smallridge · Guest

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

Austin Lesea · Guest

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.

http://tinyurl.com/5og5c

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

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

http://www.support.xilinx.com/support/mysupport.htm

(upper left hand corner)

Austin

Brad Smallridge wrote:

Brad Smallridge · Guest

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.

Brad Smallridge · Guest

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 <= reset_cnt_pulse and (not dcm_lock);
-- Do a periodic reset pulse if no dcm lock is available
-- The reset_cnt_pulse comes from a 20 bit counter threshold.
-- It's a one 20ns pulse with a 20mS period @50MHz oscin frequency.
-- This is twice the time needed for a 10mS LOCK.
-- The counter clocks on oscin input, not the dcm output clk.

-- scope <= reset_cnt_pulse; -- testing purposes
-- should trigger but not be seen on scope
-- because of tiny duty cycle

reset_process:process (dcm_lock,resetpushbutton)
begin
reset <= not (dcm_lock and resetpushbutton);
end process;

Enjoy,

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

	CASTalk.com Forum Index -> FPGA	All times are GMT
Page 1 of 1