audio passthrough using SPI in PL

Qualification: I don't use Vivado and don't own a Zedboard, so this is just in very general terms.

The audio data streams in to the FPGA on the i_codec_(xxx) inputs.

Given the names, it's most likely the CODEC chip has an I2S output. Serial data on adc_data, clock on bit_clock, and the left-right qualifier on lr_clock.

It's possible that the CODEC being used here has a register set that needs to be loaded via SPI at the start (sometimes they're I2C, sometimes SPI, and sometimes there's no setup and it's just done by strapping inputs on the CODEC chip). Normally that would be done from a processor, but can also be done from logic (it's usually quite a small selection of options, so not too onerous). Try going down a level into the spi_controller_inst and see if there's not only a shift register for the SPI, but also a simple state machine to sequence everything and a store of the values that will be sent in sequence to the CODEC.

If that's the case, the i_spi_miso input would come from the CODEC, for reading back register contents, but may not actually be necessary to get the CODEC set up (there's a good chance it could work just by pushing the right data at it).

Hopefully that will get you a bit further.

Yeah, I should've said that earlier. The audio codec on zedboard is ADAU1761. The I2C is default, and for set up SPI, in spi_driver_inst there are 3 dummies write sends to spi_master. Also in documentation of that codec was said so. As i told before, I'm new to FPGA, and i dont understand everything that has been written in that intances, and I'm not sure why there's need to configure SPI eventually, because I only need the audio output to use further in PL. Could you help me understand that? My job for now is to short the LINE_IN and LINE_OUT to make sure that board is working properly.

Also, in audio_proccessor_inst there are simple assign o_codec_dac_data to i_codec adc_data. Is that could work, or something is missing?. Of course the name of that pins are from constraints file dedicated to this zedboard.

I'm seriously puzzled by your diagram.

The SPI controller does not appear to have any reset or parallel data input/output - how does it know what config data to send out, when to send it etc etc.

If you want to accept analogue input data on the ADC input to the codec and output analogue data on its audio output DAC you will need to initialise the codec, then the FPGA can accept serial digital data from the codec ADC and buffer it , read from the buffer and output serial digital data to the codec which will use its DAC to convert it to analogue audio data.

I'm not sure that you have got the hang of how to clock the codec and the FPGA, the LR clock from the codec will be synchronous with the M clock into the codec. It is unlikely that you will run the FPGA synchronously with the LR clock and you may well have a choice between clocking data out of the codec synchronously with M clock of FPGA clock. There will be timing constraints in the codec spec about clocking and the MUST be observed if you want it to work correctly.

I suggest that you find a complete working example of a pass through application for your hardware and study it carefully. Then try tweaking it a bit. I took a quick look at the example you linked and although I didn't like its use of video rather than static diagrams it probably covers a lot of what you need. Have you been able to make it work ?

MK

I'm seriously puzzled by your diagram.

The SPI controller does not appear to have any reset or parallel data input/output - how does it know what config data to send out, when to send it etc etc.

If you want to accept analogue input data on the ADC input to the codec and output analogue data on its audio output DAC you will need to initialise the codec, then the FPGA can accept serial digital data from the codec ADC and buffer it , read from the buffer and output serial digital data to the codec which will use its DAC to convert it to analogue audio data.

I'm not sure that you have got the hang of how to clock the codec and the FPGA, the LR clock from the codec will be synchronous with the M clock into the codec. It is unlikely that you will run the FPGA synchronously with the LR clock and you may well have a choice between clocking data out of the codec synchronously with M clock of FPGA clock. There will be timing constraints in the codec spec about clocking and the MUST be observed if you want it to work correctly.

I suggest that you find a complete working example of a pass through application for your hardware and study it carefully. Then try tweaking it a bit. I took a quick look at the example you linked and although I didn't like its use of video rather than static diagrams it probably covers a lot of what you need. Have you been able to make it work ?

MK

Hey, I read the documentation of the audio codec, and i get it that to set up the SPI communication i have to pull ~CLATCH 3 times low, and it is written in spi_driver. I also understand that those other "messages" have to be sent, to properly work, but in that implementation, i dont understand what is going on in spi_master, especially that half of the code includes clock_phase and  clock_polarity that are grounded.  If you or anyone could look at the example here: https://www.rtlaudiolab.com/004-zedboard-audio-codec-spi-controller/ and tell me if thats correct i would be thankful.

Also, i dont understand why i_spi_miso get involved here, cause the whole spi_controller has only sending the configuration to o_spi_mosi, so why we have the reading option here. Below i'm putting screenshot of whole spi_controller for the record.

About that clock that you mentioned, the i_codec_lr_clock and bit_clock are nowhere used. The clock generator are "creating" 45MHz clock that is send to mclock, in that project was said that if I want to sampling in 44.1kHz, the mclock should be 1024xfs, in documentation i found it too(in the case of not using internal PLL).

About the example, unfortunately I didn't found another example of setting audio codec with SPI using only PL. It's not that I can't use it, just prefer to use PL if thats possible.

I can't review the code in your link because its written in Verilog which I can understand but never use if I can help it. So I am not confident in spotting bugs in Verilog code.

Having said that, there is a bug in the spi_controller block diagram which casts huge doubt on the utility of the whole rtaudio project as a learning aid.

i_reset input to the spi_master block is grounded, if you look at the code for the spi_master block you will see that all this should happen when reset is asserted:

        if (i_reset) begin
            fsm_state <= IDLE;
            spi_data_counter <= \'b0;
            spi_cs_n <= 1\'b1;
            data_out_shift <= \'b0;
            done <= 1\'b0;
            spi_mosi <= 1\'b0;
            data_out_shift <= \'b0;
            o_data_out <= \'b0;
            o_busy <= \'b0;

It is possible that the complete project will work, or often work depending on the way the registers start up, but not certain. To fail to initialise a standard block like the SPI in this way, is  what I would call an unforgivable error. It is a deliberate action (not an error of omission) which will result in an uncertain design. To do this in a published teaching style project is beyond sloppy ! Do NOT trust this project .

Moving on ........

The SPI_MASTER is a standard block of code (the audiolab article says:

"The SPI Master is a generic module that implements the master device in a single-slave SPI bus. In addition to the standard SPI signals, the clock phase and polarity of the SPI Master can be changed at runtime using the corresponding input ports. The bit width of a transaction can be adjusted during the module instantiation." )

Using standard blocks of code is common but, as in this case, frequently results in features in the code that are not required for your specific application. SPI is  a bidirectional protocol, but you only need on direction so some unwanted connections are to be expected. You have a miso pin but you don't need it.

In section 5 of the rtaudio project they have a block diagram of the audio pass through:

This is a bit of it and you can see that they connect the codec_adc_data output directly to the codec dac_data input. This is a trivial and pointless audio pass through application in which the data is never read properly into the FPGA and the bit clock and LR clock rely on internal synchronisation in the codec chip. It will tell you if the codec is working but not that you can actually read and write digitised data from/to it.

The do cover this later:

I have not checked their code at all !

(If you have considered using VHDL then let me know - I could then provide some code examples (but not for your hardware, although obviously modifiable.)

MK

Hey, thanks for your effort. I really appreciate that. I found that earlier, and even assign it for another button, but it doesnt help either. I wanted to simply check the audio codec, if it's working properly. I won't be sending any signal to audio output further in the project. What I need is having digitilized signal on known "port", to further analisys. But for now, I have struggle with audio codec :(

I have a question about that master module, especially abaout that part that you mentioned, and the few lines under that. If I'm correct, I could simply start the procedure of configurating codec after reset? With that, I would have one button to reset and start sending messages.

Also, if you could explain in your own words what exactly is bit clock and LR clock, and about that internal synchronisation. I will be very grateful.

The spi_drive code is suspect because it doesn't use reset and the state machine may start up in any state.

Pressing the enable button should kick things off - you shouldn't need to auto start the driver writing to the codec registers but if those missing resets are spoiling things it won't work.

It's normal when working on FPGA code to simulate before running on actual hardware. It will help you understand what is going on much better if you can get into that habit.

If you don't have access to a simulator you should sort that out first - it is a necessary tool.

You could modify the spi driver to toggle spare output pins as it does certain things so you can see if it is working.

Or connect a scope to the SPI mosi output to the codec and look for the *** config. signals.

The data sheet for the ADAU1761explains the timing of all signals very well - you need to study that document carefully.

MK