Design Of A Dual Elevator Controller - Seminar Report

An elevator is a device designed as a convenience appliance that has evolved to become an unavoidable feature of modern day urban life. The Oxford Dictionary [2] defines an elevator as, “A machine that carries people or goods up and down to different levels in a building or mine”. While a standalone elevator is a simple electro-mechanical device, an elevator system may consist of multiple standalone elevator units whose operations are controlled and coordinated by a master controller. Such controllers are designed to operate with maximum efficiency in terms of service as well as resource utilization. This chapter details the design of a dual elevator controller.

Basic Principle – Dual Elevator Controller
Dual elevator controller is an elementary system consisting of two elevator cars serving two floors. Each of the elevator cars has a pair of control buttons (up / down) for moving the elevator up and down. Each of the floors also has call buttons to call for the service of the elevator system. The following principles have been applied during the design of the dual elevator controller:
            • The floors are defined as ground floor (gndFlr) and first floor (fstFlr).
            • The elevator cars are designated as elevator-A (elvtrA) and elevator-B (elvtrB).
            • Elevator-A gives priority to ground floor and elevator-B gives priority to first floor.
            • A floor call is serviced using the nearest available elevator.
            • Upon arrival at a floor, the doors open immediately.
            • Doors remain open for approximately 20 seconds, before closure.
            • If an obstruction is detected when door is about to close, it remains open
            • Each elevator car is treated as a sub-system controlled by the controller.
            • Elevator Up / Down buttons are connected to individual elevator units.
            • Elevator units depend on floor sensor inputs to determine the current status.
            • Each door unit is treated as a sub-system controlled by the respective elevator car.
            • Timing and obstruction detection systems act as slave systems to the door units.
            • Floor call buttons are connected to the elevator controller.

 State Flow The entire dual elevator controller system has been treated as a collection of smaller sub-systems viz. door units, elevator units and the master controller. The following sections describe these subsystems.

Door Units
The door units are controlled by the elevator units through a set of door commands. The status of each of the door units is passed on to the elevator units as an input. Table 2.1 shows the commands and corresponding state transitions.

  Elevator Units
The elevator units are controlled by the master controller through a set of elevator commands. The status of each of the elevator units is passed on to the master controller as an input. 

  Master Controller
The master controller controls the elevator units through a set of elevator commands. The state of each elevator unit is taken by this controller as input. Table 2.3 shows the state table for the master controller.

Design Using HDL The dual elevator controller system was modeled using Verilog HDL. The HDL code is attached herein as Appendix 1. The design is organized into six modules. The door, elevator and timer units are modeled as separate modules, followed by a clock divider module. The master controller is designed as another module and then all these are integrated using a top module which contains instantiations of all the sub-system modules. The resultant RTL was synthesized using the Xilinx Synthesis Tool ISE v9.1. The following sections show the RTL schematics obtained after synthesis.

 Verification Using Test-bench
The Verilog code for the test bench is attached as Appendix 2. Figure 2.8 shows the simulation results obtained from the test bench.
It can be seen that at reset, both the elevators move to ground floor, the doors open, timers get activated (note that timer duration is minimum to facilitate ease of simulation) and after the wait is over, doors close.
At time 184.2, a call is received from ground floor. Elevator-A opens for the duration dictated by the timer and then closes.
At time 394.3, for the call received from first floor, elevator B moves to first floor and the door open – close routine repeats.
At time 895.1, elevator B is at second floor when a call is received from the same floor. Here, an obstacle is detected while the door is open; it can be observed that the door remains open till the obstacle is removed. The ‘tmrOutB’ waveform shows the reactivation of the timer when an obstacle is detected (approx. at time 1095.1). Elevator A behaves in a similar manner at ground floor.

another set of simulation results obtained from the test-bench. At time 1606.6, when elevator A is in motion to first floor, the down button inside the elevator is pressed. The input is ignored and the elevator remains in motion to first floor.
At time 1845.0, when elevator B is at first floor and the up button inside the elevator is pressed it opens, and after the specified time interval, closes. Similar behavior can be observed for elevator A at time 2635.0.
At time 2135.7, the down button inside elevator B is pressed. The elevator starts moving to ground floor. While elevator B is in motion, the ground floor up button is pressed at time 2285.3. The system waits for the arrival of the moving lift to the ground floor.

 An elevator controller is a complex system that had to be broken down into smaller modules in order to model using HDL. Behavioral modeling is a very powerful tool that helps a designer to efficiently handle large and complex designs. A modular approach in design helps simplify the task of designing a complex system. Finite State Machines can be used to accurately describe the functioning of systems that have a large number of inputs and operational states.
An elevator system that serves the bare minimum of two floors was designed and modeled. The reset state of the system ensures that both the elevator cars return to ground floor and the doors remain open for a stipulated period of time. This facilitates the evacuation of personnel in the event of an emergency. A test bench was developed to perform functional verification of the design before implementation. Specific test vectors were designed to test various operating conditions. While the model was found to be working reasonably, there is ample scope for enhancements. An important enhancement is to make the controller scaleable so that more floors and elevator cars can be added to the system. It was found that to achieve accurate and consistent delays; an external delay timer is best suited. Further, an efficient queuing system needs to be implemented to store and service requests that are received but cannot be serviced immediately.
A reasonable amount of familiarity was gained on the process of HDL coding and synthesis in general and Xilinx ISE tool in particular.


Implementing a digital design is one among the most challenging steps involved in VLSI system design. Implementation involves translating the RTL code into a basic net list, mapping it to a particular technology to suit specific design goals and placing and routing (PAR) the design on the hardware platform of choice. PAR is the phase where the components are physically placed and interconnected. FPGA prototyping is a low cost, fast turn around methodology for validating large and complex designs, without having to worry about the risks involved in fabricating a test chip. Advanced EDA tools available in the market today enable the design team to simulate and validate the performance of any design at every stage of its implementation.
This chapter explains the implementation of the Dual Elevator Controller system designed in Chapter 2, on a Xilinx SPARTAN II platform. The implementation process was performed using Xilinx’s own tool, ISE v9.1.

FPGA Implementation – Dual Elevator Controller
During the course of the implementation the various optimizations performed by the tool were observed. After synthesis, the estimated slice utilization was 7% (54 out of 768). However, after place & route, this was reduced to 6% (51 out of 768). The PAR report observed that the average connection delay for this design is 1.244ns. The worst case hold slack is 2.168ns and the best achievable setup time is 8.397ns. The total equivalent gate count for the design is 805. The maximum operating frequency was found to be 119MHz.

Setting Constraints
User constraints’ setting is the method by which the implementation process can be controlled. The Xilinx Synthesis Tool allows creation of Area, Timing and pin location constraints.
The clock lines have been set to be routed using low skew lines. This has been done to improve the overall timing performance of the system.
The steps involved in the implementation of a design on hardware are translation to low level net list, technology mapping, placement and routing. Timing analysis was performed during implementation. FPGA prototyping provides a lot of flexibility to the designer at a lower cost as compared to an ASIC. FPGA synthesis and implementation tools facilitate easy access to timing, power and performance analysis reports. These tools also support setting and modification of timing and area constraints, which makes it easy to optimize the design before once decides to go in for fabrication.

No comments:

Post a Comment

leave your opinion