[FEATURE] Statically linked testbench for xt-xcc build

[singalsu]

Is your feature request related to a problem? Please describe. Yes, there's currently no way to simulate pipelines with xtensa intrinsics optimized code. The xtensa libraries (newlib, uclib, xclib) do not support dlopen() feature. It makes building and using current testbench impossible for xt-run environment.

Also the topology parsing of testbench could be replaced with pre-calculated and attached IPC sequence to instantiate the pipeline. Topology parsing would slow down unnecessarily the xt-run execution that is already much slower than native code execution on host.

Describe the solution you'd like Statically linked binary avoids the need for dlopen() usage. IPC sequence data files support would be a nice feature add to avoids topology parsing in simulation.

Describe alternatives you've considered We have cmocka that builds with xt-xcc but it is for cmocka paradigm only for fast bit accuracy kind of tests.

Additional context Add any other context or screenshots about the feature request here.

[jajanusz]

@singalsu I would somehow link testbench with unit tests, so you'll have nice simple template there (with your file components from testbench) and you just put in your processing components that you want to test/perf.

@mmaka1 You wanted something like this, can you describe how you think it should look?

[singalsu]

@ranj063 @jajanusz @kv2019i @lgirdwood @tlauda Does this proposal sound good to you?

Also the cmake build testbench is rather compilicated. I failed in build even before reaching dlopen(). I tried to make changes to build with xt-xcc but got stuck with include of platform specific headers. The cmake build system looks rather complicated and I wasn't able to fix it for my need. We should be able to support generic "host" architecture for both x86 and xtensa.

[jajanusz]

@singalsu Having it as part of testing framework will make it easy and they will be statically linked for whatever platform you choose. Yes cmake for testbench may seem complicated, but it was necessary to split testbench and FW code. I can make it work with xt-xcc in current form, but I think testbench shouldn't look as it is now. F.e. are topology parser and whole components+scheduling architecture necessary? If I understand correctly you only test topologies like FileIn->processing with src or vol->FileOut. Testbench is way too complicated for something simple like this.

[singalsu]

@jajanusz Yep, a "file read -> desired component 1-> desired component 2 -> ... -> file write" pipeline executor that supports initialization of components via normal IPC controls is what I'd need. The earlier test bench version that used static pipeline macros was like that I used it to develop tone generator, SRC and EQ code.

[singalsu]

@jajanusz A simplified testbench is OK as long as the IPC between testbench and components is similar to real SOF. I agree the current version has got more complicated than necessary. And usually I have only one component under test. The FIR and IIR EQs are meant to be used in series and likely there will be other similar cases so capability for simulating more than just one component is good to have, especially if there would be IPC between them.

[hunghsienchen]

Hello @singalsu , I'd like to execute a component with Testbench, while the component involves a 3rd party generated library (somelib.a) targeting Xtensa. So I also tried to compile Testbench with xt-xcc, but encountered lots of obstacles.

I'd like to ask:

1. Do you have updates on building Testbench with xt-xcc?
2. Are there other ways to execute a component, involving with Xtensa libraries, like Testbench does? Thanks!

[singalsu]

Thanks for refreshing this topic @hunghsienchen !

1. The blocker for me is lack of knowledge of cmake to accomplish this. I tried once to start but I wan't able able to do what I need. The testbench code changes needed like remove of shared library code from component registration, and possible remove of file seeking in topology parsing are straightforward. Now there's also need for non-threaded scheduler but also that's just normal C development work. If someone who knows cmake could make the initial changes for static build of another executable I could work with rest.

2. See the cmocka tests in SOF, they execute either as native (scripts/run-mocks.sh) or as xt-run (more complicated, explained in https://thesofproject.github.io/latest/developer_guides/unit_tests.html).

(cc @cujomalainey )

[hunghsienchen]

@singalsu Great! I'll try the cmocka tests. Thanks for your quick response!