Hi. I have problem about async mod13 down counter, and I couldn't find any solution in internet:
I got simple idea: my full mod16 counter works, so just add reset signals to 2^0 flip flop, and 2^1 flip flop, when circuit reach "15". And it worked - from value 0 i reach value 12, but then, i have values 8 - 4 - 3 - 2 - 1 - (0)
And I need help, because I don't know what's wrong - my AND gate gives one, only when all four states are positive, so why my circuit acts so weird?


Value 12



And after next clock signal - value 8???

 

It is doing exactly what I would expect it to do.

The problem is that you are creating glitches on inputs to asynchronous inputs, as well as setting up critical races, but it this case it's pretty easy to place a bet on who will win them.

After you hit 1111, your AND gate resets the two lsb FF so that you have 1100.

But then what happens on the next clock?

Remember, this is a RIPPLE counter, so first the lsb changes and you have 1101. Then the next bit changes, and you have 1111. Well, guess what? That satisfies the criteria for your AND gate, so it is going to reset the two lsb's again. But this takes a bit of time and, in the mean time, the ripple counter continues on and you have 1011 (i.e., the state you want it to be), but then the reset signal from the AND gate gets there and you end up with 1000.

What happens next?

You get a clock and the states ripple across: 1000 -> 1001 -> 1011 -> 1111 -> 0111

But you passed through that 1111 state again and reset the two lsb's, giving you 0100.

After that, the msb is a 0 and it will ripple count down to 0000 without any more false resets.

Why are you trying to design asynchronous logic? There are LOTS of demons in those waters.

The moment you start using asynchronous resets to implement logic, you take on the responsibility for fully analyzing the entire transition-by-transition behavior of the circuit.

The designers at the company I first worked for weren't aware of that -- the brilliant guy that started the company was a physicist and an VERY good analog designer -- but didn't know much about digital design beyond the basics. I couldn't convince him or anyone else to stop using asynchronous logic. We had a sister company (we shared office space to split the lease costs) and we sometimes sat in on each other's design reviews. They had a chip that failed to function properly after being fabbed and so they asked us to sit in on the post mortem review. As soon as I sat down and saw the schematic, I started drawing a timing diagram on the pad in front of me and before the meeting even got started I was able to tell the guy that headed that chip design that it had a critical race and how I expected it to behave. He looked rather sheepish as he acknowledged that that was exactly the problem that it was exhibiting. At that meeting, both companies agreed to adopt the policy that ALL logic would be fully synchronous unless there was a damn good reason and, even then, only if it went through a thorough review.

Life was good for several years until we had to design a chip that was so noise sensitive that we had to suppress the clock entirely during the noise-sensitive aspects of it, but there was still sequential logic that had to function in order to capture events during that window. So, for my sins, I got tasked with designing the fully-asynchronous logic on the chip. Interestingly, I came up with a handshaking approach based on how the mechanical sequencing happens on the F-15 main landing gear deployment. It worked beautifully, somewhat to my surprise, and for the rest of my time there (and for several years after as a contractor) I became the only one that was allowed to design asynchronous logic (which was still kept to an absolute minimum, per the "damn good reason" clause).