{"id":638,"date":"2015-04-24T10:33:47","date_gmt":"2015-04-24T18:33:47","guid":{"rendered":"http:\/\/www.beyond-circuits.com\/wordpress\/?page_id=638"},"modified":"2026-10-23T13:35:49","modified_gmt":"2026-10-23T21:35:49","slug":"tutorial18","status":"publish","type":"page","link":"https:\/\/www.beyond-circuits.com\/wordpress\/tutorial\/tutorial18\/","title":{"rendered":"Tutorial 18: I2S Receiver"},"content":{"rendered":"

In this tutorial, we will develop an I2S audio receiver. The goal of the tutorial is to really give you a chance to write your own RTL code. The tutorial will give you a simulation test bench which you will use to verify your RTL code. The tutorial will proceed in a number of steps, with each step adding more to your design. Let’s get started.<\/p>\n

I2S Overview<\/h1>\n

The I2S protocol is a common standard used to send audio data. It is a serial protocol very similar to SPI, but it is a streaming protocol. That means it is always transmitting data.<\/p>\n

I2S sends a stream of stereo audio data. For each audio sample there is a left channel and a right channel value. The values can be any number of bits, although 16, 20, 24, and 32 bit values are the most common. The\u00a0I2S Bus Specification<\/a>\u00a0provides a really good overview of the protocol and you should download and peruse that link now.<\/p>\n

There are three signals involved in sending audio data. A serial clock SCK<\/em>, a word strobe signal WS<\/em> which indicates if the data is for the left channel or the right channel, and a serial data signal SD<\/em>. The WS<\/em> and SD<\/em> signals are synchronous to the SCK<\/em> signal and change on the falling<\/em> edge of SCK<\/em>. Data is sent most significant bit first. One wrinkle is that the data is one cycle late with respect to the word strobe. The timing diagram illustrates the details.<\/p>\n

Implementing the Receiver<\/h1>\n
\"tutorial18_i2s_timing\"<\/a>

I2S protocol timing diagram<\/p><\/div>\n

In the next few tutorials, we will be using a technique called Test Driven Development<\/em>. With Test Driven Development, you write the test first and then write the RTL code that passes the test. Then you add more to the test, then add more to the RTL to again pass the test. By iterating this way, you get to the point where the test tests everything you want and the RTL performs the correct function. I will be providing the test code and it is your job to write the RTL. I will also give you a block diagram for the RTL so you have a good idea of what you will need to code.<\/p>\n

\"tutorial18_receiver1_bd\"<\/a>

Basic I2S receiver block diagram<\/p><\/div>\n

For our first pass, we will implement a receiver that has a fixed 32-bit word size. The block diagram (almost schematic) is shown to the right. This figure is largely taken from figure 6 of the I2S specification. However, I believe the figure in the specification is actually incorrect. The specification has the polarities of the WSD signals into the AND gates, which enable data from the shift register to be written to the left and right data registers.<\/p>\n

Ideas and Tips<\/h2>\n

Here are some ideas and tips about designing this module.<\/p>\n

First, remember that an HDL like Verilog describes the hardware. You are not describing a task or a sequence of steps like you would in software. You need to take the block diagram and code each piece of it.<\/p>\n

Registers with enables<\/h3>\n

So for example, data_left<\/em> and data_right<\/em> are 32-bit output registers which are clocked off of sclk<\/em> and they each have an enable. How do you code a register with an enable? Here is an example.<\/p>\n

always @(posedge clk)\n  if (enable)\n    my_reg <= my_value;\n<\/code><\/pre>\n
The enable<\/em> expression can be more complex than a simple value. But, the result of that expression will enable the register my_reg<\/em> to update its value.<\/p>\n
Combinational Logic<\/h3>\n
How about the output of a combinational gate? Let’s say we have values a<\/em> and b<\/em> and we want to create the signal z<\/em> which is the logical OR of a<\/em> and b<\/em>? Well, there are two ways that we can do this in behavioral<\/em> Verilog code. We can declare z to be a wire and use a continuous assignment like this:<\/p>\n
wire z;\nassign z = a|b;\n<\/code><\/pre>\n
We can even combine the wire declaration and the assign statement into a single line like this:<\/p>\n
wire z = a|b; <\/code><\/pre>\n
We could also use a combinational procedural block and a reg variable like this:<\/p>\n
reg z;\nalways @(*)\n  z = a|b;\n<\/code><\/pre>\n
Note a couple of things. First, we need to use a blocking assignment and not a non-blocking assignment. If we were to use a non-blocking assignment, weird interactions with the combinational always block and other sequential blocks could cause incorrect simulation results. Basically, if you were to use a non-blocking assignment and then assign the z<\/em> value into a flip-flop, whether you get the updated value of z<\/em> would depend on simulation ordering of the events. It would lead to the simulation being incorrect and not matching the synthesized design.<\/p>\n
Second, it is critical that all<\/em> paths of execution in the always block assign a new value to z<\/em>. If this is not the case, then you are specifying that there may be conditions where z<\/em> does not update and should hold its value. This implies a latch type construct. The only time you should need to use a latch is interfacing with some unusual external logic. I have designed dozens of FPGAs and have only needed a latch once or twice.<\/p>\n
Shift Registers<\/h3>\n
There are a number of ways to code a shift register. Say we have a four-bit register called shift<\/em> that shifts a value shift_in<\/em> in the least significant bit.<\/p>\n
You could code this the C<\/em> way:<\/p>\n
reg [3:0] shift;\nalways @(posedge clk)\n  shift <= (shift<<1)|shift_in;\n<\/code><\/pre>\n
You could code this the VHDL<\/em> way:<\/p>\n
integer i;\nreg [3:0] shift;\nalways @(posedge clk)\n  begin\n    shift[0] <= shift_in;\n    for (i=1; i<4;i=i+1)\n      shift[i] <= shift[i-1];\n  end\n<\/code><\/pre>\n
You could code this the caveman way:<\/p>\n
reg [3:0] shift;\n  always @(posedge clk)\n    begin\n      shift[0] <= shift_in;\n      shift[1] <= shift[0];\n      shift[2] <= shift[1];\n      shift[3] <= shift[2];\n     end\n<\/code><\/pre>\n
Or the more literate Verilog way:<\/p>\n
reg [3:0] shift;\nalways @(posedge clk)\n  begin\n    shift[0] <= shift_in;\n    shift[3:1] <= shift[2:0];\n  end\n<\/code><\/pre>\n
Or the more aesthetic Verilog way:<\/p>\n
reg [3:0] shift;\nalways @(posedge clk)\n  shift <= {shift,shift_in};\n<\/code><\/pre>\n
Some people, and more importantly, some linting tools will complain about the above code. The complaint is that the expression on the right is five bits and the value on the left is four bits and so we are dropping a bit. My rebuttal to this is “Well, of course we are. We don’t need that bit any more.” They would have you write the code like this:<\/p>\n
reg [3:0] shift;\nalways @(posedge clk)\n  shift <= {shift[2:0],shift_in};\n<\/code><\/pre>\n
I guess that is well and good, but with this new code, in addition to being more verbose, you need to modify two lines of code if the width of the shift register changes. In general, I don’t think it looks as clean and prefer to just turn off those warnings with the lint tool.<\/p>\n
Anyway, hopefully these tips will help you to code the module.<\/p>\n
Files<\/h2>\n
Here are the files you will need. The test file uses another module called common_test_util<\/em> for some housekeeping tasks. You will need to have both of these files in your simulation as well as your RTL file.<\/p>\n