Traffic Light Controller Design: A Verilog HDL Implementation, Study notes of Electrical and Electronics Engineering

An implementation of a traffic light controller using verilog hdl at the university of illinois at urbana-champaign. The design includes a system description, diagram, and verilog code for the controller module, its inputs/outputs, internal variables, initializations, and single assignment rule. The document also covers the working of the north, south, and east traffic, as well as the safety and liveness properties.

Typology: Study notes

Pre 2010

Uploaded on 03/11/2009

koofers-user-vyu-1
koofers-user-vyu-1 🇺🇸

9 documents

1 / 10

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
1
37
Naresh Shanbhag, University of Illinois at Urbana-Champaign 37
Traffic Light Controller
38
Naresh Shanbhag, University of Illinois at Urbana-Champaign 38
Diagram
pf3
pf4
pf5
pf8
pf9
pfa

Partial preview of the text

Download Traffic Light Controller Design: A Verilog HDL Implementation and more Study notes Electrical and Electronics Engineering in PDF only on Docsity!

Naresh Shanbhag, University of Illinois at Urbana-Champaign 37^37

Traffic Light Controller

Naresh Shanbhag, University of Illinois at Urbana-Champaign 38^38

Diagram

Naresh Shanbhag, University of Illinois at Urbana-Champaign 39^39

System description

  • N and S traffic allowed simultaneously
    • They both activate the same lock signal
    • E traffic not allowed when lock signal ON (when either/both N and S ON) -SAFETY
  • E decided first, then S and finally N
  • Only one car at each light at an instant
    • Model has a notion of time steps
    • A car when sensed, eventually gets a green- LIVENESS
    • No concept of a timer for a flow of cars, as signals are assigned every instant

Naresh Shanbhag, University of Illinois at Urbana-Champaign 40^40

A Traffic Light Controller

module main(N_s, S_s, E_s, N_g, S_g, E_g){ input N_s, S_s, E_s : boolean; output N_g, S_g, E_g : boolean; …

Naresh Shanbhag, University of Illinois at Urbana-Champaign 43^43

Initializations

N_g, E_g, S_g, N_r, E_r, S_r -All green lights are initially 0 NS_lock -Initially 0. Use the init command

  • init(N_g) := 0;
  • All the above signals are register variables
  • Values retained unless explicitly changed by assignment

Naresh Shanbhag, University of Illinois at Urbana-Champaign 44^44

Single Assignment rule

  • default {block1}
  • in {block2} -Assignments in block2 get priority. -Signals given in block1are assigned, if not assigned in block2. -Only one assignment to a signal is to be active at a time. -The “default” keyword allows a nice nesting of blocks rather than enumerating all cases explicitly for each signal.

Naresh Shanbhag, University of Illinois at Urbana-Champaign 45^45

Setting the requests

default{ if (N_s) next(N_r) := 1; if (S_s) next(S_r) := 1; if (E_s) next(E_r) := 1 } in default case { … (in next slide)

Naresh Shanbhag, University of Illinois at Urbana-Champaign 46^46

Working of N and S

  • If there is a north request , and the north light is not green and there is no east request, then switch on the north light and set the lock (in effect, we give priority to the east traffic).
  • If the north light is on, and there is no more north traffic, switch off the light, clear the request, and switch off the lock. However, if the south light is on, don't switch the lock off. This is to prevent south and east traffic from colliding.
  • The south light code is similar

Naresh Shanbhag, University of Illinois at Urbana-Champaign 49^49

Working of E

  • The east light is switched on whenever there is an east request, and the lock is off.
  • When the east sense input goes off, we switch off the east light and reset the request

Naresh Shanbhag, University of Illinois at Urbana-Champaign 50^50

Controlling E-going traffic

in case{ E_r & ~NS_lock & ~E_g : next(E_g) := 1; E_g & ~E_s : { next(E_g) := 0; next(E_r) := 0; } }

Naresh Shanbhag, University of Illinois at Urbana-Champaign 51^51

Properties

safety: assert G ~(E_g & (N_g | S_g)); N_live: assert G (N_s -> F N_g); S_live: assert G (S_s -> F S_g); E_live: assert G (E_s -> F E_g);

N_live is interpreted as AG (N_s -> AF N_g)

The liveness properties can only hold if drivers do not wait forever at a green light (FAIRNESS) -Otherwise the sensors will remain set. -Similar to the idea of disallowing continuous traffic at one light

Naresh Shanbhag, University of Illinois at Urbana-Champaign 52^52

So we need to assume …

Assume infinite occurrences of states with no pending requests N_fair: assert G F ~(N_s & N_g); S_fair: assert G F ~(S_s & S_g); E_fair: assert G F ~(E_s & E_g);

In the controller implementation these fairness constraints will have to be ensured.

Naresh Shanbhag, University of Illinois at Urbana-Champaign 55^55

Modification 1(2.smv)

  • S code modified to check if N is going to switch on (not just if N is on at present), before turning off lock If (~(N_g|N_r & ~N_g & ~E_r)) next(NS_lock):=0;
  • SAFETY property holds, but N_live (E_live and S_live as well) fails
  • N and S goes off together
    • Each thinks the other will remain on
    • Neither switches off the lock
    • E request cannot be served
    • Deadlock

Naresh Shanbhag, University of Illinois at Urbana-Champaign 56^56

Modification 2(3.smv)

  • N code modified to switch off lock if both N and S turning off. If (~S_g | ~S_s) next(NS_lock) := 0;
  • Now, all safety and liveness properties hold.