![\"I2S](\"https:\/\/www.beyond-circuits.com\/wordpress\/wp-content\/uploads\/2015\/04\/tutorial19_bd.png\")
<\/a>I2S transmitter block diagram<\/p><\/div>\n
I have also created a timing diagram for the circuit shown in the block diagram. It is shown below:<\/p>\n
<\/a>I2S transmitter timing diagram<\/p><\/div>\n
The really important thing to note about the design is the parallel load. The authors of the specification don’t really explain what this means, but based on the requirement that sd<\/em> change on the falling edge of sck<\/em>, we can infer they mean what is shown in the detailed block diagram below. In this diagram, I have shown the details of the most significant bit of the shift register. Notice that we have the wsp<\/em> signal being generated on the rising edge of sck<\/em>, but it is captured on the falling edge of sck<\/em>. This makes the circuit dependent on the duty cycle of the sck clock. If it is high for a short period of time we could run into timing issues with the design.<\/p>\n I2S transmitter block diagram details<\/p><\/div>\n We want to modify the design such that it uses the FPGA clock domain rather than sck<\/em>. If we just use S_AXIS_ACLK<\/em> and condition the flip-flops on sck_rise<\/em> and sck_fall<\/em> where appropriate, we would get a timing diagram like that shown below:<\/p>\n Timing diagram of delay caused by sampling sck<\/em><\/p><\/div>\n Notice how long it takes from the fall os sck<\/em> to the change in the output data sd<\/em>. This can take up to two S_AXIS_ACLK<\/em> clock cycles. The I2S specification says this is supposed to change when sck<\/em> falls. We can fix this by shifting the data on the rise of sck<\/em> but then using a flip-flop clocked off the actual falling edge of sck<\/em> to generate the data out of the chip. In this situation, it’s not really a big deal to use sck<\/em> as an actual clock, since it is only going to a single flip-flop. We don’t need to use dedicated clock resources on the FPGA to do this since there is no requirement that skew on the clock tree be balanced. It is balanced by construction because there is only a single clock tree leaf.<\/p>\n The timing diagram below shows the result of doing this. Notice how the sd<\/em> output is pulled back closer to the falling edge of sck:<\/em><\/p>\n Timing diagram detailing reduced delay by clocking sd<\/em>\u00a0on the falling edge of sck<\/em><\/p><\/div>\n A schematic of this is shown below.<\/p>\n Clocking sd<\/em> out on the falling edge of sck<\/em><\/p><\/div>\n There are some problems with the design the way it is shown, though. First, we observed previously that the wsp<\/em> signal was generated on the rising edge of sck,<\/em> but used on the falling when we load the shift register using the parallel load feature. If we use the logic as it is shown then the wsp<\/em> pulse will last too long and on the next cycle when we should do a shift we will again do a parallel load. The fix is to not condition the second flip-flop on the sck_rise<\/em> signal. This will keep wsp<\/em> as a single clock pulse in the S_AXIS_ACLK<\/em> domain. This of course means that wsp will not be true while sck_rise is true so we need to remove the enable when the shift register does the parallel load. But of course, we need to keep the enable condition when it comes to shifting the data in the shift register. Our modified design looks something like this:<\/p>\n Final I2S transmit block diagram<\/p><\/div>\n The test will instantiate your i2s_transmit<\/em> module and an AXI 4 streaming master module to connect to the slave interface on your design. The basic premise of the test is that it tells the AXI master to write audio data to your transmitter. Your transmitter should take the audio data and write it out the I2S audio interface. The test will drive the audio clock sck<\/em> and the left\/right channel signal ws<\/em>. Your i2s_transmit module will drive the sd<\/em> serial data signal. The serial data will be compared against the audio data sent by the AXI streaming master. The figure below illustrates this.<\/p>\n I2S transmitter test block diagram<\/p><\/div>\n The ws<\/em> signal will not be a consistent number of clocks for each sample. The test will vary this period, and your design should accommodate this. Also, your design must keep up with the data driven by the AXI streaming master. While your design determines when it can accept data by asserting the S_AXIS_TREADY<\/em> signal, it must not wait too long to do so. If your design does not keep up, the test will terminate with an error.<\/p>\n You still need to design the logic to take data from S_AXIS_TDATA<\/em> and put it in your data_left and data_right registers. You will also need to design some logic to generate S_AXIS_TREADY<\/em> to tell the AXI4 Streaming master that you are ready to accept data. I won’t go into detail on that for now so you can have a chance to work it out on your own.<\/p>\n Here are some links to my testbench files:<\/p>\n Update (October 2026):<\/strong> Some readers using newer versions of Vivado saw the testbench comparisons come out one sample off. The cause was a race in the testbench: I2S Transmitter Spec Let’s take a look at the block diagram for an example transmitter from the I2S spec. It is shown below: I have also created a timing diagram for the circuit shown in the block diagram. It is … Continue reading <\/a>Changing to the FPGA clock domain<\/h1>\n
<\/a><\/a><\/a><\/a>Test<\/h1>\n
<\/a>Wrap-up<\/h1>\n
\n
output_checking_enabled<\/code> was set with a blocking assignment on the same clock edge the checkers read it, so the result depended on the simulator’s scheduling order. It now uses a nonblocking assignment (output_checking_enabled <= 1;<\/code>). If you downloaded i2s_transmit_test.v<\/em> before this, grab the updated copy above. Thanks to Zdzislaw and detiber for reporting it.<\/p>\n","protected":false},"excerpt":{"rendered":"