Best practices for benchmarking Simulink → C code on TMS320F28388D (TI C2000) and AM2634 (Sitara)

Hello everyone,

I’m preparing a benchmark to compare the computational performance of code generated from a Simulink model on two target boards:

• TMS320F28388D (TI C2000 family)
• AM2634 (TI Sitara family)

I do not have Simulink Hardware Support Packages for both boards available, so my goal is to generate one portable C codebase that can be compiled and executed on both targets for a fair comparison.

Before I post my model or code, I’d like to ask the community for recommendations and best practices on several point:

How to best measure “computational power” / performance

• What metrics should I use for a fair comparison between these two architectures? (e.g., execution time per model_step(), cycles/step, throughput, latency, memory footprint, flash/ROM usage, RAM/stack usage, determinism/jitter)

ERT vs GRT — which to use for benchmarking?

• Is ert.tlc (Embedded Coder) always preferable for embedded benchmarking vs grt.tlc?
• If I generate with grt.tlc for quick host prototyping, what differences should I expect vs ert.tlc that would meaningfully affect timing/size comparisons?

How to configure the “Hardware Implementation” / ProdHW if I don’t have both HW packages

• If I want a single source tree that compiles on both boards, what are the safest Hardware Implementation settings to choose (native word size, endianness, char/short/int/long sizes, portable word sizes, floating-point settings)?
• Is setting the target to a Generic 32-bit little-endian + Portable word sizes = ON the recommended conservative approach?

Does using a specific hardware support package / ProdHW device improve generated code optimization?

• If I later install the official TI hardware support packages for each board and regenerate code per-board, how much difference should I expect in performance compared to a single generic build?
• In practice, is the recommended approach to generate single portable source that compiles on both boards, or generate two board-specific builds (each with its ProdHW/hw package configured) to maximize per-board optimization?

Thanks in advance — any pointers, links to docs/examples or short code snippets will be very helpful.

Best regards,

Pasquale

Answer 1

[Snehal]

Hi @Pasquale,

I understand that you are working on benchmarking Simulink - C code on TMS320F28388D and AM2634.

You may take the following points into consideration while implementing your workflow:

1. For a fair and focused comparison, measure CPU cycles per model_step()(primary, architecture-neutral metric), execution time and jitter(average, worst-case, and distribution over many iterations to capture determinism), and memory footprint (flash/ROM, RAM, and stack usage from the linker map). These three cover raw compute power, real-time behavior, and resource usage and are some of the most relevant factors for embedded performance benchmarking.
2. Use ert.tlc for benchmarking as it generates smaller, faster, production-style code optimized for embedded targets. grt.tlc is for host simulation, adds extra scaffolding and overhead, so timing and size results won’t reflect real embedded performance.
3. Setting Hardware Implementation to Generic 32-bit little-endian with >Portable word sizes = ON is indeed the recommended approach. Additionally, use consistent single-precision floats and fixed-width types since this ensures one portable codebase that compiles cleanly and behaves identically on both boards.
4. Board-specific ProdHW/support packages usually give better optimization (use of FPU, intrinsics, linker scripts), so expect noticeable speedups. You may consider comparing with a single portable build for fairness first, and generating per-board builds to measure each target’s best-case performance later.

Here are some documentation links for your reference:

• https://www.mathworks.com/help/rtw/ug/compare-system-target-file-support.html
• https://www.mathworks.com/help/ecoder/ref/enableportablewordsizes.html
• https://www.mathworks.com/matlabcentral/fileexchange/43096-embedded-coder-support-package-for-texas-instruments-c2000-processors

Hope this helps!

[Pasquale]

Hi @Snehal,

Thank you for your precise answer; it really helped me clarify the path to follow.

I still have a couple of practical questions about how to implement what you suggested:

1. What is the best way to measure CPU cycles accurately? Would it be sufficient to schedule the Simulink-generated function using Timer 0, while using the Timer 1 registers to evaluate the cycle count?
2. Do you know if a hardware support package is already available for the Sitara AM2634 board? From what I could find, it looks like it might only be available starting with MATLAB 2025.

Thank you a lot in advance!

Best,

Pasquale

[Snehal]

Hi Pasquale,

Glad it helped!

1. Regarding the measurement of CPU cycles, using Timer 1 (or the CPU cycle counter register) to bracket model_step() is a good way to get accurate cycle counts; just make sure you read/reset it back-to-back with minimal overhead and run enough iterations to average out noise. Toggling a GPIO at entry/exit once helps validate results on a scope
2. As far as a hardware support package for Sitara AM2634 board is concerned, I do not see any public documentation listing this officially. So, for now you’ll need to use a generic 32-bit little-endian target with portable word sizes and build using TI’s toolchain

Let me know if you have any further queries.

Thanks.

[Pasquale]

Thanks Snehal!

Just to conclude, that's what I found online as AM263X Support Package:

• https://it.mathworks.com/matlabcentral/fileexchange/174295-embedded-coder-hardware-support-package-for-ti-am26x

Have a nice day,

Pasquale

[Snehal]

Oh thanks for sharing!

Have a great day!