- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Read the count value is not the problem, the key is the pulse width is very narrow, and some pulses can not trigger counter.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page