Arbiter Using Fixed Priority Logic for Fair Resource Access
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Modern ASICs face challenges in implementing arbitration schemes like LRU due to high latency and area considerations, while fixed priority arbiters are not fair, leading to starvation of lower-prioritized clients.
Innovation Solution
An arbitration system that adapts a fixed priority arbiter to various schemes by associating each client with a priority value, ordering requests based on priorities, and updating priorities according to the configured scheme, allowing fair access to shared resources.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If LRU arbitration scheme is implemented, then fairness is improved, but latency and area increase
Solution Approach 1:
The arbitration system is segmented into two independent modules: a fixed priority arbiter for fast grant generation and a priority update module for fairness maintenance. This segmentation allows the FPA to operate independently with low latency while the priority updates occur in parallel, achieving both speed and fairness without the complexity of full LRU implementation.
Solution Approach 2:
Priority values are pre-calculated and stored in priority storage elements before arbitration occurs. The priority update module proactively updates these stored priority values based on grant outcomes, so that when the next arbitration cycle begins, the correct priorities are already in place. This preliminary action eliminates the need for complex real-time priority calculation during arbitration, reducing latency.
2Reliability
If LRU arbitration scheme is implemented, then fairness is improved, but area increases
Solution Approach 1:
The system separates the arbitration function (performed by the fixed priority arbiter) from the priority management function (performed by the priority update module). This segmentation allows each module to be optimized independently: the FPA uses simple combinational logic with minimal area, while the priority update module uses lightweight sequential logic that only stores and updates priority values, avoiding the large state machines required by traditional LRU arbiters.
Solution Approach 2:
Instead of implementing full LRU state tracking which requires storing complete arbitration histories, the system changes the parameter representation to simple priority values (e.g., 0-7 for 8 clients). These priority values are updated incrementally based on grant outcomes, transforming the complex LRU state into compact numerical parameters that require minimal storage area while still enabling fair arbitration.
3Loss of time
If fixed priority arbiter is used, then latency is reduced, but fairness deteriorates causing starvation
Solution Approach 1:
The system combines the static structure of a fixed priority arbiter with dynamic priority values. While the FPA itself remains a simple static circuit for low latency, the priority inputs to the FPA are dynamically updated by the priority update module based on previous grant outcomes. This dynamics allows low-priority clients to eventually receive grants when higher-priority clients do not continuously contend, preventing starvation while maintaining the speed of the FPA.
Solution Approach 2:
The priority update module implements feedback by monitoring grant signals and using them to update priority values. When a client receives a grant, its priority is adjusted (e.g., set to lowest or incremented), and this updated priority feeds back into the arbitration process for the next cycle. This feedback mechanism ensures that continuously winning clients cannot monopolize the resource, providing fairness while the FPA maintains low latency through its simple structure.
Data Source
AI summary
An arbiter may include a plurality of cells, mapping logic, a fixed priority arbiter, and unmapping logic. Each cell may be associated with a corresponding client and configured to store a priority for the corresponding client. The mapping logic may be connected to the plurality of cells to order requests received from the clients according to the priorities stored in the cells. The fixed priority arbiter may receive the ordered requests and generate a grant for a winning request of the requests. The unmapping logic may use the stored priorities to yield the grant back to the winning client that sent the winning request.


