Virtual Function Interrupt Routing in Multi-Die CGRA Processors
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Reconfigurable processors, particularly coarse-grained reconfigurable architectures (CGRAs), are optimized for single-task and static-workload scenarios, conflicting with the multi-tenancy and dynamic resource allocation requirements of cloud computing, leading to hardware underutilization due to the lack of practical virtualization support for accelerators.
Innovation Solution
A system is developed that enables the execution of multiple applications on a reconfigurable processor with two dies, ensuring isolation and efficient resource sharing by supporting virtual functions, utilizing a compiler to map operations to CGR units across dies and managing data flow and synchronization in parallel and pipelined computation.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If reconfigurable processors are optimized for single-task and static-workload scenarios, then execution efficiency for specific tasks is improved, but hardware utilization deteriorates when multi-tenancy and dynamic resource allocation are required
Solution Approach 1:
The reconfigurable processor is divided into multiple independent CGR arrays that can be individually allocated to different virtual functions. Each CGR array operates as an independent execution unit, allowing the system to segment hardware resources and assign them to multiple tenants simultaneously, thereby improving hardware utilization while maintaining execution efficiency for each task
Solution Approach 2:
The reconfigurable processor is designed to support multiple virtual functions on a single device, enabling one physical processor to serve multiple roles and tenants. The CGR arrays can be dynamically reconfigured to handle different workloads, making the hardware universal and adaptable to various computing tasks while maintaining high utilization rates
2Adaptability or versatility
If virtualization support is added to reconfigurable processors, then multi-tenancy capability is improved, but device complexity increases
Solution Approach 1:
A runtime processor is introduced as an intermediary component to manage virtualization functions, configuration loading, and resource allocation. This mediator handles the complexity of virtualization support, allowing the main reconfigurable processor to focus on execution while the runtime processor manages the overhead of multi-tenancy, thus reducing the complexity burden on the core processing units
3Quantity of substance
If multiple CGR arrays are distributed across two dies, then resource capacity is improved, but interrupt handling complexity increases
Solution Approach 1:
Multiple CGR arrays distributed across two different dies are merged into a single unified reconfigurable processor through the runtime processor. The runtime processor aggregates the arrays and presents them as a cohesive resource pool to virtual functions, simplifying interrupt handling by providing a centralized management point rather than requiring each die to independently manage its own interrupts
Data Source
AI summary
A system is presented that includes a communication link, a runtime processor, and a reconfigurable processor. The reconfigurable processor is adapted for generating an interrupt to the runtime processor in response to a predetermined event and includes first and second dies arranged in a package, having respective first and second arrays of coarse-grained reconfigurable (CGR) units, and respective first and second communication link interfaces coupled to the communication link. The runtime processor is adapted for configuring the first and second communication link interfaces to provide access to the first and second arrays of coarse-grained reconfigurable units from first and second physical function drivers and from at least one virtual function driver, and the reconfigurable processor is adapted for sending the interrupt to the first or to the second physical function driver and for sending the interrupt to a virtual function driver of the at least one virtual function driver.