Introduction
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
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.
FPGA IMPLEMENTATION OF ELEVATOR CONTROLLER
Introduction
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