motty wrote:
> > I googled around a bit but could not find the answer.
>
>   The data sheets, user guides, and switching characteristics data
> sheets are your friend.
>
> > I am using Xilinx Spartan FPGA, with 2 DCM's in series to generate a
> > 32MHz clock (50% duty cycle) from a 75MHz input. (First DCM is divide
> > 2.5, second multiply 32 and divide 30).
> >
> > The first DCM is connected to a system reset via a user pin, and the
> > LOCKED signal of this DCM is used to reset the second DCM.
> >
> > My question : What is the total lock time i.e. When will the 32MHz
> > clock be available ?
> >
> > Thanks for any insights,
> >
> > Steven
>
> I'm sure the Spartan datasheets spec the time needed for the DLL to
> lock given a certain output frequency.  Find that number for the first
> DCM and then find the lock time for the DFS on the second DCM.  You
> should have a ballpark figure then.  You're talking about milliseconds
> (at least according to the Virtex4 data - which should be close to the
> Spartan figures).  So the delay from the lock asserting on the first
> DCM to the second DCM being enabled should be negligible.

Hi,

You are of course correct. I checked the datasheets, and the values are
there (0.48ms + 2.88ms).

Next time I will check more carefully.

Thanks,

Steven

> I googled around a bit but could not find the answer.

  The data sheets, user guides, and switching characteristics data
sheets are your friend.

> I am using Xilinx Spartan FPGA, with 2 DCM's in series to generate a
> 32MHz clock (50% duty cycle) from a 75MHz input. (First DCM is divide
> 2.5, second multiply 32 and divide 30).
>
> The first DCM is connected to a system reset via a user pin, and the
> LOCKED signal of this DCM is used to reset the second DCM.
>
> My question : What is the total lock time i.e. When will the 32MHz
> clock be available ?
>
> Thanks for any insights,
>
> Steven

I'm sure the Spartan datasheets spec the time needed for the DLL to
lock given a certain output frequency.  Find that number for the first
DCM and then find the lock time for the DFS on the second DCM.  You
should have a ballpark figure then.  You're talking about milliseconds
(at least according to the Virtex4 data - which should be close to the
Spartan figures).  So the delay from the lock asserting on the first
DCM to the second DCM being enabled should be negligible.

<moogyd@yahoo.co.uk> wrote in message 
news:1169217267.704821.197420@m58g2000cwm.googlegroups.com...
> Hi,
>
> I googled around a bit but could not find the answer.
>
> I am using Xilinx Spartan FPGA, with 2 DCM's in series to generate a
> 32MHz clock (50% duty cycle) from a 75MHz input. (First DCM is divide
> 2.5, second multiply 32 and divide 30).
>
> The first DCM is connected to a system reset via a user pin, and the
> LOCKED signal of this DCM is used to reset the second DCM.
>
> My question : What is the total lock time i.e. When will the 32MHz
> clock be available ?
>
> Thanks for any insights,
>
> Steven
>
Hi Steven,
In the usenet spirit of ansering a different question, here's my insight!

So, I guess you're using Spartan3 as the earlier ones don't have a DCM, 
IIRC. Why not just multiply by 32/15 and then divide by 5 using the DDR 
feature of the IOBs to get your 50% duty cycle. Anything internal wouldn't 
need 50% duty cycle. Probably!

HTH, Syms. 

Hi,

I googled around a bit but could not find the answer.

I am using Xilinx Spartan FPGA, with 2 DCM's in series to generate a
32MHz clock (50% duty cycle) from a 75MHz input. (First DCM is divide
2.5, second multiply 32 and divide 30).

The first DCM is connected to a system reset via a user pin, and the
LOCKED signal of this DCM is used to reset the second DCM.

My question : What is the total lock time i.e. When will the 32MHz
clock be available ?

Thanks for any insights,

Steven