But, is what I did alright too? Present state is 11111 and the next state would be 11101. Or will that cause problems?

What you did is okay, but using don't cares would typically simplify the logic.

I will try to create another diagram using don't cares for invalid counts.

Arrange it in gray code order so it will be easier to transfer information to your Kmaps.

 

What you did is okay, but using don't cares would typically simplify the logic.
Arrange it in gray code order so it will be easier to transfer information to your Kmaps.

I didn't arrange it in gray code order yet because I'm kind of used to this kind of format. But will try to study about it for future purposes!

 

What you do with the unused states depends on how you want the system to behave should it find itself in one of those states.

If you use "don't cares" for them, then you need to be comfortable with it doing whatever happens -- you need to truly not care what happens. If it powers up in one of the two unused states and then just sits there looking stupid, you have to say, "That's fine, because I don't care what happens." In many instances you want to do what you did and have it transition to the "start" state. In other instances you WANT it to lock up so that the system can detect that something bad had happened and respond accordingly. In general, in the real world, deciding how unused states should be handled is one of the more critical -- and often neglected -- design issues. In your case, just decide how you want the system to behave, document that desire (it's basically a performance spec) and then proceed with the design accordingly. You basically have three choices -- truly don't care, trap the machine in an invalid state, or force the machine to a valid state and let it continue from there.

As for ordering your table in Gray code order -- that's six to one and half dozen to the other. With a counter you have a clear sequence of states and if you order it in that sequence, then it becomes very easy to tell if the transitions are correct with just a glance. If it is in Gray order then a mistake in a transition becomes a lot harder to catch. But, as dl324 noted, if your table is in Gray order then it becomes easier (and more reliable) to transfer it to your K-maps. Personally, I prefer to order my state tables according to what makes the most sense for the problem (which is often, by design, in gray order) and then deal with the mapping when it is time. You can get the best of both worlds by just setting up a spread sheet that lets you put the transition table in an arbitrary order and then automatically builds the K-map tables by looking up the necessary values in the transition table. This has lots of advantages, not the least of which is that you only have your logic defined in one place and all other places draw from that single definition.

 

I didn't arrange it in gray code order yet because I'm kind of used to this kind of format.

OK, post your Kmaps and equations.

Are you simulating or breadboarding the circuit?

 

What you do with the unused states depends on how you want the system to behave should it find itself in one of those states.

If you use "don't cares" for them, then you need to be comfortable with it doing whatever happens -- you need to truly not care what happens. If it powers up in one of the two unused states and then just sits there looking stupid, you have to say, "That's fine, because I don't care what happens." In many instances you want to do what you did and have it transition to the "start" state. In other instances you WANT it to lock up so that the system can detect that something bad had happened and respond accordingly. In general, in the real world, deciding how unused states should be handled is one of the more critical -- and often neglected -- design issues. In your case, just decide how you want the system to behave, document that desire (it's basically a performance spec) and then proceed with the design accordingly. You basically have three choices -- truly don't care, trap the machine in an invalid state, or force the machine to a valid state and let it continue from there.

As for ordering your table in Gray code order -- that's six to one and half dozen to the other. With a counter you have a clear sequence of states and if you order it in that sequence, then it becomes very easy to tell if the transitions are correct with just a glance. If it is in Gray order then a mistake in a transition becomes a lot harder to catch. But, as dl324 noted, if your table is in Gray order then it becomes easier (and more reliable) to transfer it to your K-maps. Personally, I prefer to order my state tables according to what makes the most sense for the problem (which is often, by design, in gray order) and then deal with the mapping when it is time. You can get the best of both worlds by just setting up a spread sheet that lets you put the transition table in an arbitrary order and then automatically builds the K-map tables by looking up the necessary values in the transition table. This has lots of advantages, not the least of which is that you only have your logic defined in one place and all other places draw from that single definition.

I'm going to try to force the machine in a valid state. If it doesn't work, I'll try the "don't care".

Thank you for all the information you told me! I'll keep those in mind.

 

I'm going to try to force the machine in a valid state. If it doesn't work, I'll try the "don't care".

Either way will work. Forcing the counter to count out of invalid states could be considered better. It just depends on what your instructor is trying to teach you.

In most cases, part of the lesson is to teach how using don't cares can simplify logic. I did the design both ways and forcing the counter to count out of invalid states doesn't increase gate count much.

As I keep saying. It depends on the lesson your instructor is trying to teach you. If you're in doubt, you should ask clarifying questions.

 

OK, post your Kmaps and equations.

Are you simulating or breadboarding the circuit?

I'm simulating the circuit using Proteus 8.

 

I'm simulating the circuit using Proteus 8.

Did your simulation work?

Which letter is LSB? It appears to be E.

From your equations, it looks like you used don't cares for the invalid counts instead of having it count of invalid states explicitly.

 

Did your simulation work?

Which letter is LSB? It appears to be E.

From your equations, it looks like you used don't cares for the invalid counts instead of having it count of invalid states explicitly.

For the first state diagram (the one where the present state was 11111 then the next state is 11101), it worked at first. The counter started at 29, then 28 then here comes the problem: it went back to 29.

I'm going to try to simulate the second state diagram (don't cares as next state of invalid counts).

The LSB is E.

 

I'm going to try to force the machine in a valid state. If it doesn't work, I'll try the "don't care".

Thank you for all the information you told me! I'll keep those in mind.

If you want to maximize your learning (and probably also impress the instructor/grader and either get extra credit outright or at least get more partial credit in case you don't get it completely correct) do it all three ways and include a sentence or two in the write up about why a designer might make each decision and the impact of the decision on the resulting design. You should find that once you do it one way, that doing it the other two ways won't take that much additional time.

 

For the first state diagram (the one where the present state was 11111 then the next state is 11101), it worked at first. The counter started at 29, then 28 then here comes the problem: it went back to 29.

I'm going to try to simulate the second state diagram (don't cares as next state of invalid counts).

The LSB is E.

That sounds like a problem with the basic logic and not with how you handled the invalid states since you weren't in an invalid state when it misbehaved. Look at what your logic specifically told it to do when in state 28 and verify that your equations are telling it to do the right thing in that specific case. If they are, then verify that the implementation matches the logic equations.

 

If you want to maximize your learning (and probably also impress the instructor/grader and either get extra credit outright or at least get more partial credit in case you don't get it completely correct) do it all three ways and include a sentence or two in the write up about why a designer might make each decision and the impact of the decision on the resulting design. You should find that once you do it one way, that doing it the other two ways won't take that much additional time.

I'll try to do that! Hopefully, Ill be able to do at least one before Friday.

That sounds like a problem with the basic logic and not with how you handled the invalid states since you weren't in an invalid state when it misbehaved. Look at what your logic specifically told it to do when in state 28 and verify that your equations are telling it to do the right thing in that specific case. If they are, then verify that the implementation matches the logic equations.

Alright! i'll do so tomorrow morning and let you know what happened, is that all right?

 

For the first state diagram (the one where the present state was 11111 then the next state is 11101), it worked at first. The counter started at 29, then 28 then here comes the problem: it went back to 29.

Probably a wiring or transcription problem.

When I transfer information to a simulator, I usually make a few mistakes. I could triple check my work, but I use it as an opportunity to use my troubleshooting skills