While I've run many simulations, I've not yet attempted to use the things. The Spartan-II DLL also requires a reset prior to lock, but since I'd be switching inputs, albeit inputs all within a very close tolerance (100 ppm, I'd guess) I'd know to reset the DLL and when to do it. There's a fair amount of literature that seems to muddy the waters as to what the acquisition time, tracking range, and capture range would be. Needless to say, they (XILINX) don't want to attempt to characterize their DLL in such PLL terms.

One issue I've been trying, occasionally, to resolve, is whether the DLL can be used to acquire lock to a modulated data stream, in which there are frequent "missing pulses". Consider a manchester-encoded data stream, or, somewhat worse, an MFM- or GCR- encoded data stream. I've been totally unable to get any data on how missing pulses affect the behavior of the DLL.

I appreciate the ready availability of 4 phases of the input clock, and of the ability do double, or even quadruple the input clock. Until I get details, however, it's a test project, and I will probably never have the means to establish an adequately broad sample base.

Andy, is that the Spartan 3E "starter kit" that you're using? I've got one, but, due to the rather odd and rather flimsy connector I've not wandered into experimenting with it. What have you observed with that board, so far?

RE