Shared OTP Memory Logic for Local Memory Repair Access
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing memory test and repair systems in hardware accelerators, such as GPUs and FPGAs, suffer from inefficient use of one-time programmable (OTP) memory, leading to significant memory wastage due to dedicated OTP memory allocation for each system, which is not fully utilized.
Innovation Solution
Implementing a single OTP memory partitioned into multiple partitions, with an offset addition scheme allowing multiple systems to access repair data sequentially, optimizing memory usage and reducing waste.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If a dedicated OTP memory is allocated for each main-controller in a hierarchical memory test architecture, then each controller can independently access repair data without coordination overhead, but significant memory space is wasted since each controller does not utilize its entire allocated OTP memory space
Solution Approach 1:
Multiple main-controllers share a single common OTP memory resource instead of each having dedicated OTP memory. The OTP memory is partitioned into multiple partitions, with each partition storing repair data for a specific main-controller. This merging approach eliminates memory wastage while maintaining independent access capabilities through partitioned organization.
Solution Approach 2:
The common OTP memory is segmented into multiple partitions, where each partition is dedicated to a specific main-controller. This segmentation allows each controller to access only its required repair data portion, preventing interference between controllers while maximizing memory utilization. The partitioning structure enables efficient space usage without sacrificing operational independence.
2Loss of substance
If multiple main-controllers share a common OTP memory with partitioned repair data, then memory space utilization is maximized, but coordination overhead and access complexity increase due to the need for grant signal management
Solution Approach 1:
An intermediary control mechanism manages access to the shared OTP memory by issuing grant signals to main-controllers. The system includes control logic that arbitrates between multiple controllers, granting access permissions sequentially or concurrently based on readiness signals. This intermediary layer coordinates access without requiring complex direct negotiation between controllers, simplifying the overall system architecture.
Solution Approach 2:
Main-controllers indicate their readiness to access repair data in advance by asserting readiness signals before actual access is needed. The control logic uses these preliminary indications to pre-coordinate access permissions, issuing grant signals before the controller needs to read its repair data. This preliminary action reduces access latency and simplifies coordination by establishing access rights beforehand.
3Speed
If repair data for multiple main-controllers is stored in separate dedicated OTP memories, then access time is minimized with no coordination overhead, but the total memory capacity required increases significantly
Solution Approach 1:
Multiple OTP memory resources are merged into a single shared OTP memory structure that serves all main-controllers. By consolidating what would otherwise be separate dedicated memories, the system reduces total memory capacity requirements while maintaining efficient access times through partitioned organization and controlled access mechanisms.
Data Source
Figure 1~2
Figure 3~6
Figure 4
AI summary
According to an embodiment, a method for testing and repairing local memory (108) in a hardware accelerator (100) from a one-time programmable memory, OTP (502) is provided. The method includes asserting a grant signal (804), a loading of a first repair data for a sub-set of the local memory (108) associated with a main-controller (706a) from a first partition (602) of the OTP memory, communicating a status signal (806) after completion of the loading indicating a completion of the loading, and de-asserting the grant signal (804) in response to receiving the status signal (806).