You've changed the requirements by a lot! Measuring something in nanoseconds is hard. Measuring something with a +-100 ns accuracy really isn't. A 10 MHz counter works perfectly fine for that, do 20 MHz if you want to be sure.
Any modern 32 bit microcontroller (read: 2€ investment...) has timer/capture units that can do that for you.
You've went from a ...
I see two issues:
No decoupling caps. Edit: Add decoupling caps (see comment). When ICs switch state they draw a pulse of current on the 5V. Your power wires have enough inductance to cause the 5V to momentarily dip to near zero. This causes the IC to lose it memory.
No series resistors on your LEDs, although some LEDs have built-in resistors, so I can't be ...
Time to digital converter chip, available from several manufacturers. Accuracy: picoseconds.
Microcontroller timer in capture mode to measure pulse width, or time between two pulses. Pretty much any microcontroller will do the job, but accuracy will be at best one clock cycle, so you must choose a microcontroller ...
15 years ago I designed a two parameter digitizer (energy and time) to measure time of flight. For this system I used a constant current source into a cap held in reset by a JFET. On receiving the trigger (NIM fast logic, level shifting kept in the analog (as opposed to saturated switching) regime, the JFET opened, and I was able to achieve 50ps resolution ...
The circuit you cited is a ripple counter, not a synchronous counter. It actually has eleven states, 0000 through 1010, but as soon as the last state is reached, the NAND gate immediately (asychronously) resets the flip-flops to the 0000 state.
In a synchronous counter, all of the flip-flops would share a common clock, and you'd control the sequence of ...
Given it is an assignment, I'm not going to work through the logic. However in all such questions you can boil it down to a circuit with two steps:
You have a binary 0 to n-1 counter, where n is the number of required states (13 in your case). This can be a bog standard synchronous binary counter that starts at 0000 and then when it reaches n is reset back ...
We can see from the datasheet, that the CD4020 has the following block diagram:
Notice the naming of the outputs, you have Q1, and Q4-Q14.
Note also that it is a 14-stage counter, which means the counter internally has 14 outputs.
From your data you can see that Q1 (the LSB) is toggling on every negative edge pulse as you would expect. Q1 is the first bit ...
Is the trigger input completely asynchronous to the 50MHz clock? If so, it probably violates the setup and hold time requirements from time to time. You need to synchronize it to the clock through at least two FFs before you use it in any decision making.
I can hear you saying, "But it's only used in one if statement. If the trigger_state gets updated, ...
You're using a "glitch" to reset your counters. In other words, when the reset pulse starts, it immediately removes the conditions for its own creation, so it's only as wide as the propagation delay through one of the counters.
Clearly, one of those counters is faster than the other, so it resets successfully, while the other does not. This is why this is ...
Your cheapest solution is going to be determined by the cost of your time , components and circuit board with debug time.
In this case your best solution is a used 100 MHz counter off EBAY for $150
(basically +/- 100ns).
Well then, a cheap 8-bit microncontroller like ATTINY2313 can be clocked at 20Mhz, then you can just use its timers in input capture mode and that will get you +/- 25ns precision at each end of the pulse for over-all +/- 50ns precision (modulo clock jitter and innacuracy so use a good crystal for the clock) 75ns accuracy should be ...
The book is wrong. The minimum clock period is 30 ns.
First FF clock-to-Q: 10 ns
First AND gate in-to-out: 10 ns
Second AND gate in-to-out: 10 ns
Setup time to third FF: 0 ns
Total: 30 ns
This is the time required from when the output of the first FF goes high (while the other two FFs are already high) to insure that the third FF goes low on the next ...
Other answers have focused on why you might be approaching this the wrong way. Although I agree with those answers, what you're asking for does exist, so I'll go ahead and give you a straight answer. You'll likely find that this approach is more expensive than alternatives though.
What you want is a 2 GHz voltage-controlled oscillator (VCO) with 3.3-V ...
Set Jam Inputs J1-J4 to 0V (pulldown) then give a short positive going pulse on Preset Enable. That should set the all the outputs to low. Once Preset Enable goes back to 0, pulses on the clock input will cause the counter to count up or down (depending on how you've set UP/DOWN.)
A simple, easy, and not terribly reliable way to do this would be to ...
With synchronous counters the delay occurs while the clock is inactive (unchanging, or an inactive edge). When the next active edge arrives at the clock inputs, the data inputs are already stable. Hence all outputs change at the same moment, which is the essence of the system being 'synchronous'.
This is a pretty difficult accuracy/precision to hit.
First of all, according to the datasheet, you can't have a period on that pin of less than 20 ns, so that is a max frequency of 50 MHz. This is from Table 17-8 of the datasheet. So, 60 MHz is out.
But more importantly, you are trying to get a timing accuracy of 100 Hz / 60 MHz, this is 1.7 ppm ...
It sounds like you are expected to solve this with a state-machine type circuit, however it can also be done using a classical counter circuit.
The key to this problem is recognizing that for half the count you are inverting the counter output bits. Further, your output bit 0 is actually the most significant bit of the counter, it is just presented as the ...
Fist of all:Your trigger is coming in a-synchronous to the clock. You must first synchronize it before you can safely use it.
The code for that is:
always @(posedge clk)
sync_trigger <= trigger;
safe_trigger <= sync_trigger;
The behavior your are seeing is because the hardware will more look like this:
I think the most realistic approach here is probably still a bit tricky:
First of all, you'll have to realize that your signal has a pretty high bandwidth, assuming that the rise time of your pulses needs to be pretty steep to even get the required timing accuracy (e.g. if your rise time is 40 ns, then in 1 ns of an edge not that much voltage difference ...
You can solve this problem with just a couple of parts. TI makes logic parts in their 74AC logic family that operate correctly down to 1.5V. Use a 4 bit counter as shown below to repeatedly count from 8 to 15. Use the RCO output, which is a one clock wide pulse to reload the counter and to also drive an R/C circuit to produce the narrow pulse that you ...
I think you do have an output signal but it only lasts for maybe 10 nano seconds before the reset in the chip has activated and cleared everything down again. Try using a scope with a trigger function and a fast time base.
Each segment on a 7-segment display is designated a letter (A-G). This is standard and is shown in the SN7447 datasheet:
You can use a diode tester or a simple voltage source and a resistor to determine the pinout of your particular display. Then just map the pins correctly (again, from datasheet):
An IR Diode and IR Transistor pair would work well. Make or break the line of sight, and your microcontroller or other input method can talk to the computer.
Drill a small hole on each side, and adjust it so that when the center plastic gets pushed down, the signal breaks. That's a count.
We have to assume that "it's impossible" is not the right answer, so that means that we can assume that the CPU has enough power to poll the pin at a rate that's fast enough not to miss any pulses.
I don't know why you think that "you need to hardcode the transition pattern". All you need to do is find the 0→1 and 1→0 transitions and count one or ...
Some long while ago, as a thought experiment, I 'designed' a time capture FPGA.
It had a ring oscillator, conventional other than the fact it had 41 inverters. The period was thus much much lower than the delay of any gate. The FPGA process had individual gate delays down in the 10s of pS where the routing was local and the fan-out low, but could only ...
As someone already pointed out, there are dedicated ICs for that purpose.
If you want to do it on your own a possible approach would be to use so called Vernier delay lines.
You have two delay lines (chains of buffers) where one chain uses faster buffers than the other. The resolution of your measurement is equal to the difference of the delays of the ...