ECE532 Digital Systems Design Winter 2010 Human Pong Design Report Chris Langan Kevin Lam Nancy Chong Group Report 0 Table of Contents 1 Overview 2 1 1 Project Background 2 1 3 Block Diagram 2 1 4 Description of IP 2 2 Outcome 4 2 1 Initial Concept 4 2 2 Final Design 4 2 3 Improvements for Future Attempts and Continuation 4 3 Block Descriptions 5 3 1 MicroBlaze 5 3 1 2 FSM 5 3 1 1 Video Output Ball Drawing 5 3 1 3 Music Control 6 3 2 MPMC 6 3 3 XPS TFT 6 3 4 Video to RAM 6 3 5 IIC Interface 6 3 6 Paddle Locator 6 3 7 Tone Generator 6 4 Appendix 7 4 1 Zip File Directory 7 4 2 References 7 1 1 Overview 1 1 Project Background Pong is an early arcade games that most people are still familiar with It is a simple game where there are two vertical paddles on either side of the game area and a ball bouncing between the two sides It could be thought of as a very simple tennis or ping pong game Our group objective is to build a Human Pong game on an FPGA board Xilinx Virtex II Pro XC2VP30 with the Digilent VDEC1 Video Decoder Our concept for human pong is heavily based on the original game Instead of using controllers however two human players will use physical paddles that will be detected by the hardware The ball will be projected onto a wall between the two users 1 2 Goals Design a two player human pong game where the players will be able to interact physically with the objects in the game The system will be able to detect physical paddles of distinctive colours based on video input then output the location of the ball and determine where the ball will move next As part of the design music will be played at the start and end of the game 2 1 3 Block Diagram Control Flow Diagram 3 System Diagram 1 4 Description of IP This section provides an overview of the components as appearing in the Control Flow Diagram Further details on the blocks in the System Diagram can be found in section 3 Video Decoder Digitizes video signal from camera storing frames in memory Memory Controller Provides access to memory from multiple sources Needs 2 write ports for the Video Decoder and Ball Drawing modules 2 read ports for the Paddle Locator and VGA output Paddle Location Identifier Finds endpoint coordinates for paddles based on digitized video frames in memory Custom module implemented in hardware Game Controller FSM for controlling overall game operations Contains game state including ball position velocity etc to identify collisions between ball and paddle and react accordingly 4 Audio Output Hardware input interface consists of an edge triggered go signal a done signal and data buses for tone frequency and duration Hardware module used to provide audible response to paddle ball collisions and other game sounds Communicates directly with the audio codec hardware Ball Drawing Generates video frames in memory for output to VGA via the XPS TFT The ball drawing is performed in software and receives ball position from the FSM When called the function erases the old ball and draws a new ball at the current position VGA Output Reads generated frames stored in memory from Ball Drawing module outputs to projector This is handled by the XPS TFT core 5 2 Outcome 2 1 Initial Concept The initial concept for the game was to use a projector and camera to create a game that allows players to interact physically with game objects From the block diagram in Section 1 3 we expected the following components to be readily available from code libraries or previous projects Video Decoder Memory Controller Audio Output VGA Output The rest of the components would be designed and implemented by ourselves as custom hardware or software with varying levels of expected difficulty In particular we identified a few key points of highest uncertainty Video processing speed Accuracy of colour detection Method of drawing game frames to video memory We were uncertain about the complexity required to implement the paddle location algorithm in hardware Therefore the speed of video processing was a major concern since performing this feature on full resolution video frames in software would most likely be prohibitively slow requiring a processing rate of 9 2 million pixels per second 640x480x30 frames per second to run at full speed With regard to colour detection accuracy there were two primary concerns the uniqueness of the paddles colour with respect to each other the background and players skin and clothing and variation in lighting conditions causing pre calibrated colour values to become invalid In particular when using a RGB colour representation colour values are extremely sensitive to brightness shifts caused by ambient lighting changes cloud passing by outside and angle of reflection of the detected object The method of drawing the game to video memory was subject primarily to difficulty of implementation in hardware and running speed if implemented in software If implemented in hardware a significantly complex engine would need to be built to output different shapes colours in the correct locations but software implementations would potentially suffer from the same speed issues as video processing 2 2 Final Result The final design of the game uses a digital camera for input and a projector to output video frames A border is projected on a blackboard in order to provide a frame of reference for players and the camera 6 is carefully aligned during set up to match the captured image s boundaries to the projected border The players controls are two distinctly coloured strips of fluorescent cardboard which can be held at any position angle within the playing field in order to reflect the path of the ball Initially either player is able to hit the ball however after the first hit players must alternate hitting the ball and the game ends when the ball leaves the left or right edge of the playing field As expected the Video Decoder Memory Controller and VGA Output modules were taken from libraries previous projects more details on specific components in Section 3 However no audio module was found that suited our purpose of asynchronously generating a tone of specified frequency and duration Thus the audio module was created by adding custom tone generation logic to an existing core that handles the interface to the on board audio codec Initially for ease of implementation the paddle detection was done in software This allowed us to finetune our detection algorithm and focus on fully developing other features of the game However as