I am trying to obtain the graphical representation of the logic circuit using tools like Logisim and quartus, as I'm not proficient at drawing it by hand. This is the FSM (Finite State Machine):




This was the workflow I used to derive the state and output equations:

• Inputs (requests):
  • R1 = 01
  • R2 = 10
  • R3 = 11
• Outputs (actions):
  • D1 = 001
  • D2 = 010
  • U1 = 011
  • U2 = 100
  • NoGo = 111

Note: Both requests and actions are synchronized to a clock; this block is purely combinational.

State Transition Diagram

(States S1, S2, S3 are encoded as Q1Q0 = 00, 01, 10 respectively)

Current State (Q₁Q₀)​	Input (R₁R₀)​	Next State (Q₁′Q₀′)​	Output​
00 (S1)​	01 (R1)​	00 (S1)​	111 (NoGo)​
00 (S1)​	10 (R2)​	01 (S2)​	011 (U1)​
00 (S1)​	11 (R3)​	10 (S3)​	100 (U2)​
01 (S2)​	01 (R1)​	00 (S1)​	001 (D1)​
01 (S2)​	10 (R2)​	01 (S2)​	111 (NoGo)​
01 (S2)​	11 (R3)​	10 (S3)​	011 (U1)​
10 (S3)​	01 (R1)​	00 (S1)​	011 (U1)​
10 (S3)​	10 (R2)​	01 (S2)​	010 (D2)​
10 (S3)​	11 (R3)​	10 (S3)​	111 (NoGo)​

Boolean Functions
UP = (!Q1 & !Q0 & !R0) + (R1 & R0)
DOWN = (Q1 & !Q0 & R1) + (Q1 & !Q0 & R0)
NOGO = (Q0 & R0) + (Q0 & R0 & !R1)
Q1' = (!Q1 & R1 & R0) + (Q1 & Q0 & !R1 & !R0)
Q0' = (!Q0 & R1 & !R0) + (!Q1 & Q0 & R1 & R0)



Question: How do I enter this full transition table (16 rows) into Logisim or Quartus's combinational analisys tool?

 

If I understand correctly, you are wanting to use Logisim or Quartus to draw a logic diagram primarily because you don't feel proficient at drawing them by hand?

Well, how you gain proficiency at most things is by doing them, so you are unlikely to gain any proficiency at drawing logic circuits by hand except by drawing logic circuit by hand.

So sketch your best attempt to draw them by hand and post them here, and we can (1) look at them to tell if they are correct (i.e., at least match your equations), and (2) make suggestions on how you might make them more presentable.

 

If I understand correctly, you are wanting to use Logisim or Quartus to draw a logic diagram primarily because you don't feel proficient at drawing them by hand?

Well, how you gain proficiency at most things is by doing them, so you are unlikely to gain any proficiency at drawing logic circuits by hand except by drawing logic circuit by hand.

So sketch your best attempt to draw them by hand and post them here, and we can (1) look at them to tell if they are correct (i.e., at least match your equations), and (2) make suggestions on how you might make them more presentable.

Thank you sir! If yu can answer me a one more question: In the state diagram table, I got the output equations by simply selecting those outputs that were present in each state. For example, for NOGO, I selected the combinations in s1, s2, and s3; and for u1, the combinations in s1, s2, and s3. THEN I SIMPLIFIED THEM. Is this procedure correct?

 

Thank you sir! If yu can answer me a one more question: In the state diagram table, I got the output equations by simply selecting those outputs that were present in each state. For example, for NOGO, I selected the combinations in s1, s2, and s3; and for u1, the combinations in s1, s2, and s3. THEN I SIMPLIFIED THEM. Is this procedure correct?

No, I do not think it is correct. It might be correct if the machine was a Moore machine, where the output is a function of the state only. Your problem specifies a Mealy machine where the output is a function of the present state and the input. In other words, it is the transition that determines the output. Other than that, I think you are good to go.

 

No, I do not think it is correct. It might be correct if the machine was a Moore machine, where the output is a function of the state only. Your problem specifies a Mealy machine where the output is a function of the present state and the input. In other words, it is the transition that determines the output. Other than that, I think you are good to go.

If you look at his table, he has one row for each of the state/input combinations defined in the diagram, with each row showing the next state and the current output per that combination of current state and current inputs.

I wouldn't say that it is the transition that determines the output in a Mealy machine, because there doesn't have to be a transition at all. Transitions occur upon a clock edge, but the output changes immediately with a change in inputs. So the outputs could change dozens of times before any transition occurs.

 

Thank you sir! If yu can answer me a one more question: In the state diagram table, I got the output equations by simply selecting those outputs that were present in each state. For example, for NOGO, I selected the combinations in s1, s2, and s3; and for u1, the combinations in s1, s2, and s3. THEN I SIMPLIFIED THEM. Is this procedure correct?

I haven't looked at each equation in detail, but I notice that you have things like !Q1 and !R2. But Each of these is a multibit signal. So what, exactly, do you mean by !Q1 and !R2 in terms of the individual Boolean variable that make it up? If you thinking about it carefully, you can get away with this nomenclature. But if you aren't careful, you can make some big mistakes. Also, it's easy to miss simplifications in your logic.

Notice that your diagram is not complete in that your two inputs bit allow for four possible input cases, but the behavior is only defined for three of them. Similarly, there are three states that are defined, but in a binary system the number of possible states is in integer-power of two. In academic settings, the unused combinations are often treated as "don't cares", but in the real world this is the exception rather than the rule. It's fine to introduce state machines using 'don't care' conditions in order to show things like K-map optimizations and such, but lots of courses don't go beyond that to discuss how real engineers designing real systems should approach undefined conditions.

There are three basic approaches that are used -- fore-thought, after-thought, and a hybrid of the two. In the fore-thought case, every possible condition is explicitly included in the design with acceptable behaviors assigned to the ones not in the original specification. This is commonly done in safety- and mission-critical systems. The downside is that potential design optimizations tend to get overlooked. The after-thought case treats them initially as don't cares and then, after the design is done for that situation, goes back and examines what the resulting behavior actually is for each of the don't care conditions. While this can allow for the greatest optimization, it often results in having to do multiple iterations as it is discovered that the behavior in those don't care conditions isn't as don't care as was originally thought. The hybrid attempts to get the best of both worlds while avoiding the worst of each. Before the design commences, some effort is made at identifying those unspecified conditions for which the allowed behavior is pretty evidently not completely 'don't care' and defining at least some bounds on the allowable behavior. Then doing the design, optimizing for the remaining don't care conditions which are, hopefully, truly don't cares. Then, afterwards, the behaviors in those conditions is reviewed in order to determine that it truly is acceptable.

There's no clear guidance on how to proceed, because each system is different. I could have two very different systems that have the exact same state diagram for normal operation and each has one input condition that is left off as 'don't care'. But, upon closer examination of the system being implemented, in one case, if that were to ever happen, I want the system to come to a screaming halt and sound an alarm and not have anyway to get back into normal operation without human intervention, while in the other case the last thing I want is for the system to come to a screaming halt and I need it to get back into normal operations automatically.

 

If you look at his table, he has one row for each of the state/input combinations defined in the diagram, with each row showing the next state and the current output per that combination of current state and current inputs.

I wouldn't say that it is the transition that determines the output in a Mealy machine, because there doesn't have to be a transition at all. Transitions occur upon a clock edge, but the output changes immediately with a change in inputs. So the outputs could change dozens of times before any transition occurs.

Each of the states has a transition back to itself with no change in output. You still cannot argue that the output is only a function of the state which is the requirement for a Moore machine. The output in any state depends on how the machine got to that state and not on the state itself.

 

Each of the states has a transition back to itself with no change in output.

So?

First off, I don't think the diagram is well-defined with regards to what the output is when no state transition occurs. Is that what the hyphen means? Perhaps (but then it would be neither Mealy nor a Moore machine). Or does it mean that the output doesn't matter? Perhaps. But, if either of those is the case, then why is there a "No Go" output defined that would then never be used? The implication is that the hyphen might mean that the output in those cases is "No Go", which is clearly what the TS interpreted it to mean (possibly based on more information about the problem than they have shared with us).

You still cannot argue that the output is only a function of the state which is the requirement for a Moore machine.

Who's arguing that? I don't see anywhere where anyone has claimed that this is a Moore machine or that the outputs aren't dependent on both the state and the current inputs.

The output in any state depends on how the machine got to that state and not on the state itself.

No. The output in any state depends on the state it is in and the CURRENT inputs. Underscoring this is that there is no indication on the diagram of what the initial output is, only what the initial state is.

If it depended on how it got to that state, then that information would need to be remembered, which would mean that it would have to be incorporated into the state information, which would then mean that it could be implemented as a Moore machine.

But it is a Mealy machine, meaning that while it is in a given state, the current outputs are a function not only of the state it is in, but the current inputs. Which also means that the outputs change as the inputs change, even between events (like a clock) that determine when state transitions happen.

Both Moore and Mealy machines are memoryless beyond what state they are currently in. The have no awareness of their history beyond the fact that, whatever it was, it placed them in their present state. The only difference between a Moore machine and a Mealy machine is that in a Moore machine, the current output is ONLY a function of the present state, while it is also a function of the current input.

I think you are falling into a pretty understandable trap by confusing the normal convention of labeling the outputs associated with each input on the transitions that those same inputs would result in on the next transition event (e.g., clock). But this is merely a graphical convention to keep the diagram from being cluttered. In a Moore machine, each state has one possible output (which, of course, can be a multibit output), so it makes sense to annotate it on the state symbol itself. But in a Mealy machine, each state can have a different output for each possible input. This could be done by placing an input/output table on each symbol, but anything over two inputs would quickly result in large and unwieldy state diagrams, though there would be some advantage to doing that way (and you sometimes DO see it that way, particularly when doing so can be condensed into just a few rows due to precedence and don't care entries). But since you generally need a transition arrow for each possible input, it is simply tidier to put the output for each input on the transition arrow leaving the state for that input. It does NOT mean that that output is carried forward to the next state.

Example:

S0 -------- A/X ---------> S1  -------- A/Y ---------> S2
  \-------- B/Z ---------> S2  -------- A/W ---------> S0

If the system is currently in State S0 and the input is 'A', then the output is 'X'. It doesn't matter how it got there. If the input then changes to 'B', the output changes immediately to 'Z'. If it then changes back to 'A', the output changes back to 'X'. If a transition event occurs at this point, the machine transitions to State S1 and the output immediately changes to 'Y'.

This is both the strength and weakness of Mealy machines.

 

BTW: what college set this homework?
part of the problem your seeing is

reducing even a simple state machine by hand is long and error prone turning of handles,
back in the 70's we used to do this , when we were designing state machines with PROMS and registers
but since,
we use things like CPLDs and FPGAs , and we write state machines in languages such as VHDL
and the tools do the logic reduction and synthesis very well

I'm pleased its still being taught, I guess its something thats easy to set / mark ,
Ive just looked an there are many videos on line in many languages that show how to do this
It might be easier to follow,