Home » Corelis Boundary-Scan Blog » Flash Programming – Part 3 of Test Coverage Q and A

Flash Programming – Part 3 of Test Coverage Q and A

Part 3: Flash Programming
In-system-programming is a popular application of JTAG/Boundary-scan, but what about test coverage? How can flash (and other non-volatile memories) be tested and what kind of test coverage is available?

In this article we’ll explore which flash tests offer coverage and how that coverage is presented in ScanExpress DFT Analyzer.

Q: How do ScanExpress tools handle calculate test coverage for flash memory components?

A: This is a complex topic because in general, flash components are not boundary-scan compatible. In order to verify interconnections, the flash component is treated as a cluster and its functional behavior is used to verify interconnections, much like with memory cluster tests. To understand flash coverage, we’ll first look at a typical configuration and then examine the tests.

Let’s take a look at a typical boundary-scan component connected to parallel NOR flash, as shown in the example schematic. By analyzing the connections while considering the test vectors to be applied, we can observe analytically which fault cases will be caught on each type of pin.


Figure 4. Example boundary-scan component and flash memory schematic

Flash Tests
There are two main optional verification steps provided with flash programming in ScanExpress tools. Note that these features provide testing outside of what is covered by in-system-programming erase/program/verify process. Note that we are only considering verification of the interconnections between the boundary-scan device and flash, not the functionality of the flash component—though basic functionality is of course required for the test to operate in the first place.

Check Device ID Prior to Programming
During the device ID test the boundary-scan component will perform an auto-select operation by driving alternating ones and zeros in a pattern shown in the table below. The alternating one and zero patterns provide a quick test that provides some amount of assurance that the address, data, and control interconnections are working.


Table 1. Device ID test command cycles

Check Interconnect Prior to Programming
The Flash interconnect test will perform a sliding 1 test on the address bus while sliding a 0 on the data bus for full verification of flash interconnects, much like the memory cluster test that is used for RAM components. Note that this test is destructive and will erase the flash contents. After the test finishes, some test data will be left in the flash.

Flash Pin Types
We will look at three categories of pins: Address, Data, and Control.

Address Pins
Address pins are commonly connected as individual direct lines from the boundary-scan component to the flash component. The boundary-scan pins may be defined as single-direction or bidirectional—this will depend on the boundary-scan device. Note that the tests will slide values across the address bus and verify that the correct data is returned—for example, if a pin is shorted or open, we’d expect to see the same data returned for multiple addresses. This provides full coverage on each address pin that participates in the test.

Note that the flash interconnect test allows diagnosis of faults down to address line level.

Control Pins
Control pins are considered critical to flash operation and, like address pins, are often single direction with no tri-state capability. If the test works, then the control pins must be connected and not shorted, right? This is of course a simplistic view and—depending on the component, may not be accurate.

For example, the flash test may still pass if, for example, the chip select line is stuck active. A negative test that attempts to access the flash with the chip select line inactive may be used to verify that the flash does not respond when chip select is inactive. Thus we can label flash control pins with partial coverage, but the reality may be different and would require a more comprehensive model.

Data Pins
Data pins must be bidirectional to allow both reading and writing to the flash component. An open or stuck fault will be caught by the flash interconnect test patterns. Just like address pins, data pins have complete coverage and faults can be diagnosed to the data line level.

Now, with all of that out of the way, let’s address the questions at hand.

Q: A Flash control pin shows PARTIAL coverage, but the net shows COMPLETE coverage. Why is the Flash pin not considered to have COMPLETE coverage?

A: Flash control pins, unlike memory cluster control pins, are currently considered to be PARTIAL unless they otherwise qualify for complete coverage. As discussed, flash control pin coverage is not as clear an issue as data and address pins. This is likely under-reporting and may be changed in a future version of the ScanExpress DFT Analyzer.

Q: Can I alter the coverage to account for possible under-reporting?

A: Modern boundary-scan test coverage—including that provided by cluster tests, Flash programming, and CPU-based tests such as those provided with ScanExpress JET—is often under-reported by ATPG tools since it relies on un-modeled functional behavior of components.

The ScanExpress DFT Analyzer application includes a report editor feature for just this sort of thing. If additional coverage is available and should be included in the coverage reports, the report editor can be used to adapt the reports to a specific test coverage philosophy. Of course, good judgment should always be exercised to avoid overestimating coverage and risking test escapes!

Conclusion
That concludes the series on test coverage. While boundary-scan component to boundary-scan component test coverage is often relatively straightforward, involving non-boundary-scan components adds a layer of complexity that may require some intelligent interpretation by both the tools and the user. If you have any questions or comments, let us know!

Leave a Reply

Your email address will not be published. Required fields are marked *