50%duty cycle 3-bit binary counter problem

[spritbille]

I am corrently trying to solve the question "So far so good. The general thinking was OK, but there was a major problem with the circuit, can you discover what it was?"

The problem can be seen here:
Real World Examples #5 – Clock Divider by 5 « Adventures in ASIC Digital Design

The possible answers is seen here:
**broken link removed**

But I really don't see how I can handle this problem?

Thank you. I would really help me.

Kind regards
Bille

 

[BradtheRad]

Since it says 'major problem' it suggests we should look for things like two outputs going to one input, or something happening on a leading edge not jibing with a test for a value on a falling edge, etc.

I noticed that the article talked about one thing happening when an output goes high, and elsewhere a condition is tested on the falling edge.

However it wasn't obvious. Instead I see the solution was to change the values used to test x and y.

This is the kind of thing that is hard to notice except when you build with real IC's. My own mental eye has too much trouble picturing what happens down the line when a 0 changes to a 1, etc.

Furthermore a working circuit will need to be more complicated than the simple flowchart in the article. I imagine the engineer in the article had already built many real circuits just to be able to draw this one on paper.

Working with real IC's brings out the problems that are not obvious beforehand. Conundrums such as asynchronous counting, where a carry ripples through stages gradually causing the updated value to be a cycle late. To solve this the synchronous counter had to be devised. I don't know if that was a problem here, but it's easy sort of thing to overlook.

Truth tables do not take into account what is going on halfway through a clock cycle.

Anyway don't blame yourself for not seeing the problem and solution right away.

 

[spritbille]

Thanks you

Now the problem is that I need to answer in 4½ hours :???:

Is there some solution that you think is more likely than another?

Kind regards

 

[FvM]

Now the problem is that I need to answer in 4½ hours.

I think the problem is reading. The divide by 5 with 50% duty cycle is a series topic at edaboard - and all over the internet. You can simply start with the similar threads listed below and find some useful answers. As you surely find out, the design involves utilizing dual edges and/or asynchronous logic combinations. Happy developing!

@BradtheRad: I suggest reading before writing in this case

 

[spritbille]

okay... now I have looked a lot in here and I have consulted my friend. We both agree that it must be answer c.... Could you confirm this? :grin:

 

[BradtheRad]

There's a few things that have been left out. The answer link shows a list of 3 ways to test for x and y. At the bottom it says "b and c are correct."

I'm not sure I understand why statement 'a' is in the list. If it's not correct then why are other incorrect combinations not listed too? Even if they are incorrect?

I for one cannot contain it all in my mind. I would need to compile a comprehensive truth table, listing all combinations of x and y, with outcomes. Or better yet, construct a real circuit and spend an hour watching how it behaves.

As far as I can tell the puzzle serves to emphasize an approach we need to take with binary. We want certain numbers to trigger some action in the next clock cycle. We list the ones that do this. Then we notice a pattern. Maybe they're the numbers that occur before a carry? Or all the numbers except that?

If we can solve this puzzle quickly it's because we recognize these patterns from previous encounters. You aren't expected to solve it by intuition.

Incidentally it's a cute puzzle, however notice the puzzle asks us to say 'Here's how to get over this hurdle, and now that we solved one problem no further revisions will be necessary.' This approach didn't work for the original designer of the circuit, did it?

Can we hold all permutations in our mind? How do we know our answer will make the circuit work flawlessly afterward?

Can we assume that changing the test values for x and y won't cause another problem? Or unmask a problem not foreseen?

The correct answer is 'try changing the values we test x and y for, then watch what happens, then we troubleshoot some more, etc.'

 

[lostinxlation]

okay... now I have looked a lot in here and I have consulted my friend. We both agree that it must be answer c.... Could you confirm this? :grin:

I'm responding with spine, but I'm not sure if any of these works.
(b) could have an issue when it transitions from 001 to 010.
In the same way, (c) probably has an issue when it transitions from 011 to 100.

Gray counter may work.

 

[FvM]

If the flop outputs from the 3 bit counter can toggle like 011 -> 001 -> 101 -> 100 when it transitions from 011 to 100, even (c) could be a trouble.

To simplify the problem, a combinational logic must be expected to create glitches, if more than one input is changing at the same time. So every logical term, that combines outputs of a binary counter can have glitches.

One possible solution is to change the counter sequence in a way, that one bit gives the intended information without further decoding. You could e.g. operate the counter in the interval 1..5 and use the MSB as output.

P.S.: I think, a gray counter doesn't work modulo 5.

 

[lostinxlation]

P.S.: I think, a gray counter doesn't work modulo 5.

Ya, I guess that's true. Having only 1 bit changing at a time, a bit pattern after even number of cycles and the starting bit pattern are different by even number of hot bits and wrapping around to the starting pattern would be an issue.

Probably can go semi gray counter changing only 1 bit at a time, but changing multiple bits in a cycle that neg edge flop launches 1. Assumption is the delay from the counter output to the AND gate doesn't exceed a half cycle.