Update simple serial commands + AES & KMAC bitstreams & binaries

[vogelpi]

Change simple serial command identifiers

This commit aligns the simple serial command identifiers in
capture.py with the latest changes lowRISC/opentitan@4da6006

In particular the commands change as follows:

• Setting the fixed key / plaintext for fvsr experiments is now 'f'. Previously this was using 't'. This affects AES, KMAC and SHA3.
• Doing a fvsr batch encrypt on AES is now triggered using 'e' (previously 'f').

[vogelpi]

@nasahlpa @vrozic @johannheyszl after merging lowRISC/opentitan#20248 which allows us to select the trigger type (precise hardware-generated as now vs software controlled like on the real target) some of the simple serial command identifiers changed. This means when you want to generate a binary and bitstream on top of 20248, you also need to include the changes in this PR.

[vogelpi]

I've marked this as draft because it fails CI (we need to update the binaries, bitstreams and the command identifiers in sync).

[johannheyszl]

Thanks @vogelpi LGTM

I guess this illustrates nicely how the future OTTF-based commands will improve since the multi-letter commands have better readability and space :)

[nasahlpa]

LGTM, thanks!

[vogelpi]

Ironically, the CW310 capture which should have failed before didn't fail CI. The capture was aborted due to a mismatch between device and host (as expected due the command identifiers not being inline) but CI wouldn't fail. We should investigate this at some point. For reference, I've attached the log file.
log.txt

[nasahlpa]

Ironically, the CW310 capture which should have failed before didn't fail CI. The capture was aborted due to a mismatch between device and host (as expected due the command identifiers not being inline) but CI wouldn't fail. We should investigate this at some point. For reference, I've attached the log file. log.txt

Thanks for pointing this out! I had a look into this - the "Capture traces" CI test calls a bash script to capture traces. Although the capturing fails, the script is not correctly passing the error to the CI. Instead of calling bash scrips in azure-pipelines.yml, we should directly call the capture Python script. With the simple capture scripts from #207, this should then be easier.

[vogelpi]

Ironically, the CW310 capture which should have failed before didn't fail CI. The capture was aborted due to a mismatch between device and host (as expected due the command identifiers not being inline) but CI wouldn't fail. We should investigate this at some point. For reference, I've attached the log file. log.txt

Thanks for pointing this out! I had a look into this - the "Capture traces" CI test calls a bash script to capture traces. Although the capturing fails, the script is not correctly passing the error to the CI. Instead of calling bash scrips in azure-pipelines.yml, we should directly call the capture Python script. With the simple capture scripts from #207, this should then be easier.

Thanks for your feedback on this Pascal. IIRC there are ways to pass errors through the scripts back in to CI. In general, the advantage of having a script is to be able to quickly re-run the job locally without having to reverse engineer the actual commands running in CI. But I agree, let's look into this after the restructuring, it will make things easier.

[vogelpi]

I've now also updated the binaries for AES and KMAC. CI passes, I am merging this.