Q&A Explorer XK-EVK-XU316 and XK-AUDIO-316-MC

Discussions relating to the XK-EVK-XU316
User avatar
fabriceo
Experienced Member
Posts: 70
Joined: Mon Jan 08, 2018 4:14 pm

Q&A Explorer XK-EVK-XU316 and XK-AUDIO-316-MC

Post by fabriceo »

Hello
I m just starting with XK-EVK-XU316 and already some question, this topic might be used to Q&A for this board

in term of pin mapping, here is attached a modified version of the original xmos X200 port mapping spreadsheet (v13), adding on the right end side XU316 in version QF60A and FB265. (the former xs200 column are just hidden, same for lines tile 2&3.
the 2 last columns are the pin allocation on the EVK explorer.
remark : column K for IO power rails is not OK for XU316


Then it seems more interesting to have the USB PHY on tile 0 for QF60A as all the required port are not connected to any pin package.
For the FB265, I do not understand the choice made on the Explorer board. if we connect usb phy on tile 0 then we cannot use wifi chip (WIFI_WIRQ and MOSI conflict with RXRDY and USBCLK), and on tile 1 this would impact the microphone (MIC_DATA line conflicting with FLAG1)...
the PLL (X1D11) is connected to I2S_MCK but also to X0D11 which gives the possibility to measure the real frequency for the feedback-endpoint with usb_phy on tile0.

for discussion and q&a
You do not have the required permissions to view the files attached to this post.
Last edited by fabriceo on Mon Feb 06, 2023 9:35 am, edited 4 times in total.


MaximLiadov
Active Member
Posts: 60
Joined: Mon Apr 16, 2018 9:14 am

Post by MaximLiadov »

XU316 Q1: How many jitter (in ps) does have PLL MCLK in integer and N-fractional modes? Comparable to inexpensive Silabs 5351A specs?
XU316 Q2: These days many manufacturers are using FPGA to supress MCU jittery I2S. Is it possible to syncronize XMOS I2S and SPDIF output ports to audio PLL not to system 100 MHz?
Last edited by MaximLiadov on Sat Jan 28, 2023 11:06 am, edited 1 time in total.
User avatar
fabriceo
Experienced Member
Posts: 70
Joined: Mon Jan 08, 2018 4:14 pm

Post by fabriceo »

Hi MaximLiadov
for Q1, the data sheet (xu316-QF60A) mention extra jitter when using fractional mode (chapter 7.2) with register SS_APP_PLL_FRAC_N_DIVIDER (chapter D.16).
But if you want to generate say the standard 49,152mhz and 45,1584mhz you can use the following value for F,R,OD which gives results very closed to a dedicated crystal:
with a 24mhz crystal and OD = 3, x1D11 is also divided by 2(x+1) with x in APP_CLK_DIVIDER (D.12)
for 49,152mhz : F = 1834, R = 55 gives 49,151786mhz (-4ppm)
for 45,1584mhz : F = 571, R = 18 gives 45,157895mhz (-11ppm)

for Q2, according to figure 7 of chapter 7.2, seems the clock from PLL2, after the APP_CLK_DIVIDER, goes directly to the hardware pin x1D11 without any latch triggers by PLL1 or ref clock. my view.
hopefully XMOS specialists will confirm ?

anyway, having a very clean MCLK close to the DAC will remain the best ever solution for pure hifi. this PLL2 is good for making life easy for USB Host clocking or for following software spdif_rx rate

by the way, for those on budget, there is a xu316 USB Audio board under reference PXUA-XU316-KIT form pawpaw on Ali... they have put 2 crystals on board+24mhz
https://docs.pawpaw.ltd/docs/docs/PXUA- ... T_firmware
https://inf.news/en/digital/0598ff6b8a4 ... cb900.html
https://www.xmos.ai/pawpaw-electronics-case-study/
Last edited by fabriceo on Sat Feb 04, 2023 8:42 am, edited 3 times in total.
MaximLiadov
Active Member
Posts: 60
Joined: Mon Apr 16, 2018 9:14 am

Post by MaximLiadov »

Thank you, Fabriceo. I don't agree "anyway, having a very clean MCLK close to the DAC will remain the best ever solution for pure hifi". All I2S signals must be stable, not jittery. Also two crystal oscillators next to DAC chip is not too good idea as it's a source of powerful high frequency pickups. Chinese PCBs with this ideology sound rubbish. Now they use FPGA for MCU's jitter suppression. So it's actual question to make stable I2S signals right our of XMOS. I tried system clock change on the fly on XU216 this way:
F = 1175; R = 24; OD = 0; unsigned pllCtrlWriteData = R + (F<<8) + (OD<<23) + (1<<30) + (1<<31);
write_node_config_reg ( tile[0] , XS1_SSWITCH_PLL_CTL_NUM , pllCtrlWriteData);
To make I2S proportional to 44100*512. Correct me if I am wrong with code? It works, system and ports clock changed on the fly, but I2S outputs still jittery on oscillograph and not in synch with external MCLK. So system PLL looks like not good and stable for audio. I see no any jitter though if I set system clock to 480 Mhz / port clock 96 Mhz. So best way would be use 22.5/24.5 Mhz instead of 24.0 for XMOS, but USB part doesn't work then. So that's why I am curious about XU316 with secondary audio PLL. I have tested a commercial XU316 based product with single 24.0 Mhz clock and see no jitter on its I2S ports, but obviously I have no firmware source-codes, just a board. So seems to be it's possible somehow on XU316. May be even possible somehow on XU216.
Last edited by MaximLiadov on Tue Jan 31, 2023 10:51 am, edited 1 time in total.
User avatar
fabriceo
Experienced Member
Posts: 70
Joined: Mon Jan 08, 2018 4:14 pm

Post by fabriceo »

Hi MaximLiadov,
I will not disagree with you as there are many DAC chips with different behavior. for sure an AD1862 requires everything hyper clean, while an ES9028 with 100mhz local crystal and dpll activated will be fine as Long as lrclk is clean.

your PLL settings looks ok for getting 564.48mhz which is multiple of 44100, but then I m a bit surprised that you overclocked the device so much :)
I m used to overclock for spdif_rx software (524mhz gives better result on my hardware for 192k spdif). Did you also change other dividers for core clock or ref clock?

anyway its good if you saw a board providing clean 44k multipliede mclk with PLL2.
I could try this on my XU316 EVK, but my 100mhz DSO is not good enough to show jitter.

anyone from XMOS able to provide figures about PLL2 jitter on x1D11 ?
MaximLiadov
Active Member
Posts: 60
Joined: Mon Apr 16, 2018 9:14 am

Post by MaximLiadov »

Dear Fabriceo. Thank you very much! Really appriciate your positive way of thinking.

One more question for Q&A: What is the minimum RTL (round-trip latency) for XU316?

It's a critical question for the professional audio application. It depends on Fs and ASIO buffer size sure thing, also as Safe Mode checkbox state in Thesycon panel. But some MCU is a bit better than others with the exactly same settings. Is XU316 any better than XU216? Or it's more firmware? I measured a XU316+CS4272 based USB audio interface (Arturia MiniFuse 4) with optimal settings and got 6 ms sharp @ 44.1 kHz & 64 samples buffer size. Is it minimum possible RTL or there is some way to reduce it a bit more? What is the best practice to do that?
User avatar
fabriceo
Experienced Member
Posts: 70
Joined: Mon Jan 08, 2018 4:14 pm

Post by fabriceo »

Hello
MaximLiadov wrote: Tue Jan 31, 2023 10:46 am One more question for Q&A: What is the minimum RTL (round-trip latency) for XU316?
Hi MaximLiadov
the total RTL has to do with the Asio buffering back and forth, the USB frame (8khz), the USB buffering in XU316 back and forth, and the DAC+ADC conversion (sigma-delta are quite long)
in the end I think the USB Buffering technique used in the USB Audio application is the main contributor.
Ive been playing with that 2 years ago, rewriting all the xmos usb buffering routines in order to better understand and manage this with my own approach due to some changes in decouple.xc and usbbuffer.xc to implement some downsampling before sending to audio task...
you can find my usbfifo code code in GitHub for information https://github.com/fabriceo/XMOS/tree/master/usbfifo
I then realize that you do not need too much usb-frame buffering in facts. 4 frames of 125us is okay. but you are always keen to take more...
if you want to tweak the xmos usbbuffer, be prepared for some headache :)
Last edited by fabriceo on Wed Feb 01, 2023 7:59 am, edited 1 time in total.
User avatar
fabriceo
Experienced Member
Posts: 70
Joined: Mon Jan 08, 2018 4:14 pm

Post by fabriceo »

I ve just found a preliminary document on xmos.ai for USB Audio Guide Version 7.1,
including details on a new Multichannel evaluation kit XK-AUDIO-316-MC.
It uses a new device : XU316-1024-TQ128-C24 !
This device is already setup in digikey database, with a high price, but no stock.
https://www.xmos.ai/download/sw_usb_aud ... pha.0).pdf
https://www.xmos.ai/download/XU316-1024 ... eet(7).pdf
pretty cool :)

Edit: the new MC Audio board is equipped with both CS2100 and SI5351A-B-GT and some routing gives the possibility to use either CS or SI or PLL2. The guide also says:
The xcore.ai application PLL is obviously the lowest cost and significantly lowest power solution, however its jitter performance can not match the Si5351A which may be important in demanding applications.

Extending the topic to both Evaluation boards then :)
Last edited by fabriceo on Sat Feb 04, 2023 8:54 am, edited 1 time in total.
MaximLiadov
Active Member
Posts: 60
Joined: Mon Apr 16, 2018 9:14 am

Post by MaximLiadov »

fabriceo wrote: Tue Jan 31, 2023 1:22 pm Hello
MaximLiadov wrote: Tue Jan 31, 2023 10:46 am One more question for Q&A: What is the minimum RTL (round-trip latency) for XU316?
Hi MaximLiadov
the total RTL has to do with the Asio buffering back and forth, the USB frame (8khz), the USB buffering in XU316 back and forth, and the DAC+ADC conversion (sigma-delta are quite long)
in the end I think the USB Buffering technique used in the USB Audio application is the main contributor.
Ive been playing with that 2 years ago, rewriting all the xmos usb buffering routines in order to better understand and manage this with my own approach due to some changes in decouple.xc and usbbuffer.xc to implement some downsampling before sending to audio task...
you can find my usbfifo code code in GitHub for information https://github.com/fabriceo/XMOS/tree/master/usbfifo
I then realize that you do not need too much usb-frame buffering in facts. 4 frames of 125us is okay. but you are always keen to take more...
if you want to tweak the xmos usbbuffer, be prepared for some headache :)
Dear Fabrice!
I saw this your project in the past. Impressive! As I understand it's just a part of experimental source code, not 100% replacement for official files. Did you make it work finally? Did you measure RTL in CEntrance ASIO Latency test? What do you think about a new audio project for 316 MCUs? Is it possible to use 316 feature set to get any benefits over old generation? Do you plan to use hardware FPU and more fast cores for DSP processing? My 316 explorer board is coming. Hope to get it today.
User avatar
fabriceo
Experienced Member
Posts: 70
Joined: Mon Jan 08, 2018 4:14 pm

Post by fabriceo »

Hi MaximLiadov, let me share some points hopefully also interesting others on this topic :)

yes I have used this exact usb_fifo code in a commercial project (DAC8PRO) so it is not academic, only the file usb_fifo_demo.xc is an example of integration which I ve produced by copy pasting or removing unrelated code as I couldn't give the original ones due to so many changes.

About a new project with xu316, yes. in fact xu216 is already as you know a perfect fit for a large usb audio project.
xu316 brings a bit more cpu for handling dsd512 or DSD256 for 8 channels but here we are limited by the usb 64MB/s and I hope the next release of lib_xud and lib_xua (the new name for the usb audio app) will provide support for PIDDATA2 and thus twice bandwidth.

The very key benefit is obviously on the DSP side.
I have written an AVDSP library code (open source here) perfectly running today on RaspberryPI and fully optimized for XU216 multicore and I m planning to tune it for XU316.
for example my 8 channels dac at home is integrating a 2x3way crossover with additional eqs and 2 channels with eqs for the headphone. this is OK up to 192k, but at the very limit. With xu316 vpu, we can execute 8 biquads at once (35 cycles in dualissue) in nearly same time as 2 on xu216 (28 cycles). Also the c32 grade gives more mips in total. So I plan to test the VPU asm code available on xmos GitHub here soon :)
Regarding FPU, biquad would not be faster than with integer (as there is no MACC just FMUL and FADD), and my specific routines use the "reminder-reintegration" so the compute noise is not existing and I m absolutely fine with fixed-point integer (4.28) performance compared to 24bit FP mantissa.
if you want to reuse this routine it ishere, you just need to subtract 1 to the a1 coef of your biquad and allocate 6 words for state data instead of 4 (feel free to contact me by PM);
FPU is useful to compute filter coefficient realtime for sure.
but I will tell you more once I have ported AVDSP with VPU and FPU.

Edit: after some deep dive on the famous xmos biquad routine using VMACC, there is no chance to use "reminder-integration" concept as there is a LSAT and LEXTRACT equivalent operation at the end of each VMACC... in fact the vector unit execute 1.31 (sample) x 2.30 (coef), but the 3.61 result is rounded, saturated and provided in the vR register as 1.31 reusable value as I understand.

Also I m tempted for a modular product using xmos-links transport layer, and I m testing that at the moment :)

enjoy your 316kit and let us know your thoughts and findings
Last edited by fabriceo on Sat Feb 04, 2023 9:07 am, edited 4 times in total.