report on scrap number 01

8/12/2019 report on scrap number 01

1/3

1

Scrap document to uploadSome dude

I. INTRODUCTIONThe Purpose of this project was to design a traffic light

controller, for a complex intersection. This was achieved using

digital circuits and programmable logic devices. The scope of

the project was to use Programmable Logic Devices that we

had access to and create digital controllers using them for

control applications. The design of the report was the major

point of deliberation as we changed it a few times, in the early

stages of the project and the later stages. The report also goes

into a lot of detail on how the implementation and testing was

done. The report examines the specification of the traffic light

controller. The design of the traffic light controller and also

the implementation, testing, results and how we can improveon the design in the future

II. SPECIFICATION OF T RAFFIC L IGHT C ONTROLLER

A GAL 4 trainer was used, along with 8 GAL22v10

PLD chips. The logic was burnt onto the chip using a PLD

programer device and Opaljr compiler software. The traffic

light being designed for had an intersection with 4 points

of entry and each consisting of multiple lanes. There were

6 flows of traffic that we had to design our system around.

These flows were labeled 1-6. In the concept stages of our

design, one flow was slightly modified(flow 4) but this was

done to increase the eficciency of the design and allow greatertraffic throughput like in real world scenarios. The default flow

(flow 1) had to be green for a minimum of 20 seconds and it

also had to stay in flow 1 if all sensors showed no signs of

incoming traffic. Flow 3 had to be green for 5 seconds and the

rest of the flows had to be green for 7 seconds. The trainer

had 4 in-built sensor switches. The function of the switches

was to simulate traffic conditions. In the project specifications

assumptions were made that through traffic from A and C were

always present. This allowed the sensors to be combined with

the sensors for traffic turning right at both points. The final

sensors for the light controller consisted of:

A Through/Right B

C Through/Right

D

III. DESIGNA IDS FOR P ROGRAMMABLE L OGIC D EVICES

The Traffic Light Controller system is a complex system that

involves 30 output signals, each of these being functions of

the states from finite state machines. These outputs included

each of the different lights for every direction in the traffic

light system(e.g AGreen, AYellow, ARed signals). To make

the process of designing a suitable working system easier, the

design process is divided into parts to aid the process.

A. Hierarchical DesignThis approach is used to aid with complex systems that

are of singular structure. Partitioning the system into modules

of input and output aids with visualizing the functionality of

important signals. Initial designs of the system was singular

in nature, consisting of one finite state machine that both

had sensor input functionality for all directions and all light

outputs. Problems with this design was caused by limitations in

the GAL22v10 hardware. Applying hierarchical design helped

identify where the system could be divided into modular

functioning blocks, highlighting the interconnections between

inputs and outputs between the modules, thus helping in

keeping track of the systems various signals.

B. Synchronous Sequential Circuit

When designing the traffic light controller system, consid-

erations had to be made for the synchronization of the inputs,

timing constraints, sensor inputs and state machine coding.

The GALs used in this project made use of D flip-flops, this

had the result state machine synchronization with the CLK

available on the trainer board. Timing of sensor inputs had

to be carefully considered because of the timing requisite

of the flows. When to consider sensor inputs and transition

timing between flows was applied to the operation of our state

machine. Binary coding was the system used for the FiniteState Machine.

IV. IMPLEMENTATION

A. State Machine

Four separate state machines control the timing of flows,

utilizing chips 1,2,3 and 4.

1) Chip 1 contains flow 1.

Inputs

Sensors Sa, Sb, Sc, Sd

Enables EN1 (from the flow controller) and PB

from the Start/Reset synchronous push button

Outputs

Q0.D, Q1.D, Q2.D, Q3.D, Q4.d for the state

machine

Z1 end output

C0, C1, C2 configuration outputs

See Figure 1.

2) Chip 2 contains flow 2 and 3.

Inputs

Sensors Sb, Sc

EN2 and EN3 for enabling flow 2 or 3

Outputs


2/3

2

Q0.D, Q1.D, Q2.D, Q3.D, Q4.d for the state

machine

Z2 and Z3 end outputs

C3, C4, C5 - configuration outputs

See Figure 2.

3) Chip 3 contains flow 4 and 5.

Inputs

EN4 and EN5 for enabling either flow 4 or flow

5

Outputs

Q0.d, Q1.D, Q3.D, Q4.D for the state machine

Z4 and Z5 end outputs

C6, C7, C8 configuration outputs

See Figure 3.

4) Chip 4 contains flow 6 and D green light.

Inputs

EN6 for enabling flow 6

L0, L1, L2, L3, L4 light inputs

Outputs

Q0.D, Q1.D, Q2.D, Q3.D for the state machine

Z6 end output

C9, C10 configuration outputs

D

GREEN

See Figures 4, 8.

Starting the machine requires an enable signal from a

synchronous push button. This button can also be used to reset

the system at any time while the system is running. The flow

control chip (Chip 5) was utilized to implement the buttonhowever the push button output is separate from the normal

EN1 output.

Each state on the state machines represents 1 clock cycle.

This model is reminiscent of the state machine used in the

simple Traffic Light Controller implemented in the practical

classes. Because this method has been implemented, there is

no need for secondary timing structure to control the duration

that each flow remains active.

Only 1 chip of the state machine can be active at any one

time. The remaining 3 chips will be in an off state.

Although a flow controller is required and is responsible

for enabling a flow on a state machine that is currently in its

off state, state machine 1 and 2 still utilize the sensors to

determinee which flow will be next and uses this information

to enter states that will transition to the next flow efficiently.

As an example, flow 1 transitioning to flow 5 will have a

different configuration of lights during the yellow and red

states compared to if flow 1 was transitioning to flow 6 (since

different directions of traffic need to remain green during

the transition). As a result we end up with the next flow

decision being made twice, once when a flow transitions from

green to yellow (made by the chip itself), and again by the

flow controller when a state machine is in a red state. This

introduces in some situations a bug which will be explained

in more detail under Testing/Results.

B. Flow Controller

Structure

Chip 5.

Inputs

Sensors Sa, Sb, Sc, Sd

End inputs Z1, Z2, Z3, Z4, Z5, Z6

Outputs Enable outputs EN1, EN2, EN3, EN4, EN5,

EN6

See Figure 5.

Uses the information from Z (which flow is currently in

a red state and will be turning off next clock cycle) and

the sensor configuration to activate an enable signal output

which will allow a state machine to transition from being in

an off state to the beginning of a flow. The flow controller

was a necessary implementation as it offloaded the enabling

capabilities from being on the state machines themselves, so

that we could utilize the now free inputs and outputs for the

configuration outputs.If a flow is transitioning to a flow which is contained on

the same chip (for example, FLOW 2 to FLOW 3), the flow

controller does not receive a Z signal and therefore does not

operate.

The outputs are connected directly to the inputs as to avoid

a delay when transitioning from one flow to another. If they

were connected via flip flops there would be a blank clock

cycle in between the end of one flow and the beginning of

another.

It operates in very much the same way as the flow controller

specified in the supplied buggy design.

C. Light Controller

Maps/decodes the 11 configuration inputs to a 5 bit number.

Chip 6.

Inputs

C0, C1, C2, C3, C4, C5, C6, C7, C8, C9, C10

configuration inputs

Outputs

L0, L1, L2, L3, L4 light outputs

See Figure 6.

It was deemed necessary to reduce the amount of bits used

to determinee the configuration of the lights because of the

fact that 21 lights were used. It would have been acceptable

to use the 11 configuration bits as inputs to the light chips

as they have 11 free inputs, however due to the fact that D

green is situated on chip 4 which had fewer available inputs

(as it also contains flow 6) - it was required that this was

done. After completion of the project and further analysis it

was determineed that this reduction wasnt necessary since C9

and C10 were provided by chip 4 and this allows us to remove

the need for the light controller.

The configuration signals were implemented because of the

fact that the state machine is split into 4 individual state

machines. This meant that the light chips could no longer

use the state machine outputs themselves to determinee the


3/3

HARVARD UNIVERSITY ENGINEERING 3

configuration of the lights (as seen in the simple traffic light

controller implemented in the class practicals), simply because

there are too many.

There are 20 unique light configurations in total, each

configuration is assigned a unique 5 bit number.

The combinations of C0-C10 that occur are assigned to a 5

bit number that represents the required lighting configuration.

D. Light Chips

Chip 7.

Inputs


Outputs

A through

RED, YELLOW, GREEN

A right

RED, YELLOW, GREEN

B through/right

RED, YELLOW, GREEN

B left

RED

See Figure 7

Chip 8.

Inputs


Outputs

B left

YELLOW, GREEN

C through RED, YELLOW, GREEN

C right

RED, YELLOW, GREEN

D

RED, YELLOW

See Figure 8

The operation of this type of chip is straight forward. Based

on the truth tables as can be seen in the appendix, they

determinee which lights are active based on the input bits L0,

L1, L2, L3 and L4. The light outputs are directly connected

to the inputs so there is no clock cycle delay in operation.

V. TESTING/R ESULTS

Upon initial testing, every sequence was perfectly executed

under normal operating conditions. However as hypothesized

after implementing the flow controller, there exists a double

bug. It can be simulated and occurs when the following

conditions are met:

1) Flow enters final green state and makes decision about

which flow will be next.

2) After this decision is made and before the flow controller

makes a decision about which flow to enable next, the

sensor configuration changes.

3) The flow which the chip thought was going to occur

next, and the flow which the flow controller actually

enables require different yellow/red state transitions

If the flow which the chip thought was going to

occur next and the flow which the flow controller

enables share the same yellow to red transition then

this does not cause unusual behavior.

This can either cause a dangerous transition or an inefficienttransition.

If the circumstances cause a dangerous transition, we see

that lights can change from green to red immediately. This

is clearly unwanted and could have catastrophic implications

during real world operation. If the circumstances cause an

inefficient transition, we see that the traffic in some directions

is stopped, when it would not normally need to stop since this

traffic is enabled in both flows. This is not as detrimental as

the dangerous transition but is not intended behavior of the

design.

V I. SUGGESTIONS FOR I MPROVEMENTSThe improvements that can be made on the circuit are based

observing real-world standard. This involved either lanes 18-

17 or lanes 4-5. If lane 18-17 had traffic waiting while there

was no traffic at any of the other points. Then The lights at

C-right would turn off(The C-right inputs would be 0), this

would indicate that the traffic could turn accordingly at a safe

time. This also apply s to lanes 4-5.

Pedestrian access should also be taken into account. Addi-

tional sensor inputs would need be implemented. The sensor

inputs would theoretically indicate to the flow control chip

that there are pedestrians present. Then the light control chip

would have to account for the change traffic conditions.Additional sensors could be added, these sensors determine

the weight and a particular lane. The purpose of these sensor

would be to determine the traffic density. This would help the

traffic control chip to determine the most optimum configura-

tions for the flow transitions.

The design was possible in 7 chips. The light control (Chip

6) wasnt necessary for our design. We used the light control

chip for 11 to 5 bit binary conversion. Since there were only

10 spare inputs on chip 4 and two of the product terms came

from chip 4, that left 9 spare inputs which were available on

chip 4.

VII. CONCLUSION

In conclusion, our traffic light system was successful in

demonstrating the different flow transitions. If The project

was to be attempted again, improvements for the group are;

delegation of tasks, efficient documentation, communication

and efficient use of time.

Documents

report on scrap number 01