Distributed Memory Repair Network for Scalable BISR
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing BISR systems face challenges in scalability due to excessive nonvolatile memory usage and slow repair information loading, as they generate and store repair information for all memory components, regardless of defects, leading to increased costs and complexity.
Innovation Solution
Implementing a distributed memory repair network where each sub-block is attached to a volatile memory component, connected via a shared configuration bus, allowing only defective sub-blocks to generate and store repair vectors, reducing nonvolatile memory usage and improving loading speed by skipping non-defective sub-blocks.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If repair information is generated for each memory component regardless of defects, then all memory components can be repaired, but nonvolatile memory usage increases and system scalability is adversely impacted
Solution Approach 1:
The patent extracts only the necessary repair information from each sub-block. Instead of generating repair vectors for all memory components, the system identifies and extracts repair information only from sub-blocks that contain defective columns, eliminating unnecessary data storage.
Solution Approach 2:
The memory system is divided into multiple independent sub-blocks, each with its own repair vector. This segmentation allows the system to process and store repair information for only those sub-blocks that require repair, rather than treating the entire memory as a single unit.
2Reliability
If repair information is stored in embedded nonvolatile memory, then repair information is readily available, but system scalability is reduced
Solution Approach 1:
The system segments repair information storage across multiple sub-blocks, each maintaining its own repair vector in local nonvolatile memory. This segmentation enables the system to scale by adding or removing sub-blocks independently, as each sub-block is self-contained with its own repair capabilities.
3Device complexity
If repair information is serially shifted using low speed clock, then routing is simplified, but loading time increases significantly
Solution Approach 1:
The patent extracts and loads only the necessary repair information for defective sub-blocks. By identifying which sub-blocks require repair and loading only their corresponding repair vectors, the system reduces the total amount of data that must be serially shifted, thereby reducing loading time while maintaining simple routing.
Solution Approach 2:
The system skips sub-blocks that do not require repair by checking the defective column status before initiating the loading process. This allows the system to quickly identify and load only the necessary repair information, reducing overall loading time without requiring faster or more complex routing infrastructure.
4Quantity of substance
If compressed repair information is used, then nonvolatile memory usage is reduced, but decompression time and processing complexity increase
Solution Approach 1:
The system extracts and stores only the essential repair vectors for defective columns, eliminating the need for compression algorithms. By taking out only the necessary repair information and storing it in an uncompressed format, the system achieves compact storage without introducing the complexity of compression and decompression operations.
Data Source
AI summary
A device includes a plurality of memory components with redundant columns associated therewith, a sub-block controller, and a volatile memory. The sub-block controller generates a repair vector, during manufacture testing mode. The repair vector is associated with the plurality of memory components and is generated responsive to detecting a defect within a column of the plurality of memory components. No repair vector is generated responsive to detecting no defect within a column of the plurality of memory components. The volatile memory receives and stores the repair vector in a nonvolatile memory component, during the manufacture testing mode. The volatile memory receives the repair vector from the nonvolatile memory component if the repair vector was generated during the manufacture testing mode, at startup mode, and provides it to the sub-block controller. The sub-block controller loads a repair data into the plurality of memory components based on the repair vector.