------------------------------------------------------------------------------------------------------------ Team: Adegoke Adediran Neil Sarkar Stephanie Maryon DVoiceR Digital Voice Recorder ------------------------------------------------------------------------------------------------------------Table of Contents 1 Introduction 2 Design Components 2.1 Audio Codec 2.2 SRAM 2.3 User Interface 3 Conclusion 3.1 Further Developments 3.2 Lessons Learned 4 Appendix: Code1 Introduction Our project is a digital voice recorder. The voice recorder is accessed with a user interface through a CPU. The user interface digitally records and playbacks sound, specifically a voice, on one of two chosen tracks for about sixteen seconds via a microphone, speakers, and the board. The microphone is connected to the int0 pin on the board and used to record audio data to the XESS board. A user can then play back one of their recordings and listen to it through a speaker connected to the RCA jack. The components used on the board are the Xilinx Spartan-IIE 1.8V FPGA, the AKM AK4565, the Toshiba TC55V16256J 256k X 16 SRAM, and the OPB bus. 2 Design Components 2.1 Audio Codec: AKM AK4565: The AKM AK4565 is an audio codec which enables us to connect a microphone and speakers to our system. The audio codec had built in analog to digital and digital to analog converter, so we use it to accept an analog signal from the microphone in order to store the bits in a FIFO, or to receive a digital stream of bits from the CPU, which are stored in a FIFO and send the converted analog signal out through speakers. The Intr0 pin is used to connect the microphone to the codec and the Out outputs to connect the speakers. Fig 1. FPGA connection to the Audio Codec The audio codec uses three clocks to coordinate its system, a master clock, a clock for audio serial data, and a channel clock. We made two FIFOs, two shift registers, input and output registers, and a finite state machine for the codec. We used counters to implement the clocks. Data is put into or taken out of the FIFOs by the codec every channel clock event that is being read or written to by the OPB bus. The shift registers shift every serial data clock event.One of the challenges of implementing our codec was synchronization between the OPB bus and the codec. Our first idea was to use BRAMs to interface the data between the OPB bus and the codec. We were able to send data back and forth, but the data was random. This was because the addresses of the BRAM were not synchronized. We could not figure out a proper coordination scheme. Then we were thinking about using a polling system to locate the instance the data was ready to be either read or written. This seemed too simple and slow for the system that we wanted to design, so we decided to use FIFOs. This eliminated the address problem of the BRAMs while keeping the speed of our system up by using a memory interface between the OPB bus and the codec. Fig 2. Audio Codec Datapath The datapath of the codec is shown above. Either a read or a write an analog input signal comes from the source and is converted to a digital signal. The digital signal goes into a shift register to form a 16-bit data value. The data value is put into a FIFO and waits for retrieval from the OPB bus. The codec receives control from the finite state machine telling it to either write or read a value from the FIFO. The rightmost multiplexor is used to poll the codec to find out if the FIFOs have data if the OPB bus wants to read data and record a value, or if the FIFOs are not full so that data can be written and played back through the audio codec. The finite state machine is shown below in figure 3. The cuss signal is a chip select determined by the top 16-bits of theOPB_ABus and the OPB_Select signal. The address of the codec is 0xFEFE0000 for writing and reading, and is 0xFEFE0004 for polling. Fig 3. Audio Codec Finite State Machine 2.2 The Toshiba TC55V16256J 256k X 16 SRAM: The SRAM is used to hold the samples we feed into the codec from the microphone. It is organized as a 262,144 by 16-bit array of memory blocks. Each sample received from the codec 16 bits long. Therefore our memory will be able to hold 262,144 samples. We chose to design our system based on an 8 KHz sample rate. Every second 96,000 samples are stored in memory by the codec. (We are sampling from both the left and the right channels). If we write one out of every eight samples to memory, we will achieve our sample rate of 8 KHz. This will allow us to store a total of approximately 16 seconds. Our SRAM is divided into two tracks in our user implementation file. Each track allows the user to store an 8 second long audio clip. The basic signals used to instantiate the SRAM are shown in figure 4. Fig 4: FPGA connection to the SRAMThe datapath of our SRAM is shown below. It includes multiple input and output registers, a finite state machine, and an input output buffering system as the data wires to the SRAM are both inputs and outputs. A request is sent by the OPB bus to either read or write to the SRAM. The finite state machine sees the request and sends the proper controls to the SRAM which tell it to read or write data. The cs signal, which is the chip select is implemented in the same way respectively as it in the codec. The chip is selected when OBP_Select is high and when the address of the SRAM is selected, which means that the top twelve bits of the OPB_ABus will be high. The SRAM addresses start at 0xFFF00000 and continue to 0xFFF3FFFF. The finite state machine moves out of idle, it moves into a common mode which is not dependent on reading or writing. If the access is a read the SRAM reads the codec and transmits it in the xmit state. If the access is a write, the SRAM can just move into the xmit state and transfer the data to be written. Fig 5. SRAM DatapathFig 6. SRAM Finite State Machine Once we were successfully reading and writing data, we started thinking about file system implementation. With the size of the files, our original idea of a primitive, variable length file system seemed unnecessary, as a user would realistically only want about 5 files, as there is only 32 seconds of audio to divide amongst the files. Originally, we tried to implement a four file system, but there were some memory issues with the SRAM, so we defaulted to
View Full Document