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

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

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

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

5. 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

6. 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

7. 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

8. 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

9. 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

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

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

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

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

14. 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

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

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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

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

24. 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

25. 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

26. 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

27. 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

28. 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

29. 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

30. 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

31. 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

32. 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

33. 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

34. 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

35. 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

36. 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

37. 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

38. 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

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