CS 150 CHECKPOINT 3

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

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

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

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

5. P5 – T1out (on MAX233) GND 1 2 3 4 5 6 7 8 9 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

6. start of tranmission end of tranmission start bit stop bit MSB LSB 17.36ms 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 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. transmit UART Transmitter serial out P37 8 data 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.

9. P37 GND VCC GND 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!

10. Video Interpreter mana[13:0] • This “DreamKatz” program draws the game screen on the computer monitor. • <demonstration> 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 • GO: 1000 0000 • D: 0,score[13:7] • D: 0,score[6:0]

15. Protocol (5) • Display a frame • GP: 1000 0010 • D0: 0, block0[6:0] • D1: 0, block1[6:0] • … • DN: 0, blockN[6:0] • … • D127: 0, block127[6:0] • D: 0, mana[13:7] • D: 0, mana[6:0] • D: 0, score[13:7] • 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 ACTIVE IDLE done

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…