Run/Stop a counter using a train of pulses

[omara007]

Hi folks

I have a train of pulses .. each pulse is seperated from its preceeding pulse by a number of clock cycles .. I want to design a counter that counts these clock cycles .. in other words, this counter should start counting once the first pulse comes, and ends/resets once the next pulse comes ..

Anyone has a VHDL/Verilog code for that ?

 

[barfi]

hi Omara
what is the frequency of your clock pulse?
why you don't use 74hc590?
it is simple and straight forward you can use some logics to trigger it and stop it.
and then read its counter value by simple microcontroller...

 

[omara007]

hi Omara
what is the frequency of your clock pulse?
why you don't use 74hc590?
it is simple and straight forward you can use some logics to trigger it and stop it.
and then read its counter value by simple microcontroller...

the pulse doesn't have a rate .. yet, it's synched with an 8mhz clock ..
i want to have the counter integrated in my chip

 

[FvM]

Please supplement the necessary signal definitions:

process (clk)
begin
if rising_edge(clk) then
-- have a synchronous edge detection
  pulse_sync <= pulse;
  pulse_s_prev <= pulse_sync;
  if pulse_sync = '1' and pulse_s_prev = '0' then
    counter <= (others => '0');
    result <= counter;
  else
    counter <= counter + 1;
  end if;
end if;
end process;

 

[omara007]

Please supplement the necessary signal definitions:

process (clk)
begin
if rising_edge(clk) then
-- have a synchronous edge detection
  pulse_sync <= pulse;
  pulse_s_prev <= pulse_sync;
  if pulse_sync = '1' and pulse_s_prev = '0' then
    counter <= (others => '0');
    result <= counter;
  else
    counter <= counter + 1;
  end if;
end if;
end process;

The solution looks fine to me .. but did you have 2 delayed copies of the pulse ? .. why didn't you directly deal with PULSE and PULSE_SYNC the same way you are dealing with PULSE_SYNC and PULSE_S_PREV ?

In other words, you approach seems to solve the problem but with one clock cycle skipped from being counted .. right ?

 

[j_andr]

why didn't you/.../the same way you are dealing with PULSE_SYNC and PULSE_S_PREV ?

FvM assumes the pulse can be asynchronous with your clock,
so he wants to have two signals with well defined timing in the clock domain;
at least I think so ...
btw - if the PULSE can be shorter then your clock period
the solution has to be modyfied;
---

 

[FvM]

if the PULSE can be shorter then your clock period
the solution has to be modyfied

Very right. But the solution is somewhat complex (involving two clock domains, interfaced by handshake signals). It should be considered, if actually relevant.

why didn't you directly deal with PULSE and PULSE_SYNC

That's the $1000 question. As supposed, I assume an asynchronous input signal, simply the general case. It may happen then, that the rising edge coincides with the clock edge. Depending on the exact signal timing, the event may be detected in the present or the next clock cyle. Unfortunately, this decision is performed for each counter and result bit independantly. Due to logic delay skew, in a small time intervall of at least a few 100 ps, counter reset and latching of period measurement shows inconsistent results.

As an example, assume a counter that is latched while it is advancing from 0x0FF to 0x100. Due to delay skew, any result between 0x000 and 0x1FF may be latched.

with one clock cycle skipped from being counted

No, not skipped, just delayed. And absolutely unavoidable, to my opinion.

 

[omara007]

if the PULSE can be shorter then your clock period
the solution has to be modyfied

Very right. But the solution is somewhat complex (involving two clock domains, interfaced by handshake signals). It should be considered, if actually relevant.

why didn't you directly deal with PULSE and PULSE_SYNC

That's the $1000 question. As supposed, I assume an asynchronous input signal, simply the general case. It may happen then, that the rising edge coincides with the clock edge. Depending on the exact signal timing, the event may be detected in the present or the next clock cyle. Unfortunately, this decision is performed for each counter and result bit independantly. Due to logic delay skew, in a small time intervall of at least a few 100 ps, counter reset and latching of period measurement shows inconsistent results.

As an example, assume a counter that is latched while it is advancing from 0x0FF to 0x100. Due to delay skew, any result between 0x000 and 0x1FF may be latched.

with one clock cycle skipped from being counted

No, not skipped, just delayed. And absolutely unavoidable, to my opinion.

Good .. Yet, this counter will be running even before the arrival of the first pulse .. the first pulse will be resetting it for a new counting period .. in case the first pulse arrives late, the counter will be freely running and consuming power. Is there a way to disable counting until the arrival of the first pulse ?
Effectively, I'm using this in a wireless design in which power consumption is very critical ..

 

[FvM]

I think, the design is incompletely specified. Behaviour before the first pulse is only a special case. After the last pulse, it will continue counting as well.

A possible solution is to stop counting at maximum count, this also allows to determine an overflow easily. Another solution would require a state machine and defined system states.

  elsif counter < maxcount then 
    counter <= counter + 1;

 

[j_andr]

Is there a way to disable counting/.../

a simple solution to hold counting until first pulse can be adding
a one bit flag [flop-flop] - count_enable which is initialized
to '0' after power up and then defined as:
count_enable <= pulse OR count_enable;
then use it in the RTL as a standard count enable signal,
or add it as a third condition that resets the counter:
if (pulse_sync = '1' and pulse_s_prev = '0') or count_enable = '0' then
---

Added after 3 hours 53 minutes:

if the PULSE can be shorter then your clock period/.../

the solution is somewhat complex (involving two clock domains/.../

may be not so complex ?
you can easily extend too short input PULSE triggering an FF with the pulse
rising edge and reseting it together with the counter [from your example code];
---

 

[omara007]

Is there a way to disable counting/.../

a simple solution to hold counting until first pulse can be adding
a one bit flag [flop-flop] - count_enable which is initialized
to '0' after power up and then defined as:
count_enable <= pulse OR count_enable;
then use it in the RTL as a standard count enable signal,
or add it as a third condition that resets the counter:
if (pulse_sync = '1' and pulse_s_prev = '0') or count_enable = '0' then
---

Added after 3 hours 53 minutes:

if the PULSE can be shorter then your clock period/.../

the solution is somewhat complex (involving two clock domains/.../

may be not so complex ?
you can easily extend too short input PULSE triggering an FF with the pulse
rising edge and reseting it together with the counter [from your example code];
---

Are you going to use the short pulse itself as a clock triggering a flop ?

 

[j_andr]

[Are you going to use the short pulse itself as a clock triggering a flop ?

yes;
---

 

[omara007]

[Are you going to use the short pulse itself as a clock triggering a flop ?

yes;
---

I believe it's not a good coding style to trigger a flop with a data signal. This signal may not be of a fixed period/duty-cycle.

How will that affect the backend implementation ?

 

[j_andr]

I believe it's not a good coding style/.../

me too, but if you have to detect a signal which is shorter
then a clock period - what you can do ?
may be a detailed specification would show this approach is not acceptable
or different solution is better but so far I see no danger using
the PULSE signal as a clock input to a flip-flop;

This signal may not be of a fixed period/duty-cycle

that's why I suggest to use its slope - the solution doesn't rely
on any parameters [length/frq./duty] of PULSE;
---

 

[omara007]

I believe it's not a good coding style/.../

me too, but if you have to detect a signal which is shorter
then a clock period - what you can do ?
may be a detailed specification would show this approach is not acceptable
or different solution is better but so far I see no danger using
the PULSE signal as a clock input to a flip-flop;

This signal may not be of a fixed period/duty-cycle

that's why I suggest to use its slope - the solution doesn't rely
on any parameters [length/frq./duty] of PULSE;
---

Will this PULSE signal be considered a CLOCK while doing the physical implementation (Back-End) ?

 

[j_andr]

Will this PULSE signal be considered a CLOCK while/.../

yes, sounds like sacrilege ?
may be an asic world is more different then fpga then I'm aware of;
see how nicely it works on a simulator:

module pulse
(
  input            clk, pulse,
  output reg [7:0] result
);

reg  pls_sync, pls_sync_prev;
reg  pls_int = 1'b0;
wire clr = pls_sync & !pls_sync_prev;
 
 always @(posedge pulse or posedge clr)
   if ( clr ) pls_int <= 1'b0;
   else       pls_int <= 1'b1;
 
 always @(posedge clk)
   begin
     pls_sync <= pls_int;
     pls_sync_prev <= pls_sync;
     if ( clr)  result <= 0;
     else      result <= result + 1;
   end

---

 

[FvM]

I think, the solution is generally applicable. The pulse input would be regarded as (unrelated) clock, in so far it should have a maximum frequency and a minimum pulsewidth. However, if these constraints are violated, the worst possible result would be in unregistered pulses. That's acceptable, to my opinion. The important point is, that the pulse input is processed by a single flip-flop and synchronized to clk afterwards. So there's no room for unpredictable behaviour, as far as I see.