Calculating Pulse per minute in a FPGA

Discussion in 'VHDL' started by Cory Shol, May 28, 2013.

  1. Cory Shol

    Cory Shol Guest

    Hi all,

    Another problem from the two year FPGA newbie.

    I am working on a new work project that does all this magnificent things and now I am a little stumped on a rather easy to understand problem.

    I need to calculate how many pulses per minute of an input to display out of a Seven segment display.

    I have completed all the user interface stuff and it works fine etc...

    The problem is with the calculation.

    I am running at 25 Mhz clock. 40 ns period.

    Basically I wait for a rising edge of the first pulse and reset my counter. Every rising edge of my 25 Mhz clock I increment the counter until the next rising edge of the pulse.

    Basically the Pulse can be as slow as 15 ppm to 1000 ppm. So if you have a 1000 ppm pulse inputting you would see 1500000 25 Mhz clock counts.

    The hard part is converting 1500000 counts into a PPM.

    I know the math is easy : 60 /[(count)*(Period of Clk)] = PPM

    60/ (1500000 *(0.00000004))= 1000 ppm

    Doing division in VHDL seems to be tough.

    I have one algorithm idea of doing basically the basic of all basics.

    which is: 60/clkPeriod = 1.5 billion
    initially do this:

    newCount <= newCount - count;
    quotient <= quotient + 1;

    Then after initial do this:

    if(newCount >= Count) then
    newCount <= newcount -count;
    quotient <= quotient + 1;
    finalanswer <= quotient;
    end if;

    Are there any other easy algorithms that are relatively easy to implement? Or a standard way the VHDL community does divisions?


    Cory Shol, May 28, 2013
    1. Advertisements

  2. Cory Shol

    Rob Gaddi Guest

    Stupid question: if you're trying to count how many pulses per minute
    you get, why don't you just block off 1 minute chunks of time, and see
    how many pulses you get in each chunk?
    Rob Gaddi, May 28, 2013
    1. Advertisements

  3. Cory Shol

    Cory Shol Guest

    Because The input of the pulse can change at any time. So if it changed within the minute period you wouldn't have the correct PPM.
    Cory Shol, May 28, 2013
  4. Cory Shol

    Cory Shol Guest

    Also it is a requirement to update after every pulse.
    Cory Shol, May 28, 2013
  5. Cory Shol

    rickman Guest

    Can you say, "look up table"?
    rickman, May 29, 2013
  6. Cory Shol

    Gabor Guest

    Even updating 1000 times per minute you have a long time to make the
    calculation. If 1000 ppm is the highest rate, you could even do a
    simple successive subtraction loop in 1000 cycles or about 40
    microseconds with a 25 MHz clock.

    On the other hand unless you're really short of resources, why not
    just use a division IP core? I know Xilinx has it in Coregen, and
    would assume other vendors offer one, too.
    Gabor, May 29, 2013
  7. Cory Shol

    chrisabele Guest

    If you're display is seven segment then I have to assume it's for people
    to read. A display that changes at 1KHz (your specified maximum rate)
    would be very difficult for most people to make sense of. One solution
    would be to average the PPM values that you collect over some period
    that's closer to human perception scale and display that. Rob's
    suggestion of simply accumulating pulses for one minute is a very simple
    direct way to achieve that. Or you could accumulate pulses for one
    second and display that value multiplied by 60. You'd have to how to
    handle the 15 to 60 PPM range, but still the problem would be much easier.

    As usual starting out with a good specification of what's really needed
    makes developing a solution more efficient.
    chrisabele, May 29, 2013
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.