Relationship between high and low speed clocks

Hello,

I have a design which I am porting to a Cyclone II FPGA.  This design
includes two clocks, one at 25 MHz and one at 100 MHz, currently
generated from the Cyclone II PLL from a common clock (and thus
synchronous.)  I have avoided it so far, but I'm running into a
situation where the high-speed logic would like to understand where it
is in relation to the low-speed clock cycle, in order to generate clock
enables.

In particular, part of the high-speed logic drives an external SRAM
which I'd like to time division multiplex between two of the low-speed
units.  The SRAM is fast enough to do that.  However, I can't seem to
figure out a reasonable way to generate the necessary clock enables,
other than switching the 25 MHz clock to be generated from a counter or
shift register implemented in LUTs rather than using the dedicated PLL
logic.  The obvious solution of sampling the 25 MHz clock output in the
100 MHz clock domain seems like it would fail since the clocks
transition at the same time, effectively a setup/hold violation.

	-hpa

On Wed, 03 Dec 2008 13:27:45 -0800, "H. Peter Anvin" <hpa@zytor.com>
wrote:

>Hello,
>
>I have a design which I am porting to a Cyclone II FPGA.  This design
>includes two clocks, one at 25 MHz and one at 100 MHz, currently
>generated from the Cyclone II PLL from a common clock (and thus
>synchronous.)  I have avoided it so far, but I'm running into a
>situation where the high-speed logic would like to understand where it
>is in relation to the low-speed clock cycle, in order to generate clock
>enables.
>
>In particular, part of the high-speed logic drives an external SRAM
>which I'd like to time division multiplex between two of the low-speed
>units.  The SRAM is fast enough to do that.  However, I can't seem to
>figure out a reasonable way to generate the necessary clock enables,
>other than switching the 25 MHz clock to be generated from a counter or
>shift register implemented in LUTs rather than using the dedicated PLL
>logic.  The obvious solution of sampling the 25 MHz clock output in the
>100 MHz clock domain seems like it would fail since the clocks
>transition at the same time, effectively a setup/hold violation.

If you tell the PLL to create the two clocks with zero skew,
you can move signals seamlessly from one clock domain to the
other and the timing analyzer will take care of all the
setup/hold issues - at least, it works with TimeQuest; 
I've not tried to use the "classic" STA in such situations.

To get a counter in the fast clock domain correctly 
sync'd with the slow clock, I guess you could consider
sampling the slow clock on the inactive edges of the fast
one.  That should give plenty of setup time.  I agree, 
though, that it seems like duplication of work that
the PLL has already done.  Alternatively, get the
PLL to emit a second 25MHz clock with a suitable
phase offset relative to the main 25MHz, and use that
as your synch signal.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

On Dec 3, 4:27=A0pm, "H. Peter Anvin" <h...@zytor.com> wrote:
> Hello,
>
> I have a design which I am porting to a Cyclone II FPGA. =A0This design
> includes two clocks, one at 25 MHz and one at 100 MHz, currently
> generated from the Cyclone II PLL from a common clock (and thus
> synchronous.) =A0I have avoided it so far, but I'm running into a
> situation where the high-speed logic would like to understand where it
> is in relation to the low-speed clock cycle, in order to generate clock
> enables.
>

Use the 25 MHz clock to simply toggle a flip flop.  Then in the 100
MHz domain look for a change from one 100 MHz clock to the next in the
state of that flop to tell you that an edge occurred on the previous
clock cycle (or a 0 to 1 change to tell you that it was a rising
edge).  That flop change can be used to initialize a 2 bit counter in
the 100 MHz domain so it can know exactly what phase the 25 MHz clock
is in right now.

Kevin Jennings

>   The obvious solution of sampling the 25 MHz clock output in the
>100 MHz clock domain seems like it would fail since the clocks
>transition at the same time, effectively a setup/hold violation.

You can kludge in a lot of delay.  :(

One clean way is to look at a FF clocked by the 25 MHz clock
rather than the raw 25 MHz clock.  You can either find an edge
and just keep counting from there or make a FF that toggles
on each 25 MHz clock and restart your state machine each toggle.

You have to make sure the skew between your two clocks is
low enough not to cause problems.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.

Jonathan Bromley wrote:
> To get a counter in the fast clock domain correctly 
> sync'd with the slow clock, I guess you could consider
> sampling the slow clock on the inactive edges of the fast
> one.  That should give plenty of setup time.  I agree, 
> though, that it seems like duplication of work that
> the PLL has already done.

Duplication of work, sure, but's only a few FFs worth.  This seems to be
a sensible solution.  The technique suggested by KJ and Hal, to sample
not the 25 MHz clock but a FF toggled by it seems like it should work
fine, too.

Hal Murray wrote:
> You have to make sure the skew between your two clocks is
> low enough not to cause problems.

That shouldn't be a problem per se; the timing analyzer should catch
issues there, and in fact has done so already during development.

Thanks guys, I really appreciate it!

	-hpa

On Dec 3, 4:27 pm, "H. Peter Anvin" <h...@zytor.com> wrote:
> Hello,
>
> I have a design which I am porting to a Cyclone II FPGA. This design
> includes two clocks, one at 25 MHz and one at 100 MHz, currently
> generated from the Cyclone II PLL from a common clock (and thus
> synchronous.) I have avoided it so far, but I'm running into a
> situation where the high-speed logic would like to understand where it
> is in relation to the low-speed clock cycle, in order to generate clock
> enables.
>

Use the 25 MHz clock to simply toggle a flip flop.  Then in the 100
MHz domain look for a change from one 100 MHz clock to the next in the
state of that flop to tell you that an edge occurred on the previous
clock cycle (or a 0 to 1 change to tell you that it was a rising
edge).  That flop change can be used to initialize a 2 bit counter in
the 100 MHz domain so it can know exactly what phase the 25 MHz clock
is in right now.

Kevin Jennings 

Slight correction to the previous post.  Any change in the output of the 
toggle flop would indicate that the previous 100 MHz clock edge corresponded 
to a rising edge on the 25 MHz, not just a 0->1 transition on the flop.

KJ 

> One clean way is to look at a FF clocked by the 25 MHz clock
> rather than the raw 25 MHz clock.  You can either find an edge
> and just keep counting from there or make a FF that toggles
> on each 25 MHz clock and restart your state machine each toggle.
>

Good point, *any* signal from the 25 MHz domain would work, it doesn't need 
to be a free running toggling flop.

KJ 

KJ wrote:
>> One clean way is to look at a FF clocked by the 25 MHz clock
>> rather than the raw 25 MHz clock.  You can either find an edge
>> and just keep counting from there or make a FF that toggles
>> on each 25 MHz clock and restart your state machine each toggle.
> 
> Good point, *any* signal from the 25 MHz domain would work, it doesn't need 
> to be a free running toggling flop.
> 

I actually have one handy anyway (part of a counter in the 25 MHz domain.)

	-hpa

"H. Peter Anvin" <hpa@zytor.com> wrote in message 
news:gh6tkh$s08$1@terminus.zytor.com...
> Hello,
>
> I have a design which I am porting to a Cyclone II FPGA.  This design
> includes two clocks, one at 25 MHz and one at 100 MHz, currently
> generated from the Cyclone II PLL from a common clock (and thus
> synchronous.)  I have avoided it so far, but I'm running into a
> situation where the high-speed logic would like to understand where it
> is in relation to the low-speed clock cycle, in order to generate clock
> enables.
>
Hi H.,
Is it not possible to ditch the 25MHz clock and use only the 100MHz clock 
for all the synchronous elements? Just enable it once every four goes.
HTH HPA, Syms.