EE 330 Final Project

Elevator Controller Design Nhat Pham & Brittany Duffy

1

Table of ContentsIntroduction- 1 -Design- 1 -Design Strategy- 3 -Verilog Implementation- 4 -Elevator- 4 -Input, Output, and Register- 4 -Initialization- 6 -Elevator Test bench- 9 -Registers and Wires- 9 -Initialization- 10 -Verilog Simulation- 12 -Verilog Synthesis with RTL Compilation- 13 -Layout of Digital circuits with Encounter- 14 -1.Running SoC Encounter- 14 -2.Importing Synthesized Verilog- 14 -3.Floorplanning- 14 -4.Power Planning- 15 -5.Placement- 15 -6.Routing- 16 -7.Filler Cells- 17 -8.Verification- 18 -9.GDS Export of Layout from Encounter- 19 -10.GDS Import of Layout into Virtuoso- 19 -Debouncing Circuit- 21 -Conclusion- 21 -

IntroductionFor our EE 330 Final Project, we chose to develop a design for an eight-floor elevator. The inputs/outputs are shown below. The elevator displays the moving direction and the current floor. In addition, the maximum weight in the elevator is 4500lb. If the current weight is larger than 4500lb, the elevator will alert automatically. A Boolean signal comes from the maximum weight detector and will be set to 1 whenever the maximum weight is exceeded. The door of the elevator should not kept open for longer than 3 minutes. Otherwise, it will close automatically. The door alert signal should normally be low but go high whenever the door has been open for more than 3 minutes. This door alert signal will be used by the mechanical part of the elevator to issue a close door command. Whenever the door is open for more than 3 minutes, a blinking 30mA lamp will come on. This blinking will happen at a rate of approximately 1 blink every 2 seconds. In addition, there is a sensor at each floor to sense whether the elevator has passed the current floor. This sensor provides a 3-bit Boolean signal that encodes the floor that has been passed. We assumed we were given a 3-bit Boolean signal.DesignOur design consisted of five inputs: Request Floor, Current Floor, Weight Sensor, Clock, and Reset along with five system outputs: Complete, Direction, Current Floor, Weight Alert, and Door Alert. Below is the diagram of our system: Input [2:0]

Input [2:0]

Input [2:0]

Request Floor Current Floor

Weight Sensor

CLK

Reset

Complete

Direction

CurrentFloor

Weight Alert

DoorAlert1: Reach Floor0: Otherwise

1: Up0: Down

Output [2:0]

Input Clock

1: Weight Exceeded0: Otherwise

Input Reset

1: Open for 3 min0: Otherwise

Figure 1: System Diagram

The original design did not include the Weight Sensor; however, we added a Weight Sensor input port to the system because the Weight Alert output depend the corresponding Weight Sensor input. Without the Weight Sensor input we will not able to check whether the maximum weight is exceeded or not. Below in Table 1 you can view the design specifications:Port NameTypeDescription

Request floorInput8bits

Current floorInput8bits

Weight SensorInput1: Exceeded max weight0: Otherwise

CLKInput1 bit

ResetInput1 bit

CompleteOutput1: Reach the request floor0: Otherwise

DirectionOutput1: up0: down

Current floorOutput8bits

Weight AlertOutput1: Overload0: Otherwise

Door AlertOutput1: Open for 3 min0: Otherwise

Table 1: Design Specifications

Design StrategyUsing the finite state machine approach, we developed an efficient way for the elevator to reach each floor (Figure 2). Having the elevator go up and down was just a small design portion of this final project. We thought of the case when multiple buttons are pressed at once, having the elevator handle each floor one state at a time until it reaches its final destination. Also, we created a door alert with the assumption that the door is always open once it reaches a floor. Once the request floor and the current floor are equal, the counter begins to count the clock cycles until it reaches 3 minutes. This is when the door alert becomes on. In addition, we had to encounter if the elevator exceeded a certain weight. In this case, we chose the elevator to alarm users with the weight alert. When the weight alert is on, the elevator is not able to go up nor down, and therefore we assume that the doors are open at all times when the weight alert is on. This in turn causes the door alert to come on and begin its count to 3 minutes. You may find additional cases stated later during the test bench section. The Verilog Implementation section and Initialization also have a better description of how we went about executing each instance.11111110000000

Figure 2: Finite State Machine Illustration

Verilog ImplementationIn order to design our circuit-using Cadence, we first wrote code describing how our design would work using a Hardware Description Language (HDL). Below is the Verilog code describing the entire circuit:ElevatorInput, Output, and Register

Figure 3: Input, Output, and Registers

WeightSensor:Weightsensor represent an input from mechanical part hardware that sense whether the elevator is overweight or not, which corresponding to:1: When the weight in the elevator is exceeded 4500lb.0: When the weight in the elevator is less than 4500lb.

[2:0] Requestflr:3-bit Boolean input corresponds to each floor that the user is requesting.Request FloorBinary

Floor 03b000

Floor 13b001

Floor 23b010

Floor 33b011

Floor 43b100

Floor 53b101

Floor 63b110

Floor 73b111

[2:0] Currentflr:3-bit Boolean input from each floor sensor that encodes each floor the elevator is currently on.Current FloorBinary

Floor 03b000

Floor 13b001

Floor 23b010

Floor 33b011

Floor 43b100

Floor 53b101

Floor 63b110

Floor 73b111

Complete:Complete is an output port that will display whether the elevator has reached the requested floor.1: Completed and currently at the requested floor.0: Not complete and currently not at the requested floor.

Direct:Direct is an output port that displays the direction of the elevator motion.1: Elevator is going up.0: Elevator is going down.

wAlert:wAlert represent the weight Alert output port that will display an alarm when the weight in the elevator exceeds 4500lb.1: Weight in the elevator has exceeded the maximum weight of 4500lb.0: Weight in the elevator is less than the maximum weight.

drAlert:drAlert represents the door alert output port. The door alert will display an alarm signal when the door is open for more than three minutes. In the instructions given, the original system diagram does not have an input port that provides the state of the elevator door (being open or closed); therefore, we included an additional door alert input. We did not want to make too many variations to the problem, so we decided to make an assumption: if the elevator stays on a floor for longer than three minutes the door alert will go on, assuming the door is always open once it reaches its destination floor or if the elevator is not moving.1: Door is open longer than 3 minutes.0: No door alert

[2:0] Displayfloor:Displayfloor is an output port that represents the current floor output on the system diagram. This is a 3-bit Boolean that will display the floor that the elevator just reached.Current Floor(OUTPUT)Binary

Floor 03b000

Floor 13b001

Floor 23b010

Floor 33b011

Floor 43b100

Floor 53b101

Floor 63b110

Floor 73b111

Initialization Counter

Figure 4: Counter CodeIn the final project instructions, one of the tasks that we accomplished was to make sure the door did not stay open longer than three minutes; however, there was no input port given that we could relate back to check whether the door is open or close. We then made an assumption that if the elevator stays at a certain floor for more than three minutes, the door has been open the entire time starting from when the elevator reaches that floor. In the case when the elevator has been at a certain floor for more than three minutes, the door alert will go high. To accomplish this task, we kept track of the clock cycles, which we used in conjunction with the counter technique that we learned in previous homeworks. We registered an 8-bit Boolean to the counter to ensure that we covered at least 180 cycles. Our clock of 1MHz has one second for each period; therefore, we needed the total of 180 periods, which will equal three minutes. The counter will add one every time the clock goes from 0 to 1 (positive edge), which will track the time.

Counter Simulation:

Figure 5: Counter Simulation ResultWe can clearly see that the door alert goes high when the counter reaches 3 minutes or 180 seconds. The Figure 6 shows our simulation result: Point Where Door Alert Comes On

180sec = 3 minutes

Figure 6: Door Alert Simulation Result

Finite State Machine

Figure 7: Finite State Machine CodeOur main focus in this project was determining how to move the elevator among all of the 8 floors. During our team discussion, we realize that this elevator system works much like a finite state machine. For example, if the elevator wants to move from floor 0 to floor 7, it has to go up and pass every single floor until reach floor 7. We were instructed that at each floor a sensor was there telling the user which floor the elevator is currently on/currently passing; therefore, we assumed each floor corresponds to a different state. Currentflr < requestflr && weightsensor != 1In this case, we will constantly check for the requested floor and compare it with the current floor the elevator is on. If the request floor is larger than the current floor, this means that we have to move up while continuing to check for the current floor input and request floor input. The elevator will only compare if the weight sensor is low, which means the weight inside the elevator does not exceed 4500lb. Currentflr > requestflr && weightsensor != 1With basically the same scenario as described before, we will constantly check for the requested floor and compare it with the current floor the elevator is on. If the request floor is smaller than the current floor, it means that the elevator has to move down while checking for the current floor input and request floor input. The elevator will only compare if the weight sensor is low (which in this case it is). This means the weight inside the elevator does not exceed 4500lb. Currentflr == requestflr && weightsensor != 1In this case, we will compare the request floor with the current floor the elevator is on. When the current floor is equal to the requested floor, the request will be complete. Once the request is accomplished, the system will display a complete output. We have to keep in mind that this will only happen when the weight inside the elevator is under the maximum weight. Weightsensor == 1One last and very important scenario is when the weight exceeds 4500lb. In this case, the elevator will not do anything but alarm the user with the weight alert and stay at the current floor.

Elevator Test benchRegisters and WiresIn our process of developing a test bench, we have to create a timescale delay that allows the counter to reach 3 minutes. In addition, we want to make our results easy view, so we used the timescale of 100ms/100ms. If we had too small of a time scale, then the counter would take a very long time to reach 3 minutes in real time. Figure 8: Registers and Wires

InitializationBelow is our initialization for our test bench. In order to ensure that our elevator Verilog code is working correctly, we create a test for different scenarios that could possibly happen when the user operates the elevator.

Figure 9: Test Bench Initialization

Movement TestThis motion test verifies that the elevator move up and down upon user request. For example, if a user wants to go up to the 7th floor from the basement (floor 0). The elevator will begin to compare the current floor with the requested floor and move up to floor 1 meanwhile displaying the direction which the elevator is moving. Once the elevator has reached floor 1, the system will display floor1 and compare floor 1 with requested floor again. The system will repeat until the current floor is the same as the requested floor. The system will then display the current floor and issue a complete signal. The same concept will happen during the traveling down scenario. A result is shown below to demonstrate our test.

Figure 10: Elevator Movement Test BenchElevator constantly checking for current floor

Display complete when reached requested floor.

Figure 11: Elevator Movement Test Bench Simulation Result

Test Weight AlertTo ensure safety, the elevator will always check the sensor. In the case of the elevator weight exceeding 4500lb, the weight sensor will go high to let the system know that the maximum weight is exceeded. The elevator will then sound weight alert alarm and not move to its requested floor; it will say at its current floor.

Figure 12: Weight Alert Test Bench

Weight alert also goes high.Weight sensor went high.

Figure 13: Weight Alert Test Bench Simulation Result

Verilog SimulationIn order to assure this code is giving the correct outputs, we compared the outputs of each module to its expected outputs. In the end, we determined that each module was giving the correct output. Below is the waveform of the elevator module generated according to the test bench we developed:Door Alert goes high when reaching 3 minutes

Figure 14: Test Bench Simulation ResultVerilog Synthesis with RTL CompilationWith the Verilog code written and verified for correct output, we next had to design our circuit layout using RTL. To begin, we set up all of the files synthesized by using the terminal. The following topics were the basic flow of the design:1. Design in HDL ( Verilog file )2. RTL Compiler ( Verilog file --> Synthesized Verilog file ) 3. Encounter ( Synthesized Verilog file --> Layout )4. Cadencea. Layout Import ( Encounter --> CIW Import Stream)b. Netlist Import ( Synthesized Verilog file --> Verilog Import ) 5. LVS VerificationOnce we loaded the Verilog file for the Boolean function into the RTL Compiler, the following image resulted after the synthesis update.

Figure 15: Synthesized Verilog

Layout of Digital circuits with Encounter1. Running SoC EncounterIn the lab folder, we created a folder named encounter and then entered the encounter folder. we began Encounter by entering encounter in the command line. Figure 16 shows the GUI.

Figure 16: GUI

2. Importing Synthesized VerilogOnce Encounter was initiated, we imported our synthesized HDL description file. But first, we set the power nets for a later step by typing various commands in the encounter terminal.

3. FloorplanningThe Encounter GUI displayed an empty die and the information box in the bottom-right corner read Design is: In Memory. The next step was to specify a floorplan for the layout. Floorplanning is done to specify the dimensions of the layout and spacing between the core (or area where the standard cells are placed) and power/signal routing. We opened up the floorplanning options by clicking on the Floorplan menu and selecting Specify Floorplan. Figure 17 shows the floorplanning layout.

Figure 17: Floor Planning

4. Power PlanningIn this next section, we added power rings into floor rings. To connect supply voltages to the standard cells, power and ground need to be available on all sides of the die. Adding power rings and specifying global net connections do this.

Figure 18: Power Planning

5. PlacementNow we were ready to perform the placement. At the end, the cells used in the design were placed so that they didnt overlap and so that there was enough space for routing in between them. We selected the Place menu and then Standard Cells. In the main GUI window. We verified that the standard cells were placed by selecting the Physical View Icon in the upper-right. Figure 19 shows the result.

Figure 19: Placement

6. RoutingThe built-in routing options within Encounter can now be used to connect the supply nets and create interconnects between the standard cells. Power and ground routing is performed with the Special Route tool. This was found by selecting the Route menu and then Special Route. In the dialog box that appears, we unselected Block pins, Pad pins, and Pad rings. After clicking OK, we saw horizontal and/or vertical metal power routing added to the design (Fig 20). Once the power routing was complete, the remaining connections between standard cells and the die I/O were routed using the NanoRoute tool. Figure 21 shows the result.

Figure 20: Routing

Figure 21: NanoRouting

7. Filler CellsFiller cells were placed by selecting the Place menu and then Physical Cell -> Add Filler. The filler cells fill in blank regions in the core of the layout (Figure 22). These cells provide continuity for nwell layers and power rails between placed cells.

Figure 22: Filler Cells

8. VerificationBefore exporting the layout, we verified that there were not any geometric errors that occurred during placement or connectivity errors from routing. We verified by selecting Verify Geometry and Verify Connectivity in the Verify menu. Reports were then generated. Please see the following figures for verification.

Figure 23: Geometric Verification

Figure 24: Connectivity Verification

9. GDS Export of Layout from EncounterOnce the layout was complete in Encounter (post-routing and post-filler cells), we then performed an export of the layout.

10. GDS Import of Layout into VirtuosoAfter creating a layout in Encounter and creating the GDS file, we opened Virtuoso. We clicked on the CIW (Virtuoso window where errors and messages appear) and clicked File -> Import - > Stream. We translated the file to import the design. As you can see in Figure 25, only a few warnings were given. The layout in Virtuoso is shown in Figure 26. The LVS was then ran.

Figure 25: Translate

Figure 26: Final LayoutDebouncing CircuitThe debouncing circuit on any critical input is a great technique to eliminate the interpretation of multiple input signals. For example, anytime a switch is opened or closed, there is some chance that multiple opening and closing will be counted; however, for our elevator controller system the debouncing circuit is not necessary because as long as input signals are given, the system will compare and respond to each particular task at hand. ConclusionThis project was extremely fun to work on because we were able to design a circuit that can be extremely useful in the elevator industry. Throughout the process we ran into various problems that took us a while to develop solution for; however, once we overcame each problem we learned a way to solve that problem for future reference. This project helps us understand much more about Hardware Description Languages in the working environment. As soon as we started the analyzing process, we found that there were many problems that were never clarified in the introduction. To finish the given task, we developed our own understanding and assumptions of the problem and ways to solve it. Ultimately, our design satisfied all the required functions. Our Verilog simulation was identical to the theoretical result, and finally our layout passed the DRC. Overall, we really enjoyed this project and are quickly realizing what it is like to be an electrical engineer.