Hal Murray wrote:
> 
> If the counter is on the opposite side of the chip from the place
> where you want your 25/100 logic, you have to route the signal
> across the chip.
> 
> What I was trying to suggest is changing the source text to create
> a new FF in order to avoid that routing.
> 
> It all depends...
> 
> I'd probably start with the extra FF just to keep the source code clean.
> Why add an obscure dependency if you don't need it.
> 

My point was mostly that the compiler will treat two FFs with identical
clocks and identical inputs as a single FF, and then will split that
single FF if warranted.

This is actually the right thing for the compiler to do, as it has
information the programmer generally does not in this instance.  I'll
just do in my source what ends up looking cleanest.

	-hpa

>>> I actually have one handy anyway (part of a counter in the 25 MHz domain.)
>> 
>> FFs are generally plentiful in FPGAs.  The routing from where you 
>> have a FF over to where you need it may be more valuable than a FF.

>Yes.  Fortunately the compiler takes care of that (it will split and
>merge identical registers as routing warrants.)  I guess one can
>override that, but that's hard to know without knowing where things end
>up anyway.

If the counter is on the opposite side of the chip from the place
where you want your 25/100 logic, you have to route the signal
across the chip.

What I was trying to suggest is changing the source text to create
a new FF in order to avoid that routing.

It all depends...

I'd probably start with the extra FF just to keep the source code clean.
Why add an obscure dependency if you don't need it.

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

Hal Murray wrote:
>>> 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.)
> 
> FFs are generally plentiful in FPGAs.  The routing from where you 
> have a FF over to where you need it may be more valuable than a FF.
> 

Yes.  Fortunately the compiler takes care of that (it will split and
merge identical registers as routing warrants.)  I guess one can
override that, but that's hard to know without knowing where things end
up anyway.

	-hpa

>> 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.)

FFs are generally plentiful in FPGAs.  The routing from where you 
have a FF over to where you need it may be more valuable than a FF.

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

"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. 

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

> 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 

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 

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 

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