1.0 Introduction2.0 Prelab3.0 Lab Procedure3.1 AudioBuffer.v3.2 UserInputParser.vEECS150 Fall 2007 Checkpoint 4UNIVERSITY OF CALIFORNIA AT BERKELEYCOLLEGE OF ENGINEERINGDEPARTMENT OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCECHECKPOINT 4Basic i50Phone1.0 IntroductionThroughout the semester, you have been building the basic components needed for creating a wireless phone system. In Checkpoint 1, you designed the audio component, which reads audio input from a microphone and plays it back on your local speakers. In Checkpoint 2, you designed the display and user interface components. In Checkpoint 3, you designed a means of transferring generic data between two systems viawireless communications. In this checkpoint you will put all of these components together.The primary goal of this checkpoint is to define a communications protocol that allows two FPGAs to selectively exchange audio data. This goal involves several steps:1. Defining the application layer protocol, i.e. giving meaning to the 41-byte packets that are being exchanged.2. Designing a communications FSM that handles the handshaking between systems.3. Designing an intuitive user interface that allows you to connect with another station.2.0 PrelabThe region in the dotted red line shown in the figure below shows the componentsthat you will be adding in Checkpoint 4.UC Berkeley 1EECS150 Fall 2007 Checkpoint 4Figure 1: Checkpoint 4 AdditionsThis region encompasses the changes that you will need to make to the previous checkpoints, and the modules you will be adding:1. Checkpoint 1 – The audio buffer must allow sending and receiving audio data from the wireless transceiver.2. Registry – Users will be coming in and out of channels, and in and out of calls. A registry is need to keep track of who is connected.3. Checkpoint 2 a. The input parser must support the complete navigation of the phone system, and send appropriate messages to the communications module.b. The video display module must support reading a registry of users in the channel, a registry of connected users, and a console that displays messages.4. Communications – This module ties everything together and handles all of the handshaking between two stations, and within the local phone system.3.0 Lab Procedure Remember to manage your Verilog, projects and folders well. Doing a poor job of managing your files can cost you hours of rewriting code, if you accidentally delete your files.3.1 AudioBuffer.vThe audio buffer in Checkpoint 1, shown below, only supported local record and play back. This was implemented by using a large FIFO that stored 8 seconds of voice.Figure 2: Checkpoint 1 Audio BufferIn this checkpoint, such a large FIFO is unnecessary. Instead, you be changing the functionality to support sending to and receiving from a remote source. To do this, you will change the design of the audio buffer to look more like the figure below:UC Berkeley 2EECS150 Fall 2007 Checkpoint 4Figure 3: New Audio BufferThe large asynchronous FIFO in checkpoint 1 will be replaced by two small asynchronous FIFOs, a single synchronous fifo, and two shift registers. Note that both ofthe new FIFOs must remain asynchronous because they are crossing clock domains. For debugging the new audio buffer, you may choose to support a loopback mode, such that the microphone input is played back locally.Below is a port specification for the new audio buffer:Signal Width Dir DescriptionClock1 I The 27MHz clock signalReset1 I The reset signalAudioClock1 I The audio clock signalPCM_Request1 I Request from local AC97 controller for dataFromAudio32 I Audio data from local audio controllerFromAudioValid1 I Indicates that FromAudio is validToAudio32 O Audio data going to local audio controllerToAudioValid1 O Indicates that ToAudio is validFromWireless320 I Packet of audio data from transceiverFromWirelessValid1 I Indicates that FromWireless is validToWireless320 O Packet of audio data to be send to transceiverToWirelessValid1 O Indicates that ToWireless is validSelfLoop1 I Enable audio loopbackTable 1: Port Specification for New Audio Buffer.We have also provided a small synchronous FIFO (audio_fifo) for additional buffering. You will need to use this synchronous buffer to buffer data when you are receiving data from the wireless. When the prog_full (a signal that says when the buffer is partially full) signal goes high from the audio_fifo, you should have enough audio data to begin streaming it to the audio chip. If the fifo is every empty, you should wait to buffer audio until the prog_full signal comes high again. UC Berkeley 3EECS150 Fall 2007 Checkpoint 43.2 UserInputParser.vThis module will now be extended to support complete navigation of the phone system, including requesting to establish calls with users, accepting and rejecting calls, and changing the display appropriately. This module must keep track of two cursor positions: one for the users in the channel, and one for the users connected in a call. The input parser must support obey the following constraints:1. Only allow the cursor of a particular region to change when the focus ison that region.2. When the cursor is on a valid user in the Channel region and “A” is pressed:a. Change the focus to the consoleb. Send a call request and wait for a responsei. If “B” is pressed, cancel the request and change focus back to the Channel regionii. When a connection is either established or refused, change the focus to the Channel region.iii. Ignore incoming calls while requesting a call.3. When the cursor is on a valid user in the Connection region and “B” is pressed:a. Send a disconnect signalb. Focus remains in the same region4. When there is an incoming call, and you are not currently requesting a calla. Change the focus to the consoleb. If “A” is pressed, send “Accept Call” message and return focus to Channelc. If “B” is pressed, send “Reject Call” message and return focus to ChannelThe table below is a port specification for the new input parser module.Signal Width Dir DescriptionClock1 I The 27Mhz Clock signalReset1 I The Reset signal.(N64 Buttons)30 I Buttons from N64ButtonParser.vSpeakerVolume5 O Speaker volumeSpeakerMute1 O Speaker muteMicVolume5 O Mic volumeMicMute1 O Mic muteChannel4 O Wireless channel* (See note below)Focus2 O Region focusChanCursor3 O Position of the channel cursorConnCursor3 O Position of the connection cursorChanSelectValid1 I Indicates that the name that the
View Full Document
Unlocking...