Forum Discussion

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

LVDS High-speed counter。

I designed a counter, used to LVDS level pulse signal count. The number of pulses per second is a few hundred or so. Pulse width is random, from 1ns to 3ns, need to count the number of pulses, the interface is LVDS, I use the LVDS IO direct input pulse, with verilog write counter. Result, the counter can not count the number of pulses accurately , the count number is much less than the actual number. Is there any way to achieve LVDS High-speed counter?

7 Replies

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

    --- Quote Start ---

    I designed a counter, used to LVDS level pulse signal count. The number of pulses per second is a few hundred or so. Pulse width is random, from 1ns to 3ns, need to count the number of pulses, the interface is LVDS, I use the LVDS IO direct input pulse, with verilog write counter. Result, the counter can not count the number of pulses accurately , the count number is much less than the actual number. Is there any way to achieve LVDS High-speed counter?

    --- Quote End ---

    How close can two pulses be together?

    I would count pulses as follows;

    1) The input LVDS pulse is the clock pin on a toggle register. The output of the register will then toggle for each incoming pulse (assuming 1ns is enough of a 'clock' signal - you'll have to check the pulse high/low minimum with TimeQuest).

    2) Synchronize the toggle signal to your FPGA clock domain, and generate a pulse for every change in toggle signal.

    3) Count the pulses.

    Cheers,

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

    The distance between each two pulses is greater than 70ns, using EP3C5E144C8, LVDS pin is PIN_101 and PIN_103. Pulse generation time is uncertain. Pulse signal is generated by a sensor.

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

    Why don't you show the code? It's very likely, that you made a big mistake but don't mention it in your post. So you are possibly reporting about your intentions rather than what you actually did.

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

    always @(posedge plusein or negedge c)

    begin

    if(c==1'b0)

    count_data1[11:0]=12'b0;

    else

    begin

    if(count_data1[11:0]<12'hfff)

    begin

    count_data1[11:0]=count_data1[11:0]+1'b1;

    end

    end

    end

    The "count_data1 [11:0]" is the counter,the "c" is the reset signal, the "plusein" is the pulse input.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    The counter should perfectly work. But how you are reading the result?

    If you read it from an unrelated clock domain, you should expect accidentally inconsistent data due to timing violations in the domain crossing data transfer. There are several ways to overcome the problem. In case of a counter, transferring gray encoded data is the most simple one. According to the low count rate of > 70 ns, you could also synchronize the pulse event to the system clock domain and count it therein. It's always easier to transfer a single a bit correctly between clock domains than a data word.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Read the count value is not the problem, the key is the pulse width is very narrow, and some pulses can not trigger counter.

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

    --- Quote Start ---

    the key is the pulse width is very narrow, and some pulses can not trigger counter.

    --- Quote End ---

    Did you perform a timing analysis and determine the minimum acceptable pulse width using TimeQuest?

    Since your current design uses a counter directly, you do not give the synthesis tool much in the way of options for placing logic. If you use the scheme I suggest, then you can use an IOE register on the input signal. Since these registers work with DDR LVDS signals up to close to 1Gbps, and SERDES LVDS up to 1.6Gbps, there is a good chance you can get it to work.

    Cheers,

    Dave