[CMSIS-NN] Fix memory alignment bug in CMSIS-NN demo

[grant-arm]

There is a latent bug in the CMSIS-NN demo app where the input and output tensors generated by the create_image.py script are not 16-byte aligned in memory. Although this does not cause an issue in the demo using the current person_detect model, if a different model is substituted with a larger output tensor, it causes the FVP to hang in certain cases.

This PR updates create_image.py to correct the issue.

@Mousius @ashutosh-arm @areusch

[ashutosh-arm]

@grant-arm Thanks for the PR. Just for my understanding, why do we need to align .rodata to 16 bytes? I have seen this for constants in the code generated C files as well. Also, does it hold good for all variations of Arm® Cortex®-M processors?

[Mousius]

@grant-arm Thanks for the PR. Just for my understanding, why do we need to align .rodata to 16 bytes? I have seen this for constants in the code generated C files as well. Also, does it hold good for all variations of Arm® Cortex®-M processors?

Hi @ashutosh-arm, the reason is because we default the workspace allocation alignment to 16 bytes in a few places, for example:

tvm/src/relay/backend/aot_executor_codegen.cc

Lines 831 to 832 in eae836c

	Integer workspace_byte_alignment =
	executor_config->GetAttr<Integer>("workspace-byte-alignment").value_or(16);

Which means we have to ensure we start on a 16 byte boundary to avoid overflows when we round up the allocations in memory planning. I believe we chose this because it's the max alignment required across all devices (including microNPUs), we could actually detect this and align as per the architecture at some point but the savings are minimal.

[ashutosh-arm]

@grant-arm Thanks for the PR. Just for my understanding, why do we need to align .rodata to 16 bytes? I have seen this for constants in the code generated C files as well. Also, does it hold good for all variations of Arm® Cortex®-M processors?

Hi @ashutosh-arm, the reason is because we default the workspace allocation alignment to 16 bytes in a few places, for example:

tvm/src/relay/backend/aot_executor_codegen.cc

Lines 831 to 832 in eae836c

	Integer workspace_byte_alignment =
	executor_config->GetAttr<Integer>("workspace-byte-alignment").value_or(16);

Which means we have to ensure we start on a 16 byte boundary to avoid overflows when we round up the allocations in memory planning. I believe we chose this because it's the max alignment required across all devices (including microNPUs), we could actually detect this and align as per the architecture at some point but the savings are minimal.

Thanks for the detailed explanation @Mousius.