Tools: Testbench: xt-testbench

[singalsu]

Now ready. see commit texts for description.

[btian1]

one more question is: where is the entry for this testbench?

[lgirdwood]

one more question is: where is the entry for this testbench?

src/tools/testbench

[singalsu]

Thanks @marc-hb the file DAI may be missing some DAI operation that fuzzer expects.

[lyakh]

Do I understand it correctly, that we currently can run testbench tests on the host multi-threaded and after this PR we won't be able to do that any more? Cannot we keep both modes?

[singalsu]

Do I understand it correctly, that we currently can run testbench tests on the host multi-threaded and after this PR we won't be able to do that any more? Cannot we keep both modes?

Yep, this is what it does... @lgirdwood can we restore the multi-threading with your work for alsa plugin so we could have both?

My idea is that I would get the improvements for topology parser and IPC simulation to xt-testbench from the plugin work. So this would be an intermediate step. Or wait to have both somehow.

[sys-pt1s]

Can one of the admins verify this patch?

[lyakh]

shouldn't double be %lf?

[singalsu]

Double is overkill for this, I'll change the equation to float. The table https://cplusplus.com/reference/cstdio/printf/ suggests that L would be used for long double, while l seems to be for integers unless I'm misunderstanding it.

[singalsu]

I've now addressed review feedback, thanks for the comments!

[singalsu]

Changing 0x%lx to 0x%zx seems be OK for both gcc and xcc, I'll update the patch with it.

[singalsu]

Yep, I've added functions to get time and cycles. The patch now also computes MCPS with file read/write consumption excluded.

[singalsu]

Thanks, yes that works!

[singalsu]

Double is overkill for this, I'll change the equation to float. The table https://cplusplus.com/reference/cstdio/printf/ suggests that L would be used for long double, while l seems to be for integers unless I'm misunderstanding it.

[singalsu]

Now run of e.g. >> process_test('volume', 32, 32, 48000, 0, 'xt-run'); gives test result for MCPS

Input sample (frame) count: 326400 (163200)
Output sample (frame) count: 326400 (163200)
Total execution cycles: 18810961
File component cycles: 11272232
Pipeline cycles: 7538729
Pipeline MCPS: 2.22

[marc-hb]

long long for consistency?

[singalsu]

Thanks, yes changed now!

[marc-hb]

Caught one $TPLGFN typo, otherwise shell script changes LGTM

[marc-hb]

typo

Suggested change

	echo"Error: topology $TPLGFN does not exist."
	echo"Error: topology $TPLG does not exist."

[singalsu]

Fixed, the previous print was without path. Better this way.

[marc-hb]

indent

[singalsu]

Same, I have no idea what's wrong with this indent. My emacs bash mode indents this way.

[marc-hb]

Mix of tabs and spaces again?

[marc-hb]

indent

[singalsu]

Sorry, I have no idea what's wrong with indent. Help?

[paulstelian97]

Spaces on one line and tabs on the next feels fishy, even for shell scripts.

[marc-hb]

It's unfortunate that we have some files with tabs and other files with spaces in the same project but I agree 100% with @paulstelian97 : let's please not cross the line where we have a mix of tabs and spaces in the same file!

So @singalsu please find the shortcut in your editor that lets you quickly switch between tabs and spaces like the rest of us :-)

PS: I can't resist sorry: this sort of time-consuming discussion is exactly why tabs suck. Off-topic.

[singalsu]

The file is already without my patch a mix of tabs and spaces. I can convert them all to spaces then.

[singalsu]

M-x untabify is now done.

[marc-hb]

I checked and there are only 5 tabs right now. Feel free to convert them to spaces or to leave them alone, as long as you don't add any it's fine by me.

[paulstelian97]

Modulo that one comment this looks good (and I can live with that one too).

[btian1]

it may be a int32 usage, no need int64.
https://elixir.bootlin.com/zephyr/v1.7.0-rc2/source/drivers/timer/xtensa_sys_timer.c#L41

int32 should be enough, max should be set to: 400,000?

[singalsu]

I'd keep this as 64 bits. With 400 MHz 32 bit counter overflows at 10.7s. Other Xtensas can be over 1 GHz clocked and we can support also other processor simulators too in the future.

[btian1]

cycle should be a wrap data, once it go to max, then will go back to zero, so there is another issue with the code,
please refer below:

if (cycles1 > cycles0)
diff = cycles1 - cycles0;
else
diff = UINT32_MAX - cycles0 + cycles1;

it is not a always increase data.

[marc-hb]

so there is another issue with the code,

What was the first issue?

cycle should be a wrap data, once it go to max, then will go back to zero,

Yes and that's OK because unsigned integers (unlike signed integers) are guaranteed to wrap around by the C standard

importnumpyasnpnp.uint32(5) -np.uint32(0xffffffff)
6

https://www.acepace.net/integerQuiz/

[btian1]

int32 should be ok, since it is delta between one module. no way to exceed int32

[singalsu]

Yes, it's true a single file copy should not consume over 32 bit worth of cycles but having this 64 bits avoid type casts. The overhead from this is small and it makes this more future proof, so I'd keep it as is. Unless you or others really want me to change this to smaller size.

[marc-hb]

As far as I understand this code will only ever run on a GHz 64bits CPU so I don't see what difference 32 bits would make.

Mixing signed and unsigned is fraught with peril and signed overflow is undefined so unsigned is clearly better here.

[kv2019i]

Looks great @singalsu !

[singalsu]

I just rebased this PR and added a commit with only tabs to spaces changes to comp_run.sh.

[kv2019i]

Style checkpatch warning relates to long string literals -> this is ok

One unrelated fail in https://sof-ci.01.org/sofpr/PR6513/build6991/devicetest/index.html

Proceeding with merge.