EE365: A Traffic Light Controller
11/30/2004
Chris Ouellette
Joshua Smith
I. Purpose
The purpose of this project is to design a simple traffic light controller for a 4-way intersection of a North-South country road and an East-West heavily traveled highway. The principles guiding this design are described in the project specification, but key considerations are listed below:
· Pedestrians have priority over all vehicles traveling NS or EW.
· Pedestrians must not prevent traffic from flowing EW or NS if need be.
· East West is heavily traveled so these lights are usually green. Remains green 6-7 clock cycles before changing to red for NS cars or pedestrian travel.
This project will require the user of combinational and sequential logic components. State diagrams will be used in conjunction with behavioral code in ModelSim to develop the sequential logic. The end result of this project will be a design in ModelSim which we will be able to target to a XC9500 series CPLD using Xilinx ISE WebPack.
Note: The timing diagrams used in this report are in nanosecond units. State transitions are considered in the scale of cycles (for example, EW is green 6-7 cycles before going to NS). Therefore, do not literally interpret the nanosecond time-scale, but the relative magnitudes of waiting periods—a multiplier on the waiting period could easily increase the actual waiting period of various traffic states.
II. Design and Testing Plan
The design and testing process of this project will be carried out in a series of steps where the design of each step will be individually tested before being integrated into the next higher level entity. The major steps are as follows:
1. Develop a general high-level design that will use the inputs of a car’s presence in the NS lane, or a pedestrian wishing to walk, that will control the flow of traffic. This high level design will consist of two state machines (outlined in a later section): a counter and a “traffic-state” machine.
2. Develop a state diagram for the traffic-state component, model the design using behavioral language in ModelSim and test the design using inputs that are representative of possible traffic state changes.
3. Develop a state diagram for the counter component, model the design using behavioral language in ModelSim and test the design using inputs that are representative of possible needed counting patterns.
4. Integrate the two components together using structural language (component instantiation) in ModelSim. This will be the final proposed design. Test this design using the NS car and pedestrian inputs for various cases.
5. If the final design works as expected, import the ModelSim project into Xilinx ISE and iteratively attempt to fit the design to increasingly large XC9500 series CPLDs, until the design fits. Analyze the fitter report.
Each of these steps will be conducted in the sections that follow.
III. High-Level Traffic Controller Design
The traffic light controller for the specification given will require two major components: a state machine to keep track of the current state of the traffic, and the next state that the traffic should enter into, and a counter which will control when the transitions from one traffic state to another occurs. These will be designed as two separate entities and then combined into one entity after tested. The final proposed design is shown below:
Figure 1 - High Level Traffic Controller Design
In this design we can see the two entities. Both entities have inputs P (presence of a pedestrian), C (presence of a NS car), and CLK. The traffic-state machine has an input T which goes high when the traffic state needs to transition to the next appropriate state. Thus, when a pedestrian decides to press the walk button, the current state will continue for its set number of cycles (determined by W_STATE and the counter). When the counter reaches the appropriate count for the current state, T goes high which signals the state machine to transition to the pedestrian state. The output of the traffic light controller as a whole is “lightstate” which is simply the current state of the traffic state machine.
Assumptions of the Traffic Controller’s Design:
A few assumptions have been made that significantly impact the design of the traffic controller. There assumptions are listed below:
· Inputs P and C have already been synchronized with CLOCK of the traffic controller—that is, we do not need to worry about a pedestrian pressing the “walk” button on the rising clock edge, or a NS car triggering C at that time.
· Inputs P and C stay high until the “request” has been fulfilled. For example, if a pedestrian pushes the walk button, the input P will go high and remain high until all the pedestrian requests at the time have been fulfilled (which means no one presses the button again within the pedestrian walking cycle). This also means the “pulsing” of the pedestrian pushing a button has already been taken care of, external to the circuit.
· It is possible for P or C to go low during their respective states (PED1 or PED2 and NS), but by the assumption above it is not possible for a pedestrian (for example) to be “served” and thus to have the P input go low during any other state (say EW or NS).
· The purpose of the design is a controller—that is, it will be connected to other logic networks (such as decoders) which will interpret the output traffic state (lightstate) and operate the traffic lights accordingly.
IV. Traffic State Machine
Design:
The state machine will consist of 5 states. First is the INIT state (000) which represents a fail safe were all the lights will go red including walking lights if a undesirable state is reached. The next state is EW (001) which represents a green light in the East/West direction, allowing traffic to flow. The third state is the NS (010) state, which is the green light in the North/South direction. This means that the traffic may flow North/South. Next is PED1 (011) state. This state represents a pedestrian has pushed the walk button during an East/West traffic flow. Possible states after this may be either NS or EW. The final state is PED2. This state occurs when a pedestrian wishes to cross during North/South flow. This state forces East/West flow after the pedestrian is allowed to cross. This is a measure to keep the traffic flowing in all directions.
The state names and logic value assignments are summarized in the table below.
State Name / Logic ValueINIT / 000
EW / 001
NS / 010
PED1 / 011
PED2 / 100
Table 1 - State names and logic levels
As stated in Section III the traffic state machine has three inputs, T, P, C. These inputs tell the machine which state to go to next. Since the output of the traffic-state machine corresponds directly to the current state, this is a Moore machine design. Below is a diagram showing under what circumstances each state can be reached. Note that only transitions for which the input T is high is shown: this is because all transitions for which T is low just loop back on the current state. In the traffic-state’s implementation this simply means that the counter has not yet counted up to the transition time and the state does not need to switch.
Figure 2 - Traffic State Diagram
Note: This has not been drawn in a typical “state-diagram” way in sake of clarity. Arrows drawn to states that are named the same means it is looping back on the state, not to a different state.
As an example, if the current state of traffic is flowing in the East/West (EW) direction and a car shows up in the north/south lane (input of TPC=101), the state machine will transition during the next clock cycle from EW to NS after the count has elapsed and T has gone high. Once in the NS state if a pedestrian shows up (110) then again when T goes high the state machine will transition to the PED2 state.
Modeling:
The traffic state machine will be modeled using behavioral language in ModelSim. While the Quine McClusky algorithm could be used to generate reduced logic networks and the design modeled using dataflow, in the interest of time behavioral was chosen. This choice will be assessed when the design is synthesized.
Behavioral language was used in ModelSim by using the case statement. By creating a new data type that could store the variable names that we are using (INIT, EW, etc.), we directly translated the state table into ModelSim, coding all of the next states for each current state. Using Table 1 to directly assign logic values to different states (since this is a Moore-based design), the output of the traffic-state machine was made.
Not shown in Figure 2 are some extra “safety features” for the traffic-state machine. The INIT state has been coded as the initially state that the network will start in. This is an “all stop” state. This state cannot normally be reached again after it first goes to EW, under normal operation. However, if the machine reaches an unknown state it will automatically reset back to the INIT state.
Test Strategy:
Testing of this design will be conducted on two levels.
· The “low-level” test will involve generating a sequence of likely inputs (pedestrians and cars) coming to the intersection and determining the correct sequence of states based on the state diagram proposed in Figure 2. The results of the expected output will then be compared to that of a timing diagram generated in ModelSim.
· “High-level” test will be a conceptual check to verify that traffic and pedestrians are getting the correct traffic flow based on the specification given for the design.
Test and Verification:
The table below is a list of inputs to be tested, and their expected outputs. These can be determined by tracing Figure 2 starting from the INIT state.
T / P / C / Curr. State / Next State1 / 0 / 0 / INIT / EW
1 / 0 / 1 / EW / NS
1 / 1 / 0 / NS / PED2
1 / 1 / 0 / PED2 / EW
1 / 0 / 0 / EW / EW
1 / 1 / 1 / EW / PED1
0 / 1 / 1 / PED1 / PED1
1 / 1 / 1 / PED1 / NS
1 / 1 / 1 / NS / PED2
1 / 1 / 1 / PED2 / EW
Table 2 - Traffic State Expected Outputs
Constructing a TestBench with these inputs we obtain the following timing diagram:
Figure 3 - Traffic-state timing diagram
First note that this testbench was constructed such that the inputs T, P, and C change on the negative clock edge and the output changes on the positive clock edge. So in regions for the same input there are two different outputs (states). These represent the current state and next state, respectively. By changing the input at the negative clock edge, sufficient time could be given to the input to setup before the rising clock edge (if timing considerations were made).
We can see that there is a 1-1 correspondence between the timing diagram and the expected state table. On a low-level basis we can conclude that the design is functioning correctly.
On a high-level basis, there are a few interesting portions of Figure 3 to consider. First is the importance of the PED2 state. This shows up twice in the timing diagram, at CASE 4 and 10. In case 4, PED2 was not needed since there was no car wanting to go in the NS direction again. However, in CASE 10, the PED2 state prevented the traffic state from going back to the NS direction after it has just been in the NS state, even though C was high. Other interesting occurrences are when EW is held along CASE 5 and 6 because neither P nor C was asserted. Finally in cases 7 and 8 PED1 is held while T is low. This will be very important later because as the counter is counting, T is zero, until T=1 and the traffic-state transitions.
Considering all of this, we believe that the traffic-state machine is working correctly in controlling which state should be asserted based on inputs and the value of T.
V. Counter
Design:
The counter consists of a series of states which represent a delay before T is output high to signal a traffic-state transition. The amount of delay (number of states the counter passes through before T goes high) is primarily a function of state, with one exception where the inputs P and C are needed. The states PED1, PED2, and NS all have a pre-defined delay time; that is, once entering these states the delay time is 3 cycles, 3 cycles, and 4 cycles respectively. The exception occurs because EW can occur indefinitely if P or C never go high. However, if P or C goes high, then the output T goes high after 6-7 clock cycles.
This design needs to be a Mealy-based state machine since the output is based on both the inputs to the circuit and the current state of the network. That is, for a given state of the counter the output is not always the same. The output is based on the current state of the counter and the input state (the state of the traffic-state machine).
The state diagram which summarizes the transitions which are possible is shown below. Instead of using variables to represent the states (such as INIT and EW in the traffic-state design) counts are directly coded as binary numbers (1 = 0012, 2=0102, etc.).
Figure 4 - Counter State Diagram
Modeling:
The counter was modeled similar to the traffic-state machine using behavioral language in ModelSim. However, instead of using a new datatype to describe the states, they were directly coded with binary numbers. The same style case statements were used to describe the state transitions that occur on the positive clock edge.