Lunar Lander

1. Introduction

In this lab a classic video game of Lunar Lander is implemented on Altera DE2 development board. The objective of the game is to successfully land the lunar lander on a level spot on the lunar surface with very low horizontal and vertical velocities. The lander will crash if either of these velocities are beyond the prescribed values. The lander needs to be successfully landed before the timer runs out or the fuel is exhausted. The game ends if either the lander crashes or successfully lands.

The orientation of the lander and its velocities are controlled by three switches one each for left rotation, right rotation and thrust. The video of the lunar lander game is displayed on the VGA monitor. Once the game ends, an audio will be generated and played through the speaker. The audio generated will be a crash sound if the lander crashes else it’ll generate a nice tone upon successful landing.

Lunar Lander Screen Shot

Lunar Lander Screen Shot

2. RTL Schematics and State Machine Diagram

The complete RTL schematic of the whole system is shown below.

Lunar Lander RTL Schematics of Video System

Lunar Lander RTL Schematics of Video System

The Video System module is generated using the SOPC builder. The RTL schematic for the same is shown below.

Lunar Lander RTL Schematics of Complete System

Lunar Lander RTL Schematics of Complete System

3.    Design and Testing Methods

In this section, the design of both hardware and software is explained along with the testing methodologies for both hardware and software.

3.1. Hardware Design and Testing

As can be seen from Lunar Lander RTL schematics of the complete system, the Lunar Lander system hardware design comprised of following modules.

3.1.1. Reset delay

The Reset delay module receives the 50 MHz clock as input and generates the reset signal for the VGA Audio PLL. This module is heavily used in many examples and has a very simple implementation and is known to work correctly. Thus this module did not need testing.

3.1.2. VGA Audio PLL

The VGA Audio PLL generates a clock for the Audio DAC ADC module. This module takes the on‑board 27MHz clock signal as the input to generate the required 18MHz clock for the audio. This module is generated from the Mega wizard utility from the Quartus II software. This module is well tested and used heavily in many examples. Thus this module is known to work fine and did not require testing.

3.1.3. Video System

The biggest module in the whole design of Lunar Lander system is Video System module. This module is generated from the SOPC builder within Quartus II software. The Video System performs two major functionalities. First, it instantiates a NIOS II/e CPU along with On Chip Instruction Memory that stores the C program for the Lunar Lander execution. Second, this module instantiates character and pixel buffers and then blends them together and feeds it to the VGA Controller to generate the required Video for the VGA display.

This module was borrowed from one of the examples from the Quartus II software example package and tested for correct functionality by porting it on the board and executing the C program. Once this module was tested and verified for the correct behaviour, the same was enhanced with additional components as required for the Lunar Lander system implementation. The RTL schematics for the Video System is shown in Figure 2. The various sub modules within the Video System are explained below. NIOS II/e CPU

This is an economy version of the NIOS II processor. This is a 32 bit RISC processor that uses 600-700 Logic Elements and two M4K blocks internal memory. The Reset and Exception vectors are initialized at memory locations 0x84000 and 0x84020 respectively. On-Chip Memory

The On-Chip Memory is a M4K block based memory used to store the instructions compiled from the C program that controls the Lunar Lander game flow. The memory implemented is 32 bit data width RAM with total of 16KB memory size. Pixel Buffer

This is a SRAM memory used to store the 640 X 480 image of the Video Game Screen. This is a standard module instantiated from the SOPC builder. This memory is used a pixel buffer for the video out. Pixel Buffer DMA

This is a DMA controller for a pixel buffer for the DE series board. This is also a standard module instantiated from the SOPC Builder. This module is configured for frame resolution of 640 X 480 and for 8-bit RGB Color Space Pixel format. Pixel RGB Resampler

This is a RGB resampler for the DE Series boards configured for 8 bit RGB incoming format and 30  bit RGB Outgoing format. Character Buffer

This module is a buffer for ASCII characters to be displayed on the VGA/LCD Screen. This module is also instantiated from the SOPC Builder. This module is connected to the On-board VGA DAC for the video output. Alpha Blender

This is the alpha blender module from Quartus SOPC Builder. It takes in two video streams one from the character buffer and another from the Pixel RGB Resampler, blends them and sends out the stream as one which contains both streams overlapped over one another. The Pixel buffer is in the background and character buffer in the foreground of the blended image. This module is operated in the Normal Mode. Dual Clock FIFO

This is a Dual Clock FIFO for the DE series boards instantiated from the SOPC Builder. This module is configured with 10 color bits and 3 color frames. VGA Controller

This is a VGA controller module for the DE series boards from the Altera Quartus software instantiated from the SOPC Builder. This module is connected to the VGA Connector on the DE2 board.

3.1.4. FM decay

This module generates the modulation for the main oscillator. The modulator frequency is set differently for winning and losing audios. For the winning audio generation, the modulator frequency is set with 440 Hz tone while for losing audio generation the upper 14 bits of the switches SW[17:4] are read to set the modulator frequency.

3.1.5. FM Depth

This module reads lower 4 bits from the switches SW[3:0] and uses it set the modulator depth. This FM modulator depth is then fed to the sine FM decay module.

3.1.6. Sine FM decay

This module generates the FM modulated main sine wave to generate the sine decayed FM modulated audio output.

3.1.7. Audio DAC ADC

This module receives the two modulated audio waves in quadrature one each from FM module and other from

3.2. Software Design and Testing

One all the required hardware modules were instantiated, they were tested by drawing the basic boundary for the video game. The boundary were displayed without any hustle confirming the correct implementation of the hardware. Then the software was developed to draw the Lunar surface structure. Once the boundary and lunar surface were ready, the software is designed to develop the Lunar Lander game and display the same on the VGA Monitor. The flow chart for the software design is shown below.

Lunar Lander Flow chart

Lunar Lander Flow chart

The execution starts with testing for whether the lunar lander is within the boundary. If the lunar lander goes beyond the boundary, the program verifies if the lander has landed successfully or not by verifying that the lander inclination and velocities are within the normal range and prints appropriate messages while playing either victory or crash sounds through the speaker.

On the other hand, if the lander is still within the boundary, it checks if the VGA Vertical Sync (VS) has gone low. The program updates the lander position and draws the lander at the new position once per frame when the VGA VS is low. Since there are 60 frames per second, this fact is made use of to determine the timer value. A counter is defined which counts frames and updates the timer once every 60th frame.

During each frame, after the counter is updated, the program checks if the keys are enabled. If so, it reads the key inputs from the user and updates the lander inclination, thrust, and fuel. Based on the remaining fuel, it lights the LEDs to indicate the remaining fuel to the user. The keys will be disabled upon the timer expiry or if the fuel exhausts. Then it erases the previous position of the lander, calculates the new position and redraws the lander at the new position. Once it has redrawn the lander, it checks if the lander has crashed on a inclined region within the boundary. If the lander has crashed, it breaks out of the loop and proceeds as stated earlier else it’ll loop back for the next cycle of VGA_VS low.

4. Results

All the requirements for this lab are met. The timer was counted down every second and displayed on the VGA screen. The fuel gauge was displayed on the LEDs on the Altera DE2 board.

The lander was launched with initial horizontal and vertical velocities of 1 pixel per frame. The constant acceleration in the vertical direction was enforced on the lander due to gravity with acceleration of 10 pixels per squared frame. The initial inclination of the lander was 5 degrees with respect to the vertical axis inclined towards the origin while moving away from the origin in the positive x direction. These values were chosen for the initial conditions by trial and error method for a good visual display.

The user controls are provided by means of Keys on DE2 board one each for left rotation, right rotation and thrust. The maximum permissible values for inclination and velocities for successful landing are +/-15 degrees and 3 pixels per frame respectively. These values were also chosen upon trial and error method for easier successful landing. Upon the game over irrespective of win or lose, the user can reset the game by pressing Key 0.

5. Documentation

The motion of the lunar lander is modelled by various parameters such as the velocities and accelerations in both horizontal and vertical directions. As such, to calculate the new position of the lunar lander, the model needed to relate acceleration, velocity and position. Keeping in mind that the video coordinate system has X axis increasing to the right and Y axis increasing downwards, the various mathematical equations that governs acceleration, velocity and position are developed. If θ is the angle of inclination of the lunar lander with respect to the vertical axis, the various equations are developed as shown below.

ax=-thrust*sin(θ)                            and                        ay=g-thrust*cos(θ)

vx(t+dt)=vx(t)+ax*dt                     and                        vy(t+dt)=vy+ay*dt

x(t+dt)=x(t)+vx*dt                         and                        y(t+dt)=y(t)+vy*dt


ax, ay    – acceleration in x and y axis,

vx, vy    – velocity in x and y axis

x, y         – coordinates of the lunar lander

These equations were further simplified by assuming (dt = 1) since the parameters are calculated once per each frame. The simplified equation looks as shown below.

x(t+dt)=x(t)+ vx(t) -thrust*sin(θ)                             and        y(t+dt)=y(t)+vy g-thrust*cos(θ)

6. The arithmetic system used

The above arithmetic calculations requires lot of floating point computations. There are two options for the arithmetic system that could be used to perform floating point computations namely fixed notation and floating point system. The floating point computation required special module which enables floating point computations. However, computations in floating point notations is slower. As such, the program made use of the fixed point notations. The values were converted to fixed point notations before computation. Then the values were used to compute the acceleration, velocity and position parameters. Once these parameters are computed, the values were converted back before drawing the lunar lander at the new location. To convert the floating point values to the fixed notation, the values were left shifted by 8 bits and to revert back the values were right shifted by 8 bits.


The major objective of this lab was to give exposure to the CPU on FPGA. There were two options for CPU that could be used namely NIOS II or Pancake. The biggest task in this lab was to learn the CPU, instantiate it in the hardware and make use of it to develop the lunar lander application. Both CPUs had different set of challenges. While the NIOS II processor was a classic 32 bit RISC processor, the challenge with NIOS processor was in learning the Quartus tool, SOPC builder to instantiate the required processor and Altera Monitor or the NIOS IDE to develop the lunar lander application. On the other hand, Pancake Processor was a stack based processor and had a completely different set of instructions. The biggest challenge here was to understand the functioning of the stack based Pancake processor along with its assembly instruction to code for the lunar lander application. Both CPUs had its own pros and cons.

Categories: Embedded Systems Design | Tags: , , , | Leave a comment

Post navigation

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Blog at

%d bloggers like this: