Arbiter Weight-Based Memory Request Scheduling
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The increasing complexity of systems on chips (SoCs) with multiple agents and endpoints leads to management challenges due to growing latencies between sending commands and corresponding data across the interconnect, particularly in intermediate storage and outstanding transactions.
Innovation Solution
A communication fabric with intermediate buffers and an arbiter that schedules read and write requests based on attributes such as weight and data size, adjusting weights to prioritize requests and reduce latency by temporarily blocking affected requests, thereby optimizing traffic flow and simplifying storage management.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Loss of time
If traditional scheduling methods are used for memory requests in SoC interconnects, then all requests are treated equally with uniform scheduling, but this results in growing latencies between command sending and data sending, and complex management of intermediate storage and outstanding transactions
Solution Approach 1:
The patent changes the scheduling parameter from uniform treatment to weight-based prioritization. The arbiter assigns different weights to requests based on their data size and type, dynamically adjusting scheduling parameters to favor requests with larger data sizes or higher priorities, thereby reducing their latency without requiring complex intermediate storage management changes
Solution Approach 2:
The scheduling mechanism transitions from static uniform scheduling to dynamic weight-based scheduling. The arbiter continuously adjusts request weights and scheduling decisions based on current request characteristics (data size, type), making the system adaptive to varying traffic patterns and reducing overall latency dynamically
2Device complexity
If uniform scheduling is applied to all memory requests, then the scheduling mechanism remains simple, but requests with larger data sizes experience increased latency and intermediate storage management becomes complex
Solution Approach 1:
The patent introduces weight as a new scheduling parameter that directly reflects request characteristics (data size, type). By changing from uniform parameter scheduling to parameter-based weight scheduling, the system achieves better productivity without significantly increasing mechanism complexity, as the weight calculation follows straightforward rules based on request attributes
3Ease of operation
If multiple requests of the same type are processed consecutively, then the scheduling is straightforward, but the latency between command sending and data sending increases significantly
Solution Approach 1:
The arbiter uses feedback from request characteristics (data size, type) to adjust scheduling decisions in real-time. When a request with large data size is detected, the system increases its weight and prioritizes it, creating a feedback loop that automatically reduces latency for time-sensitive requests while maintaining simple scheduling operations through clear priority rules
Solution Approach 2:
The scheduling system dynamically adjusts request priorities based on real-time request characteristics. Instead of fixed sequential processing, the arbiter continuously reevaluates and reorders requests based on their current weight, which is determined by data size and type, thereby reducing latency without complicating the operational framework
Data Source
AI summary
A system and method for efficiently scheduling requests. In various embodiments, a processor sends commands such as read requests and write requests to an arbiter. The arbiter reduces latencies between commands being sent to a communication fabric and corresponding data being sent to the fabric. When the arbiter selects a given request, the arbiter identifies a first subset of stored requests affected by the given request being selected. The arbiter adjusts one or more attributes of the first subset of requests based on the selection of the given request. In one example, the arbiter replaces a weight attribute with a value, such as a zero value, indicating the first subset of requests should not be selected. Therefore, during the next selection by the arbiter, only the requests in a second subset different from the first subset are candidates for selection.