Design traffic light using D flip-flop (State machine)

Discussion in 'Homework Help' started by JohnTZ, Apr 7, 2015.

  1. JohnTZ

    Thread Starter New Member

    Mar 30, 2015
    4
    0
    Design a state machine that mimics the operation of traffic light . I've already draw the state diagram, but don't know how to produce the minimal form of the logical equation corresponding to each flip-flop. Please use the following d flip flop and standard gate (And,NOT,,OR or NAND) and LEDs.

    The state machine for this has 8 states. The initial state has to be red state. It should stay in that state for at least 4 clock cycles. Then it goes to the green state for at least 3 clock cycles. Finally it goes to yellow state for one clock xylem before going back to red state. To ensure the state machine starts in red state, it will need to have a single "reset" input that will set all of the d flip flop to the correct value. Additionally, it should have an input, which when asserted will allow the state machine to cycle to the red state but then stay there until input is de-asserted.

    Please draw a Karnaugh map, determine the minimal forms of the state transition and output equation and draw the schematic of the circuit using D flip-flip.

    Below is the state diagram I draw so far, but don't know how to use it to find the minimal form of the equation.

    Thank you for any help!


    State diagram:
    [​IMG]




    Please use this D flip flip to design:
    [​IMG]
     
  2. WBahn

    Moderator

    Mar 31, 2012
    17,757
    4,800
    I think your state diagram is fine. The behavior coming out of the "dwell-in-red" is not well defined. For instance, once that input is deasserted it is allowable for the output to go to green right away if it has been in the red for at least four cycles or should it always stay in three additional cycles after that? Also, if it is asserted while the light is not red but deasserted before the light gets to red should it be as though the signal was never asserted at all?

    If those behaviors are not defined as part of the problem, then you should document how YOUR solution behaves in those situations. This is not uncommon in real world engineering where the costumer overlooks the fine print and it is usually NOT okay for you to just make your own assumptions (the world has far fewer "don't care" states than universities like to think). So you document the behavior of your design and review it with your customer and get them to either buy off on it or revise the specs accordingly.

    But let's assume that your state diagram meets spec. The next step would be to make a state transition table which will then lead you into your K-maps. So make your best effort at that.
     
Loading...