Forums

PLL and clock in altera cyclone 2 fpga

Started by Jamie Morken December 20, 2008
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.