# Simple high-speed counter (part of a random number generator)

Joined Oct 14, 2015
13
This is my first time posting, and first time using this forum!

Overview

ak

Last edited:

#### AnalogKid

Joined Aug 1, 2013
8,157
Here is a first pass based on the 8154. There might be race conditions in the latch enable, still thinking it through. Reset Out is there to clear the big counter at power on and any other time you want it to start over.

An alternate arrangement has U2 cleared by the Arduino as in your sch.

ak

#### Attachments

• 11.6 KB Views: 6

Joined Oct 14, 2015
13
Easy part first, you do not want a transparent latch. An edge-triggered latch prevents the latched data from changing if the latch pulse is wider than a counter clock pulse. A blah-blah-blah-574 is the standard critter.
http://www.digikey.com/product-search/en/integrated-circuits-ics/logic-flip-flops/2556318?k=574&stock=1
ak
Good. Thanks for the link. https://www.digikey.com/product-detail/en/SN74AC574N/296-33651-5-ND/1575954 looks good.

Tri-state is not trinary logic. It is a signal multiplexing method to reduce pin counts at the expense of bandwidth. For example, your desktop computer might have 4 GB of ram, but it does not have 32 billion individual data lines running from the memory array to the CPU. Depending on its age and cost, it probably has 32 or 64 data lines. An address and decoding scheme selects which parts of which memory devices are connected to the data bus at any time. Same thing for your circuit. The 8 output lines from each of three 8-bit latches are connected in parallel, presenting only 8 data lines to the Arduino. Each latch has an output enable control input, and the Arduino drives these individually with three output lines. The Arduino sends out an enable-1 signal, waits a microsecond, then reads the 8-bit data input. Then it disables latch #1, enables latch #2, and reads in that data. 8 data lines plus 3 control lines is fewer than 24 data lines. Note that the three latches were clocked simultaneously, so no matter how long it takes to read the data, the data is exactly what you want - a snapshot of a single 24-bit counter value. There is not a big time penalty for this because even if the latches presented all 24 bits in parallel, the Arduino has to read them in with three separate port read commands. It is multiplexing the data internally anyway.
ak
Okay, that makes total sense. I'll update the schematic.

All of the parts are available in 3.3 V, 5 V, or anything from 2 to 5 V. The Digi-Key parametric table lists all options. Totally up to you.
ak
Noted.

Latch logic in a separate post. Two questions:
What is the absolute minimum time between external event triggers?
Is the Arduino polling an input to detect a trigger, or is the external event trigger signal pulling a hardware interrupt?
ak
There is no guaranteed minimum between external triggers. I'll have control over the typical rate, which could be from a few per second to possibly hundreds or more events per second, depending on the empirical results and performance of the circuit. But the minimum time could dip between trigger-highs could be a nanosecond or less. There could even be no gap at all, a trigger event collision of sorts, which would obviously be indistinguishable from a single event. I know the circuit will not be able to gather data when the events are too close together, and that is fine. I'll use the event trigger to pull the hardware interrupt, which could be the same signal that locks the latches. I'm expecting to have the Arduino give a feed back signal when it is done collecting all the data of the latches, which would ready the circuit to receive the next event-trigger rising edge. If other trigger events happened before the Arduino readied the circuit, I would want them to just be ignored. And if the event trigger signal was high (as it could,periodically, persist for an extended time) at the moment the Arduino readied the circuit, I would want that input to be ignored, the logic waiting for the next rising edge instead.

Let's assume that the external event triggers (EET) are at least tens of milliseconds apart. This is enough time for the Arduino to read in the data without any kind of feedback to the timer circuit. The EET signal goes to the latches and the Arduino simultaneously. No timing issue here because the latches latch in 10 ns and the Arduino cannot possibly do anything that fast. So whenever the Arduino gets around to reading the latches (parallel, multiplexed, whatever), the data is just sitting there.

What happens if another EET happens before the Arduino has read the data from the last one? The previous data is overwritten, gone, poof. There is no FIFO or other buffer structure in the design so far. If this is a problem, then the latches can wait for feedback from the Arduino before accepting another EET, but that means an EET might be skipped. If you want some kind of buffer memory to allow the Arduino the ability to catch up, things just go much more complex. It still can be done with discrete chips, but I'd recommend moving to a CPLD.

One way to make sure that the counter outputs are stable before the latches latch is to play games with the logic polarities and edge directions of the control signals. I'm looking into that now.
ak
It is totally fine if EETs get skipped on account of the circuit not being ready. Waiting for feedback from the is what I was thinking. An alternative would be to have a tune-able delay on the circuit itself, locking the latches for x cycles. That amount of time could be adjusted to be longer than the longest it typically took the Arduino to get the data it needs. For now though, I prefer the idea of Arduino feedback.

Potential problem - what is the minimum clock frequency your application can stand? While 16x counters are rated for up to 200 MHz, that speed rating does *not* extend to any form of multi-counter string. It has to do with the way the chips internally decode the carry or terminal count pulse. That pulse can have glitches, and when clock pulse widths are below about 30 ns a glitch might occur on top of a clock edge. So, how low can you go? If you really really really need 50 MHz, we're talking ECL or PECL for discrete logic, or a CPLD.

If you can go with a slower clock speed, such a 10 or 20 MHz, then check this out:

32 bit counter, snapshot latch, and tri-state drivers all in one chip for \$1.10. That is just so sick.
ak
10 or 20 Mhz is totally fine to achieve simplicity. I could go to 2 Mhz if I had to. More Mhz would will give overall project a higher maximum output of entropy. But this is a prototype / proof of concept, and the concept will be just as relevant in lower-performance implementation. But I want the result to be awesome, and in this case more bits / second = more awesome.

Nice find one that chip! It looks good on first review, I'll examine it a little more closely this evening. I must go for a bike ride this afternoon, the nice days are about to run out for the season.

Edit: Look at that beautiful schematic you made! I am grateful.

#### GopherT

Joined Nov 23, 2012
8,012
Wow, @AnalogKid You seem to have fallen in love with this project. That was a lot of effort.