Hi all,
I'm exploring possibiliy to implement a device that stream 32 in and 32 out audio channel from AVB to I2S (16 + 16 stereo I2S) using the XE216 device.
This high number of i/o channel seems possible looking to the appnote AN00203 where the i/o is in TDM format.
Looking to the tdm/i2s library documentation seems instead that i2s implementation can't reach in the real word this high number of channel that seems possible only in tdm mode.
This seems to me a limitation due to the fact that the library use a single core...do you think is possible to create multiple instance of I2s library. for example 4 instance running on 4 core each with 8in and 8 out and make all run sincronously exchanging data with avb library?
Many thanks for suggestions
Lorenzo
32 in /32 out with I2S possible? Topic is solved
-
lorenzochiesi
- Active Member
- Posts: 34
- Joined: Mon Sep 05, 2016 4:20 pm
-
infiniteimprobability
- XCore Legend
- Posts: 1126
- Joined: Thu May 27, 2010 10:08 am
Hi lorenzochiesi,
You've done some homework on this and yes, you are correct, the AVB implementation can handle 32i/32o. However, you're also right that I2S is the issue.
There are a few things to think about here. Firstly, there's I/O. lib_i2s uses a 1b port per stereo pair.
So that's (32 / 2) = 16 in and (32 / 2) = 16 out.
There are only 16 1b ports available per tile, and you need some for booting (flash), other I2S signals and some are reserved for the RGMII interface inside the chip.
So you would need an XE232 chip to meet the I/O requirement. Doing this would mean that the I2S would need to be running on different tiles (and by inference cores) anyhow.
The next thing is that the standard I2S master is only tested up to 8 in 8 out, and actually would struggle above that. This was recognised and a new "frame based" version was developed which can do much higher rates and channel counts. I would be astonished if this cannot hit 16i / 16o at 48KHz as it was doing 8i / 8o at 384KHz, but has not been explicitly tested for 16 channels yet.
The API for I2S frame based, and so the callback handler for that (buffer_manager_to_i2s in main.xc) would need to be modified - but it would result in lower overhead (less callbacks) so should be OK.
You would need to also think about synchronisation - multiple I2S interfaces would share the same MCLK so that's OK, however starting them at exactly the same time would need considering. Perhaps it would be better if one was a slave and one was a master.. All of the IP is there to do that and I2S slave should easily be able to handle the channel count.
The other option is that I2S is modified to use 4b ports. Using the zip/unzip you can stream 32b words out on individual pins of a 4b port. There's an app note which goes thorugh that:
https://www.xmos.com/download/private/A ... rc1%29.pdf
However, it would be prudent to test this out first. Essentially you'd be developing a variant of the I2S library that uses 4b ports and testing at 32ch/48KHz. It feels feasible, but short of doing a few calculations and running some tests, the error bars on confidence factor are large..
So in summary, a few ways to do what you want, but each is non trivial.
You've done some homework on this and yes, you are correct, the AVB implementation can handle 32i/32o. However, you're also right that I2S is the issue.
There are a few things to think about here. Firstly, there's I/O. lib_i2s uses a 1b port per stereo pair.
So that's (32 / 2) = 16 in and (32 / 2) = 16 out.
There are only 16 1b ports available per tile, and you need some for booting (flash), other I2S signals and some are reserved for the RGMII interface inside the chip.
So you would need an XE232 chip to meet the I/O requirement. Doing this would mean that the I2S would need to be running on different tiles (and by inference cores) anyhow.
The next thing is that the standard I2S master is only tested up to 8 in 8 out, and actually would struggle above that. This was recognised and a new "frame based" version was developed which can do much higher rates and channel counts. I would be astonished if this cannot hit 16i / 16o at 48KHz as it was doing 8i / 8o at 384KHz, but has not been explicitly tested for 16 channels yet.
The API for I2S frame based, and so the callback handler for that (buffer_manager_to_i2s in main.xc) would need to be modified - but it would result in lower overhead (less callbacks) so should be OK.
You would need to also think about synchronisation - multiple I2S interfaces would share the same MCLK so that's OK, however starting them at exactly the same time would need considering. Perhaps it would be better if one was a slave and one was a master.. All of the IP is there to do that and I2S slave should easily be able to handle the channel count.
The other option is that I2S is modified to use 4b ports. Using the zip/unzip you can stream 32b words out on individual pins of a 4b port. There's an app note which goes thorugh that:
https://www.xmos.com/download/private/A ... rc1%29.pdf
However, it would be prudent to test this out first. Essentially you'd be developing a variant of the I2S library that uses 4b ports and testing at 32ch/48KHz. It feels feasible, but short of doing a few calculations and running some tests, the error bars on confidence factor are large..
So in summary, a few ways to do what you want, but each is non trivial.
-
lorenzochiesi
- Active Member
- Posts: 34
- Joined: Mon Sep 05, 2016 4:20 pm
Many thanks, I understand all your points....
I add another option I'm considering now: add to the hardware a small CPLD that take TDM stream and transform to I2S stream and vice-versa.
As long as the the TDM port are master generating a clock of Fs*24*8 that can be converted to I2S clock Fs*32*2 simply dividing by an integer factor of 3 is a "trivial" design.
The only drawback is that this add one sample delay in the chain and is a 2 chip solution.
Anyway this should work safely.
Lorenzo
I add another option I'm considering now: add to the hardware a small CPLD that take TDM stream and transform to I2S stream and vice-versa.
As long as the the TDM port are master generating a clock of Fs*24*8 that can be converted to I2S clock Fs*32*2 simply dividing by an integer factor of 3 is a "trivial" design.
The only drawback is that this add one sample delay in the chain and is a 2 chip solution.
Anyway this should work safely.
Lorenzo
-
infiniteimprobability
- XCore Legend
- Posts: 1126
- Joined: Thu May 27, 2010 10:08 am
HI, yes this is a fairly trivial CPLD design. Not quite sure how you got to a factor of 3 though!? 24b I2S is normally carried in a 32b word with the bottom 8b unused.
Looking at the portmap again, you only get 24b worth of 4b ports per tile, so it is likely 2 I2S interfaces will be needed, unless you used 24b in 6 x 4b ports and 8 x 1b ports. Makes it a little more complex, but still feels feasible and keeps it to a single core. The last point is good since the Gbit AVB design pretty much fills the XE216 device..
I guess this comes down to engineering effort/BOM cost pressure tradeoff. If you have a large production run then a single chip solution is worth engineering. At a very rough guess, I'd put a couple of weeks to develop and verify a custom I2S interface like this.
Looking at the portmap again, you only get 24b worth of 4b ports per tile, so it is likely 2 I2S interfaces will be needed, unless you used 24b in 6 x 4b ports and 8 x 1b ports. Makes it a little more complex, but still feels feasible and keeps it to a single core. The last point is good since the Gbit AVB design pretty much fills the XE216 device..
I guess this comes down to engineering effort/BOM cost pressure tradeoff. If you have a large production run then a single chip solution is worth engineering. At a very rough guess, I'd put a couple of weeks to develop and verify a custom I2S interface like this.
-
lorenzochiesi
- Active Member
- Posts: 34
- Joined: Mon Sep 05, 2016 4:20 pm
If I understand correctly the AN00203 this implement a 32in/32out TDM interface using 4 TDM input streams and and 4 TDM output streams each multiplexing 8 audio channel.
This seems to meet the port capabilities of XE216 because, if I correctly understand, 16 1Bit port are available asnd thus can accomodate the 4+4 TDM stream plus frame and bit clock common for all streams. (This seems to be just ready to use from the appnote)
About CPLD design... I imagine that the TDM stream contain 8 channel each with 24bit resolution...isn't it? In this case the TDM bit clock is 48k*8*24 = 9.216MHz.
The I2S, as you say, always use 32bit for each channel leaving 8 blank, so the I2S bit clock should be 48k*2*32 = 3.072MHz.
So for the CPLD is easy to create the I2S bit clock simply dividing by 3 the TDM bit clock (9.216/3.072 = 3), no PLL is needed for fractional division.
Once you have the clock all you need is to implement a double buffering system that can store an incoming frame of TDM stream while shift out the previous in I2S format at the rate of I2S bit clock.
Simple enough to run on a 3Euro CPLD and to be designed and tested in a week!
Many thanks again
Lorenzo
This seems to meet the port capabilities of XE216 because, if I correctly understand, 16 1Bit port are available asnd thus can accomodate the 4+4 TDM stream plus frame and bit clock common for all streams. (This seems to be just ready to use from the appnote)
About CPLD design... I imagine that the TDM stream contain 8 channel each with 24bit resolution...isn't it? In this case the TDM bit clock is 48k*8*24 = 9.216MHz.
The I2S, as you say, always use 32bit for each channel leaving 8 blank, so the I2S bit clock should be 48k*2*32 = 3.072MHz.
So for the CPLD is easy to create the I2S bit clock simply dividing by 3 the TDM bit clock (9.216/3.072 = 3), no PLL is needed for fractional division.
Once you have the clock all you need is to implement a double buffering system that can store an incoming frame of TDM stream while shift out the previous in I2S format at the rate of I2S bit clock.
Simple enough to run on a 3Euro CPLD and to be designed and tested in a week!
Many thanks again
Lorenzo
-
infiniteimprobability
- XCore Legend
- Posts: 1126
- Joined: Thu May 27, 2010 10:08 am
All of the DACs and ADCs I've interfaced to have been 32b x 8 frame (example CS5368 ADC), but I have come across requirements for shorter sample sizes. I guess you just need to match whatever the spec is of your device!I imagine that the TDM stream contain 8 channel each with 24bit resolution...isn't it?