I²S slave cannot support > 96 kHz on a 4-bit port

[xross]

This is due to a timing failure.

This should at least be mentioned in user documentation.

See note in test:

lib_i2s/tests/i2s_frame_slave_4b_test/src/i2s_frame_slave_test.xc

Line 37 in 7ba884c

// Only 1 channel in, 1 channel out pass timing for 192KHz sampling freq, all the other channel count combinations fail timing for 192 KHz(and 176.4)

[giuliomoro]

hi there, I'm curious as to what's the underlying limiting factor here? @xross could you expand on "This is due to a timing failure." ?

[xross]

AndrewXcav explains why it's slower here: https://www.xcore.com/viewtopic.php?p=41582#p41582

Essentially you have less buffering in the port for a 4-bit port vs 1-bit, since buffer size in the port is fixed regardless of size.

[giuliomoro]

Thanks for the pointer

• For a given clock, the buffer is 4x shorter (in time, not in bits) so the CPU thread will need to tend to the port 4x as often
• To interleave/de-interleave the channels from the buffer requires a series of zip/unzip instructions

These seem like they would as well affect an I2S master implementation, so do you have any further insights as why this issue mentions I2S slave specifically?

[xross]

when xcore is the target ("slave") there is a requirement for additional checks to ensure it's is still in sync with the controller ("master"). For example, that no extra clocks have been detected due to some EMI event etc.

Generally "slave" interfaces are always harder for the device to handle since the device needs to be ready well ahead of time for a transition.