Memory Function Path ATE Testing

Make it to the Right and Larger Audience

Blog/Press Release

Memory Function Path ATE Testing

Memory BIST is well known and widely used to test on-chip memories. However, Mbist does not use function path. Instead it drives memory inputs and check outputs directly. How do we test memory function path on ATE? Pull out a Freescale white paper online, Testing Around Memories – an inside look

It states several ways to deal with the issue. Later we will show other ways and which way is normally adopted these days.

A typical on-chip memory scenario is shown in the following.  We would like to check combo logic at RAM input and output on tester.

The following diagram shows how Mbist is inserted. Mbist drives RAM input (as shown) and checks RAM outputs (not shown) directly. Combo logic can not be checked by Mbist. Due to lack of observation on ram input combo logic and controllability on ram output combo logic, these two combo logic can’t be tested which is the issue here.

One way is to bypass memory. So combo logic stuck-at faults can be detected. But since bypass changes func path timing, at-speed test can not be done.

The following is another way to bypass memory. Same downside. It can cover stuck-at faults but not at-speed faults.

One way to cover both stuck-at and at-speed faults is to explore the nature of RAM that it can capture data and it can also preload data and then drive outputs. This is what below diagram means.

Below shows some detail of memory write/read/capture sequence. For details, please refer to above white paper. Again intention here is to check memory external function path timing. The paper stops here. But this RAM based method has some drawbacks. What if DUT is not an RAM but a ROM? We can’t write to it so we can’t capture data into it. In addition it also complicates ATPG pattern generation and more importantly test time is long.

One way proposed was to use Mbist to check combo logic. The way Mbist is inserted is changed. On memory input side Mbist mux is moved outside of combo logic. On memory output side Mbist checks combo logic output and not RAM output. This solution has a clear and fatal downside. Mbist needs to understand how the combo logic which is customer logic works. This approach never flies.

 

Instead what we commonly do is to insert DFT observation cell on memory inputs and DFT controllable cell on memory outputs. Then we can just use the normal shift-capture to check combo logic. In this way RAM is treated as a blackbox. So we can check RAM, ROM, or other hard macro.

A lot of time, memory or other hard macro have built-in boundary scan. This can be viewed as a special case of above obs/ctrl cell insertion. It is just the cells are moved inside memory or hard macro.

 

 

 
Author brief is empty
Groups:

Tags:

1 Comment
  1. chieuluu 9 months ago
    0
    -0

    Good

    5

Contact Us

Thanks for helping us better serve the community. You can make a suggestion, report a bug, a misconduct, or any other issue. We'll get back to you using your private message ASAP.

Sending

©2020  ValPont.com

Forgot your details?