17
Universidade de Coimbra Faculdade de Ciências e Tecnologia Departamento de Engenharia Electrotécnica e de Computadores Digital Systems Design – 2014/2015 Final Report Altera De2 maze game using CMPS10 sensors André de Jesus Gradil 2009107891 Tiago Filipe Rodrigues Catarino 2009119637 1

2.2.2 Memory Module

  • Upload
    vanbao

  • View
    245

  • Download
    1

Embed Size (px)

Citation preview

Page 1: 2.2.2 Memory Module

Universidade de CoimbraFaculdade de Ciências e Tecnologia

Departamento de Engenharia Electrotécnica e de Computadores

Digital Systems Design – 2014/2015

Final ReportAltera De2 maze game using CMPS10 sensors

André de Jesus Gradil2009107891

Tiago Filipe Rodrigues Catarino2009119637

1

Page 2: 2.2.2 Memory Module

Índice1 Introduction 3

2 Main Architecture 42.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 RTL Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.1 Display Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.2 Memory Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.3 I2C Communication Module . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.4 Game Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Implementation Details and Results 113.1 Communication problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2 Lack of memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.3 Sphere velocity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.4 Sphere representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.5 Extra Hardware Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4 Conclusion 14

5 Appendix 155.1 Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155.2 Appendix B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

6 References 17

2

Page 3: 2.2.2 Memory Module

1 IntroductionThe base objective for this project is to create a version of a popular game in mobile platforms

and run it with an Altera FPGA using an inertial sensor as game controller. The game we aretrying to emulate in the Altera FPGA consists in a maze with a sphere inside, the objective is totilt the maze in order to make the sphere roll throughout the paths of the maze using intuitivecontrols. Our approach on this problems consists in one Altera FPGA, connected to a CMPS10sensor, the communication protocol will be I2C with the FPGA as the Master and the sensorsthe slaves and the physical connection will be made in the FPGA’s expansion port GPIO_0 . Bymeasuring the output of the sensors we can program the physics of the game emulating the motionas if we are holding the maze with our hands.

3

Page 4: 2.2.2 Memory Module

2 Main ArchitectureThe architecture of this project consists in two main components, Hardware and RTL (Register-

transfer level) description. In the Hardware part of it we will have, as said before, an Altera CycloneII FPGA board as the processing unit, a VGA CRT display with 640 by 480 resolution as thedisplay unit, and a prototyping board with a CMPS10 inertial sensor (with the proper conditioningcircuit and switches) as the control unit for the project. In the RTL description we will be usingQUARTUS 9.1 IDE and programming using logic blocks and VHDL processes.

2.1 Hardware

As said in the previous item, the Hardware can be divided into three main components, theprocessing unit, the display unit and the control unit.

The control unit is a prototyping board with a CMPS10 inertial sensor, this sensor will give usthe values of pitch and roll in real time with a 170º range each (being 0º a stationary position in aflat surface and having approximately 85º range in both directions). This control unit communi-cates with the processing unit via I2C protocol using the FPGA GPIO_0 interface.

Figure 1: Prototyping board with a CMPS10 inertial sensor.

The processing unit as previously stated is an Altera Cyclone II FPGA board used in theDigital Systems Design classes, the only information this unit display is the direct value of pitchand roll from the sensor, both in the 7-segment display and in red LED lights, the 2 green LEDlights will be active with the SDA and SCL signals from the I2C comunication.

Figure 2: Altera Cyclone II FPGA board.

4

Page 5: 2.2.2 Memory Module

The display unit is a simple CRT display with 640 by 480 resolution, that will show the outputfrom processed data from the Altera, the display of the game itself. This CRT is connected withthe processing unit by a simple VGA cable.

(a) Start Screen in Display. (b) Game Engine in Display

Figure 3: CRT Display.

5

Page 6: 2.2.2 Memory Module

2.2 RTL Description

The programming aspect of this project was created/programmed in QUARTUS 9.1 IDE usingcombinational logic blocks, and VHDL files. In this report we are going to split our main blockdiagram file into several modules and explain them separately. The division will be made the fol-lowing way: "Basic Inputs", "Display Module", "Altera Display", "Memory Module","Game Engine"and "I2C Communication Module".

The basic inputs and Altera display modules are very simple so we are only explain them briefly.The first one consists in several key blocks like "VCC", "GND" and "CLOCK_50" that are declaredand assigned to named lines, this is not mandatory however it will reduce the visual complexity ofthe block diagram. The second one (Altera Display) consists in the visualisation of key data (thevalues given by the sensor) on 7-segment displays.

2.2.1 Display Module

This module has two components, the VGA_SYNC and a multiplexer. The multiplexer works asa selector, so it’s possible to iterate between the information coming from the CHAR_ROM(in gametext) and the information coming from the Memory Module(interface design). The VGA_SYNCblock receives the clock signal from the basic input module and the data from the multiplexer,with this information it will display in the VGA monitor the data from the game as well as providethe pixel_clk, pixel_rows and pixel_columns to the Game Engine.

Figure 4: Display Module.

6

Page 7: 2.2.2 Memory Module

2.2.2 Memory Module

In this module of the project we are using a single LPM_DP RAM block with 65536 word’s ofsize (the biggest RAM QUARTUS allows) and this memory receives both the ram_data and thewaddress from Game Engine Module. Unlike the previous version of the project, there is no needfor multiplexers in this module having in consideration that the selection of the address is madeinside the Game Engine Module.

Figure 5: Memory Module

7

Page 8: 2.2.2 Memory Module

2.2.3 I2C Communication Module

This module accepts as an input the 50MHz clock from the DE2 board and converts thisclock to a 400kHz signal needed for the I2C communication. At each cycle this module initiatescommunication with the CMPS10 according to the I2C protocol. The bit sequence for the I2Cprotocol will look like this:

Figure 6: I2C Communication Bit Sequence.

As outputs we have the SCL and SDA connections as well as the data from various register:compass, pitch angle, roll angle and the Z axis from the accelerometer.

Figure 7: I2C Communication Module.

This module was created by our colleagues from the previous year [7] and adapted to work withour implementation, in order to understand this communication we created a finite state machinewhich is present in the ’Appendix A’ section of this report.

8

Page 9: 2.2.2 Memory Module

2.2.4 Game Engine

This module was upgraded since the early development version. In the last version the GameEngine and Text Module were separated, now there is only one main block in the game engine.This block is the VHDL implementation of the finite state machine in the ’Appendix B’ section ofthis report.

This Finite State Machine has 6 States:

• State 0 - Main/Start Screen

This is the inicial state of the game, here we define the initial conditions of the programm, weuse the Char_ROM as an output to write the desired text in this screen. Using another process(with an input of 1Hz clock) parallel to the main one, we use a ’blink’ effect on the text "StartGame". To start the game it is necessary to press ’button 1’, we implemented some shortcuts usingthe Altera switches (SW[17..15]), changing the value given by these switches in binary (we can seethe value in the 7 segment display, ’HEX6’) allows to select the corresponding level.

• State 1 - Level 1

On the next four states we implemented the same game engine only varying small diferencesto give the player a sense of progression with multiple dificulties across four levels. We implementthe velocities, we draw the map and its collisions, the text (again using Char_ROM as output andthe parallel process to make the counter for the remaining time before losing), the ’win’ and ’lose’conditions and we update any needed control variables (sphere position, for example) and extra’flags’.

This first level is very simple with only two ways to leave this state, by reaching the appropriatearea to advance to ’Level 2’ or by letting the timer reach zero advancing to the ’Losing screen’.

• State 2 - Level 2

For the second level we use the same implementation as in the previous state, includingthe same map (we use exactly the same VHDL code, making it usable by these four states) andinclude some traps to make the game harder for the player. We draw some traps (which we call’mines’) on certain areas of the map and if the sphere touches these areas the state is changed tothe ’Losing screen’.

• State 3 - Level 3

This state is very similar to state 1, we only activate a flag which is used by another block(’SHOW_BALL’) to put the map all black except a small radius with the sphere as a centre togive the sensation of playing the game in the dark.

• State 4 - Level 4

This state is a compilation of the previous two levels where we implement both the minesand the black map. If the sphere reaches the end area a flag is activated, where upon returning tothe state 0 extra text is shown saying "You Won".

9

Page 10: 2.2.2 Memory Module

• State 5 - Losing Screen

This state is activated every time the player loses in the game, we draw a skull to representdefeat and again using the ’blink’ effect we show text "try again". Upon pressing the button twothe state changes to state 0.

Figure 8: Game Engine Module.

This block(GAME_ENGINE) receives all of the inputs(two buttons,the Altera switches SW[17..15],the Roll and Pitch values from the CMPS10, clocks, the rows and columns from the VGA_SYNC),computes them in the state machine and send them to both the Memory Module and theSHOW_BALL.

This separation of static data to the RAM and dynamic data to the SHOW_BALL block,reduces the memory consumption of the application because the SHOW_BALL shows in real timeon the screen instead of loading from memory. This block receives the current state from the block"Game_Engine" and uses this information to show on the vga a round sphere using a smaller scalethan the used for the rest of the game and the ’black map’ for state 3 and 4.

Figure 9: Show_Ball Module.

10

Page 11: 2.2.2 Memory Module

3 Implementation Details and Results

3.1 Communication problems

In this project, like in all projects, there were difficulties. The first difficulty found was relatedwith the I2C communication. The solution was the implementation of a FSM as said in thesubsection 2.2.3 ("I2C Communication Module") the result was a real-time communication.

3.2 Lack of memory

The next problem we encountered was a lack of memory (we were using 2 ram blocks, one fortext and another for the engine itself), this was a waste of memory that needed to be optimized.In order to optimize and organize our entire project, the Game Engine was described in a FSM (asshowed in the previous section), with this change we only used one memory block and were ableto continue creating levels and implementing features.

3.3 Sphere velocity

Considering the physiscs of a sphere rolling down an inclined plane, which is essencially theway the sphere travels in the game, we made an approximation of its behaviour.

Figure 10: Ball rolling down an inclined plane academic representation.

The system is closed, so energy must be conserved. We set the reference point for potentialenergy such that the ball starts at height of h. Initially the sphere is at rest, so at this instant itcontains only potential energy. When it has traveled the distance d along the ramp, it has onlykinetic energy (translational and rotational). Expressing h in terms of d, this gives us the squarevelocity after the particle moves the distance d.

For simulation purposes, we only vary the the angle of the plane considering the rest asconstantes so that we obtain the following graph:

Considering this graph we tried to implement on our project an exponential growth formulato simulate this behaviour but, as stated in the previous report, we encontered some dificulties

11

Page 12: 2.2.2 Memory Module

Figure 11: Velocity variation with plane angle.

in the use of non constante real variables to calculate the velocity. As a solution to this problemwe decide to implement a discrete aproximation of this curve, knowing that it will result in thedesired behaviour but not with the desired fluidity. We defined three velocities based on the angleof pitch and roll (+/- 85º at maximum tilt in either direction), resulting in the next graph:

Figure 12: Velocity discrete aproximation.

We took this approach and implemented it in VHDL, we only had to take into account therefresh of the screen, as we noticed that the sphere moved faster when going down or to the left.We simply added a delay in these directions to correct the movement.

We concluded that the final implemented physic of the game resembles closely the desiredfeeling of moving a sphere in a plane.

12

Page 13: 2.2.2 Memory Module

3.4 Sphere representation

The following problem in the project was a more aesthetic one, with the resolution chosen togive an retro game feeling we had difficulties in representing the sphere properly (it was a 3 by 3square in the first version), so to solve this and at the same time save memory a new block wascreated ("SHOW_BALL"). This block receives the position of the sphere, flags and clock, and therows and columns of the vga. With this information it shows directly, without putting the spherein the ram. For the sphere representation we used the following equation:

((px_row) − (posY ))2 + ((px_column)) − (posX)2 < 92

Being posY and posX the centre of the sphere and 9 the number of pixels in the desired radiusof the sphere.

3.5 Extra Hardware Implementation

As a final effort to implement a more realistic and entertaining application we tried to use anold lcd screen from a broken laptop as the vga monitor for our game. The idea was to make asimple and thin structure with the controller board attached to the lcd screen to play the game asif it was in our hands (like a tablet).

With that purpose in mind we ordered an universal LVDS controller based on MT6820 chip,we chose this kind of controller because it is extremely cheap, with small dimension, single supply5V and easy screen programming by jumpers, it also works with five keys interface with a nice’On-Screen Display’ menu. We tested this controller using the screen with its inverter board andusing simple bench power supply provided in most laboratories. We managed to build the fullcircuit and got the interface controller to work but not the screen itself.

We were unable to do any further testing as we were already nearly at the deadline to deliverthe project so we leave in this report the idea of such an implementation.

Figure 13: Universal LVDS controller based on MT6820 chip.

13

Page 14: 2.2.2 Memory Module

4 ConclusionWith the completion of this last phase of the project, we had a complete functional game that

explores the capabilities of an Altera Ciclone 2 FPGA board with a CMPS10 sensor. The resultingapplication uses the majority of the inputs and outputs of the FPGA (Switches, keys, leds, 7segment displays, VGA port and GPIO port). We supply a gameplay video that shows the finalproduct: "https://youtu.be/3n4hQ7E4WI4".

We were able to create several levels with unique player handicaps, and lose screen withanimations. This game can be improved with the creation of more levels/handicaps. The use of asecond CMPS10 sensor paired with the first one would give more precision in the control of theball.

14

Page 15: 2.2.2 Memory Module

5 Appendix

5.1 Appendix A

Figure 14: Finite State Machine of the I2C Communication Module.

15

Page 16: 2.2.2 Memory Module

5.2 Appendix B

Figure 15: Finite State Machine of the Game Engine.

Inputs:

• button_one (1 bit) (abbreviated to: ’b1’);• button_two (1 bit) (abbreviated to: ’b2’);• SW[17..15] (3bits);

Outputs:

• level (3 bits) - This variable represents which level is currently being shown in the vgadisplay;

Registers:

• time_counter (4 bits) (abbreviated to: ’tc’) - This variable is used to count time in seconds;• time_counter_10x (4 bits) (abbreviated to: ’tc10’) - This variable is used to count time

in dozens of seconds;• win (1 bit) - This variable represents the win condition of each level;• mine (1 bit) - This variable represents a way to die in the game (by touching a mine);

16

Page 17: 2.2.2 Memory Module

6 References[1] Frank Vahid. Digital Design, 2007. Ref: John Wiley and Sons.

[2] Frank Vahid. Introdução a VHDL, 2007. ’VHDL for Digital Design’ Ref: John Wiley and Sons.

[3] Altera Corporation. DE2 Development and Education Board - User Manual, version 1.4 edition,2006.

[4] Cmps10 – tilt compensated compass module. http://www.robot-electronics.co.uk/htm/cmps10doc.htm. Último acesso: 30-06-2015.

[5] Cmps10 – tilt compensated compass module– i2c mode. http://www.robot-electronics.co.uk/htm/cmps10i2c.htm. Último acesso: 30-06-2015.

[6] I2c tutorial – using the i2c bus. http://www.robot-electronics.co.uk/acatalog/I2C_Tutorial.html. Último acesso: 30-06-2015.

[7] Daniela Nobre e Elísio Sousa. Controlo de um aviao no ecra vga com um sensor cmps10.Relatorio de projecto de sistemas digitais, Departamento de Engenharia Electrotécnica e deComputadores, 2013/2014.

[8] James O. Hamblen and Michael D. Furman. Rapid Prototyping of Digital Systems, 2nd editionedition. Chapter 9, 10 and 11.

17