PLL and clock in altera cyclone 2 fpga

Hi,

I am using a cyclone 2 FPGA, and have a propagation delay warning in one 
of the megafunction's, lpm_divide.  If we use a slower clock to this 
block it will work properly, but the system clock is 27MHz which is too 
fast for the bit width's of the numerator and denominator even with 
pipelining selected in lpm_divide.  I haven't used the cyclone PLL 
before, but its lowest output frequency is 10MHz which is still a bit 
higher than I would like to run the lpm_divide at.  I could add another 
external crystal, but I was wondering if it is possible to generate a 
logic clock inside the FPGA by using flipflops etc.  I have been told 
that this is a bad idea to clock this way due to logic glitches, but am 
not sure why or if that is true?

cheers,
Jamie

Jamie Morken wrote:
> Hi,
> 
> I am using a cyclone 2 FPGA, and have a propagation delay warning in one 
> of the megafunction's, lpm_divide.  If we use a slower clock to this 
> block it will work properly, but the system clock is 27MHz which is too 
> fast for the bit width's of the numerator and denominator even with 
> pipelining selected in lpm_divide.  I haven't used the cyclone PLL 
> before, but its lowest output frequency is 10MHz which is still a bit 
> higher than I would like to run the lpm_divide at.  I could add another 
> external crystal, but I was wondering if it is possible to generate a 
> logic clock inside the FPGA by using flipflops etc.  I have been told 
> that this is a bad idea to clock this way due to logic glitches, but am 
> not sure why or if that is true?
> 

Well actually using combinatorial signals as a clock is not good design 
practice. Though it will most likely work in Your case.

A much better way, however, to solve Your problem might be to create a 
clock that's twice as fast as the clock You really like to have (I 
suppose You are going for 9 MHz?).
So create a clock with 18 MHz and use a clock-enable signal  that's 
generated using logic that is only high every second clock-cycle of Your 
18 MHz clock (that's the "official way" to deal with those problems).

You could probably even use the 27 MHz clock and divide that by three 
using clock-enables and set that logic path to timing ignore.

> cheers,
> Jamie

Regards,

Lorenz

Jamie Morken wrote:

> I am using a cyclone 2 FPGA, and have a propagation delay warning in one 
> of the megafunction's, lpm_divide. 

lpm_divide sucks up luts and routes, and is slow.
I would make a constant reciprocal table
and use one of the dsp block multipliers.

   -- Mike Treseler

Mike Treseler <mtreseler@gmail.com> wrote:
> Jamie Morken wrote:
 
>> I am using a cyclone 2 FPGA, and have a propagation delay warning in one 
>> of the megafunction's, lpm_divide. 
 
> lpm_divide sucks up luts and routes, and is slow.
> I would make a constant reciprocal table
> and use one of the dsp block multipliers.

or use an iterative divider (if you can).

-- glen

"Jamie Morken" <jmorken@shaw.ca> wrote in message 
news:L9%2l.17194$iY3.2034@newsfe14.iad...
> Hi,
>
> If we use a slower clock to this block it will work properly, but the 
> system clock is 27MHz which is too fast for the bit width's of the 
> numerator and denominator even with pipelining selected in lpm_divide.

I've used lpm_divide at ~100+ MHz in Stratix without any difficulties, 
Cyclone II performance should be fairly comparable.  It could be that you 
have.a long logic path leading up to the the divide (or perhaps on the 
output result) and that is the real culprit.  Is the lpm_divide being 
directly instantiated or is it being inferred from code (i.e. x <= a / b)? 
Directly instantiating it gives you more controls in trading off latency in 
clock cycles.

> but I was wondering if it is possible to generate a logic clock inside the 
> FPGA by using flipflops etc.  I have been told that this is a bad idea to 
> clock this way due to logic glitches, but am not sure why or if that is 
> true?
>
The reason why you never want to generate a clock signal with logic or flip 
flops in an FPGA/CPLD is that you open yourself up to failing timing.  No 
matter what the device, the generated clock will
- Be delayed a bit from the system clock, there are no 0ps 
logic/flops/routing in the real world.
- That skew will change from route to route.
- The delay is not controllable.

Now ask yourself what happens when logic that is clocked by the system clock 
enters a flop that is clocked by the skewed clock?  The answer is that, 
depending on what the specific logic is, the signal that comes out of a flop 
that is clocked by the system clock can beat the delayed clock and get 
itself clocked into that flip flop which is one clock cycle early, or it can 
cause it to not meet the setup and/or hold time requirements of the fliip 
flop causing that register to behave unpredictably.  This can show up in the 
timing analysis but only if you enable analyzing for fast paths (which is 
not the default in Quartus).

PLLs get around this problem because they delay the output by exactly one 
full clock cycle (for a 'zero' skew clock) after having done the requested 
frequency multiply/dividing.

Kevin Jennings 

"Jamie Morken" <jmorken@shaw.ca> wrote in message
news:L9%2l.17194$iY3.2034@newsfe14.iad...
> Hi,
>
> I am using a cyclone 2 FPGA, and have a propagation delay warning in one
> of the megafunction's, lpm_divide.  If we use a slower clock to this block
> it will work properly, but the system clock is 27MHz which is too fast for
> the bit width's of the numerator and denominator even with pipelining
> selected in lpm_divide.  I haven't used the cyclone PLL before, but its
> lowest output frequency is 10MHz which is still a bit higher than I would
> like to run the lpm_divide at.  I could add another external crystal, but
> I was wondering if it is possible to generate a logic clock inside the
> FPGA by using flipflops etc.  I have been told that this is a bad idea to
> clock this way due to logic glitches, but am not sure why or if that is
> true?
>
> cheers,
> Jamie

Jamie :

LPM_DIVIDE is very resource expensive and slow - it is a complex
combinatorial implementation.
I would suggest the following solutions :
1 : Implement a successive approximation divide - this will use far less
resource but will take at least one clock cycle per bit of the quotient
(plus some for sign restoration probably)
2 : Register the inputs and outputs to LPM_DIVIDE, then define a suitable
multi-cycle assignment from the input registers to the output register. This
will use all the resources that LPM_DIVIDE needs, but allows you to cope
with its slowness.