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.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.Wow, @AnalogKid You seem to have fallen in love with this project. That was a lot of effort.
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.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.
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.**What needs to be counted is how many times an oscillator cycles between events.** -> That is what I am trying to do.
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.For a different approach, this could easily be implemented in a $10 Altera CPLD.
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.I can't quite visualize how a more general-purpose circuit could beat our current layout in terms of latency...
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.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.
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.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.
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?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
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?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
That's what the little bubble on the reset pin means.Turns out the clear pin was active low, not active high as I had assumed.
by Jake Hertz
by Duane Benson
by Jake Hertz