Simple counter in verilog (Lattice MachXO2 7000H)

Hi,

I am working on a simple multi-channel pulse counter. The pulses counted
are infrequent (up to 100 kHz), and slow (at least 1 us), coming form a
comparator. In total I have 20 parallel channels (identical). Every 0.5
s I read out the counters and reset them to 0 using SPI.

The counter code is simple, contained in a module:
....
reg [17:0] counter_ripple_high;

always @(posedge slow_gate, posedge reset)
begin : b1
/*synopsys resource r0:
map_to_module = "DW01_inc",
implementation = "csa",
ops = "inc1";*/
if (reset)
counter_ripple_high <= 18'b0;
else
counter_ripple_high <= counter_ripple_high + 1'b1; // synopsys label inc1
end

assign counter = counter_ripple_high;
....

Some channels (not more than 3 out of 20) count two times the input
frequency. How is it possible? One channel is not counting properly at
all. I would expect the latter to be obviously caused by the speed of
arithmetic logic, but the former..?
I am looking forward for your opinions.

Regards,
Krzysztof

 

W dniu piątek, 20 czerwca 2014 19:12:08 UTC+2 użytkownik gabor napisał:

Hi,



I am working on a simple multi-channel pulse counter. The pulses counted

are infrequent (up to 100 kHz), and slow (at least 1 us), coming form a

comparator. In total I have 20 parallel channels (identical). Every 0.5

s I read out the counters and reset them to 0 using SPI.



The counter code is simple, contained in a module:

...

reg [17:0] counter_ripple_high;



always @(posedge slow_gate, posedge reset)

begin : b1

/*synopsys resource r0:

map_to_module = "DW01_inc",

implementation = "csa",

ops = "inc1";*/

if (reset)

counter_ripple_high <= 18'b0;

else

counter_ripple_high <= counter_ripple_high + 1'b1; // synopsys label inc1

end



assign counter = counter_ripple_high;

...



Some channels (not more than 3 out of 20) count two times the input

frequency. How is it possible? One channel is not counting properly at

all. I would expect the latter to be obviously caused by the speed of

arithmetic logic, but the former..?

I am looking forward for your opinions.



Regards,

Krzysztof



You have a lot of clocks in this design. It's likely that your

part doesn't have enough dedicated clock routes to implement them

all. Then any counter that doesn't use a proper clock buffer

will have too much clock skew to work properly. This could

explain the one that doesn't work at all.



As for the double rate, I'd start by looking at the input signal

integrity. A common cause for this is counting both edges of

the clock signal due to slow rise / fall times superimposed with

some noise, or fast rise / fall times with ringing that reaches

the input threshold region.



The fix for all of this would be to synchronize the inputs to

a common higher-speed clock and possible add a glitch filter

before using a pair of flip-flops and an AND gate with one inverted

input to do the edge detection. This creates count enables for

counters that all run on the same higher speed clock.



--

Gabor

Hi,

in fact I am using 8 clocks (source are two PLLs), but they fit into primary and secondary clock nets in the MachXO2 device. The trigger pulse is already synchronized in "one shot" module, which produces clean 2-clock cycle signal (15 ns). Then these 15 ns are triggering shift counter producing 100 ns pulse (clocked by the PLLs). I also routed all the intermediate signals outside the FPGA - they look perfect (the raw source signal is generated by a LVPECL comparator - no ringing, reflections etc.).
Is it possible that placement (which I am using in that project) affects the counters? Is it possible to generate the counter, which is unable to count even 20 kHz signals??

Regards,
Krzysztof

PS: I also asked the same question here (with more details): http://embdev.net/topic/336874#3697391

 

[GaborSzakacs]

krzysztof.pelczar@gmail.com wrote:

Hi,

I am working on a simple multi-channel pulse counter. The pulses counted
are infrequent (up to 100 kHz), and slow (at least 1 us), coming form a
comparator. In total I have 20 parallel channels (identical). Every 0.5
s I read out the counters and reset them to 0 using SPI.

The counter code is simple, contained in a module:
...
reg [17:0] counter_ripple_high;

always @(posedge slow_gate, posedge reset)
begin : b1
/*synopsys resource r0:
map_to_module = "DW01_inc",
implementation = "csa",
ops = "inc1";*/
if (reset)
counter_ripple_high <= 18'b0;
else
counter_ripple_high <= counter_ripple_high + 1'b1; // synopsys label inc1
end

assign counter = counter_ripple_high;
...

Some channels (not more than 3 out of 20) count two times the input
frequency. How is it possible? One channel is not counting properly at
all. I would expect the latter to be obviously caused by the speed of
arithmetic logic, but the former..?
I am looking forward for your opinions.

Regards,
Krzysztof

You have a lot of clocks in this design. It's likely that your
part doesn't have enough dedicated clock routes to implement them
all. Then any counter that doesn't use a proper clock buffer
will have too much clock skew to work properly. This could
explain the one that doesn't work at all.

As for the double rate, I'd start by looking at the input signal
integrity. A common cause for this is counting both edges of
the clock signal due to slow rise / fall times superimposed with
some noise, or fast rise / fall times with ringing that reaches
the input threshold region.

The fix for all of this would be to synchronize the inputs to
a common higher-speed clock and possible add a glitch filter
before using a pair of flip-flops and an AND gate with one inverted
input to do the edge detection. This creates count enables for
counters that all run on the same higher speed clock.

--
Gabor

 

[unfrostedpoptart]

Where is your SPI read/reset logic? Is it synchronized to all the other clocks? If not, you're going to get problems! Do you know what cross-clock synchronization and metastability are? If not, Google them or it will never work right.

David

On Friday, June 20, 2014 9:14:47 AM UTC-7, krzyszto...@gmail.com wrote:

Hi,



I am working on a simple multi-channel pulse counter. The pulses counted

are infrequent (up to 100 kHz), and slow (at least 1 us), coming form a

comparator. In total I have 20 parallel channels (identical). Every 0.5

s I read out the counters and reset them to 0 using SPI.



The counter code is simple, contained in a module:

...

reg [17:0] counter_ripple_high;



always @(posedge slow_gate, posedge reset)

begin : b1

/*synopsys resource r0:

map_to_module = "DW01_inc",

implementation = "csa",

ops = "inc1";*/

if (reset)

counter_ripple_high <= 18'b0;

else

counter_ripple_high <= counter_ripple_high + 1'b1; // synopsys label inc1

end



assign counter = counter_ripple_high;

...



Some channels (not more than 3 out of 20) count two times the input

frequency. How is it possible? One channel is not counting properly at

all. I would expect the latter to be obviously caused by the speed of

arithmetic logic, but the former..?

I am looking forward for your opinions.



Regards,

Krzysztof

 

Hi,

the problem was solved on another forum, where I asked the same question - see my post from 20. June. The problem was stemming from not synchronizing of one of the logical signals driving the counter (NAND gate checking for null in another counter). Following the ideas given there I also changed the code responsible for readout, which solved all the problems.
If you have some other ideas for improvements, I would be glad to hear them.
Thanks for your efforts.

Regards,
Krzysztof


W dniu wtorek, 24 czerwca 2014 15:47:18 UTC+2 użytkownik gabor napisał:

W dniu piątek, 20 czerwca 2014 19:12:08 UTC+2 użytkownik gabor napisał:

Hi,

I am working on a simple multi-channel pulse counter. The pulses counted

are infrequent (up to 100 kHz), and slow (at least 1 us), coming form a

comparator. In total I have 20 parallel channels (identical). Every 0..5

s I read out the counters and reset them to 0 using SPI.

The counter code is simple, contained in a module:

...

reg [17:0] counter_ripple_high;

always @(posedge slow_gate, posedge reset)

begin : b1

/*synopsys resource r0:

map_to_module = "DW01_inc",

implementation = "csa",

ops = "inc1";*/

if (reset)

counter_ripple_high <= 18'b0;

else

counter_ripple_high <= counter_ripple_high + 1'b1; // synopsys label inc1

end

assign counter = counter_ripple_high;

...

Some channels (not more than 3 out of 20) count two times the input

frequency. How is it possible? One channel is not counting properly at

all. I would expect the latter to be obviously caused by the speed of

arithmetic logic, but the former..?

I am looking forward for your opinions.

Regards,

Krzysztof





You have a lot of clocks in this design. It's likely that your



part doesn't have enough dedicated clock routes to implement them



all. Then any counter that doesn't use a proper clock buffer



will have too much clock skew to work properly. This could



explain the one that doesn't work at all.







As for the double rate, I'd start by looking at the input signal



integrity. A common cause for this is counting both edges of



the clock signal due to slow rise / fall times superimposed with



some noise, or fast rise / fall times with ringing that reaches



the input threshold region.







The fix for all of this would be to synchronize the inputs to



a common higher-speed clock and possible add a glitch filter



before using a pair of flip-flops and an AND gate with one inverted



input to do the edge detection. This creates count enables for



counters that all run on the same higher speed clock.







--



Gabor



Hi,



in fact I am using 8 clocks (source are two PLLs), but they fit into primary and secondary clock nets in the MachXO2 device. The trigger pulse is already synchronized in "one shot" module, which produces clean 2-clock cycle signal (15 ns). Then these 15 ns are triggering shift counter producing 100 ns pulse (clocked by the PLLs). I also routed all the intermediate signals outside the FPGA - they look perfect (the raw source signal is generated by a LVPECL comparator - no ringing, reflections etc.).

Is it possible that placement (which I am using in that project) affects the counters? Is it possible to generate the counter, which is unable to count even 20 kHz signals??



Regards,

Krzysztof



PS: I also asked the same question here (with more details): http://embdev.net/topic/336874#3697391



Do you see the problems in post P&R timing simulation?



--

Gabor

 

[GaborSzakacs]

krzysztof.pelczar@gmail.com wrote:

W dniu piątek, 20 czerwca 2014 19:12:08 UTC+2 użytkownik gabor napisał:
Hi,
I am working on a simple multi-channel pulse counter. The pulses counted
are infrequent (up to 100 kHz), and slow (at least 1 us), coming form a
comparator. In total I have 20 parallel channels (identical). Every 0.5
s I read out the counters and reset them to 0 using SPI.
The counter code is simple, contained in a module:
...
reg [17:0] counter_ripple_high;
always @(posedge slow_gate, posedge reset)
begin : b1
/*synopsys resource r0:
map_to_module = "DW01_inc",
implementation = "csa",
ops = "inc1";*/
if (reset)
counter_ripple_high <= 18'b0;
else
counter_ripple_high <= counter_ripple_high + 1'b1; // synopsys label inc1
end
assign counter = counter_ripple_high;
...
Some channels (not more than 3 out of 20) count two times the input
frequency. How is it possible? One channel is not counting properly at
all. I would expect the latter to be obviously caused by the speed of
arithmetic logic, but the former..?
I am looking forward for your opinions.
Regards,
Krzysztof


You have a lot of clocks in this design. It's likely that your

part doesn't have enough dedicated clock routes to implement them

all. Then any counter that doesn't use a proper clock buffer

will have too much clock skew to work properly. This could

explain the one that doesn't work at all.



As for the double rate, I'd start by looking at the input signal

integrity. A common cause for this is counting both edges of

the clock signal due to slow rise / fall times superimposed with

some noise, or fast rise / fall times with ringing that reaches

the input threshold region.



The fix for all of this would be to synchronize the inputs to

a common higher-speed clock and possible add a glitch filter

before using a pair of flip-flops and an AND gate with one inverted

input to do the edge detection. This creates count enables for

counters that all run on the same higher speed clock.



--

Gabor

Hi,

in fact I am using 8 clocks (source are two PLLs), but they fit into primary and secondary clock nets in the MachXO2 device. The trigger pulse is already synchronized in "one shot" module, which produces clean 2-clock cycle signal (15 ns). Then these 15 ns are triggering shift counter producing 100 ns pulse (clocked by the PLLs). I also routed all the intermediate signals outside the FPGA - they look perfect (the raw source signal is generated by a LVPECL comparator - no ringing, reflections etc.).
Is it possible that placement (which I am using in that project) affects the counters? Is it possible to generate the counter, which is unable to count even 20 kHz signals??

Regards,
Krzysztof

PS: I also asked the same question here (with more details): http://embdev.net/topic/336874#3697391

Do you see the problems in post P&R timing simulation?

--
Gabor