Theatre

I want both: low CPU load and low E2E Latencies

Watch Now

29:59

EOC 2023

Login to Watch

Olaf Schmidt

Olaf started with embedded systems as a kid. He studied computer science and has 20 year of professional experience in development, product management, marketing and sales of embedded automotive systems. At INCHRON he enables customers to build embedded real-time systems with optimal timing behavior. He is responsible for business development, marketing and sales.

View full profile

Topics Covered

Architecture Design Cycle Software Design Performance

Theatre

I want both: low CPU load and low E2E Latencies

Olaf Schmidt

29:59 EOC 2023

Olaf Schmidt

29:59

"All functions are ok now - we just need it to be faster." Everyone has heard this before and we all know how hard it is to improve the performance of a system towards the end of a project. In our experience, the system / hardware / software architecture defines the limits of performance. Some things may be improved in implementation and integration, but the big things are set during architecture phase. Making the right decisions in the architecture & design phase ensures that performance requirements are met and avoids late changes.

Real-time systems - both big and small - have to find an optimal balance between CPU load and end-to-end latency. Either you put all software on one core and avoid communication or you distribute software load to multiple cores, but introduce communication overhead. Communication overhead also means extra latency. If your system has critical latency requirements for data flows, it is wise to find a good distribution of software loads while maintaining the maximum latency requirements. It is the job of the system and software architects to design for an optimal real-time behavior and manage real-time requirements.

A model-based simulation approach supports architects in exploring design alternatives. In early project phases performance requirements can be checked and the system can be optimized. During the project the same requirements can be applied to the implementation and integration in order to ensure, that the architecture is implemented correctly.

This talk discusses the value of model-based design and optimization of the dynamic architecture.

1 / 3

Please log in or create an account to test your knowledge and see the answers.

What is the primary trade-off between CPU load and end-to-end latency that Olaf describes for real-time embedded systems?

A Putting all software on a single core minimizes communication and latency but increases CPU load on that core.

B Distributing software across multiple cores always reduces latency while increasing CPU load due to communication.

C Using more cores has no impact on latency; only algorithmic code changes affect latency.

D Raising the CPU clock speed is the only reliable way to lower end-to-end latency without affecting load.

E Offloading tasks to background batch processes removes all end-to-end latency concerns.

Why does Olaf argue design decisions about architecture and timing should be made early in the project?

A Early in the project there are many design alternatives and changes are cheap; later choices become fewer and much more expensive to change.

B You should wait until implementation is complete because only then will timing behavior be meaningful.

C Decisions are best left to the testing phase since simulation during design is unreliable.

D Let the marketing team choose architecture late to match changing requirements.

E Postpone all architecture choices until hardware is available to avoid speculation.

What workflow does Olaf recommend to verify timing requirements and avoid late surprises?

A Use model-based simulation (virtual integration) early to explore variants and then apply trace-based continuous testing during implementation and integration to validate timing budgets.

B Rely only on static code review and desktop profilers before integration; skip modeling and tracing as unnecessary overhead.

C Delay all timing verification until hardware prototypes are assembled and then run a single round of manual timing tests.

D Optimize scheduling heuristically on the final product without prior modeling or continuous checks.

E Eliminate inter-component communication entirely so no timing verification is needed.

Formatting help

italics	surround text with asterisks
bold	surround text with two asterisks
hyperlink	[hyperlink](https://example.com) or just a bare URL
code	surround text with `backticks`
~~strikethrough~~	surround text with ~~two tilde characters~~
quote	prefix with >

Upvotes Newest Oldest

ChipWeller

Score: 1 | 3 years ago | 1 reply

Olaf,
Thanks for the talk.
For your timing simulations how do you typically determine WCET for each task for the early phases.
I worry that the simulation could miss rare conditions which would cause deadlines to be missed. Could you compare this method against against analytical methods such as deadline monotonic analysis.
Thanks, Chip Weller

OlafSchmidtAtINCHRONdotCOSpeaker

Score: 0 | 3 years ago | no reply

Hi Chip Weller
the ET (both WC and BC) for each task is an input to the simulation. It is usually based on expert knowledge or prio projects.
Although this includes uncertainties it allows identification of timing issues of the overall system.
Let's schedule a meeting to discuss in more detail. Please send a e-mail to olaf.schmidt@inchron.com
Best regards,
Olaf

Partners & Sponsors

STMicroelectronics

Amazon AWS

Golioth

The Qt Company

Memfault

NXP

SEGGER Microcontroller

PE Micro

PX5

Become a Sponsor