Handling overflow in a self-repeating frequency counter

On Fri, 06 Jan 2012 20:49:01 +0000, Philip Pemberton wrote:

> On Fri, 06 Jan 2012 12:18:50 -0600, Tim Wescott wrote:
> 
>> If you want the data to fit neatly into seven bits, give your counter a
>> period of 127, and assign X'00' to overflow, with X'01' through X'7f'
>> denoting a bit hit at that count.  That'll insure unique data, without
>> blowing out your bit-count budget.
>> 
>> You'll complicate the decoding a bit, but that's an easy task for a
>> computer to carry out.
> 
> That's more or less what I'm doing now.
> 
> The problem is, there's a race condition -- if there's an overflow at
> the same time as an incoming data pulse, then the overflow is stored,
> but the transition is ignored. In the example you gave, that's when the
> count is *exactly* 127, or a modulo thereof.
> 
> What I need to do is eliminate this race condition...
> 
(lots of headache-inducing code snipped)

It shouldn't.  A number between 1 and 127 means that you got an event at 
that time.  A zero means that your counter went from 127 to _1_ (because 
0 is forbidden).

// Note that my Verilog is very rusty: hopefully you'll get the idea

// This should cause a count between 1 and 127 to be emitted when an
// event occurs, and a 'count' of 0 to be emitted _only_ when an
// overflow occurs.
if (event)
  begin
    out <= count;
    emit <= 1;
  end
else if (count == 127)
  begin
    out <= 0;
    emit <= 1;
  end

// The counter update is independent to the above:
if (count == 127)
  count <= 1;
else
  count <= count + 1;

Like Glen said, the above is somewhat logic-intensive because you're 
counting modulo 127 -- but it can be done.

-- 
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com