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
INIT
EW
NS
PED1
PED2
Logic
Value
000
001
010
011
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
1
1
1
1
1
1
0
1
1
1
P
0
0
1
1
0
1
1
1
1
1
C
0
1
0
0
0
1
1
1
1
1
Curr. State
INIT
EW
NS
PED2
EW
EW
PED1
PED1
NS
PED2
Next State
EW
NS
PED2
EW
EW
PED1
PED1
NS
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.
Extra safety has been included in this design by creating a “loopbacks” to the zero count,
with an output of zero if the input state to the counter is impossible for the current count that it is
on (for example, an input state of 010—NS, when the current count is 101—5, the NS count
should have already looped back). By looping back to zero, this will give the system’s traffic
state a longer time to resolve an “undetermined” state.
Test Strategy:
In order to test the counter design, we have decided to test only a limited number of cases
and test to see whether the design a) counts correctly, and b) sends the output T high at the
correct times. To do this, we will choose a couple states to test the counting sequence on,
determine the expected output using the state diagram, and compare this to the output from a
ModelSim testbench.
Test and Verification:
First we will test to verify that the counter will leave the INIT state after 1 clock cycle,
hold the EW state as long as P and C are low, and count to 6-7 cycles when either one goes high.
The test for this is shown in the following timing diagram:
Figure 5 - Traffic Light Counter Timing Diagram, Example 1
Figure 5 shows a very simple example of the traffic light counter in action. Initialized in
the 000 state, the counter shows an output of T=1. This means that as soon as the system is
turned on, all lights are red for 1 cycle, and on the next cycle they will make their first transition
based on the system’s inputs. At t=10ns, a state of EW is shown. Since neither P nor C are high
from 10-30ns, the count remains at zero. At time of t=30ns, P transitions high signaling a
pedestrian wishes to cross the intersection. From the next positive clock edge, the counter begins
to count up to 6 clock cycles where T goes high, signaling a transition to the next traffic state.
This shows that the counter correctly counted 6.5 clock cycles from the time P went high to the
end of T’s high level/positive clock edge (at t=95ns). This has verified with our expected
outcome.
Next we will verify counting in the NS state (010) and the PED1 state (011). When in the
NS state, the count should reach 3 and T should go high (4 clock cycles), and in the PED1 state T
should go high at two (3 clock cycles). Consider the timing diagram below:
Figure 6 - Traffic Light Counter Timing Diagram, Example 2
In Figure 6 we can see that after the input C goes high at 10ns, 3.5 clock cycles elapse to
the time when there is a positive clock edge, and the negative edge of T high (45ns). This is not a
complete 4 cycles because only half of zero was counted as one of the counts. Similarly, in
PED1 state (011) there are 2.5 clock cycles from 50ns to 75ns. Half a clock cycle was eliminated
because only half of the zero state was considered. Neither of these “half cycles” will negatively
impact the final controller design because the inputs are changing with a half cycle difference to
the clock, so this difference can be expected in some situations. We feel that a safe counting
sequence can be maintained as seen above.
With the counting sequence verified for a few representative instances, we believe that
the counting mechanism works correctly to delay the traffic-state transitions appropriately based
on the current traffic-state, and presence of a pedestrian or car.
VI. Traffic Controller
Design:
The upper-level design for the traffic controller was proposed in Section III. The
assumptions stated in that section, in addition to the guiding principles to consider in the purpose
section, have been used to develop the logic network thus far. Now the counter, which keeps
track of how long the traffic should remain on a certain state; and the state controller itself, will
be integrated together in a feedback loop. The resulting circuit will be a “closed box” with inputs
of a NS car presence or pedestrian and output of current traffic state (Figure 1).
Modeling:
Since the design of the counter and traffic-state machines have already been individually
built and tested, to construct the final traffic controller, they just need to be wired together inside
a higher level entity using structural language in ModelSim. Again, one can see the way that they
are wired together in Figure 1.
Test Strategy:
The test strategy for the overall controller will be similar to that of the traffic-state
machine, but instead of verifying only that the machine transitions to the correct state to let
traffic flow as needed, consideration needs to be given to the amount of time that the controller
lets traffic flow in a given direction. Therefore by comparing the sequence of states that traffic
controller goes through and observing the time spent in each state we can determine whether the
controller is function as expected.
Since there are two state diagrams associated with this process, a narrative of inputs and
expected traffic states/counting sequences will be used as a point of comparison to the timing
diagram.
There are numerous cases for the design (because of the possible sequences EW PED NS,
EW NS PED, etc), but we will consider a few cases and attempt to apply them to all cases. We
will be able to feel confident in the general application of the results because each component
was individually tested before being used in the higher level design.
Test and Verification:
In the following test, we will start the traffic light controller with initial P and C values
not asserted (EW state, holding). After some time a pedestrian will come and P will become
asserted (EW state, counting). Pedestrians will have a change to cross after 6-7 clock cycles
(PED1), P will drop to zero, and the next state will be EW (holding). Some later time C will go
high (EW, counting) and then the NS car will be served (NS state), C will drop, and after a total
of 4 clock cycles EW will occur again.
Consider the following timing diagram to compare the narrative input to the logic levels:
Figure 7 - Traffic Light Controller Timing Diagram, Example 1
In this figure we can see that what we would expect to occur, according to the narrative,
is what occurs in the timing diagram. A few important features to point out: first, transitions in
state occur at the negative edge of T’s pulse and at the positive clock edge; second, when in the
NS state (010) C went low in the middle of the state (which can be interpreted as all cars passed
through) and the state still correctly transitions at the right time. That is, only in the EW state
when P and C are zero does the count “hold” because the states NS and PED1/2 have time
constraints whereas EW is only limited to 6-7 cycles when P or C is asserted.
The following example continues where the last example left off: in the EW state
(holding). Simultaneously P and C go high meaning EW begins counting. After 6-7 cycles, since
pedestrians have priority over cars the PED1 state should occur. After 3 cycles, all pedestrians
served, P goes low, but C remains high (as it will remain high through the rest of this example);
now the controller should be in NS state. After NS state’s 4 cycles, we should again enter the
EW state, but counting immediately for 6-7 cycles (because C is still high). We then enter the NS
state again, but during the NS state P goes high. Since pedestrians have priority over vehicles, we
should enter the PED2 state. During the PED2 state, all pedestrians served, P goes low. After 3
cycles, regardless of C still being high (possibly because of heavy traffic), EW needs to be
served (which should immediately begin counting) so that EW traffic is not held up by NS
traffic.
Consider the following timing diagram which represents this narrative’s inputs:
Figure 8 - Traffic Light Controller Timing Diagram, Example 2
Reviewing the narrative above and Figure 8 we can see that the timing diagram
corresponds to the narrative. The important controller pattern to reiterate here is the progression
from EW -> NS -> PED2 -> EW even when C is asserted because EW traffic flow takes
precedence over NS flow if NS has been served since EW was last served.
Seeing that the progression of states and number of cycles spent in each state meets the
expected outputs, which were developed to test whether or not the controller meets the
specifications originally set for the design, we believe that the logic controller produced is
accurate and complete.
VII. Synthesis and Fit
Synthesis and Fitting of the traffic controller ran into difficulties. After importing the
project into Xilinx ISE and attempting to run “Synthesize – XST,” targeting even the largest
XC9500 series CPLD yielded the following errors:
WARNING:Xst:524 - All outputs of the instance <traffic_state> of the block <traffic_sm_behavioral> are
unconnected in block <traffic_controller>.
WARNING:Xst:524 - All outputs of the instance <traffic_counter> of the block <counter_sm_behavioral> are
unconnected in block <traffic_controller>.
We have checked and re-checked all connections in the instantiation statements to verify
that all outputs and inputs are properly connected—the fact that the design tested out on multiple
levels in ModelSim also pointed to the fact that they are wired correctly.
Continuing to attempt to Fit, in the process of translate an error occurred which prevented
us from proceeding any further:
ERROR:NgdBuild:605 - logical root block 'traffic_controller' with type
'traffic_controller' is unexpanded. Symbol 'traffic_controller' is not
supported in target 'xc9500'.
Investigating this, we attempted to fit both individual entities (counter and traffic-state) to
CPLDs. This was successful—they both successfully fit on the XC9536-5pc44. The summaries
of each of these fit processes are attached.
VIII. Conclusions
In this project we developed a traffic light controller based on given specifications. We
chose to address the controller as a two part design. One part controlled the traffic state
transitions, and the other controlled the length of time that each state would be asserted. Each
part was addressed separately by creating a state diagram, and assigning values to variables.
State machines were then directly converted into a case structure using behavioral language in
ModelSim. Each of the components were individually tested by comparing expected results to
results obtained from a testbench. Finally the components were integrated using structural
language and tested again against predicted results with a testbench.
After a the proposed design was discovered to be accurate, we attempted to target a
XC9500 series CPLD using Xilinx ISE WebPack. The process of synthesis failed for the higher
level entity, but fit correctly for the lower level entities. Space was not the issue here as it was
not able to successfully complete synthesis and translate first. Had the fit process worked for the
design, we believe that it would have fit well on the XC9536-5pc44. This is based on looking at
the space (macrocells/function blocks, registers, and pins) that the counter and traffic-state
components took individually.
cpldfit: version G.37
Fitter Report
Design Name: traffic_sm_behavioral
Device Used: XC9536-5-PC44
Fitting Status: Successful
Xilinx Inc.
Date: 11-29-2004, 10:35PM
**************************** Resource Summary ****************************
Macrocells Product Terms Registers
Pins
Function Block
Used
Used
Used
Used
Inputs Used
6 /36 ( 17%) 15 /180 ( 8%) 3 /36 ( 8%) 7 /34 ( 21%) 9 /72 ( 12%)
PIN RESOURCES:
Signal Type Required Mapped | Pin Type
Used Remaining
------------------------------------|--------------------------------------Input
: 3
3 | I/O
: 6
22
Output
: 3
3 | GCK/IO
: 1
2
Bidirectional : 0
0 | GTS/IO
: 0
2
GCK
: 1
1 | GSR/IO
: 0
1
GTS
: 0
0 |
GSR
: 0
0 |
------Total
7
7
MACROCELL RESOURCES:
Total Macrocells Available
36
Registered Macrocells
3
Non-registered Macrocell driving I/O
3
GLOBAL RESOURCES:
Signal 'CLOCK' mapped onto global clock net GCK1.
Global output enable net(s) unused.
Global set/reset net(s) unused.
POWER DATA:
There are 6 macrocells in high performance mode (MCHP).
There are 0 macrocells in low power mode (MCLP).
There are a total of 6 macrocells used (MC).
End of Resource Summary
cpldfit: version G.37
Xilinx Inc.
Fitter Report
Design Name: counter_sm_behavioral
Date: 11-29-2004, 10:35PM
Device Used: XC9536-5-PC44
Fitting Status: Successful
**************************** Resource Summary ****************************
Macrocells Product Terms Registers
Pins
Function Block
Used
Used
Used
Used
Inputs Used
4 /36 ( 11%) 20 /180 ( 11%) 3 /36 ( 8%) 7 /34 ( 21%) 8 /72 ( 11%)
PIN RESOURCES:
Signal Type Required Mapped | Pin Type
Used Remaining
------------------------------------|--------------------------------------Input
: 5
5 | I/O
: 6
22
Output
: 1
1 | GCK/IO
: 1
2
Bidirectional : 0
0 | GTS/IO
: 0
2
GCK
: 1
1 | GSR/IO
: 0
1
GTS
: 0
0 |
GSR
: 0
0 |
------Total
7
7
MACROCELL RESOURCES:
Total Macrocells Available
36
Registered Macrocells
3
Non-registered Macrocell driving I/O
1
GLOBAL RESOURCES:
Signal 'CLOCK' mapped onto global clock net GCK1.
Global output enable net(s) unused.
Global set/reset net(s) unused.
POWER DATA:
There are 4 macrocells in high performance mode (MCHP).
There are 0 macrocells in low power mode (MCLP).
There are a total of 4 macrocells used (MC).
End of Resource Summary
COUNTER ENTITY VHDL CODE
LIBRARY IEEE;
USE IEEE.std_logic_1164.all;
ENTITY counter_sm_behavioral IS
PORT (
CLOCK : IN std_logic;
state : IN std_logic_vector( 2 DOWNTO 0 ) ;
P : IN std_logic;
C : IN std_logic;
T : OUT std_logic
);
END counter_sm_behavioral ;
ARCHITECTURE counter_sm_behavioral_arch OF counter_sm_behavioral IS
signal count : std_logic_vector(2 downto 0) := "000";
signal countstate : std_logic_vector(5 downto 0);
signal countzstate : std_logic_vector(6 downto 0);
signal Z : std_logic;
begin
Z <= P OR C;
countzstate <= count&Z&state;
countstate <= count&state;
process (CLOCK)
begin
if CLOCK'event and CLOCK = '1' then
case count is
when "000" => if state="001" and Z='0' then count <="000";
elsif state="000" then count<="000";
elsif state="001" then count<="001";
elsif state="010" then count<="001";
elsif state="011" then count<="001";
elsif state="100" then count<="001";
else count<="000";
end if;
when "001" => if state="000" then count<="000"; -- if get a state in a counting state
where that input state shouldnt be possible, continue counting to max clock cycles for safety.
elsif state="001" then count<="010";
elsif state="010" then count<="010";
elsif state="011" then count<="010";
elsif state="100" then count<="010";
else count<="000";
end if;
when "010" => if state="000" then count<="000";
elsif state="001" then count<="011";
elsif state="010" then count<="011";
elsif state="011" then count<="000";
elsif state="100" then count<="000";
else count<="000";
end if;
when "011" => if state="000" then count<="000";
elsif state="001" then count<="100";
elsif state="010" then count<="000";
elsif state="011" then count<="000";
elsif state="100" then count<="000";
else count<="000";
end if;
when "100" => if state="000" then count<="000";
elsif state="001" then count<="101";
elsif state="010" then count<="000";
elsif state="011" then count<="000";
elsif state="100" then count<="000";
else count<="000";
end if;
when "101" => if state="000" then count<="000";
elsif state="001" then count<="110";
elsif state="010" then count<="000";
elsif state="011" then count<="000";
elsif state="100" then count<="000";
else count<="000";
end if;
when "110" => if state="000" then count<="000";
elsif state="001" then count<="000";
elsif state="010" then count<="000";
elsif state="011" then count<="000";
elsif state="100" then count<="000";
else count<="000";
end if;
when others => count <= "000";
end case;
end if;
end process;
process (countstate, countzstate)
begin
if countstate="010011" or countstate="010100" or countstate="011010" or
countstate="000000" or countzstate="1101001" then T<='1';
else T<= '0';
end if;
end process;
END counter_sm_behavioral_arch;
TRAFFIC-STATE VHDL CODE
LIBRARY IEEE;
USE IEEE.std_logic_1164.all;
ENTITY traffic_sm_behavioral IS
PORT (
CLOCK : IN std_logic ;
P : IN std_logic ;
C : IN std_logic ;
T : IN std_logic ;
Q : OUT std_logic_vector( 2 DOWNTO 0 )
);
END traffic_sm_behavioral ;
ARCHITECTURE traffic_sm_behavioral_arch OF traffic_sm_behavioral IS
type state_def is (INIT, EW, NS, PED1, PED2, PED3);
signal state: state_def:=INIT;
SIGNAL X : std_logic_vector(2 downto 0);
begin
X <= T & P & C;
process (CLOCK)
begin
if CLOCK'event and CLOCK = '1' then
case state is
when INIT => if
X="100" then state <= EW;
elsif
X="101" then state <= NS;
elsif
X="110" then state <= PED1;
elsif
X="111" then state <= PED1;
else
state <= INIT;
end if;
when EW => if
X="100" then state <= EW;
elsif
X="101" then state <= NS;
elsif
X="110" then state <= PED1;
elsif
X="111" then state <= PED1;
else
state <= EW;
end if;
when NS => if
X="100" then state <= EW;
elsif
X="101" then state <= EW;
elsif
X="110" then state <= PED2;
elsif
X="111" then state <= PED2;
else
state <= NS;
end if;
when PED1 => if
X="100" then state <= EW;
elsif
X="101" then state <= NS;
elsif
X="110" then state <= EW;
elsif
X="111" then state <= NS;
else
state <= PED1;
end if;
when PED2 => if
X="100" then state <= EW;
elsif
X="101" then state <= EW;
elsif
X="110" then state <= EW;
elsif
X="111" then state <= EW;
else
state <= PED2;
end if;
when others => state <= INIT;
end case;
end if;
end process;
with state select
Q <= "000" when INIT,
"001" when EW,
"010" when NS,
"011" when PED1,
"100" when PED2,
"000" when others;
END traffic_sm_behavioral_arch;
TRAFFIC CONTROLLER VHDL CODE
LIBRARY IEEE;
USE IEEE.std_logic_1164.all;
ENTITY traffic_controller IS
PORT (
P : IN std_logic ;
C : IN std_logic ;
CLK : IN std_logic
);
END traffic_controller ;
ARCHITECTURE traffic_controller_arch OF traffic_controller IS
COMPONENT traffic_sm_behavioral
PORT (
CLOCK : IN std_logic ;
P : IN std_logic ;
C : IN std_logic ;
T : IN std_logic ;
Q : OUT std_logic_vector( 2 DOWNTO 0 )
);
END COMPONENT ;
COMPONENT counter_sm_behavioral
PORT (
CLOCK : IN std_logic;
state : IN std_logic_vector( 2 DOWNTO 0 ) ;
P : IN std_logic;
C : IN std_logic;
T : OUT std_logic
);
END COMPONENT ;
SIGNAL W_T : std_logic ;
SIGNAL W_STATE : std_logic_vector(2 downto 0) ;
BEGIN
traffic_state : traffic_sm_behavioral PORT MAP (CLOCK=>CLK, P=>P, C=>C,
T=>W_T, Q=>W_STATE);
traffic_counter : counter_sm_behavioral PORT MAP (CLOCK=>CLK, P=>P, C=>C,
T=>W_T, state=>W_STATE);
END traffic_controller_arch;
COUNTER TESTBENCH
library IEEE;
use IEEE.std_logic_1164.all;
entity TB_COUNTER_SM_BEHAVIORAL is
end TB_COUNTER_SM_BEHAVIORAL;
architecture BEH of TB_COUNTER_SM_BEHAVIORAL is
component COUNTER_SM_BEHAVIORAL
port(CLOCK : IN std_logic ;
STATE : IN std_logic_vector ( 2 DOWNTO 0 );
P
: IN std_logic ;
C
: IN std_logic ;
T
: OUT std_logic );
end component;
constant PERIOD : time := 10 ns;
signal W_CLOCK : std_logic := '0';
signal W_STATE : std_logic_vector ( 2 DOWNTO 0 );
signal W_P
: std_logic ;
signal W_C
: std_logic ;
signal W_T
: std_logic ;
begin
DUT : COUNTER_SM_BEHAVIORAL
port map(CLOCK => W_CLOCK,
STATE => W_STATE,
P
=> W_P,
C
=> W_C,
T
=> W_T);
W_CLOCK <= not W_CLOCK after PERIOD/2;
STIMULI : process
begin
W_STATE <= "000";
W_P
<= '0';
W_C
<= '0';
wait for PERIOD*1;
W_STATE <= "010";
W_P
<= '1';
W_C
<= '0';
wait for PERIOD*4;
W_STATE <= "011";
W_P
<= '0';
W_C
<= '1';
wait for PERIOD*5;
wait;
end process STIMULI;
end BEH;
configuration CFG_TB_COUNTER_SM_BEHAVIORAL of
TB_COUNTER_SM_BEHAVIORAL is
for BEH
end for;
end CFG_TB_COUNTER_SM_BEHAVIORAL;
TRAFFIC-STATE TESTBENCH
library IEEE;
use IEEE.std_logic_1164.all;
entity TB_TRAFFIC_SM_BEHAVIORAL is
end TB_TRAFFIC_SM_BEHAVIORAL;
architecture BEH of TB_TRAFFIC_SM_BEHAVIORAL is
component TRAFFIC_SM_BEHAVIORAL
port(CLOCK : IN std_logic ;
P
: IN std_logic ;
C
: IN std_logic ;
T
: IN std_logic ;
Q
: OUT std_logic_vector ( 2 DOWNTO 0 ) );
end component;
constant PERIOD : time := 10 ns;
signal W_CLOCK : std_logic := '0';
signal W_P
: std_logic ;
signal W_C
: std_logic ;
signal W_T
: std_logic ;
signal W_Q
: std_logic_vector ( 2 DOWNTO 0 ) ;
begin
DUT : TRAFFIC_SM_BEHAVIORAL
port map(CLOCK => W_CLOCK,
P
=> W_P,
C
=> W_C,
T
=> W_T,
Q
=> W_Q);
W_CLOCK <= not W_CLOCK after PERIOD/2;
STIMULI : process
begin
W_P
<= '0';
W_C
<= '0';
W_T
<= '1';
wait for PERIOD;
W_P
<= '0';
W_C
<= '1';
W_T
<= '1';
wait for PERIOD;
W_P
<= '1';
W_C
<= '0';
W_T
<= '1';
wait for PERIOD;
W_P
<= '1';
W_C
<= '0';
W_T
<= '1';
wait for PERIOD;
W_P
<= '0';
W_C
<= '0';
W_T
<= '1';
wait for PERIOD;
W_P
<= '1';
W_C
<= '1';
W_T
<= '1';
wait for PERIOD;
W_P
<= '1';
W_C
<= '1';
W_T
<= '0';
wait for PERIOD;
wait;
end process STIMULI;
end BEH;
configuration CFG_TB_TRAFFIC_SM_BEHAVIORAL of
TB_TRAFFIC_SM_BEHAVIORAL is
for BEH
end for;
end CFG_TB_TRAFFIC_SM_BEHAVIORAL;
TRAFFIC-CONTROLLER TESTBENCH
library IEEE;
use IEEE.std_logic_1164.all;
entity TB_TRAFFIC_CONTROLLER is
end TB_TRAFFIC_CONTROLLER;
architecture BEH of TB_TRAFFIC_CONTROLLER is
component TRAFFIC_CONTROLLER
port(P : IN std_logic ;
C : IN std_logic ;
CLK : IN std_logic );
end component;
constant PERIOD : time := 10 ns;
signal W_P : std_logic ;
signal W_C : std_logic ;
signal W_CLK : std_logic := '0';
begin
DUT : TRAFFIC_CONTROLLER
port map(P => W_P,
C => W_C,
CLK => W_CLK);
W_CLK <= not W_CLK after PERIOD/2;
STIMULI : process
begin
W_P <= '0';
W_C <= '0';
wait for PERIOD*3;
W_P <= '1';
W_C <= '0';
wait for PERIOD*10;
W_P <= '0';
W_C <= '0';
wait for PERIOD*3;
W_P <= '0';
W_C <= '1';
wait for PERIOD*7;
W_P <= '0';
W_C <= '1';
wait for PERIOD;
W_P <= '0';
W_C <= '0';
wait for PERIOD*3;
W_P <= '0';
W_C <= '0';
wait for PERIOD*3;
W_P <= '1';
W_C <= '1';
wait for PERIOD*10;
W_P <= '0';
W_C <= '1';
wait for PERIOD*11;
W_P <= '1';
W_C <= '1';
wait for PERIOD*4;
W_P <= '0';
W_C <= '1';
wait for PERIOD*7;
W_P <= '0';
W_C <= '0';
wait for PERIOD*2;
W_P <= '0';
W_C <= '1';
wait for PERIOD*7;
W_P <= '1';
W_C <= '1';
wait for PERIOD*4;
W_P <= '1';
W_C <= '0';
wait for PERIOD*3;
W_P <= '0';
W_C <= '0';
wait for PERIOD*2;
wait;
end process STIMULI;
end BEH;
configuration CFG_TB_TRAFFIC_CONTROLLER of TB_TRAFFIC_CONTROLLER is
for BEH
end for;
end CFG_TB_TRAFFIC_CONTROLLER;
Joshua Smith and Chris Ouellette – BCD Adder Subtractor Xilinx Fit Report
cpldfit: version G.37
Fitter Report
Design Name: twodigitbcdto7seg
Device Used: XC9572-7-PC44
Fitting Status: Successful
Xilinx Inc.
Date: 11-29-2004, 12:05PM
**************************** Resource Summary ****************************
Macrocells Product Terms Registers
Pins
Function Block
Used
Used
Used
Used
Inputs Used
66 /72 ( 92%) 219 /360 ( 61%) 0 /72 ( 0%) 34 /34 (100%) 92 /144 ( 64%)
PIN RESOURCES:
Signal Type Required Mapped | Pin Type
Used Remaining
------------------------------------|--------------------------------------Input
: 17
17 | I/O
: 28
0
Output
: 17
17 | GCK/IO
: 3
0
Bidirectional : 0
0 | GTS/IO
: 2
0
GCK
: 0
0 | GSR/IO
: 1
0
GTS
: 0
0 |
GSR
: 0
0 |
------Total 34
34
MACROCELL RESOURCES:
Total Macrocells Available
72
Registered Macrocells
0
Non-registered Macrocell driving I/O
17
GLOBAL RESOURCES:
Global clock net(s) unused.
Global output enable net(s) unused.
Global set/reset net(s) unused.
POWER DATA:
There are 66 macrocells in high performance mode (MCHP).
There are 0 macrocells in low power mode (MCLP).
There are a total of 66 macrocells used (MC).
End of Resource Summary