testing shadow logic around the memory

Status
Not open for further replies.
N

newebu

Newbie level 5
Joined
Mar 11, 2014
Messages
10
Helped
1
Reputation
2
Reaction score
1
Trophy points
3
Visit site
Activity points
70
Hi,
What does shadow logic around the memory mean? Does this include the muxes for selcting functional or bist mode signals ? I need to understand more on this and testing shadow logic.
 

To give a literary meaning, In DFT we consider Memories as "BLACK BOX" and all the combinational design which interacts directly with this BLACK BOX will be considered as a "SHADOW LOGIC".

Yes this would include the MUXes also.

Since memory is a block box the signals feeding memory will not be observable and signals driven by memory will not be controllable. A DFT engineer has to consider this scenario for increasing the coverage. The testability of this shadow logic can be improved with the help of different types of "Test Point Insertion". A synopsys DFT Compiler manual would be best place to give you clear idea on this.
 

Some ATPG tools are available to read/write a ram, means, during the catpure phase to execute a write/read into/from the RAMs, and by this to check the various pins of the RAMs.
Generally, we could avoid this, becaue the BIST-march engine will be used to test the RAMs, and so check the pins.

You could indicate to ATPG tools, which pins area already covered if that could help to reach the coverage.
 

generally how much coverage improvement can we expect from this? and also test pattern generation time should be more for ram_sequential mode. Please clarify .
 

You will only cover the stuck 0/1 of all pins of the memories, not so much, that are normally covered by the RAMs bist.
One issue, if you have a hardware bist, perhap, the path to stimulate the RAMs it is not the same as the functional paths, and we could not "garantee" the coverage.
To garantee the memories pins and path are correctly tested for the functional mode, you need to executed some read/write or run a software bist, but do not forget if one instance could be accessed by different path, to check all of them.
 

How can we take care of testing dual port memory during ATPG? As far as I know dual port memories will be tested with custom alogorithm using BIST, so just eager to know how it is done during ATPG?
 

ATPG and bist are two differents mechanism, and compeltly independent.
I means you will run the ATPG patterns to test the std cell, and you will run the BIST to test the memory in a second patterns.
The ATPG tool does not know the bist and don't care of the coverage done by the BIST.

The only interest could be to include the memory pin coverage in the stuck-at-fault coverage.

An ATPG (automatic tool pattern generation), only generate patterns on scan chain structure.
The BIST if it is hardware, is added by Test tool, which add the logic to the design to do the hardware BIST, but to enable/run/read the result of the BIST, the pattern is not generate by an ATPG tool.
 

Thank you. I got the difefrence between ATPG and BIST.
But when we do RAM sequential ATPG , we do write to atleast one memory location and scanout the data to ensure address , data pins and control pins toggle. I understand RAM sequential for single port memory. is there any difference between RAM sequential for dual port and single port memories or different kinds of memories?
 

why do you want the ATPG tool generate a pattern to read/write RAMs, as this will be covered by the BIST?
 

Status
Not open for further replies.

Similar threads

Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…