Wow, @AnalogKid You seem to have fallen in love with this project. That was a lot of effort.

I totally agree. It is very inspiring to have the support. I can't wait till have this all built and operational so I can share the results.

 

For a different approach, this could easily be implemented in a $10 Altera CPLD. Add an oscillator and a small circuit board to convert the surface mount CPLD to a DIP socket for the victor board and you are complete. Have to program the CPLD, of course. Much more versatile than anything using discrete IC's.

 

For a different approach, this could easily be implemented in a $10 Altera CPLD. Add an oscillator and a small circuit board to convert the surface mount CPLD to a DIP socket for the victor board and you are complete. Have to program the CPLD, of course. Much more versatile than anything using discrete IC's.

I'm going to stick with the discrete IC's for now and get this thing up and running, partly because it will help me to learn this stuff if I can put my hands on the parts and connect it all. I've never made a circuit with any of these type of components before. I made some simple stuff when I was a kid, 15 years ago, but most of it didn't even work to well.

But you have provided a great lead, and perhaps on follow up circuits or optimizations I will investigate the CPLD approach. It will also be nice since at that point I'll have a reference circuit to compare the CPLD implementation against. I can't quite visualize how a more general-purpose circuit could beat our current layout in terms of latency, but there are many things I don't understand.

 

For that matter, even a microcontroller which can use a high speed clock can be used. Instead of the internal clock if available, external 50ppm stabilty oscillator or better can be used. Time interval counting can give the no. of pulses. The timers are already rated to count at this frequency.
Advantages are, flexibility, cheap and also avoiding routing the 50MHz signal to multiple chips!

 

**What needs to be counted is how many times an oscillator cycles between events.** -> That is what I am trying to do.

From what I understand what you are trying to do is, essentially, what a frequency meter does: it counts pulses received between internal clock pulses. It is pretty simple to do. Today, of course, a single chip does it all but have a look at http://kakopa.com/frequencycounter/index.html where you can see how it is done with discrete components.

If you take a frequency counter and feed it a highly unstable frequency (pretty much just noise) then you get random numbers. If, on top of that, the counting time is highly variable then you get even more random.

So, I have not gone deeply into your project but if what you want is a random number generator then I would design a white noise generator and feed the output to a timed counter and then a latch to hold the result. If you want to make it doubly random then make the counting time also variable.

Depending on the number of bits you want you will need counter, latch, etc with more bits.

 

For a different approach, this could easily be implemented in a $10 Altera CPLD.

Yeah, I thought of that right away, and mentioned it later. But anyone with a CPLD or FPGA experience base probably is not going to join a Q & A forum asking about counters and latches, so it seemed like an unnecessary layer of complication. I just did an Altera design a few months ago. Excellent tech support, which was a good thing because there software was very poor and large sections of it completely undocumented. I strongly prefer Lattice.

ak

 

I can't quite visualize how a more general-purpose circuit could beat our current layout in terms of latency...

If you look at the internal logic schematics on synchronous counter datasheets (and, really, who *doesn't* love to spend a quiet evening deciphering look-ahead-carry logic?), what makes synchronous counters work is that they decode the data input to each ff from the outputs of all of the previous ff's. That is only 1 gate delay no matter how many bits, but only within the package. As noted above, a 4-bit counter rated for 150 MHz becomes a 15 MHz counter when combined with another chip to form an 8-bit circuit.

However, inside a CPLD you can build a 23-input AND gate (and a 22, and a 21...) so there is no ripple-carry component to the overall counter. You have a true 24-bit synchronous counter good for 100 MHz, plus the latch timing logic, plus whatever else you want to throw in, all for $5 (plus that whole learn-a-new-design-suite thing).

ak

 

From what I understand what you are trying to do is, essentially, what a frequency meter does: it counts pulses received between internal clock pulses. It is pretty simple to do. Today, of course, a single chip does it all but have a look at http://kakopa.com/frequencycounter/index.html where you can see how it is done with discrete components.

If you take a frequency counter and feed it a highly unstable frequency (pretty much just noise) then you get random numbers. If, on top of that, the counting time is highly variable then you get even more random.

So, I have not gone deeply into your project but if what you want is a random number generator then I would design a white noise generator and feed the output to a timed counter and then a latch to hold the result. If you want to make it doubly random then make the counting time also variable.

Depending on the number of bits you want you will need counter, latch, etc with more bits.

In a way you are correct, and what you suggest would be optimized for many aspects of what I have in mind. But a key part of what I am going for here is that the source of the entropy has a non-electrical origin, a macroscopic origin. For the purposes of the design work I am pursuing here I have been idealizing the input source as a button push, and at first, there will most certainly be a button for testing. Later, I will certainly explore other methods of generating pulses.

 

In a way you are correct, and what you suggest would be optimized for many aspects of what I have in mind. But a key part of what I am going for here is that the source of the entropy has a non-electrical origin, a macroscopic origin. For the purposes of the design work I am pursuing here I have been idealizing the input source as a button push, and at first, there will most certainly be a button for testing. Later, I will certainly explore other methods of generating pulses.

I would use 24 independent 555 timers with differing frequencies. I would also add a shift register and a multiplexer - the multiplexer feeds the clock on the shift register. Very randomized.

 

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

On the 74LV8154, pin 7, RCLK. When RCLK takes a rising edge, it is the same rising edge that CLKA & CLKB are receiving, though perhaps delayed by a small fraction of a period. Lets say that a specific pulse was the one that would push the counter from 1000 to 1001. Am I understanding correctly that if RCLK receives a simultaneous rising edge, the latch will have the 1001 value pushed into it? And the latch will retain the recorded value through RCLK remaining high, RCLK going to low and RCLK staying low, and that only when RCLK experiences a rising edge will the next counter value be pushed into the latch?


I might understand the trigger logic.

To start, CLR will be high, since we are feeding it +5 volts.

D will be low (open trigger, pulldown resistor).

CLK will be doing its back and forth thing.

Q-Bar and PR will be the same. If they are low nothing changes, and the chip will ignore clock and trigger input. But perhaps the function of the C5 capacitor is to cause CLR to go low, briefly, when the trigger is released, as 74AC74 side of the cap becomes a sink as positive charge rushes to fill it? So CLR would then be low, D would be low. PR and Q-Bar would still be low from before, so as soon as CLR and PR are low, Q-Bar would go high, which would make PR high. The new temporary condition would be CLR low, as the capacitor has not yet attained equilibrium, and PR high. Then, perhaps just a few clock cycles later, the capacitor would reach equilibrium, and CLR would be high again. CLR would be high, PR would still be high. D would be low.

Then a pulse arrives from the trigger. D goes high, but C5 is also acting as a sink, so perhaps D going high will be slightly delayed. By how long I am curious. CLR will remain high as the capacitor discharges. When D does go high, the next rising clock edge will cause Q to go high, and Q-Bar to go low. RCLK will get its rising edge, as will the Arduino interrupt.

As soon as Q-Bar goes low, PR will be low again too. That's okay, CLR will be high and PR will be low, so nothing changes, the outputs remain the same until the trigger is released, when CLR will momentarily go low again. This is back where we started.

It looks like you put R1 at 1/10th the resistance of R2 for the purpose of causing CLR to go low, briefly, upon release of the trigger.

If my understanding is correct, I think it would work just fine. I like that Q remains high for as long as the trigger is closed.


Here is the new chip list:

(1) Different Oscillator - Still 20 Mhz, 50 ppm. Change is now 5 volts (and through-hole) - https://www.digikey.com/product-detail/en/MXO45HST-3C-20M0000/CTX791-ND/1801906
Does that change the capacitor bank that supplies the oscillator?

(1) The counter + latch in one - https://www.digikey.com/product-detail/en/SN74LV8154N/296-34067-5-ND/1594917

(1) Trigger logic - https://www.digikey.com/product-detail/en/SN74AC74N/296-4342-5-ND/375712

 

If you look at the internal logic schematics on synchronous counter datasheets (and, really, who *doesn't* love to spend a quiet evening deciphering look-ahead-carry logic?), what makes synchronous counters work is that they decode the data input to each ff from the outputs of all of the previous ff's. That is only 1 gate delay no matter how many bits, but only within the package. As noted above, a 4-bit counter rated for 150 MHz becomes a 15 MHz counter when combined with another chip to form an 8-bit circuit.

However, inside a CPLD you can build a 23-input AND gate (and a 22, and a 21...) so there is no ripple-carry component to the overall counter. You have a true 24-bit synchronous counter good for 100 MHz, plus the latch timing logic, plus whatever else you want to throw in, all for $5 (plus that whole learn-a-new-design-suite thing).

ak

I'm thinking they must work like this: A signal arrives at every bit in the counter simultaneously. Each bit already knows what it should do upon arrive of the signal, which is "flip or not to flip". Then, after each bit does it's assigned task, there is additional logic to coordinate what each bit shall do upon the arrival of the next signal. It's almost like the next number in the counting sequence has been pre-loaded?

The fact seems to be that coordinating a many-bit counter will involve propagation delays, but in a syncoronous counter that is all done "behind the scenes", but there is still an impact of ripple-delays: the counter will not be ready to receive a new input from the clock until all of the logic has reached its resting state.

 

Got the chips. Got everything connected. Got the timing data streaming to the computer.
I'll post more once I get things a little bit more refined. I did spend quite a bit of time trying to figure out why the counter wasn't incrementing. Turns out the clear pin was active low, not active high as I had assumed.

 

Turns out the clear pin was active low, not active high as I had assumed.

That's what the little bubble on the reset pin means.

Glad everything worked out.

ak