SPI to I2S upgrade to 24 bit

[Altera_Forum]

Hi, 

 I am currently working on a USB audio signal capture and playback device. I've noticed that all of the audio quality ADC/DACs use I2S to communicate but unfortunately my usb interfacing chip uses SPI. Altera have an example project converting I2S to SPI but it only works for 16 bit. The converters I want to use are 24 bit and so I've been trying to alter the verilog code to accommodate this. Unfortunately I don't know any verilog so this is quite challenging, I just know VHDL and only on a fairly basic level.  I tried changing the various inputs/outputs and registers from 15:0 to 23:0 and the counts to 24 bit counters rather than 16 bit counters but when I view the design in the RTL viewer the buffer out section appears to be incorrect.  The 16 bit example project and testbench are available at:  altera.com/literature/an/AN487_design_example.zip  Any help would be greatly appreciated, I'm pretty newbish to this,  Regards, Dan

[Altera_Forum]

I took a short look at the code and can basically understand your difficulties with it. I think, it can be modified to 24 bit data length, but I would prefer to rewrite it from the scratch. The code has a lot of dubious details, e.g. using multiplexers rather than shift registers for the serialization and deserialization. Usually, I see this kind of code in HDL beginners first tries. 

 Are you sure, that your I2S interface uses a similar format as the said design? I have used several AD and DA chips exposing (among other standards) an I2S interface, they have all been different.

[Altera_Forum]

Thanks for your reply, and hmm an interesting point you make, I just assumed that I2S was a standard in itself it didn't really occur to me to see if there were different formats. As for it being written in beginner HDL that's annoying specially as my knowledge of it is so basic, I'll have to check the converter datasheets and then see if I can work out what the code is doing exactly, unless you could outline it briefly? As you seem to be a fairly clued up person, would you mind just clarifying that this is the correct approach to getting audio quality ADC/DACs to communicate to usb.  

 ADC --> CPLD --> USB  USB --> CPLD --> DAC  I know usb audio interfaces are on the market but I can't figure out what their methodology is and the usb audio chips I've found have all been low quality audio for headsets and such like nothing 24 bit 192KHz  Thanks again for the response.  Dan

[Altera_Forum]

I would primarly try to make the USB device communicate with the DAC/ADC directly. If this is threatened by format incompatibilities, a CPLD is a good solution and MAX II also my first choice for complex designs. 

 As another point, you may want to demand simultaneous AD and DA operation, as it's provided by most codec chips and separate ADC and DAC chips anyway.  What't your designated USB interface chip?

[Altera_Forum]

My designated USB interface is FTDI's FT4232H mini-module which I initially chose for flexibility, although now its not looking that wise, it has SPI, I2C JTAG, and bit bang capabilities although I am most familiar with the spi programming library supplied with it.  

Do you know of any direct I2S -> USB interfaces?   Regards,  Dan

[Altera_Forum]

The FTDI SPI support is nothing but generic MPSSE with a specific DLL for your comfort. You can perform I2S or other serial protocols with the chips as well. 

 But digital audio would use isochrone USB mode usually for reliable throughput. It's not provided by FTDI drivers as far as I know.

[Altera_Forum]

So I imagine I would have to write code using the D2xx drivers to configure the MPSSE for I2S. I did think this would be possible but I emailed FTDI and they said that it only supported the SPI etc formats. What your saying does sound correct though.  

Would you mind explaining your last point about isochrone a bit more, please forgive my ignorance. The other thing is that I find the FTDI dx22 library very basic and unhelpful :(  Thanks again, Dan

[Altera_Forum]

There is another problem, that isn't directly related to SPI versus I2S interface. Digital audio chips usually require a fixed serial clock rate, that is directly locked to the system clock respectively sampling frequency. When using an asynchronous SPI master as the FTDI device, you need an elastic buffer with handshake bits to adapt the data rates. The FTDI side must have be able to achieve the required data rate plus an extra for handshaking. 

 So using a CPLD may be necessary to meet this requirement.

[Altera_Forum]

--- Quote Start ---  I took a short look at the code and can basically understand your difficulties with it. I think, it can be modified to 24 bit data length, but I would prefer to rewrite it from the scratch. The code has a lot of dubious details, e.g. using multiplexers rather than shift registers for the serialization and deserialization. Usually, I see this kind of code in HDL beginners first tries.   Are you sure, that your I2S interface uses a similar format as the said design? I have used several AD and DA chips exposing (among other standards) an I2S interface, they have all been different.  --- Quote End ---     Is possible create an USB to I2S interface ? It is a business, see my article  USB to I2S 192KHz 24bit

[Altera_Forum]

I am also trying to get an I2S interfacing working with an A/D chip. 

I am using a Cyclone III FPGA, and need to interface to I2S channels that have multiple A/D chips cascaded.  I thought Altera would have some pre-made interfaces that would work for this as the concept of clocking in the data is pretty straight forward, but I am not having much luck. I was trying to use a simple shift register to clock in a channel serially then read it out in parallel, but I am new to the NIOS core interface methods and am not making much progress at setting this up.  I was quite familiar with Lattice tools using ABEL, but unfortunately I am getting up to speed with Altera with the graphic design but looking at the verilog where required at the same time as this project, my design is going way to slow. Any tips would be appreciated.  Thanks,  Dale