Viewpoint: Memory BIST for shared-bus applications
D Sargent -February 16, 2012
A typical application of memory BIST includes a BIST controller to generate algorithms and verify results and includes MUX logic local to each memory to provide test stimulus to the memories. Thus, in shared-bus applications, not only would the BIST interfere with the performance of the functional path to the memory with a MUX delay, but it would also bypass the functional path during BIST tests.
Design blocks with a shared bus and with memories on the bus (memory clusters) have a functional interface to the bus (see the figure).
The critical timing and pipelines for the shared bus are located inside the memory cluster. The other side of the memory cluster interface often has relaxed timing. Thus, a logical solution is to place the shared-bus memory BIST controller, interface logic, and TAP to control it outside of the memory cluster. MUX logic used to access the memories is implemented in the BIST interface outside the cluster. This approach preserves the performance of the shared bus while ensuring the benefits of self-test, repair, and debug you get with memory BIST.
Shared-bus memory BIST has a special structure because it doesn’t interface directly to the memories it is testing. It treats each logical memory as a separate test target, regardless of the number of actual physical memories within them. Automation for this type of memory BIST insertion and operation exists with just a few additional files that let the memory BIST tool understand the structure of the shared bus. These files include a memory cluster library file to describe the shared-bus interface port, a logical memory file, and a physical memory file. The logical memory represents a complete address space as seen from outside the shared-bus interface. Knowledge of the physical memory information is necessary for memory repair.
Built-in self-repair is also supported with shared-bus applications. The self-repair registers, however, are located inside the memory cluster, since they directly drive the memory repair ports. This is acceptable because the registers are not located on the shared bus or other performance-critical paths. A separate serial port is used to load the self-repair registers. A shadow of the repair registers is located outside of the memory cluster local to the BIST controller to avoid routing congestion of controller data that is used to write repair information for a repair efuse.
Not only does the shared-bus memory BIST approach preserve the performance of the shared bus, but it also tests the functional interface to the memories. Since the BIST MUXes are outside the memory cluster, at-speed memory BIST tests will propagate through the functional shared-bus path.
Shared-bus memory BIST can be used in applications where the functional path to the memory performance is critical and where there is a higher-level interface to a collection of memories. All the advantages of memory BIST are available along with the ability to test through the functional paths without any performance impact on the memory functional paths. T&MW
To read other Viewpoint columns, go to www.tmworld.com/viewpoint.