EEVblog Electronics Community Forum
Electronics => Projects, Designs, and Technical Stuff => Topic started by: TheUnnamedNewbie on February 21, 2015, 10:15:03 am
-
Hi,
Working on a small project, my first "real" project that I am doing where I actually found my own parts and didn't just get a kit.
We are building a binary clock that will just count seconds. To do so we are using a increment counter built out of D-flipflops and XOR gates. The XOR gates are 74HC86 and the D-flipflops are 74HC374 flip flops with tristate buffers on the outputs.
The issue is happening whenever we hit more than 3 actual "stages" in our counter. the first two work fine, but the third stage gives issues. I have tried using different actual flipflops and gates on the different IC's, as well as different parts (to ensure it wasn't just a broken part).
This has to be something obvious that I am missing, but I don't see what. Here is a quick handdrawn schematic with what I see on my scope when measuring different pins compared to the input clock (which is provided by my arduino that is simply giving me a square wave - tried different frequencies there as well).
(https://goput.it/kru.jpg)
-
Your logic doesn't look right. In a binary counter, each stage flips state when the previous (least) state changes from 1 to 0. I don't see how you logic achieves that.
-
The problem is the xor gates.
An xor gate glitches at its output.
So the moment you clock all these gates start changing their output. The accumulated delay causes you to violate some hold time in the flipflops
The flipflops in the 374 are edge triggered but ,NOT, designed to trap data that ripples between them.
Be very careful with this kind of constructions. The 374 is designed as a register to store 8 bits of data. This data must be stable for a certain amount of time before and after the edge of the clock.
In your construction this is not true. Stuff starts rippling as you give the edge.
In theory this will works, in practice : not or maybe. It will heavily depend o how many shortcuts were taken in the actual design of the 374...
Manu such flipflops are not flipflops at all but a ring of two inverters biting each others tail.
Try the same experiment with a real 74347 ( not an hc or ls or whatever, but the original 74374 that has no letters between 74 and 374.
-
Your logic doesn't look right. In a binary counter, each stage flips state when the previous (least) state changes from 1 to 0. I don't see how you logic achieves that.
He attempts to make a synchrounous counter. The xor gates act as programmable inverters.
If the previous block output is 0 then flip the next one.
If it is 1 dont do anything.
So the previous stage dictates if the next flipflop toggles or retains.
Synchronous ripple counter
-
The problem is that the stage toggles whenever the input to the XOR gate is HIGH. The first stage toggles all the time - as it should. The second stage toggles for ONE count when the first stage output is high - as expected - but this produces a high output that is two count long - as expected. Now the third stage toggles when second stage is high - and then, because the second stage output is still high (for two counts), toggles again one count later.
Edit: The input to the third stage XOR needs to be the ANDed combination of the outputs of the previous stages. And ditto any subsequent stages.
-
Edit: The input to the third stage XOR needs to be the ANDed combination of the outputs of the previous stages. And ditto any subsequent stages.
Ofcourse! I feel like a total fool not seeing it. That brings a lot of issues with it for us, since we are making a 32 digit counter, that suddenly makes for a whole lot of and gates.
Thanks a lot!
-
The problem is the xor gates.
An xor gate glitches at its output.
So the moment you clock all these gates start changing their output. The accumulated delay causes you to violate some hold time in the flipflops
The flipflops in the 374 are edge triggered but ,NOT, designed to trap data that ripples between them.
Be very careful with this kind of constructions. The 374 is designed as a register to store 8 bits of data. This data must be stable for a certain amount of time before and after the edge of the clock.
In your construction this is not true. Stuff starts rippling as you give the edge.
In theory this will works, in practice : not or maybe. It will heavily depend o how many shortcuts were taken in the actual design of the 374...
Manu such flipflops are not flipflops at all but a ring of two inverters biting each others tail.
Try the same experiment with a real 74347 ( not an hc or ls or whatever, but the original 74374 that has no letters between 74 and 374.
Do you say that it's not safe in general to build a shift register with edge triggered flip flops?
If so, it's new to me.
-
The problem is the xor gates.
An xor gate glitches at its output.
So the moment you clock all these gates start changing their output. The accumulated delay causes you to violate some hold time in the flipflops
The flipflops in the 374 are edge triggered but ,NOT, designed to trap data that ripples between them.
Be very careful with this kind of constructions. The 374 is designed as a register to store 8 bits of data. This data must be stable for a certain amount of time before and after the edge of the clock.
In your construction this is not true. Stuff starts rippling as you give the edge.
In theory this will works, in practice : not or maybe. It will heavily depend o how many shortcuts were taken in the actual design of the 374...
Manu such flipflops are not flipflops at all but a ring of two inverters biting each others tail.
Try the same experiment with a real 74347 ( not an hc or ls or whatever, but the original 74374 that has no letters between 74 and 374.
Do you say that it's not safe in general to build a shift register with edge triggered flip flops?
If so, it's new to me.
it is if you can garantee that the clk-to-Q + logic on the output of one flop is longer than the hold time on the next flop,
assuming the clock arrives at all flops the same time
-
<snip>
Do you say that it's not safe in general to build a shift register with edge triggered flip flops?
If so, it's new to me.
it is if you can garantee that the clk-to-Q + logic on the output of one flop is longer than the hold time on the next flop, assuming the clock arrives at all flops the same time
The issue is not whether it's safe or otherwise, but whether you want/need a 'synchronous' ripple counter.
Just stacking 32 flip-flops will be fine - and you certainly won't see it on a human eradable 'clock' output, but if the counter is - for example - generating the address for a ROM - then the ripple effect as each stage propagates to the next is where the problem creeps in. There will be up to 32 distinct (very fast) output states generated for each count value.
As already pointed out above, the XOR gates permit those 'intermediate' (unwanted) states to interfere with the propagation of bits rippling up the counter chain.
-
<snip>
Do you say that it's not safe in general to build a shift register with edge triggered flip flops?
If so, it's new to me.
it is if you can garantee that the clk-to-Q + logic on the output of one flop is longer than the hold time on the next flop, assuming the clock arrives at all flops the same time
The issue is not whether it's safe or otherwise, but whether you want/need a 'synchronous' ripple counter.
Just stacking 32 flip-flops will be fine - and you certainly won't see it on a human eradable 'clock' output, but if the counter is - for example - generating the address for a ROM - then the ripple effect as each stage propagates to the next is where the problem creeps in. There will be up to 32 distinct (very fast) output states generated for each count value.
As already pointed out above, the XOR gates permit those 'intermediate' (unwanted) states to interfere with the propagation of bits rippling up the counter chain.
how? The intermediate state happens on the input
-
- and each gate has a finite propagation time... nanoseconds - but a period, during which other 'edge' events may/will appear on the common signal busses - corrupting those 'well meaning clocks with hanging bits of data
-
Regardless of the delay issues, is that xor logic correct to implement an n stage binary counter? I don't see how it is.
-
The issue is not whether it's safe or otherwise, but whether you want/need a 'synchronous' ripple counter.
Just stacking 32 flip-flops will be fine - and you certainly won't see it on a human eradable 'clock' output, but if the counter is - for example - generating the address for a ROM - then the ripple effect as each stage propagates to the next is where the problem creeps in. There will be up to 32 distinct (very fast) output states generated for each count value.
As already pointed out above, the XOR gates permit those 'intermediate' (unwanted) states to interfere with the propagation of bits rippling up the counter chain.
how? The intermediate state happens on the input
There is a propagation delay, is there not? And a transition time from one gate to the next?
http://youtu.be/lNuPy-r1GuQ (http://youtu.be/lNuPy-r1GuQ)
If you don't arrange to read every set of inputs after the output transitions of the previous stages are complete, the results could be unpredictable. If there is a single input, single output A->B->C path the delays just accumulate, but if there are gates with two or more inputs then either the inputs must be in phase or the system must be clocked.
-
Regardless of the delay issues, is that xor logic correct to implement an n stage binary counter? I don't see how it is.
Of course you are right. The timing discussion is a red herring.
-
The issue is not whether it's safe or otherwise, but whether you want/need a 'synchronous' ripple counter.
Just stacking 32 flip-flops will be fine - and you certainly won't see it on a human eradable 'clock' output, but if the counter is - for example - generating the address for a ROM - then the ripple effect as each stage propagates to the next is where the problem creeps in. There will be up to 32 distinct (very fast) output states generated for each count value.
As already pointed out above, the XOR gates permit those 'intermediate' (unwanted) states to interfere with the propagation of bits rippling up the counter chain.
how? The intermediate state happens on the input
There is a propagation delay, is there not? And a transition time from one gate to the next?
http://youtu.be/lNuPy-r1GuQ (http://youtu.be/lNuPy-r1GuQ)
If you don't arrange to read every set of inputs after the output transitions of the previous stages are complete, the results could be unpredictable. If there is a single input, single output A->B->C path the delays just accumulate, but if there are gates with two or more inputs then either the inputs must be in phase or the system must be clocked.
but it all happens at the input of the flop, as long as it doesn't happen in the tiny window of setup and hold, the flop doesn't care, the output will be correct