Binary increment counter doing odd things - Page 1
Forum section: electronics / projects

author: TheUnnamedNewbie
author_rank: Super Contributor
timestamp: February 21, 2015, 10:15:03 am
content: 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).

author: zapta
author_rank: Super Contributor
timestamp: February 21, 2015, 10:57:59 am
content: 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.

author: free_electron
author_rank: Super Contributor
timestamp: February 21, 2015, 10:58:51 am
content: 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 flipflopsThe 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.

author: free_electron
author_rank: Super Contributor
timestamp: February 21, 2015, 11:01:17 am
content: Quote from: zapta on February 21, 2015, 10:57:59 amHe 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

author: Andy Watson
author_rank: Super Contributor
timestamp: February 21, 2015, 11:18:23 am
content: 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.

author: TheUnnamedNewbie
author_rank: Super Contributor
timestamp: February 21, 2015, 12:02:13 pm
content: Quote from: Andy Watson on February 21, 2015, 11:18:23 amOfcourse! 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!

author: zapta
author_rank: Super Contributor
timestamp: February 21, 2015, 10:19:39 pm
content: Quote from: free_electron on February 21, 2015, 10:58:51 amDo 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.

author: langwadt
author_rank: Super Contributor
timestamp: February 22, 2015, 12:00:22 am
content: Quote from: zapta on February 21, 2015, 10:19:39 pmit 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

author: SL4P
author_rank: Super Contributor
timestamp: February 22, 2015, 01:11:42 am
content: Quote from: langwadt on February 22, 2015, 12:00:22 amThe issue is not whether it's safe or otherwise, but whether youwant/needa '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.

author: langwadt
author_rank: Super Contributor
timestamp: February 22, 2015, 01:44:13 am
content: Quote from: SL4P on February 22, 2015, 01:11:42 amhow? The intermediate state happens on the input

author: SL4P
author_rank: Super Contributor
timestamp: February 22, 2015, 02:22:02 am
content: - 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

author: zapta
author_rank: Super Contributor
timestamp: February 22, 2015, 02:28:01 am
content: Regardless of the delay issues, is that xor logic correct to implement an n stage binary counter? I don't see how it is.

author: IanB
author_rank: Super Contributor
timestamp: February 22, 2015, 02:30:06 am
content: Quote from: langwadt on February 22, 2015, 01:44:13 amThere is a propagation delay, is there not? And a transition time from one gate to the next?http://youtu.be/lNuPy-r1GuQIf 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.

author: edavid
author_rank: Super Contributor
timestamp: February 22, 2015, 02:41:51 am
content: Quote from: zapta on February 22, 2015, 02:28:01 amOf course you are right. The timing discussion is a red herring.

author: langwadt
author_rank: Super Contributor
timestamp: February 22, 2015, 02:42:33 am
content: Quote from: IanB on February 22, 2015, 02:30:06 ambut 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