UNIVERSITY OF CALIFORNIA AT BERKELEY COLLEGE OF ENGINEERING DEPARTMENT OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE ASSIGNED: DUE: Friday, October 31 th Friday, November 14 th, 2:10pm sharp Checkpoint 4 1.0 Motivation This checkpoint serves three purposes: 1. Glue previously designed components into a more complex system. 2. Provide experience designing a data path and a control specific to a given task. 3. Provide extensive experience in implementing a design from very little specification. By the end of this checkpoint, you will be able to stream audio through your SDRAM and display it on the TV screen as a waveform composed of discrete amplitudes. This will complete your video/audio sandbox, which you can use for the remainder of the project, and constitutes the bulk of the digital storage oscilloscope. 2.0 Introduction By this point in the project, you have (or are very close to having) loop-backed video moving from the Video Decoder to the Video Encoder. This constitutes basic loop-back. The Video Decoder features a sequential address counter that counts in a very similar fashion when compared to the Video Encoder, and the two count sequentially for all time. With basic loop-back under your belt, your next objective is to be able to control different types of Read/Write patterns so that what is read out of SDRAM does not necessary match what is currently being written into SDRAM. The medium featured in this checkpoint is PCM ( pulse code modulation ) audio data. As with checkpoint 3, data will be streamed into SDRAM on the Write side and read out on the Read side. Unlike checkpoint 3, the audio data written to SDRAM is not in {Y, Cr, Y, Cb} form. Thus, your first objective will be to find a way to massage the PCM audio data into a form that when read out of SDRAM will look like a waveform on the TV. It will be up to you to find a way to make this work. You know the interface to the SDRAM Arbiter and the Video Encoder. This document will discuss the exact format of the audio data that you should expect to be streamed into SDRAM. With this information, your task will be to fill in the blanks and transform the stream of audio data out of SDRAM into a clean waveform that can be interpreted by the Video Encoder. UCB Page 1
In addition to transforming audio data into a waveform that can be interpreted by the Video Encoder, you are also responsible for adding control logic that will manage reads and writes to SDRAM. Specifically, your control logic must allow you to: 1. Record the output of the audio source. 2. Display the recorded output to the screen in real time. 3. Pause the recording and pause the display. 4. Scroll forward and backwards, in time, through the saved waveform. By the end of checkpoint 4, your audio sub-system will look like something similar to what is shown below. You will be dealing primarily with the parts in red. Input from switches Record Some Control Logic Waveform scroll control data Address Generator Waveform Source Write Address Write Data Arbiter Read Address Read Data Something Read Address Read Data Video Encoder Mode Figure 1 Checkpoint 4 datapath and control Notice the Some Control Logic and Something clouds in the diagram. The Some Control Logic cloud coordinates the recording and time stepping functionality in the system. The Something cloud is what you will have to design and implement in order to transform the PCM audio data into a viewable waveform. 3.0 Prelab Please make sure to complete the prelab before you attend your lab section. You will not be able to finish this checkpoint in 3hrs! By this time, work might be starting to pile up. Stay on top of your game! 1. Read this handout thoroughly. a. Pay particular attention to section 4.0 Lab Procedure as it describes what you will be doing in detail. 2. There will be no Verilog given to you for this checkpoint. UCB Page 2
a. Use the FPGA_TOP2 that you have been using for checkpoints 2 and 3. b. The external audio source has been written by us (the staff) and will be released within several days. The audio source will feature the Ready/Valid interface for both addresses and data. If your SDRAM Arbiter follows the Ready/Valid interface, you should be able to connect the audio source directly to your Arbiter. 3. Start your design ahead of time. a. Begin with schematics and bubble-arc diagrams. i. You will be given very little pre-baked design for this checkpoint. ii. If you don t design first, you will likely have a very difficult time finishing this checkpoint. iii. Part of your final submission will be your design. See the check-off sheet at the end of this document for more information. 4.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. 4.1 PCM Audio A Waveform in Video Audio will be written into your SDRAM through either a waveform generator (similar to the VideoROM) or a live audio source (similar to the way Ethernet packets, that contained an audio payload, were delivered in Lab 6). Regardless of the source, audio is PCM-encoded. PCM stands for "pulse code modulation." In this case, PCM audio is encoded as a waveform in the time domain as a series of amplitudes. Our audio codec uses binary integers, not floating point numbers, to represent amplitudes in a waveform. For the purposes of this checkpoint, audio is structured as a stream of 32-bit samples. Each sample is a pair of 16-bit integers representing the sample amplitude for the right and left channels of audio. You are only required to display one of the two waveforms, but we encourage experimentation. If you only intend to display one of the two waveforms, you can choose which of the two. Regardless of your choice, however, your waveform generator should be able to tolerate the full range of 16-bit integers that can be passed through each word. The effective transformation between PCM audio data and a video waveform (not to scale) is shown below. UCB Page 3
1 3 5 1 3 5 1 4.2 Control Logic Figure 2 PCM Audio Data to a Waveform As was mentioned in section 2.0 Introduction, you will also be responsible for adding the following functionality to your audio subsystem: 1. Record the output of the audio source. 2. Display the recorded output to the screen in real time. 3. Pause the recording and pause the display. 4. Scroll forward and backwards, in time, through the saved waveform. All of the above can be added to your design through control logic, appropriate control signals, and appropriate address generation into both sides of the SDRAM Arbiter. You will be required to implement these pieces. The only piece of code that will be given to you is the Waveform Source. Note again that the source only outputs data, not addresses. You will be required to manage all address generation in this checkpoint. Some of the above requirements can be interpreted several ways. What we mean by recording the output of the audio source is merely that you should be able to store audio data in SDRAM from the audio source. Displaying the output of a recorded segment of audio necessitates knowing what addresses in SDRAM have valid audio data and being able to show a PCM data stream as a waveform on the screen. Pausing the audio stream requires you to be able to control the handshaking between the Arbiter and Waveform Source/Address Generator. Finally, scrolling backwards and forwards through a paused waveform mandates that you are able to control address offsets in your address counting schemes. Given that your TV can only display N audio samples at a time, this equates to the diagram shown below. UCB Page 4
Data at Read Address Data at Read Address + N Figure 3 Scrolling backwards and forwards through audio It is thus your task to control the Read Address from which the stream starts to read out data. 4.3 RAM.v Last week, you were introduced to FIFORAM as a FIFO implementation that uses the Ready/Valid interface. This week, we will introduce the workhorse behind FIFORAM, called RAM.v. RAM.v models a readable/writable memory can be used to store data in your design. In hardware, it may become LUT RAM or Block RAM, depending on how large a RAM you want to instantiate (controllable through parameters). Know that you can t instantiate a 256 MB RAM.v. There are not enough resources on the FPGA to accommodate that large of a memory. This is why we use SDRAM in addition to memory that can be instantiated directly in the FPGA fabric. The port specification for RAM.v is shown below. Signal Width Dir Description Clock NPorts I System clock signal Reset NPorts I Reset signal Enable NPorts I Enables or disables the RAM. Write NPorts I Equivalent to WriteEnable. Address AWidth*NPorts I The address in the RAM that you wish to write to or read from. DIn DWidth*NPorts I The data that you wish to write to RAM. DOut DWidth*NPorts O The data that is currently being read from RAM. Table 1 RAM.v port specification RAM.v uses a new notation that allows it to be parameterized by a variable number of read/write ports (this is what is going on with NPorts, which will be explained shortly). This is an extremely useful feature. If you, the user, wishes to have UCB Page 5
only one outside module read/write to a RAM.v during a single cycle, you can specify a single port. If you wish to have two or more modules talking to the RAM during a single cycle, you can specify that you want more ports. To find out more with regards to how this works, please see the parameter specification for RAM.v, shown below: Name Default Description DWidth 32 The width of data stored in this RAM. AWidth 4 The number of address bits used to index into this RAM. RLatency 0 Number of clock cycles between Address and DOut. This can be 0 for asynchronous read. WLatency 1 Number of clock cycles between Write and the change. Can be 0 for asynchronous write. NPorts 1 The number of ports that this RAM will support. Every signal gets its own set of ports. WriteMask Nports x 1 b1 A NPorts-bit wide signal, with a 1'b1 for each port which can write, and a 1'b0 for each port which cannot. Table 1 RAM.v parameter specification Now that you know what NPorts is, notice that each of RAM.v s ports is Nports x some factor wide. For each port that you allocate to RAM.v, you will concatenate wires together to represent the data into and out of each port. For example, should you want to instantiate a dual-port memory, your RAM.v instantiation would look something like what is shown below. wire wire [3:0] wire [31:0] WriteEnable; WriteAddress, ReadAddress; WriteData, OutRAMBlanking, OutRAMData; RAM dpram (.Clock( {Clock, Clock}),.Reset( {Reset, Reset}),.Write( {WriteEnable, 1'b0}),.Enable( 2'b11),.Address( {WriteAddress, ReadAddress}),.DIn( {WriteData, {DWidth{1 b0}}}),.dout( {OutRAMBlanking, OutRAMData})), defparam dpram.dwidth = 32; defparam dpram.awidth = 4; defparam dpram.rlatency = 1; defparam dpram.wlatency = 1; defparam dpram.nports = 2; defparam dpram.writemask = 2 b10; UCB Page 6
This RAM features two ports. The wires connected to the first port are designated in green. The wires connected to the second port are in red. The Clock signal is sent as the clock to each port. Reset is assigned to the reset port for each port. The first port can be written to (a WriteEnable signal is tied to that portion of the Write port). Nothing is ever written through the second port (its Write port is tied to 1 b0). Address and data is connected in a similar fashion. RAM.v is being given to you for a reason. Learning how to use it effectively will be a step forward in finishing this checkpoint. As a word of caution: make sure that your concatenated ports line up correctly. If your ports aren t lined up, RAM.v will deliver garbage. UCB Page 7
5.0 CHECKPOINT 4 CHECK-OFF ASSIGNED: Friday, October 31 th DUE: Friday, November 14 th, 2:10pm sharp Man Hours Total Points TA Initial Date Time Spent / 100 / / 08 NAME SID SECTION I Waveform matches TA source waveforms (25%) (same as playing back source in real time) II Special Features Record source audio (12.5%) Pause recording (12.5%) View paused recording (12.5%) Scroll through paused recording (12.5%) III Design Quality (25%) Procedure: In addition to submitting Verilog and.bit files for this checkpoint, you will submit your design to the TAs directly during lab lecture. Designs will be given full credit if a TA can sit down with your design and write working Verilog from it (thus, the designs should be just as detailed as designs reviewed during a design review). Unlike a design review design, your submitted designs must correspond to your final implementation. Furthermore, designs must be organized, self-explanatory, and only contain diagrams. Don t put random notes on scratch paper. If we can t implement your design with your submission, we can t give you a grade. Use your design review session as a draft session for this submission. As always, your design need not be perfect by the design review. RevA 10/31/08 Chris Fletcher, Ilia Lebedev Wrote new document. UCB Page 8