CLock Issue

Hey Fizzy man,

Erm, a 19-bit counter?

Did you really mean 200Hz, or did you mean 200MHz? Why would your logic run at 200Hz? You might want to think about using a clock-enable rather than a separate 200Hz clock signal; that will be much easier for the design tools to analyse.

If you really *did* mean 200Hz, then you would be best of using a simple handshaking circuit, with enough buffering in it that the PLB doesn't get tied up for milliseconds at a time by your incredibly slow circuit. This could be an async FIFO, but it most likely doesn't need to be as complicated as that (particularly given the huge differential between the two domains).

If you meant 200MHz, then you can generate that using a DLL (x2 output) and the clocks will be related, so you can again manage without a FIFO (although you will still have to design your circuit carefully).

-Ben-

I can see a gated clock being acceptable in this case without elaborate FIFO management. First, generate the 200 MHz clock with a toggle flip-flop toggled by the "wrap" from a divede-by-250,000 counter. The only trouble then is the (delayed) alignment of the 200 Hz generated clock. If you register your data in the 200 Hz domain, you can pick up that data one or two clocks later (once and only once) in the 100 MHz domain. For feeding from the 100 MHz domain to the 200 Hz, you need the data loaded to transfer into the 200 Hz domain 1 clock before the 200 Hz transition and maintained steady for two 100 MHz clocks.

The transfer from 100 MHz output registers to 200 Hz input registers and 200 Hz output registers to 100 MHz input registers just need coordination to account for the gated clock skew.

Just be sure to try to route the 200 Hz clock through a global buffer so the

200 Hz logic doesn't get confused at the gated clock edge. The logic may be only 200 Hz but the edges are fast and can beat the skew in a poorly distributed, non-global clock source which would be a bad thing.

Its really 200 Hz. My application is very slow and the bus speed(PLB) is very fast. So my problem is to tranfer the data from very fast domain to very slow doamin. I am still looking for a easy solution.

I suggest you derive the 200 Hz from the 100 MHz with a synchronous counter, which means you divide by 500 000. That takes 19 flip-flops, and there are various ways to achieve exactly

500 000, either through BCD stages, of by loading the binary counter with the appropriate value whenever it rolls over. You end up with ~20 LUTs and flip-flops, and your signal is synchronous with the original 100 MHz, so you have no clock-crossing problems. I think this is the only meaningful and efficient way to address the problem. You do not want to cross asynchronous clock boundaries, if you can somehow avoid that. Peter Alfke

But Fizzy still has the issue of skew between the *synchronous* domains that needs to be detailed, right?

It certainly wouldn't be safe to have a 100 MHz register directly feed a 200 Hz register although the return trip *might* be a simple path if the total

200 Hz clock skew is well under the 10 ns master clock period.

(For others' benefit - Peter knows these tricks:) My own favorite divider is one that always subtracts 1 from either the counter value or 249999 when the counter is -1. The resulting count is 249998 to -1, inclusive, for an effective divide-by-250k. The MSbit pulse indicating -1 just feeds a toggle flop and the 200 Hz, 50% duty cycle clock is there.

Hello, I think you can use a 32-bit NCO.You can use the equation fout = (fin * frequency tuning word)/2^32, since you are using a 32-bit Register. Consider your example: Input Clock is 100MHz Output Clock is 200Hz, then the frequency tuning word comes to around 0x218D. You need to count your counter till this and the MSB of the counter register is nothing but the Output Clock i.e 200Hz. This I have tried and works good. All the Best , Regards, Srikanth