SoC Resource Isolation Using Group and Domain Access Control
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing System-on-a-Chip (SoC) configurations face challenges in managing resource isolation due to the integration of hardware from different vendors, requiring complex coordination and additional test cycles for software updates, and lack a unified isolation scheme that allows independent development and management of software components.
Innovation Solution
A multiple level resource isolation system for SoC, comprising initiator devices, access identifier assignment (AIDA) devices, and access control (AC) devices, which use group and domain identifiers (GIDs and DIDs) to manage resource access and isolation, allowing independent management of groups and domains without global coordination, and includes partition and group managers to program access rights and permissions.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a unified isolation scheme is implemented across all components in an SoC, then resource isolation and security are improved, but device complexity and coordination requirements increase significantly
Solution Approach 1:
The isolation management system is segmented into multiple independent levels: a unified isolation scheme at the SoC level and vendor-specific isolation schemes at the component level. Each level operates independently with its own management entity, allowing the unified scheme to provide overall security while vendor-specific schemes handle component-level details without requiring global coordination for every change.
Solution Approach 2:
An intermediary isolation management entity is introduced that sits between the unified isolation scheme and vendor-specific components. This intermediary translates unified isolation requirements into vendor-specific implementations, allowing changes at one level without requiring coordination with all other vendors, thus reducing overall system complexity while maintaining security.
2Reliability
If a unified isolation scheme is coordinated between all vendors, then security and safety are improved, but the time and effort for software updates and testing increase
Solution Approach 1:
The system segments isolation management into independent layers where the unified isolation scheme handles security-critical path coordination while vendor-specific isolation schemes handle implementation details. This allows software updates to be tested independently at the vendor level without requiring full system re-coordination, significantly reducing test cycle time while maintaining security integrity.
Solution Approach 2:
Vendor-specific isolation schemes are configured and tested in advance independently of the unified isolation scheme. This preliminary action allows vendors to prepare and validate their isolation implementations separately, so that when integration occurs, minimal re-testing is required, reducing overall time loss.
3Adaptability or versatility
If hardware components from different vendors are integrated into one SoC, then functionality and performance are improved, but coordination of isolation management becomes problematic
Solution Approach 1:
The isolation management is segmented into a unified upper layer for cross-vendor coordination and vendor-specific lower layers for implementation. This segmentation allows hardware from different vendors to be integrated with improved ease of operation, as each vendor only needs to comply with the unified interface requirements rather than coordinating all isolation details with every other vendor.
Solution Approach 2:
A universal isolation management interface is established that works across all vendor-specific implementations. This universal interface allows the unified isolation scheme to operate effectively with hardware from any vendor without requiring custom coordination arrangements, improving ease of operation while maintaining multi-vendor adaptability.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
An SoC with a multiple level resource isolation system including initiator devices that conduct transactions with addressed slave devices via an interconnect, access identifier assignment (AIDA) devices that append an access identifier (AID) including a group identifier (GID) and a domain identifier (DID) to each transaction of a corresponding initiator device, access control (AC) devices that control access to slave devices based on an AID provided with a transaction, a partition manager that programs GIDs into the AIDA and AC devices for assigning slave devices to groups, and group managers that program DIDs into the AIDA devices for each matching GID programmed therein, and that program the AC devices with access rights to one or more DIDs for each slave device assigned to a corresponding group with a matching GID programmed therein.