UW CSE
Winter 2004
CSE467 Advanced Digital Systems Design

Lab # 5
DUE: In one week, at 2:30 pm

Collaboration Policy:
Unless otherwise noted, your group may collaborate with other CSE467 groups on the lab assignments. Collaboration means that you may discuss the experiments and make notes during the discussion, but you may not copy another group’s work when doing the experiments; you may not copy experimental results from another group; and you may not copy any part of another group’s lab report. In addition, every individual in a group must understand the experiments, must participate in the writeup, and should understand the results. Collaboration does not mean that one person may perform the experiments and another write up the results – all lab partners must share equally in all parts of the lab assignment.

Late Policy:
The lab assignments are due in one week, at the beginning of your lab section. Assignments handed in after lab will incur a 10% penalty; the penalty will increase by 10% for each additional day late.

Overview:

In this lab you will design circuits that you will need to drive the audio board. You will simulate and debug these circuits this week and will be ready to download them and run them on the hardware next week. Before we let you download and run your designs, you must show that your design produces the right clocks and data. You will do this using both simulation (this week) and the logic analyzer (next week).

Part 1 – The Audio Codec Interface

We will be using a custom board designed in-house by Bruce Hemingway to generate audio signals.  This board uses the AK4529 codec (go here for the documentation). This codec takes a stream of digital values representing sound samples and turns it into an analog audio signal. Powered speakers can be plugged directly into the audio board. The first module you will design for this lab is the interface to this codec. We will describe the essentials of the codec in this document, but you will have to look at the documentation, especially the timing diagrams, to see exactly how the codec works.

 

The codec pins connected to the XCV1000 board are shown in the table below.

 

XCV1000 pin

AK4529 name

AK4529 pin

Comment

A3

MCLK

39

Master clock (50MHz/3) 6x BICK

A4

DIFO/CSN

41

0

A5

SMUTE

3

0

A8

SDTO

9

input/NC

A9

PDN

17

0= Power down, 1= Power on

B4

P/S

40

0

B5

LOOP0/SDA/CDT1

43

0

B7

SDTI1

6

Stereo serial input stream 1

B8

SDTI3

8

Stereo serial input stream 3

C5

DIF1/SCL/CCLK

42

0

C6

BICK

4

64x LRCK

C7

LRCK

5

Audio sample clock

C8

SDTI2

7

Stereo serial input stream 2

C9

SDTI4

12

Stereo serial input stream 4

D9

DFS

11

0

 

The PDN pin is very important.  If you are not using the codec, then the PDN pin must be set to 0 to protect the codec.  If PDN is 0, then the other pins can be left floating. When you are using the codec, you should set PDN to 0 when reset is asserted to cause the CODEC to be reset, and then set it to 1.

 

There are four stereo outputs on the codec, and each is driven by a different serial bit stream, SDTI1-4. At least to begin with, we will use only the first channel. The transfer mode timing that we will use is mode 2 (Table 7), which is shown in Figure 3, page 18. Data for the left and right channel are sent in bit serial fashion, 24 bits per channel. The 24-bit number is left-justified, with the high-order bit shifted first. Shorter numbers are filled out on the right with zeros. The BICK clock is used as the serial shift clock.  There are 64 BICK clock cycles per stereo sample, 32 cycles for the left channel, followed by 32 cycles for the right channel. Since only the first 24 cycles for each channel are used, data for the last 8 cycles are don’t cares. Make sure you study the timing diagram so that you use the appropriate edge of the clock to clock the serial data.

 

The LRCK serves two purposes: first it is the sample clock and must run at the sample frequency of the audio stream. Second, the clock level determines whether the left channel or right channel data is being transferred. BICK runs at 64 x LRCK.  In addition to BICK and LRCK, the MCLK clock must be provided. We will generate MCLK from our 50MHz system clock by a divide by 3 circuit to generate a 16.67MHz MCLK. We will then divide the MCLK by 6 to generate BICK with a frequency of 2.78MHz. Finally, when the BICK is divided by 64, we will have a sample frequency for LRCK of 43.4KHz which is close enough to 44.1KHz.

 

The I/O for the codec interface module is shown below:

The input to this interface is two sample streams, one for each channel. Initially we will connect the two inputs together so that both channels get the same data. This input stream uses the standard DataValid/TakingData handshake, although the Codec interface assumes there is always data when it needs it and so ignores the DataValid. We will give you test fixtures for both the input stream and the audio codec.  The input stream test fixture will read a file and generate the corresponding data streams. The codec will take the serial data you send it and write it out to a file which should have the same values as the input file.  You can also turn this file into a WAV file, although it might take a long simulation to generate enough data. You will have to prove that your codec interface generates the correct clocks and serial output before you can download your circuit to the board (next week).

Part 2 – Wavetable Synthesis

In this part, you will write the Verilog version of the program you wrote for the homework assignment. First, modify the program you wrote to produce the wavetable include file, to write a Verilog file instead. Here is the format you should use for this file. This will compile into an efficient implementation in the FPGA.

 

module rom512x16 (data, clk, addr );

   input         clk;

   input [8:0]   addr;

   output [15:0] data;

   reg [8:0]     addr_reg;

   reg [15:0]    data /* synthesis syn_romstyle = "block_rom" */;

  

   initial addr_reg <= 0;

   always @(posedge clk) begin

      addr_reg <= addr;

   end

 

   always @(addr_reg) begin

      case (addr_reg)

         9'h0: data = 16'h0034;      

         9'h1: data = 16'h012c;    

         9'h2: data = 16'h02a5;    

 

         9'h1FE: data = 16'hfeac;

         9'h4FF: data = 16'hff83;

        default: data = 0;

      endcase // case(addr_reg)

   end // always @ (...

 

endmodule

 

Now write a module that takes a frequency value as input and generates a sequence of samples for a tone of that frequency. You should write a simple test fixture that gives your module some frequencies, and check the output by adding the test fixture that writes the sample stream to a WAV file.

Part 3 – Putting it all together

The final piece of the lab is the keypad interface that you have already written. Use this interface to generate frequencies of your choice for input to the Wavetable synthesizer. Use a frequency of zero to indicate that no sound is to be produced (an output stream of zeros).

 

To put together the entire system, you will plug the keypad interface into your wavetable synthesizer, which plugs into the codec interface.  Note that you should be able to plug a FIFO or pipeline register between the wavetable synthesizer and the codec. Demo your design, showing that it produces the right waveforms and the right output file, and have the TA sign off on your programs. Turn in your printouts of your Verilog programs, any schematics and simulation files you use.