Multicore SoC Shared Resource Access Rate Safety Net
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In multicore processing environments, especially in safety-critical systems like avionics, concurrent access to shared resources by multiple cores or applications can lead to latency issues due to excessive use of shared resources, causing interference and degradation in system performance.
Innovation Solution
Implementing a shared resource access rate (SRAR) safety net that determines a baseline access time and rate for each user application, calculates a multicore derating to account for worst-case scenarios, and adjusts computation time requirements to limit data access rates using core rate limiters, ensuring sufficient execution time and reducing interference.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If multiple cores or applications concurrently access shared resources without rate limiting, then system throughput and resource utilization are improved, but latency issues and performance degradation occur due to excessive access and interference
Solution Approach 1:
The system applies preliminary rate limiting constraints to each core's access to shared resources before interference occurs. By pre-establishing access rate limits based on baseline measurements and worst-case scenarios, the system prevents excessive access and potential latency issues before they manifest, rather than reacting after performance degradation occurs.
Solution Approach 2:
The system performs preliminary characterization of shared resource access patterns by measuring baseline access times and rates under controlled conditions. This preliminary action establishes reference data that is used to calculate appropriate rate limiting parameters, enabling proactive management of resource access before actual concurrent execution begins.
2Reliability
If worst-case scenario-based rate limiting is applied to ensure sufficient execution time, then reliability and deadline meeting are improved, but system performance and efficiency deteriorate due to overly conservative constraints
Solution Approach 1:
The system dynamically adjusts rate limiting parameters based on measured baseline access times and calculated derating factors. Instead of applying fixed worst-case constraints, the system modifies access rate parameters according to actual observed behavior and statistical analysis, achieving reliable deadline meeting while avoiding excessive conservatism that would harm performance.
Solution Approach 2:
The system applies partial rate limiting by using derating factors less than the full worst-case scenario. By applying a calculated portion of the maximum possible constraint (based on baseline measurements and access patterns), the system achieves sufficient reliability without the full performance penalty of worst-case-based limiting.
3Productivity
If baseline shared resource access time is determined and used for rate limiting, then a more realistic and efficient rate limiting mechanism is achieved, but system complexity increases due to additional measurement and calculation requirements
Solution Approach 1:
The system performs self-characterization by automatically measuring its own baseline shared resource access times and rates under controlled conditions. This self-service approach eliminates the need for external calibration or manual parameter setting, reducing operational complexity while enabling realistic rate limiting based on actual system behavior.
Solution Approach 2:
The system uses feedback from baseline measurements and actual access patterns to continuously refine rate limiting parameters. By measuring baseline access times, comparing against actual performance, and adjusting derating factors accordingly, the system creates a closed-loop control mechanism that achieves efficient rate limiting without requiring complex manual tuning.
Data Source
AI summary
A multicore processing environment (MCPE) implements a shared resource access rate (SRAR) safety net to limit the access of user applications to shared system resources (SSR). For each user application, a baseline shared resource access time (SRAT) and baseline SSR access rate (while no other competing applications interfere) may be determined. A utilization for each accessed SSR, including worst case execution time and contention SRAT for competing applications, may be determined. For the user application and competing applications, an access time delta for each accessed SSR and total delta may be determined. Based on the total delta and an access count for each SSR, a multicore derating for the user application may be determined and the time requirement adjusted or allocated to include the multicore derating and baseline SRAT. Accordingly, the core rate limiters may limit data access to each SSR by the user application to a corresponding expected value.