Talk:Scan chain

Test pattern question
Thanks, --Abdull (talk) 23:12, 9 February 2010 (UTC)
 * In a full scan design, Automatic test pattern generation is particularly simple. No sequential pattern generation is required - combinatorial tests, which are much easier to generate, will suffice.
 * What is a sequential pattern? What is a combinatorial test - and why is it much easier to generate than a sequential pattern?

I agree that this article needs to answer those questions. Here's a rough draft:

A combinational logic circuit with N input bits (and, by definition, no internal state) is easy to test. For a single combinational test, the test machine setts some pattern of N input bits, waits for things to settle, and then checks that the device under test gives the proper output pattern. For an exhaustive test, the machine applies all 2^N possible combinational tests. Because it has no internal state, the test machine can apply the patterns in any convenient order. (Some people prefer using a de Bruijn sequence rather than "natural binary" order). If interrupted, the test machine can immediately resume the test at any point. If (hypothetically) the scan chain partitions up the system so that each combinational output bit depends on at most 8 input bits, you can exhaustively test the logic of entire circuit with 2^8 = 256 iterations of "set next input pattern / check output pattern". Once a person picks some sequence for the 2^8 input patterns ("natural binary", de Bruijn sequence, etc.), the test machine can apply the same sequence of input patterns to test any combinatorial circuit with up to 8 input bits.

A sequential logic circuit with the same N input bits (and, by definition, more than one internal state) is more difficult to test. A single sequential test includes the test machine setting some series of patterns of N input bits to get the circuit to a known state, then setting some other series of patterns of N input bits to persuade the device under test to move to state that we wanted to test, and then finally checking that the device under test gives the proper sequence of output patterns. For example, a synchronous 32-bit counter may have only 3 input bits ("reset" and "step" and "clock"). The "roll-over test" -- a sequential test that makes sure the counter rolls over properly -- takes a while. First the test machine sets the reset high and clock low, then reset high and clock high, then reset low and clock low -- that's just to get the device in a known state. Then the test machine goes through two more input patterns to get the counter to take a step. Then the test machine repeats that step 2^32 = 4,294,967,296 iterations and confirms that the counter actually did roll over properly. If we are almost done with the "roll-over test", and the test is interrupted and the counter is reset, it may not be possible to continue the test from where we left off -- we have to re-start the test at or near the beginning. Even after we finish the "roll-over test", the logic of the counter still hasn't been exhaustively tested. In particular, if the reset line is partially broken so that it is not connected to the high bit of the counter, the "roll-over test" may never detect that error. Generally a different sequence of input patterns is required for other 3-input-bits, 32-internal-bit sequential circuits that need to be tested.

Alas, I think this rough draft goes into far too much detail. ''Is there a better way of answering those questions in the article? --DavidCary (talk) 16:51, 19 August 2011 (UTC)''


 * It isn't normal to apply all 2N input test vectors. Goals are adopted for the kind of faults to find. One of the fault types that is usually tested for is the stuck fault, which is a signal that is stuck at a 0 or 1 when it should be capable of switching to either level when appropriate inputs are present. A satisfactory test pattern forces all nodes to assume both the 0 and 1 level, and insures that if any node is stuck at 0 or 1, a discrepancy will be caused in at least one output signal in at least one test vector. The number of tests required to do this is normally much less than 2N. Jc3s5h (talk) 17:20, 19 August 2011 (UTC)


 * What Jc3s5h says is entirely true. The automatic test pattern generation section of the article Jc3s5h pointed out has a few sentences that give a very concise answer to the questions Abdull posed.
 * I went ahead a copied those sentences from the ATPG article to this "scan chain" article.
 * Alas, I suspect those sentences are so concise and WP:TECHNICAL that they only make sense to people who already understand all this.
 * How can we make this scan chain article better? --DavidCary (talk) 14:26, 3 September 2011 (UTC)

External links modified
Hello fellow Wikipedians,

I have just modified 1 one external link on Scan chain. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
 * Added archive https://web.archive.org/web/20150226004313/http://people.ee.duke.edu:80/~krish/teaching/ECE269/how_does_scan_work.pdf to http://people.ee.duke.edu/~krish/teaching/ECE269/how_does_scan_work.pdf

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at ).

Cheers.— InternetArchiveBot  (Report bug) 20:11, 1 December 2016 (UTC)