SoC Queue Manager for Shared Resource Arbitration
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In integrated circuit systems-on-chip (SoCs) with multiple central processing units (CPUs), existing technologies face challenges in efficiently sharing resources like memory and input/output ports due to contention, leading to dedicated resource allocation per CPU, which restricts system usage and hinders load balancing.
Innovation Solution
A hardware-based method using a queue manager with first-in first-out (FIFO) memories and a resource allocator enables CPUs to share resources by managing requests and replies through input and output FIFOs, allowing prioritization and efficient access to shared resources via a simple hardware algorithm.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If resources are dedicated to each CPU to avoid contention, then resource access reliability is improved, but system resource utilization and adaptability deteriorate
Solution Approach 1:
The patent segments the resource allocation process into distinct phases: request submission, arbitration, and grant execution. Each CPU has its own request queue, but the arbitration mechanism dynamically allocates resources based on current system state, combining dedicated queue structures with shared resource access.
Solution Approach 2:
The arbitration mechanism dynamically adjusts resource allocation based on real-time system conditions, CPU priorities, and resource availability. The system transitions from static dedicated allocation to dynamic shared allocation, allowing CPUs to access any resource when needed while maintaining order through the arbitration protocol.
2Adaptability or versatility
If multiple CPUs share the same resource, then system resource utilization and adaptability are improved, but contention and access conflict increase
Solution Approach 1:
CPUs submit resource requests in advance through structured request queues before actually needing the resource. The arbitration mechanism processes these preliminary requests and grants access before contention occurs, allowing CPUs to prepare their access needs without blocking other CPUs.
Solution Approach 2:
The arbitration mechanism serves as an intermediary between multiple CPUs and shared resources. It receives requests from multiple CPUs, applies arbitration logic based on priorities and availability, and grants access in a controlled manner, preventing direct contention while enabling efficient sharing.
3Productivity
If a hardware-based arbitration mechanism is implemented, then resource allocation speed and productivity are improved, but device complexity increases
Solution Approach 1:
The patent replaces complex software-based resource allocation with a hardware-implemented arbitration mechanism. The arbitration logic is encoded in hardware circuits that automatically process requests and generate grants, eliminating the need for software intervention and significantly improving allocation speed while keeping the added complexity minimal through efficient circuit design.
4Reliability
If dedicated IO resources are assigned to each CPU, then resource access reliability is improved, but system throughput and productivity deteriorate
Solution Approach 1:
The patent makes IO resources universal and multi-functional, allowing any CPU to access any IO resource through the arbitration mechanism. Instead of dedicating specific IO ports to specific CPUs, the system enables any CPU to request and access any available IO resource, increasing overall system throughput while maintaining reliable access through structured arbitration.
Data Source
AI summary
A hardware-based method is provided for allocating shared resources in a system-on-chip (SoC). The SoC includes a plurality of processors and at least one shared resource, such as an input/output (IO) port or a memory. A queue manager (QM) includes a plurality of input first-in first-out memories (FIFOs) and a plurality of output FIFOs. A first application writes a first request to access the shared resource. A first application programming interface (API) loads the first request at a write pointer of a first input FIFO associated with the first processor. A resource allocator reads the first request from a read pointer of the first input FIFO, generates a first reply, and loads the first reply at a write pointer of a first output FIFO associated with the first processor. The first API supplies the first reply, from a read pointer of the first output FIFO, to the first application.


