EECS150 Fall 2007 - Lab Lecture #10 Allen Lee Basic i50Phone EECS150 Fall 2007 - Lab Lecture #10 Allen Lee 11/2/2007 EECS150 Lab Lecture #10

Example MyTeam UsrName1 UsrName2 UsrName3 M S 10 11/2/2007 EECS150 Lab Lecture #10

Example MyTeam UsrName1 UsrName2 UsrName3 UsrName4 Dialing User: UsrName2 Cancel(B) M S 10 11/2/2007 EECS150 Lab Lecture #10

Example MyTeam UsrName1 UsrName2 UsrName3 UsrName4 Dialing User: UsrName2 Cancel(B) User Unavailable M S 10 11/2/2007 EECS150 Lab Lecture #10

Example MyTeam UsrName1 UsrName2 UsrName3 UsrName4 Dialing User: UsrName2 Cancel(B) User Unavailable Dialing User: UsrName3 Cancel(B) M S 10 11/2/2007 EECS150 Lab Lecture #10

Example MyTeam UsrName1 UsrName3 UsrName2 UsrName3 UsrName4 Dialing User: UsrName2 Cancel(B) User Unavailable Dialing User: UsrName3 Cancel(B) Connection Established M S 10 11/2/2007 EECS150 Lab Lecture #10

Example MyTeam UsrName3 UsrName2 UsrName3 UsrName4 Dialing User: UsrName2 Cancel(B) User Unavailable Dialing User: UsrName3 Cancel(B) Connection Established Connection Terminated M S 10 11/2/2007 EECS150 Lab Lecture #10

Example MyTeam UsrName2 UsrName3 UsrName4 Dialing User: UsrName2 Cancel(B) User Unavailable Dialing User: UsrName3 Cancel(B) Connection Established Connection Terminated M S 10 11/2/2007 EECS150 Lab Lecture #10

Example MyTeam UsrName2 UsrName3 UsrName4 User Unavailable Dialing User: UsrName3 Cancel(B) Connection Established Connection Terminated Call From: UsrName4 Acc(A)/Rej(B) M S 10 11/2/2007 EECS150 Lab Lecture #10

Example MyTeam UsrName4 UsrName2 UsrName3 UsrName4 Dialing User: UsrName3 Cancel(B) Connection Established Connection Terminated Call From: UsrName4 Acc(A)/Rej(B) Connection Established M S 10 11/2/2007 EECS150 Lab Lecture #10

Overview Introduction to Checkpoint 4 Adding to Checkpoint 1 Communications protocol Advice Extra Credit 11/2/2007 EECS150 Lab Lecture #10

Checkpoint 4 (Communications and Registry) Checkpoint 4 = Everything in this circle Checkpoint 4 (Communications and Registry) 11/2/2007 EECS150 Lab Lecture #10

Checkpoint 4 Additions 11/2/2007 EECS150 Lab Lecture #10

Adding to Checkpoint 1 Audio Buffer AC97 Controller Previously stored all audio data into one huge FIFO and local playback. Must now support sending and receiving audio data from transceiver. AC97 Controller Remains the same Volume and Mute signals now come from user input module in CP2. 11/2/2007 EECS150 Lab Lecture #10

Old Audio Buffer Data output from FIFO goes back to Audio controller: 11/2/2007 EECS150 Lab Lecture #10

New Audio Buffer Must now support sending and receiving from wireless transceiver: 11/2/2007 EECS150 Lab Lecture #10

Adding to Checkpoint 2 User Input Parser Keep track of a cursor position (0 through 7) for each of the top two regions. Only allow the cursor of a particular region to change when the focus is on that region. When the cursor is on a valid user in the Channel region, and “A” is pressed: Change the focus to the console. Send a call request, and wait for a response. Press “B” to cancel the request and change focus to Channel region. Ignore incoming calls while requesting a call. When a connection established or refused, change focus to Channel region. 11/2/2007 EECS150 Lab Lecture #10

Adding to Checkpoint 2 User Input Parser (cont’d) When the cursor is on a valid user in the “Connection” region, and “B” is pressed: Send a disconnect signal Focus remains in “Connection” region When there is an incoming call and you are not requesting a call: Change focus to console Press “A” to accept, or “B” to reject In either case, return focus to “Channel” 11/2/2007 EECS150 Lab Lecture #10

Adding to Checkpoint 2 Video Display Support a registry that stores up to 8 users in the channel and 8 connected users. New users may arrive in the Channel at any time. Support disconnecting from a connected user. Don’t worry about supporting more than 8 users. Remove users that timeout (more on this later). Store and display appropriate console messages (use RAM for this). Console must display up to 8 lines of 32 characters each. Once console fills up, each new message should push the oldest one out. 11/2/2007 EECS150 Lab Lecture #10

Announcements Checkpoint 3 is due in two weeks Week of 11/12 Checkpoint 4 is due in four weeks Week of 11/26 Checkpoint 4 design reviews next week. 11/2/2007 EECS150 Lab Lecture #10

Announcements Each group should have been assigned a channel during lab last week. Don’t continuously spam your channel. Another group is sharing your channel. Guaranteed your channel during your lab section. Channel assignments will be posted this weekend. 11/2/2007 EECS150 Lab Lecture #10

Announcements Clarification for Checkpoint 3 BigOut and BigIn should be 328 bits (41-bytes), not 320 bits (40-bytes). An updated version of the checkpoint has been uploaded. 11/2/2007 EECS150 Lab Lecture #10

Announcements Midterms have been graded Pick them up after lab lecture. 11/2/2007 EECS150 Lab Lecture #10

Communications Module Responsibilities Announce presence every 250 ms. Initiate a call with another station. Acknowledge a call request. Reject a call request. Receive audio data. 11/2/2007 EECS150 Lab Lecture #10

Packet Format The 41-byte payload from Checkpoint 3 belongs to the “application layer” 1-byte header 40-byte payload 11/2/2007 EECS150 Lab Lecture #10

Packet Format Header (8-bits) Type Payload (320-bits) 8’h0 Announce {256’h0, UserName} 8’h1 Init Call 8’h2 Accept Call 8’h3 Reject Call 8’h4 Ack Init 8’h5 Data Audio Data 8’h6 Ready 320’hX 11/2/2007 EECS150 Lab Lecture #10

Packet Types Announce Init Call Ack Init Accept Call Broadcast (0xFF) an announcement packet containing your user name every 250 ms. Init Call You want to initiate a call request to someone specific. Ack Init Acknowledge that you received an init call request, but neither accept nor reject. Accept Call Accept a call request 11/2/2007 EECS150 Lab Lecture #10

Packet Types Reject Call Data Ready Reject a call request Payload contains audio data Ready Acknowledge an accept call. Used to keep an active connection alive when no data is being sent. 11/2/2007 EECS150 Lab Lecture #10

Communications Behavior Sit idle and receive packets by default. Send an Announce packet every 250 ms. If received packet is an Announce packet, notify Video Display. If you initiate a call request, send an Init Call packet and wait for acknowledgement. Keep exchanging Init Call/Ack Init until one of the following happens Connection times out. Accept Call packet is received, establish chat. Reject Call packet is received, return to idle state. You press Cancel. No need to send Announce packets during Init Call/Ack Init exchange 11/2/2007 EECS150 Lab Lecture #10

Communications Behavior During a call, perform the following: Receive audio data and Ready packets. Reset timeout counter. Send audio data whenever it is ready. Receive Announce packets and notify Video Display. Optionally send Ready packets to keep the connection alive in the absence of audio data. Return to idle receive state if: Neither audio data nor Ready is received in 1 second. You manually disconnect the call. No need to send Announce packets during a call. 11/2/2007 EECS150 Lab Lecture #10

Populate Caller in Channel User List Communications Behavior Caller Receiver Caller UI Receiver UI ANNOUNCE . Populate Caller in Channel User List Populate Receiver in Channel User List Persist Caller in Persist Receiver in INIT_CALL Dialing User Receiver Incoming Call Caller ACK_INIT 11/2/2007 EECS150 Lab Lecture #10

Communications Behavior . ACCEPT_CALL Connection Established Populate Receiver in Call User List READY Populate Caller in DATA No Response Possible Timeout Connection Timed Out (Disconnect) Depends on direction of lost packets 11/2/2007 EECS150 Lab Lecture #10

Tips, Hints, & Common Pitfalls Start early If you’re already done with CP3, start designing now! We are not providing skeleton Verilog files Run the TA solution to see what the final result should look like. 11/2/2007 EECS150 Lab Lecture #10

Tips, Hints, & Common Pitfalls Split up the checkpoint to work in parallel with your partner: User input parser can be fully tested independently without Video Display or Communications. Video Display can be fully tested with a simple user input parser and no Communications. Communications module can be fully tested in ModelSim without the user input parser or video display. Do not combine until you’ve verified each part works independently. It can take up to 50 minutes to push to board after combining! 11/2/2007 EECS150 Lab Lecture #10

Tips, Hints, & Common Pitfalls Reset is unreliable if N64 controller is unplugged (unknown button status is returned). Even if N64 controller is plugged in, the user input parser may still enter an unpredictable state upon Reset. Output the current state of the parser somewhere and keep resetting until it enters the correct state. 11/2/2007 EECS150 Lab Lecture #10

Requirements Support persistent two-way communication between two stations. Need not be compatible with TA solution Single bit file Latency between speaking into microphone and hearing on remote station must be less than 1 second. 11/2/2007 EECS150 Lab Lecture #10

Extra Credit Maximum 20% Some Ideas (Exact % TBD): Text messaging Talk with more than 1 person simultaneously Audio effects (e.g. reverberations) Using the console region for a shared game (e.g. Pong, Tetris, Guitar Hero) Send video Record and playback a long conversation using SDRAM Ring tones Open-ended! Come up with something special, cool, clever, unique, and/or challenging. 11/2/2007 EECS150 Lab Lecture #10

Stay Tuned… The spec has not been finalized yet. It should be up by later tonight. There is enough information in these lecture slides to get you started. 11/2/2007 EECS150 Lab Lecture #10

Questions? 11/2/2007 EECS150 Lab Lecture #10