 | |  | |  | |  | |  | |  |
DFT Tips for implementing Boundary Scan in your design.
1) Simple rule - provide Boundary Scan access to all Flash device pins. Simple to ask for, but very
difficult to get. Just as mentioned with Memory device testing, Flash test models are typically coded for
the stand-alone part. If you have topological restrictions induced due to non-access, more than likely
the model will not work and you will have to modify or code a new Flash test algorithm for your parts.
This can require considerable effort, given the device complexity.
2) Providing external access to your Ready/Busy and Write-Enable lines will speed up your Flash
programming. But, you must have the ability to monitor or drive then externally via a boundary scan cell.
Products like the AccessExtender(TM) can aide with this access. Please consult with your Boundary
Scan Software provider for further information on this technique.
3) Programming a large Flash - If you are worried about throughput time in manufacturing, we
recommend Boundary Scan programming of 'Boot Code' into your Flash device and doing a full Flash
program at functional test. The reason is that Parallel Scan programming runs slow (TCK rates) when
compared to system clock rates. If the programming time does not worry you, Boundary Scan is a good
tool for programming your Flash parts.
4) Use spare scan cells/spare pins to provide access to the Flash parts. We like to recommend using
spare FPGA pins/scan cells to provide this access...if of course, you have spare pins...
5) Remember one thing - testing (a write and a read) to the Flash device via Boundary Scan will
overwrite those locations in Flash. If you have pre-programmed parts, you can do a Verify without this
complication. If your designer wants you to test (write & read) the Flash, try recommending he define a
specific block or address space that is unused in the Flash for this testing.
6) Multiplexed Address and Data - We recommend checking your Boundary Scan software to see if it
can handle this. Another issue that has recently come up is multiplexed data and control....and an
inversion of control signals during this multiplexing. Again, check to see if your software can handle
these issues...if not, DFT hooks may be needed to 'ease' the pain of testing and programming these
Flash devices.
difficult to get. Just as mentioned with Memory device testing, Flash test models are typically coded for
the stand-alone part. If you have topological restrictions induced due to non-access, more than likely
the model will not work and you will have to modify or code a new Flash test algorithm for your parts.
This can require considerable effort, given the device complexity.
2) Providing external access to your Ready/Busy and Write-Enable lines will speed up your Flash
programming. But, you must have the ability to monitor or drive then externally via a boundary scan cell.
Products like the AccessExtender(TM) can aide with this access. Please consult with your Boundary
Scan Software provider for further information on this technique.
3) Programming a large Flash - If you are worried about throughput time in manufacturing, we
recommend Boundary Scan programming of 'Boot Code' into your Flash device and doing a full Flash
program at functional test. The reason is that Parallel Scan programming runs slow (TCK rates) when
compared to system clock rates. If the programming time does not worry you, Boundary Scan is a good
tool for programming your Flash parts.
4) Use spare scan cells/spare pins to provide access to the Flash parts. We like to recommend using
spare FPGA pins/scan cells to provide this access...if of course, you have spare pins...
5) Remember one thing - testing (a write and a read) to the Flash device via Boundary Scan will
overwrite those locations in Flash. If you have pre-programmed parts, you can do a Verify without this
complication. If your designer wants you to test (write & read) the Flash, try recommending he define a
specific block or address space that is unused in the Flash for this testing.
6) Multiplexed Address and Data - We recommend checking your Boundary Scan software to see if it
can handle this. Another issue that has recently come up is multiplexed data and control....and an
inversion of control signals during this multiplexing. Again, check to see if your software can handle
these issues...if not, DFT hooks may be needed to 'ease' the pain of testing and programming these
Flash devices.
DFT Tips - FLASH testing
| Copyright ©2009 JEK Technical Services LLC All Rights Reserved |
| Information on this page is provided free of charge and is subject to the Legal Notices posted on this website. |