You can build your 64Kx8 memory using the ISE tool's Architectural Wizard as outlined in lecture. This takes a while, so you may find it easier to use the mybram module included in lab4.v. In general, unless you need to load a memory with known values, making the appropriately parameterized instance of mybram will take less of your valuable design time!

module mybram #(parameter LOGSIZE=14, WIDTH=1)
              (input wire [LOGSIZE-1:0] addr,
               input wire clk,
               input wire [WIDTH-1:0] din,
               output reg [WIDTH-1:0] dout,
               input wire we);
   // let the tools infer the right number of BRAMs
   (* ram_style = "block" *)
   reg [WIDTH-1:0] mem[(1<<LOGSIZE)-1:0];
   always @(posedge clk) begin
     if (we) mem[addr] <= din;
     dout <= mem[addr];
   end
endmodule

// example use: make a 64K x 8 memory
mybram #(.LOGSIZE(16),.WIDTH(8))
       example(.addr(a),.clk(clock),.we(we),.din(mem_in),.dout(mem_out));

Record mode: When entering record mode, reset the memory address. When the ready input is asserted, a new sample from the microphone is available on the from_ac97_data[7:0] inputs at the rising edge of clock_27mhz. Store every eighth sample in the memory, incrementing the memory address after each write. You should also keep track of the highest memory address that's written. If you fill up memory, you should stop recording new samples.

Note: we're subsampling the incoming 48kHz data down to 6kHz. If the audio waveform has substantial energy above 3kHz, we'll get noticeable aliasing (spurious audio tones) in the subsample. To do this right we'd have to filter the data using a low-pass filter with a sharp cutoff at 3kHz before taking the subsample. We'll do this in Step 2!

Playback mode: When entering playback mode, reset the memory address. When the ready input is asserted, supply a 8-bit sample on the to_ac97_data[7:0] outputs and hold it there until the next sample is requested. For now, read a new sample from the memory every eight transitions of ready and send it to the AC97 eight times in a row (i.e., up-sample the 6kHz samples to 48kHz using simple replication). When you reach the last stored sample (compare the memory address to the highest memory address written which you saved in record mode), reset the address to 0 and continue -- this will loop through the saved data again and again.

Test your code. You'll hear lots of high frequency noise which was introduced by the down-sampling and reconstruction.

Step 2: Build and test low-pass filter

Replace the pass-through code of the fir31 module with code that actually implements a 31-tap low-pass filter. The filter calculation requires forming the following sum:

y = sum_{i from 0 to 30}(coeff[i] * sample[i])

where coeff[i] is supplied by the coeffs31 module and sample[i] is reaching into a buffer of recent samples. sample[0] is the current sample, sample[1] is the previous sample, sample[2] is the sample before that, etc.

This would be a lot of multiplies and adds if we tried to do the calculation all at once -- way too much hardware! Since our system clock (27MHz) is much faster than rate at which new samples arrive (48kHz) we have plenty of clock cycles to perform the necessary calculations over 31 cycles, using an accumulator to save the partial sum after each iteration.

Usually filter coefficients are real numbers in the range [-1,1] but realistically we can only build hardware to do integer arithmetic. So the coefficients have been scaled by 2**10 (i.e., multiplied by 1024) and rounded to integers. That means our result is also scaled by 2**10, so instead of the output y being the same magnitude as the input samples, 8 bits, it's 18 bits. So our accumulator should be 18 bits wide.

Conceptually, the 31-location sample memory shifts with every incoming sample to make room for the new data at sample[0]. But this sort of data shuffling would be tedious to implement, so instead let's use a circular buffer. That's a regular memory with an offset pointer that indicates where index 0 is located. When we get a new sample, we increment the offset and store the incoming data at the location it points to. Then sample[offset] is the current sample, sample[offset-1] is the previous sample, sample[offset-2] is the sample before that, etc. If we choose the sample memory size to be a power of 2, then we can just perform the index arithmetic modulo the memory size and everything will work out correctly. So now the formula becomes:

y = sum_{i from 0 to 30}(coeff[i] * sample[offset-i])

Here's what the module needs to do:

• When ready is asserted, increment the offset and store the incoming data at sample[offset]. Set both the accumulator and index to 0.

• Over the next 31 system clock cycles (@ 27MHz) compute coeff[index] * sample[offset-index], add the result to the accumulator, and increment the index. Remember to declare coeff and the sample memory as signed so that the multiply operation is performed correctly.

• When index reaches 31, it's done and the accumulator contains the desired filter output! Now the module just waits until ready is asserted again and starts over.

With this implementation the filter looks like a one sample delay and can be easily spliced into the recording pipeline.

To help you test your fir31 module, we've written a Verilog test jig, fir31_test.v, which you can use with ModelSim to run your module through it's paces. When executed, the test jig reads the file fir31.samples, feeds them to your module, captures the output value and writes it to the fir31.output file. There are two sample files:

fir31.impulse which has a string of 0 samples, followed by a single sample of 1, followed by more 0 samples. The expected output should be 0's, followed by the coeffients of the 31 filter taps in order, followed by more 0s.

fir31.waveform which has 48,000 samples of a waveform constructed by adding together 1kHz and 5kHz sine waves. The expected outputs are given in fir31.filtered, which is approximately a 1kHz sine waveform. The frequency plots of fir31.waveform and fir31.filtered are shown below -- note how the 5kHz component has been filtered out!

To test your module, enter your design (and copy of the coeffs31 module from lab4.v) in a file called fir31.v. Then copy either fir31.impulse or fir31.waveform to fir31.samples, right-click on fir31_test.v and open with ModelSim, and issue the following commands:

vlib work
vlog fir31_test.v

When you get it to compile cleanly you can run the simulation with the folowing commands:

vsim fir31_test
run 1000ms

The simulation will stop after the last input sample has been processed. Now look at fir31.output to see what happened.

Step 3: Add the low-pass filter to your recorder module

In this step, add a single instance of the fir31 module to your recorder module. Use muxes to route data to the filter inputs, memory inputs, and to_ac97_data as described below.

The filter input to your recorder module is controlled by switch 0 on the labkit. When filter is 0, your recorder module should behave as before. When filter is 1 the fir31 module should be used as an anti-aliasing filter during recording and as a reconstruction filter during playback. Note that led[7] is on when filtering is enabled.

Here's a table showing the connections during various modes of operation:

When the fir31 module is used as a reconstruction filter, it's input is a zero-expanded set of samples from the recording memory. "Zero expansion" is a type of up-sampling where one data sample is used from memory, followed by in our case seven samples of 0. The filter will interpolate between the memory samples, smoothly filling in values in place of the zeros. In this mode, the filter has a gain of 1/8 which we can compensate for by multiplying its output by 8. This is accomplished by simpling moving 3 bits to the right when selecting which output bits to use.

Which filtering operation seems to have the biggest effect: anti-aliasing or reconstruction? See the Implementation Tips below on how to use the logic analyzer to capture the playback data being sent to the AC97. During checkoff, show how the playback data changes when you switch the filter on and off.

Implementation Tips

After coding, examining the waveforms in simulation before attempting to program everything onto the FPGA can save you a lot of time. In particular, closely examine what happens when processing an incoming sample and generating a new outgoing sample (i.e., what your logic does on ready cycles). It's pretty easy to generate a known sequence of from_ac97_data values and ensure that they get written to your memory in record mode and get played back correctly in playback mode. Check that all control signals rise and fall as you would expect them to.

If your circuit seems to work under simulation but not when loaded into the labkit, try bringing critical signals out to the logic analyzer connectors, e.g., the signals for your 64Kx8 memory.

A good way to debug the filter is to use the logic analyzer to display your results. lab4.v includes code that outputs clock_27mhz to analyzer3_clock, to_ac97_data to analyzer3_data[7:0], and ready to analyzer3_data[8]. Configure the analyzer to sample the data on the rising edge of the clock if ready is 1. You can display the 8-bit data as a "magnitude waveform" in which the logic analyzer will plot the captured data values as a waveform. Zooming in, you should see the waveform as short straight line segments each made up of 8 points as your filter interpolator interpolates between the stored samples. There shouldn't be any big jumps between one captured value and the next if your filter is doing its job correctly.

In general, using the logic analyzer to examine what's happening is a quick way to "see inside" your chip and get some idea of what's going on.