Filling out unused cores with while(1)

Technical questions regarding the xTIMEcomposer, xSOFTip Explorer and Programming with XMOS.
User avatar
aclassifier
Respected Member
Posts: 405
Joined: Wed Apr 25, 2012 8:52 pm

Filling out unused cores with while(1)

Post by aclassifier »

In application note AN00219 [1] (for the mic array board) the unused cores are running this code:

par(int i=0;i<3;i++)while(1);

Why is this so? To make all cores run 1/8 of the cycles? If this were not added, the five there would run 1/5 of the cycles each, which is more. But some times more is not what's wanted. The lower level lib_mic_array uses the xta analyser, so things are rather timy.

On the xCORE-200, if 1-5 cores used: 1/5 scheduled cycles each, and if 6-8 cores used then all cycles shared out. In other words: according to XUF216-512 datasheet each logical core has guaranteed throughput of between 1/5 and 1/8 of tile MIPS.

[1] https://www.xmos.ai/application-notes/


--
Øyvind Teig
Trondheim (Norway)
https://www.teigfam.net/oyvind/home/
User avatar
CousinItt
Respected Member
Posts: 265
Joined: Wed May 31, 2017 6:55 pm

Post by CousinItt »

The only reason I can think of is to make timing predictable.

Threads can also be assigned high priority to ensure they are scheduled. Normal/lower priority threads are still guaranteed to progress.
User avatar
aclassifier
Respected Member
Posts: 405
Joined: Wed Apr 25, 2012 8:52 pm

Post by aclassifier »

CousinItt wrote: Tue Sep 28, 2021 10:32 am The only reason I can think of is to make timing predictable.

Threads can also be assigned high priority to ensure they are scheduled. Normal/lower priority threads are still guaranteed to progress.
That predicatability analysis would have been very interesting to read. Here I have built AN00219 with zero to three extra cores and taken out the last entry of the xta analysis. The result is that the margins get tighter as more cores are used. Slack is decreased and min core frequency is increased. In my head it gets "worse". And I don't know enough to know whether predictability increases, but my first guess of my stomach's feeling is: it doesn't.

But then, there could be some other task, not under xta scrutination, that gets more predicatble? In that case, I'd be happy to see that as some kind of comment in the code or PDF - which I have't found.

// par(int i=0;i<3;i++)while(1);
Constraint check for tile[0]:
  Cores available:            8,   used:          5 .  OKAY
xta: /Users/oyvindteig/Documents/dev/xc/workspace/lib_mic_array/src/pdm_rx.S:8: warning: route(17)     Pass with 10 unknowns, Num Paths: 1, Slack: 1.1 us, Required: 2.6 us, Worst: 1.5 us, Min Core Frequency: 295 MHz

par(int i=0;i<1;i++)while(1);
Constraint check for tile[0]:
  Cores available:            8,   used:          6 .  OKAY
xta: /Users/oyvindteig/Documents/dev/xc/workspace/lib_mic_array/src/pdm_rx.S:8: warning: route(17)     Pass with 10 unknowns, Num Paths: 1, Slack: 792.0 ns, Required: 2.6 us, Worst: 1.8 us, Min Core Frequency: 347 MHz

par(int i=0;i<2;i++)while(1);
Constraint check for tile[0]:
  Cores available:            8,   used:          7 .  OKAY
xta: /Users/oyvindteig/Documents/dev/xc/workspace/lib_mic_array/src/pdm_rx.S:8: warning: route(17)     Pass with 10 unknowns, Num Paths: 1, Slack: 448.0 ns, Required: 2.6 us, Worst: 2.2 us, Min Core Frequency: 413 MHz

par(int i=0;i<3;i++)while(1);
Constraint check for tile[0]:
  Cores available:            8,   used:          8 .  OKAY
xta: /Users/oyvindteig/Documents/dev/xc/workspace/lib_mic_array/src/pdm_rx.S:8: warning: route(17)     Pass with 10 unknowns, Num Paths: 1, Slack: 188.0 ns, Required: 2.6 us, Worst: 2.4 us, Min Core Frequency: 463 MHz

I have once tried to sum up priority of threads ([2]), with quotes from the different XMOS manuals. From a quick search on "priority" on the new X3 manual I think that regarding priority it is as on X2.

[2] https://www.teigfam.net/oyvind/home/tec ... /#priority
--
Øyvind Teig
Trondheim (Norway)
https://www.teigfam.net/oyvind/home/