XVF3510 UserBufferManager (UBM) Timing test fails with ff3v FIR array accessable from C and XC

[mbanth]

The recent change to make the ff3v FIR array accessable from both C and XC has added significant overhead to the operation of UserBufferManager() in XVF3510. The UBM Timing test shows a cycle count increase from 1161 to 1379, about 19%. This increase exceeds the limit of cycles available if the tile hosting the audio loop, which includes UBM, has a full complement of 8 logical cores.

The results below were produced in an XVF3510 sandbox created from the sw_xvf3510_develop view file @ xgit commit 4bc3338ac. Follow How to build the 3510 firmware on WSL to create the sandbox (it works with slight alterations on MacOs and native Linux). Then change into the sw_xvf3510/tests/ubm_timing_test directory and run:

waf configure
waf clean build
xsim bin/ubm_timing_test.xe

Results @ lib_src commit 4769609 (committed 2021-05-05 15:21:55 and direct ancestor to HEAD of develop on 2021-07-05):

(.venv) michaelb@LT000633:~/sandboxes/sw_xvf3510_feature_configurable_hid/sw_xvf3510/tests/ubm_timing_test$ xsim bin/ubm_timing_test.xe
Filters 0: shifters: 0
From 16 loops (not including first) receive_worst: 25, send_worst: 26, restart_worst: 1110
Total thread cycles: 1161 available (8t): 1368 (7t): 1559
System clock rate: 540666531Hz, margin thread cycles 8t: 207, 7t: 398
TEST PASS (assert_on_fail: 1)

Filters 2: shifters: 0
From 16 loops (not including first) receive_worst: 25, send_worst: 26, restart_worst: 1230
Total thread cycles: 1281 available (8t): 1368 (7t): 1559
System clock rate: 540666531Hz, margin thread cycles 8t: 87, 7t: 278
TEST PASS (assert_on_fail: 1)

Filters 4: shifters: 0
From 16 loops (not including first) receive_worst: 25, send_worst: 26, restart_worst: 1350
Total thread cycles: 1401 available (8t): 1368 (7t): 1559
System clock rate: 540666531Hz, margin thread cycles 8t: -33, 7t: 158
TEST FAIL (assert_on_fail: 0)

Filters 0: shifters: 6
From 16 loops (not including first) receive_worst: 25, send_worst: 26, restart_worst: 1364
Total thread cycles: 1415 available (8t): 1368 (7t): 1559
System clock rate: 540666531Hz, margin thread cycles 8t: -47, 7t: 144
TEST FAIL (assert_on_fail: 0)

Filters 4: shifters: 6
From 16 loops (not including first) receive_worst: 25, send_worst: 26, restart_worst: 1605
Total thread cycles: 1656 available (8t): 1368 (7t): 1559
System clock rate: 540666531Hz, margin thread cycles 8t: -288, 7t: -97
TEST FAIL (assert_on_fail: 0)

(.venv) michaelb@LT000633:~/sandboxes/sw_xvf3510_feature_configurable_hid/sw_xvf3510/tests/ubm_timing_test$

Results @ commit 6467329 (committed 2021-06-25 14:31:35) and 3c3956e (committed 2021-06-30 15:23:12 and HEAD of develop on 2021-07-05):

(.venv) michaelb@LT000633:~/sandboxes/sw_xvf3510_feature_configurable_hid/sw_xvf3510/tests/ubm_timing_test$ xsim bin/ubm_timing_test.xe
Filters 0: shifters: 0
From 16 loops (not including first) receive_worst: 25, send_worst: 26, restart_worst: 1328
Total thread cycles: 1379 available (8t): 1368 (7t): 1559
System clock rate: 540666531Hz, margin thread cycles 8t: -11, 7t: 180
TEST FAIL (assert_on_fail: 1)

Unhandled exception: ECALL, data: 0x00000000
(.venv) michaelb@LT000633:~/sandboxes/sw_xvf3510_feature_configurable_hid/sw_xvf3510/tests/ubm_timing_test$

[mbanth]

I have verified that XVF3510 uses all 8 logical cores on the tile hosting the audio loop. Consequently, this change will almost certainly break the timing constraint and cause audio glitches. However, we can avoid the problem by using the v2.1.0 release of lib_src.

The effects of XVF3600 and XVF3610 are unknown at present.