G
LOBBY
NAVIGATE
← →
VL2025260500897 · VIT SENSE

MULTI-FLOOR
ELEVATOR
CONTROLLER

We built the brain of an elevator in software and then proved it works correctly before a single wire is soldered. Navigate the floors to see how.

What is this project? Think of every elevator you've ever ridden. Something has to decide: which floor do I go to next? Do I go up or down? When do I open the doors? This project is that decision-making logic, built in a hardware description language called SystemVerilog and tested using a simulator called ModelSim.
24BVD0162 · BORKATAKI
24BVD0202 · RAJESH
24BVD0216 · SAINI
▲
IDLE
Abstract

THE
BRAIN
INSIDE

The elevator's logic is modelled as a Finite State Machine (FSM) with three modes: IDLE, UP, and DOWN. It reads which floors are requested, decides which direction to move, climbs or descends one floor at a time, and opens the door when it arrives.

What's a Finite State Machine? It's like a flowchart that a machine follows. At any moment, the elevator is in exactly one "state" (Idle, Going Up, or Going Down). When something changes like a button press it moves to a new state. Simple rules, predictable behaviour, no surprises.

Why SystemVerilog? It's a language used to describe how hardware chips work not software running on a computer, but the actual logic circuits inside a chip. The diagram on the right shows the three states and how the elevator transitions between them.
FSM SYSTEMVERILOG MODELSIM ABV RTL DESIGN
req_above door_open req_below door_open cur req
IDLE
UP
DOWN
Architecture

PORT
MAP

What's a "port"? Ports are the inputs and outputs of a hardware module like the pins on a chip. Think of them as the doors and windows of the elevator's brain: information flows in (which floor buttons were pressed, the clock tick, the reset signal) and decisions flow out (current floor number, which direction, whether to open the door).
INPUT what goes in
clk / rst / request[4:0]
CORE MODULE the logic
elevator_controller
OUTPUT decisions made
current_floor / direction / door_open
TESTBENCH checks the work
project_tb (verification only, not real hardware)
SIGNAL DIR WIDTH DESCRIPTION
clk IN 1-bit System clock the heartbeat. Every tick, the controller takes one step.
rst IN 1-bit Reset like a power cycle. Sends the elevator back to floor 0, waiting.
request IN 5-bit Floor buttons pressed. 5 bits = 5 floors. Bit 3 = "1" means floor 3 was requested.
current_floor OUT 3-bit Where the elevator is right now (floor 0 to 4).
direction OUT 1-bit Which way it's moving. 1 = going up, 0 = going down.
door_open OUT 1-bit Should the doors open? 1 = yes (the elevator has arrived at a requested floor).
HELPER FUNCTIONS
function request_above(req, floor)
  → |(req >> (floor+1))
function request_below(req, floor)
  → |(req & ((1 << floor)-1))
These two functions answer simple questions in one line of logic: "Is anyone waiting above me?" and "Is anyone waiting below me?" They scan the 5-bit request signal using bitwise operations (shifting and masking bits) to check only the relevant floors, without needing a loop or a priority encoder chip.
Implementation

SV
CODE

What are you looking at? This is the actual SystemVerilog code that defines the elevator's logic. Each keyword has a job: input/output declares what the module receives and sends back. always_ff means "run this block on every clock tick." The case(state) block is the FSM it checks the current state and decides what to do next.
elevator_controller.sv
module elevator_controller (
  input logic clk,
  input logic rst,
  input logic [4:0] request,
  output logic [2:0] current_floor,
  output logic direction,
  output logic door_open
);

typedef enum logic [1:0]
  {IDLE, UP, DOWN} state_t;
state_t state;

always_ff @(posedge clk or posedge rst)
begin
  if (rst) begin
    current_floor <= 0;
    state <= IDLE;
    door_open <= 0;
  end else begin
    door_open <= 0;
    case (state)
      IDLE: begin
        if (request[current_floor])
          door_open <= 1;
        else if (request_above(...))
          state <= UP;
        else if (request_below(...))
          state <= DOWN;
      end
      UP: begin
        direction <= 1;
        current_floor <= current_floor + 1;
        if (request[current_floor+1])
          door_open <= 1; state <= IDLE;
      end
      DOWN: begin
        direction <= 0;
        current_floor <= current_floor - 1;
        if (request[current_floor-1])
          door_open <= 1; state <= IDLE;
      end
    endcase
  end
end
endmodule
Assertion-Based Verification
After every clock tick, the testbench automatically checks: "Did the door just open? If so, was this floor actually requested?" If the answer is no, it immediately reports an error. This is called an assertion a built-in sanity check that runs alongside the simulation. Zero failures here means the door never opened at the wrong floor.
What is a Testbench?
A testbench is a separate piece of code written to test the design like a script that pretends to be a building pushing buttons. It applies different floor requests and watches how the controller responds. It's not real hardware; it exists only in simulation to verify correctness before anything is manufactured.
Python Log Parser
After the simulation finishes, ModelSim writes a log file. A small Python script reads that log, looks for the word "error," and prints either ✗ TEST FAILED or ✓ TEST PASSED. It also confirms the simulation actually completed by checking for the $finish signal like checking an exam paper was actually submitted.
Clock the Heartbeat
The clock signal alternates between 0 and 1 at a fixed rate. Each rising edge (0 to 1 transition) is one "tick" one moment when the FSM can change state. 10ps per full cycle extremely fast, as used in hardware simulation. Real elevators operate over seconds, not picoseconds, but the logic is identical.
Tool Stack
SystemVerilog (hardware language) → ModelSim (simulator that runs the design virtually) → Python (to automatically check the results). No physical hardware was needed the entire elevator was tested inside a computer.
Simulation Results

ALL
PASS

How was the elevator tested? Three scenarios were run in the simulator each one presses different floor buttons and watches what happens. The waveform below is the same kind of signal graph engineers use to debug chips. Each row is one signal; time flows left to right. Click a scenario to see its waveform.
ModelSim Waveform
request=5'b01000 → Floor 3 · FSM: IDLE→UP→IDLE
3/3 SCENARIOS PASSED · 0 ASSERTION ERRORS
Reading the waveform: CLK is the clock ticking. RST starts high (resetting the system) then drops to 0. FLOOR climbs as the elevator moves up you can see it step from 0 to 3. DOOR pulses green when the elevator arrives and opens. Every green pulse lines up with a requested floor. That's correctness.
3
FSM States IDLE (waiting) · UP (ascending) · DOWN (descending)
5
Floors Simulated Ground (0) through Floor 4 all tested
0
Assertion Failures The door never opened at the wrong floor ever
35%
More bugs caught Using assertions finds ~35% more bugs than just watching signals (Bergeron, 2012)
Team & Credits

THE
ENGINEERS

This project was built by three undergraduate students at VIT Vellore as part of their Scripting Languages and Verification Lab course. The work covered hardware description, simulation, assertion-based verification, and Python scripting all coming together to prove a virtual elevator works correctly before it ever touches real silicon.
24BVD0162
Mayur
Borkataki
Electronics Engineering
⚡
24BVD0202
Ronak
Rajesh
Electronics Engineering
🔌
24BVD0216
Hemanya
Saini
Electronics Engineering
🛗
Faculty Guide
Dr. Abhishek Narayan Tripathi
Dept. of Micro and Nanoelectronics · VIT Vellore
Head of Department
Dr. Sriadibhatla Sridevi
School of Electronics Engineering (SENSE) · VIT Vellore
CLASS VL2025260500897 · TT237A SCRIPTING LANGUAGES & VERIFICATION LAB · VIT VELLORE