Using a PLL for mic clock(s)

[aclassifier]

The mic array board uses an external PLL to produce the low-jitter 24.576 MHz for the mics' clocks. MCLK

The XCORE.AI EVALUATION KIT does not have any mics, but have a connect for 1-2 external PDM mics. I haven't studied how it/they are used, but I assume that the built-in "app PLL" may be used for low-jitter clocking. What is the appropriate lib for this (old or new style)? I don't have any such board.

Is this low-jitter clocking needed if I'm only going to use one mic, where relative phase info for beamforming isn't interesting?

Can the ports of the X2 (on a XCORE-200 eval board, I now have some) be set up to free-run with low enough jitter at the right frequency? Oversampling for the decimation would need at max 24.576 MHz (for 12, 24, 48, 96, 192 kHz - not 8 kHz). On my application the SW samples as 48 kHz, and I process at 16 kHz but use 8 kHz (FFT 0-4 kHz).

There also is a mic system where I understand that the decimation is done on-chip (like ICS-52000, NR/ND - any idea of others?) that might give me another core or two ..

Please don't hesitate to correct me if I'm off on the theoretic matters here.

Øyvind

[fabriceo]

Hi Øyvind,

there is a new version of the lib_mic_array (here) specific for xs3, with very nice usage of the VPU especially for the decimation of the 1 bit data flow, by 256 with only 16vpu instructions. as it is written for xs3, let say it s a "new style" version to quote your words.

you can certainly use the app-PLL low jitter for driving the mic_clk but not directly as the pin is connected to X1D22 on the EVK so you would need to connect your mic directly to X1D11 (apppll) instead. I don't have facts or references but I think the effect of jitter on a 3mhz pdm data flow is very different than on say 48khz ADC or DAC. the decimation filter will average a lot of this and push that back somewhere in noise/snr rather than Thd. but the lower jitter remains the better. It all depend if you intend to work on a "voice device" or an "microphone based instrument".

the ICS-52000 is a beast and its direct tdm output is very good and will remove a lot of burden for its integration. but it looks expensive, so again depends on your use case.

[aclassifier]

Hi Fabriceo, thank you!

This is a hobby project [1], so the ICS-52000 may just do it for me for my port to the xCORE-200 Explorer board (since I only have one functional micArray board [2]). I use lib_mic_array, lib_mic_array_board_support and lib_dsp. notWired.co has a breakout board with 4 ICS-52000. Also NR/ND I think.

One of these days I'll go for the new lib_mic_array which seems to be mostly coded in assembly, but also some lib_xcore, which doesn't look scary at all.. (By the way, ChatGPT explained [[combine]] to me, with some tasks to be set up, supplying it with example xC code, very well.)

I don't know if my application would be considered "voice device" or an "microphone based instrument". Maybe the last, which I assume would be the one with the least requirement on jitter and/or relative phase(?)

What is a VPU? I couldn't find it on the X3 processor data sheet or the X3 ai eval kit hw manual. (Edit: Vector Processing Unit;-)

The question of the X2 HW port still remains. Could I just start one and let it free-run with no comms with that task after this, to make jitter minimal? Max speed?

[1] My Beep-BRRR notes (some log & movies)
[2] XMOS microphone boards or alternative?

[fabriceo]

Hi
for the jitter on output ports and the dependencies to ref clock, there is a detailed paper from xmos about it:
https://www.xmos.ai/download/I-O-timing ... 0(1.0).pdf
it seems there will be inherent jitter in the order of magnitude of 3.5 nano seconds.
which is about 1% of a 3mhz period...
what this means at the end is either a mystery , or a very complex mathematical problem :)

[aclassifier]

Thank you, fabriceo! This is so great!

• The only place I find "jitter" in there is on page 16 concerning the I2S example
• The places I find "3.5" is on page 18 as RTTmin and on page 19 as Toskew

How did you land on jitter as 3.5 ns? I'd assume that RTTmax-RTTmin is not really jitter?

This document feels to me like belonging in the rather long list of very good documents from XMOS.

[aclassifier]

My conclusion is that I went for the NW-AUD-ICS52000 board from notWired.co, which contains four of the "beast" mic systems ICS-52000 from TDK InvenSense. There are still some left of them. Not recommended for new designs, but after all - I'm going from a mic-array board to the xCore-200 Explorer boards and still enjoying xC!

Off Topic

More about the process at My MEMS microphones notes

[fabriceo]

4 Beasts in a raw ! good

nowired.co.png

[aclassifier]

It turned out that the NotWired NW-AUD-ICS52000 boards did not work (with my SW drivers, I tested several). They only produced noise.

When I received the alternative single-mic boards EV_ICS-52000-FX (https://invensense.tdk.com/download-pdf ... on-boards/) my SW drivers, which had been unmodified since the last tests, worked right out of the box, so to say.

Another interesting thing is that I was able to pull in two audio channels at 32 kHz (16 kHz each, SCK 1.024 MHz) as well as a single channel at 16 kHz (SCK 512 kHz). The ICS-52000 data sheet (https://invensense.tdk.com/wp-content/u ... 0-v1.3.pdf) would say "The frequency of SCK will depend on the number of microphones in the system. The SCK frequency should be n × 32 × fS, where n is a power of two (2, 4, 8, or 16) equal to or greater than the number of ICS-52000s on the bus. Table 8 shows the recommended SCK frequency for a chain of ICS-52000 microphones." Table 8 also lists 1 channel, which I guess the description also should have done, since 20=1.

BUT THE MOST IMPORTANT MATTER FOR THIS THREAD
//
All of this also worked with somewhat asymmetrical SCK (but within SCK duty cycle specs) but with the sum giving 100% accurate 32 or 16 kHz. Therefore I did not have to use an external PLL for this (xCORE 200 eXplorer) design. The same also goes for the headphone SW driver for Pimoroni PIM544 audio DAC (https://shop.pimoroni.com/products/pico ... 9490853971). In other words, I did not need lib_i2s.

(Some of this also at Stack Exchange Signal Processing https://dsp.stackexchange.com/questions ... 9394#89394)