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

Reply by KJ●December 20, 20082008-12-20

"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

Reply by glen herrmannsfeldt●December 20, 20082008-12-20

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

Reply by Mike Treseler●December 20, 20082008-12-20

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

Reply by Lorenz Kolb●December 20, 20082008-12-20

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

Reply by Jamie Morken●December 20, 20082008-12-20

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