1. Video Interface Jeffery Tsai Sammy Sy And pretty much everything else too…. CS 150 CHECKPOINT 3

2. The Project so far Controller Interface Audio Interface Video Interface Game Engine Controller Block Controller Interpreter FSM Memory Module UART Audio Module Video Encoder

3. Checkpoint 3 Overview UART Serial Connection Learn Sammy’s GUI Memory Module (16x8 RAM) Simplified Game Engine Integration with previous checkpoints

4. Overall State Machine Poll the controller like normal and update the game state. Update the video 4 times each second. start initialize idle process controller data update game state process events (play sounds) video output

5. Serial Cable Protocol Regular Serial Cable Only need 2 pins since we only care about sending data to the computer. Pin 2 is to transmit (to the computer) Pin 5 is ground Pin 3 is there, but NOT USED 12345 6789 P5 – T1 out (on MAX233) GND

6. RS232 Waveforms 8 bits of data, 1 start bit, 1 stop bit Wire is normally high, and this time, you MUST keep it high. Transmission rate = 57600bps start bit MSBLSB stop bit start of tranmission end of tranmission 17.36  s Time

7. 57,600bps?!?! You can’t get a 57.6kHz clock with a conventional clock divider. (16,000,000/57,600  278) Use the 16MHz clock, and pulse the output every 278 cycles. By the way…..remember to use BUFG’s for ALL your clocks!

8. UART Universal Asynchronous Receiver Transmitter. Since we don’t receive messages from the computer, only the transmitter is needed. Need a READY signal since it is critical that you try to send at the maximum rate. UART Transmitter 8 data transmit serial out P37

9. Maxim Transceiver Actual serial connection is inverted and is 12V. Maxim transceiver takes care of everything. BUT BE CAREFUL!!! DO NOT PLUG THE 12 VOLT END TO YOUR XILINX CHIP! VCC GND P37

10. Video Interpreter This “DreamKatz” program draws the game screen on the computer monitor. mana[13:0] score[13:0] console 16x8 array of blocks[6:0]

11. Protocol (1) Types of messages (all 1 byte wide) SYNC Game start (GS) Game over (GO) Game play (GP) DATA Data byte (D)

12. Protocol (2) Only 3 legal sequences, all preceded by a SYNC byte. Each sequence can be followed by another valid sequence. Display game start screen GS Display game over screen with final score GO, D, D Display a new frame (grids + mana + score) GP, D0, D1, D2, … D127, D, D, D, D Reminder : GS = game start GO = game over GP = game play D = data byte

13. Protocol (3) Physical representation in bits Game start = 1000 0001 Game over = 1000 0000 Game play = 1000 0010 Data = 0XXX XXXX note: 0 <= Data <= 127 1XXX XX11 is always illegal

14. Protocol (4) Display game start screen easy… just send GS byte Display game over screen and final score 1. GO: 1000 0000 2. D: 0,score[13:7] 3. D: 0,score[6:0]

15. Protocol (5) Display a frame 1. GP: 1000 0010 2. D0: 0, block0[6:0] 3. D1: 0, block1[6:0] 4. … 5. DN: 0, blockN[6:0] 6. … 7. D127: 0, block127[6:0] 8. D: 0, mana[13:7] 9. D: 0, mana[6:0] 10. D: 0, score[13:7] 11. D: 0, score[6:0] blockN[6:0] represents the type of image to display in the Nth block.

16. Protocol Example Let’s display a frame with all white blocks (white=000 0001), mana=7, score=128 GP: 1000 0010(game play) D0: 0000 0001 (block0 = white) D1: 0000 0001 (block1 = white) … D127: 0000 0001 (block127 = white) D: 0000 0000 (manaHi = 000 0000) D: 0000 0111 (manaLo = 000 0111) D: 0000 0001 (scoreHi = 000 0001) D: 0000 0000 (scoreLo = 000 0000)

17. Killer checkpoint => Hints The master FSM is complicated, but fortunately runs sequentially. Make sure you design it with Control and Datapath in mind. You might find pseudocode helpful for laying out the FSM’s and thus the control signals for the datapath. If pseudocode is good, datapath falls out naturally from it.

18. Pseudocode (1) MemoryModule GameState; // 16x8 RAM /* Rotate all bits of GameState to left/right once */ HandleLeftRight(bool left, bool right) { 8bitRegister tmp; for (I = 0; I < 16; I++) { tmp = GameState[I]; tmp = UniversalShiftRegister(tmp, left, right); GameState[I] = tmp; } /* Move all bits of GameState down once */ HandleDown() { 8bitRegister tmp; for (I = 15; I >= 1; I--) { // process backwards! tmp = GameState[I-1]; GameState[I] = tmp; } GameState[0] = 0000 0000; }

19. Pseudocode (2) /* encode GameState into frame update message sequence */ HandleEncode() { 8bitShiftRegister tmp; UART_Send(1000 0010); // sync game play byte for (I = 0; I < 16; I++) { tmp = GameState[I]; for (J = 0; J < 8; J++) { UART_SEND(0000 000,tmp[0]); // either white or black tmp = tmp >> 1; } UART_SEND(0,MANA[13:7]); UART_SEND(0,MANA[6:0]); UART_SEND(0,SCORE[13:7]); UART_SEND(0,SCORE[6:0]); }

20. Pseudocode (3) /* Main loop * ENCODE_LIMIT = period of video refresh * FALL_LIMIT = period of blocks falling */ HandleMain(bool left, bool right) { count = 0; while (1) { HandleLeftRight(left, right); // process left/right if (0 == (count % FALL_LIMIT)) { // process gravity HandleDown(); } if (0 == (count % ENCODE_LIMIT)) { // process video HandleEncode(); } count ++; }

21. I don’t understand this pseudocode thing... Each subroutine is a mini-FSM that has idle and active states. Calling a subroutine can be done by sending a start pulse. When the subroutine returns, it outputs a done pulse. start done IDLE ACTIVE

22. In Conclusion… Checkpoint 3 is really long. BUT…don’t forget your midterm next week. Good luck. Now Jeff and Sammy can go sleep…