Lab 6: Elevator Controller CSE140L: Digital Systems Laboratory { Winter 2017
1 Introduction
Feel Good Inc. is constructing its new 3- oor headquarter complex at La Jolla, CA. Per California Building Code
(CBC), an elevator is required for accessibility of the building. They asked students from UC San Diego to help
them design the elevator controller in hardware.
1.1 System Composition
As shown in Figure 1, the complex has three oors. At each oor, there are request buttons on the wall indicating
if the passengers waiting at this oor want to go up or go down. (there are no going down button on the rst
oor and no going up button on the third oor.) Inside the elevator cabin, there is a panel with three buttons,
indicating the destinations of the passengers inside the cabin. The cabin is driven by the motor in the control
room. The motor is controlled by a motor controller, which controls whether the motor is rotating or not, as well
as the direction controller, which controls the moving directions of the elevator. We assume when the elevator stops
moving, the door will keep open, and when elevator keeps moving, the door will be closed.
As shown in Figure 2, the elevator control system is composed of elevator controller, and a oor sensor and
motor controller. In this lab, you will implement the elevator controller.
Figure 1: 3-storey headquarter complex with an elevator inside.
1.2 Elevator Scheduling
The elevator works as follows: based on the current state of the elevator (which buttons are pressed, the current
oor of the cabin and the moving direction of the cabin), the next oor to stop is uniquely decided. (In other
words, the next oor to stop is a combinational function of the buttons that are pressed, the current oor of the
cabin and the moving direction of the cabin).
We assume the elevator has unlimited capacity. We adapt the following general policy to decide the next oor
to stop, assuming the elevator is moving up
1. if there is no request, stop at the current oor.
2. if the elevator is currently moving up and there are going up requests from the oors above or destinations
to the oors above, stop at the closest oor from above that has either request or is destination.
3. except for the cases stated above, if the elevator is currently moving up and there are going down requests
from the oors above, stop at the farthest oor from above that has that request.
1
Lab 6: Elevator Controller CSE140L: Digital Systems Laboratory { Winter 2017
Figure 2: Schematic of the elevator control system.
4. except for the cases stated above, if the elevator is currently moving up and there are no requests from the
oors above or destinations to the oors above, change the moving directions and then check if it matches
the cases stated above.
For the cases when the elevator is moving down, the policy should change respectively. If multiple buttons are
pressed at exactly at the same time, the elevator will prefer keep its current moving direction, unless no destinations
or requests are from current moving direction.
Once the next oor to stop is decided, we are able to decide the moving/stoping and moving directions of the
cabin to get to the next oor to stop. We represent the state of the elevator control system using a tuple fmoving,
directiong. moving is an enumerate type variable with value START and STOP. direction is an enumerate type
variable with value UP and DOWN representing the moving direction of the elevator. Applying the above policy, the
elevator controller forms a nite state machine (FSM), as shown in Figure 3.
Figure 3: FSM representation of the elevator controller.
2 Lab Assignment
First, make a copy of the source code using the following command
$ cp -r /home/linux/ieng6/cs140l/public/lab7 .
In ElevatorInterface.bsv, we de ne the following enum type to represent the moving direction of the elevator.
2
Lab 6: Elevator Controller CSE140L: Digital Systems Laboratory { Winter 2017
1 typedef enum fUP, DOWNg Direction
typedef enum fSTART, STOPg Moving
Figure 2 shows the schematic of this elevator control system.
In ElevatorInterface.bsv, we give the interface for implementing the elevator controller.
interface Elevator;
2 method Action oor 0 up request;
method Action oor 1 up request;
4 method Action oor 1 down request;
method Action oor 2 down request;
6
method Action oor 0 des request;
8 method Action oor 1 des request;
method Action oor 2 des request;
10
method Action setCurrentFloor(int oor);
12
method Moving moving;
14 method Direction direction;
endinterface
floor f0,1,2g fup,downg request represents the buttons outside the cabin on each oor (Floor G = Floor 0)
to request going up or going down. floor f0,1,2g des request represents the buttons inside the cabin indicating
the destinations of the elevator. setCurrentFloor(int floor) indicates the elevator controller that the cabin is
currently at oor int floor.
moving indicates the signal the elevator controller sending to the motor controller whether to turn on the
rotation or not, and direction indicates the signal the elevator controller sending to the motor controller of the
moving direction. The motor controller checks these signals continously, and the changes of the value of the signals
are immediately received by the motor controller, resulting in the change of stop/start moving and moving direction
change of the cabin instaneously.
In order to implement the interface Elevator.bsv, we prede ned several registers inside the mkElevator.
1 module mkElevator(Elevator);
Reg#(Vector#(NUM FLOOR, Bool)) oor up pressed < mkReg(replicate(False));
3 Reg#(Vector#(NUM FLOOR, Bool)) oor down pressed < mkReg(replicate(False));
Reg#(Vector#(NUM FLOOR, Bool)) oor des < mkReg(replicate(False));
5
Reg#(int) currentFloor < mkReg(0);
7 Reg#(Direction) direction reg < mkReg(UP);
Reg#(Moving) moving reg < mkReg(STOP);
9
...
11 endmodule
floor fup,downg pressed[i] are set True if the respective requests from method floor i fup,downg request
are made, and they will remain True until the the respective request has been resolved. (=The elevator stops at
that oor due to that request. You can think of them as indicating lights on the buttons of the elevator.) Because
the moving down request at bottom oor and moving up request at top oor are meaningless, we always assume
floor up pressed[NUM FLOOR-1] and floor down pressed[0] are False.
Similarly, floor des[i] are set True if the respective requests from method floor i des request are made,
and they will remain True until the respective request has been resolved.
Register currentFloor indicates the current oor of the cabin. Register direction reg represents the moving
direction of the elevator and register moving reg represents the the moving/stoping of the elevator.
Exercise 1: 30 points
Assume the elevator is currently moving up due to some request from above or current oor or the destination to
the oors above or the current oor, we de ne the following function:
1 function int nextFloorUpStop(Vector#(NUM FLOOR, Bool) oor up pressed, Vector#(NUM FLOOR, Bool) oor down pressed,
Vector#(NUM FLOOR, Bool) oor des, int currentFloor);
3
Lab 6: Elevator Controller CSE140L: Digital Systems Laboratory { Winter 2017
to determine the next oor to stop. nextFloorUpStop takes the floor up pressed, floor down pressed,
floor des, and currentFloor as de ned in the mkElevator as input and returns the next oor to stop as an
integer.
Similarly, assume the elevator is currently moving down due to some request from below or current oor or the
destination to the oors below or the current oor, we de ne the following function:
1 function int nextFloorDownStop(Vector#(NUM FLOOR, Bool) oor up pressed, Vector#(NUM FLOOR, Bool) oor down pressed,
Vector#(NUM FLOOR, Bool) oor des, int currentFloor);
to determine the next oor to stop.
In Elevator.bsv, complete the bodies nextFloorUpStop and nextFloorDownStop.
You have to test your implementations using the following testbenches.
$ make nextFloorSingleStop
$ ./simNextFloorUpStop
$ ./simNextFloorDownStop
This test will compare the output of your implementations and the reference implementations with random
inputs. It will print out any mismatches between the outputs of implementations and reference implementation.
Exercise 2: 20 points
Now assume the elevator is at arbitrary state (not necessarily moving up or moving down due to request from
above or below.)
We de ne the following function:
1 nextFloorStop(Vector#(NUM FLOOR, Bool) oor up pressed, Vector#(NUM FLOOR, Bool) oor down pressed, Vector#(
NUM FLOOR, Bool) oor des, int currentFloor, Direction direction);
to determine the next oor to stop.
In Elevator.bsv, complete the bodies nextFloorStop.
You have to test your implementations using the following testbenches.
$ make nextFloorStop
$ ./simNextFloorStop
This will run random testcases. For each testcase, the initial state and the passenger on each oor and their
destinations are printed. No one is inside the cabin at the beginning.
START TEST 66
currentFloor=2
MOVING DIRECTION: DOWN
A PERSON AT FLOOR 0 REQUEST TO GO UP, ONCE ENTERED CABIN HE OR SHE WILL PRESS FLOOR 2
A PERSON AT FLOOR 1 REQUEST TO GO DOWN, ONCE ENTERED CABIN HE OR SHE WILL PRESS FLOOR 0
In this example, the elevator is initially stopped at Floor 2 and the internal moving direction is DOWN. There are
three people on each oor and their destination is shown.
Then the trace of the cabin will be printed based on your implementation of nextFloorStop.
The elevator stops at Floor 1
The elevator stops at Floor 0
The elevator stops at Floor 0
The elevator stops at Floor 2
The elevator will directly go up to oor 1 and let the person in, then stop at oor 0 to let the second person
in and let the rst person out, and go to oor 2 to let the second person out. You are responsible for checking if
your output meet the policy described previously.
Exercise 3: 30 points
Now that we know the next oor to stop as function of the elevator state, we can decide the moving direction and
moving/stopping of the motor based on the next oor to stop and the current oor. We de ne the following rules
4
Lab 6: Elevator Controller CSE140L: Digital Systems Laboratory { Winter 2017
in the mkElevator module:
1 module mkElevator(Elevator):
rule goingUp;
3 rule goingDown;
rule changeDirection;
5 rule stopGoingUp;
rule stopGoingDown;
7 endmodule
Complete these rules based on the information given in Figure 3. Please also notice that you have to reset the
respective registers once the elevator stops at certain oor (i.e., if the stop at the current oor is due to destination
button, going up button or going down button being pressed and the respective register for the button is set, reset
this register to False).
You have to test your implementations using the following testbench.
$ make rules
$ ./simRules
The testbench generates the trace of the cabin due to several requests, please compare it with refSimRules.txt
to see if it makes sense.
Exercise 4: 10 points
Feel Good Inc. gets more funding from National Science Foundation (NSF), and instead of building a 3- oor
headquarter complex, they plan to build an 10- oor headquarter complex. We provide interface for 10- oor elevator
in the following:
1 interface ElevatorNF;
method Action oor up request(int i);
3 method Action oor down request(int i);
method Action oor des request(int i);
5 method Action setCurrentFloor(int oor);
method Moving moving;
7 method Direction direction;
endinterface
In Elevator10f.bsv, complete the rules inside mkElevatorNF module.
You have to test your implementations using the following testbenches.
$ make 10floor
$./sim10Floors
The testbench generates the trace of the cabin due to several requests, please compare it with ref10Floors.txt
to see if it makes sense.