In safety-critical systems, the ability to guarantee that safety-critical tasks have sufficient time to execute is key for system integrity and safe operation. A big challenge facing developers of safety-critical software applications is managing the shared resources of memory and cache to minimize worst case execution times (WCET). On-chip cache allows the processor to run at on-chip memory bus speeds and increases overall compute power when executing from the cache. However, task switching and competition among multiple cores can degrade cache performance and have dramatic impacts on WCET. Benchmarks demonstrate that WCET can be 3 times higher than average-case execution time (ACET) on single-core processors, up to an order of magnitude higher or more on multicore processors.

Figure 1. Common Dual-Core Architecture
By utilizing real-time operating systems like Deos that support cache partitioning, programmers can isolate safety-critical tasks from detrimental cache effects, thereby reducing WCET and boosting overall CPU time available for time-critical tasks. The ability to bound and control cache effects also simplifies analysis of inter-application interference patterns, thereby streamlining safety certification. Results from benchmarks derived from actual flight software demonstrate these benefits, and are presented later in the article.

Cache Effects

Cache maximizes processor performance by enabling it to access faster on-chip memory. That advantage, however, only exists when the data for the executing task resides in the cache. During a task switch in a memory-partitioned RTOS, the cache must be invalidated, and those portions of the cache that had been altered by the previous task (dirty cache) must be written back to main memory. Only after this is done and the cache is repopulated with data for the new task will the CPU again be able to access memory at chip speeds.

On a multicore processor, the problem is even worse because no longer is the major impact limited to a process or memory partition context switch. Now, multiple cores will compete for shared cache during normal process execution. A common dual-core processor configuration is shown in Figure 1. In this configuration, each core has its own CPU and small L1 cache, and both cores share the large L2 cache.

Figure 2. Single-Core Configuration with Cache Partitioning
In this configuration, applications executing on Core 0 compete for the entire L2 cache with applications executing on Core 1 (note that applications on the same core also compete with one another for the caches). If application A on Core 0 during normal operation uses data that maps to the same cache line(s) as application B on Core 1, then a collision occurs and must be corrected by the hardware.

As an example, suppose A’s data resides in L2, and that B accesses data that happens to map to the same L2 cache line as A’s data. At that point, A’s data must be evicted from L2 (including a potential “write-back” to RAM), and B’s data must be brought into cache from RAM. The time required to handle this collision increases B’s execution time. Then, suppose A accesses its data again. Since that data is no longer in L2 (B’s data is in its place), B’s data must be evicted from L2 (including a potential “write-back” to RAM), and A’s data must be brought back into cache from RAM. The time required to handle this collision increases A’s execution time.

Most times, A and B will encounter such collisions infrequently. In those cases, their respective execution times are considered “average case” (i.e., ACETs). However, on occasion, their data accesses will collide at a high frequency. In these cases, the impacts of the worst possible flip-flopping of cache lines must be included as the “worst case” possible execution times (i.e., WCETs), as it can occasionally happen during normal execution, although infrequently.

Figure 3. Dual-Core Configuration with Cache Partitioning
When developing certifiable, safety-critical software, one must design and budget an application’s execution time for worst-case behavior, since such software must have adequate time budget to complete its intended function every time it executes, lest it cause an unsafe failure condition. With the potential for multiple applications on multiple cores to generate contention for L2, WCETs on MCPs often are considerably higher than ACETs. Because certifiable, safety-critical applications must have adequate time budgets to accommodate their WCETs, this situation leads to a great deal of budgeted but unused time, resulting in significantly degraded CPU availability for time-critical tasks.

« Start Prev 1 2 3 Next End»