Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
14 years ago

lpm_divide, when is the output valid?

On a Cyclone IV I'm trying to use the lpm_divide module to divide an unsigned 22 bit numnerator by an unsigned 12 bit denominator. I've left the PIPELINE_DELAY parameter at 11, but I really need to know when my quotient will be valid. Using signaltap it appears that the quotient goes invalid after 1 clock cycle and becomes valid after 4 clock cyles!

This doesn't make sense to me at all. If it's a pipelined design, why do I get any invalid outputs at all? Why do I appear to get valid outputs after 4 clocks when the pipeline delay parameter is 11???

PS I've looked in the documentation and it tells me what throughput I can expect in a Stratix device, but what use is that to me?

7 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    You results are only plausible in case of a timing violation, either exceeding the clock frequency assumed in timing simulation, or changing the input values at the wrong time. The latter can easily happen in simulation, if you change the input at an arbitrary time.

    Pipeline delay of 11 sounds unusually high, I see a default delay of 1 clock cycle suggested by the Megawizard. By the way, what's your clock frequency?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    "Change the input at the wrong time" won't be primarly a matter of input change frequency. How's the input value generated?

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    It's all latched stuff. The 100MHz and the 10MHz clock are generated by he same PLL block

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Then the observed behaviour should never happen, presumed the design passes timing analysis. Also the SignalTap part must not create timing violations, of course.

    P.S.: I assume, that you ignore the output before the initial state has propagated to the divider output, in other words for the first 11 clock cycles.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    That was the plan (the bit about waiting 11 cycles anyway). Does that mean that you concur that the ouput should appear X clock cycles after the inputs change where X is the LPM_PIPELINE value?

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

    Does that mean that you concur that the ouput should appear X clock cycles after the inputs change where X is the LPM_PIPELINE value?

    --- Quote End ---

    Yes. It also means, that you can input new date each clock cycle, just keep track of the pipeline delay.