As an example, we will describe automatic test generation using boundary scan together with internal scan. We shall use the function Z = A'B + BC for the core logic and register the three inputs using three flip-flops. We shall test the resulting sequential logic using a scan chain. The simple logic will allow us to see how the test vectors are generated.
Figure 14.31 shows a structural Verilog model of the logic core. The three flip-flops (cell name dfctnb ) implement the input register. The combinational logic implements the function, outp = a_r'.a_r + a_r.a_r[2 ]. This is the same function as Figure 14.14 and Figure 14.16 .
Table 14.15 shows the structural Verilog for the top-level logic of the Threegates ASIC including the I/O pads. There are nine pad cells. Three instances (up1_b0 , up1_b1 , and up1_b2 ) are the data-input pads, and one instance, up2_1 , is the output pad. These were vectorized pads (even for the output that had a range of 1), so the synthesizer has added suffixes ( '_1' and so on) to the pad instance names. Two pads are for power, one each for ground and the positive supply, instances up11 and up12 . One pad, instance up3_1 , is for the reset signal. There are two pad cells for the clock. Instance up4_1 is the clock input pad attached to the package pin and instance up6 is the clock input buffer.
The next step is to insert the boundary-scan logic and the internal-scan logic. Some synthesis tools can create test logic as they synthesize, but for most tools we need to perform test-logic insertion as a separate step. Normally we complete a parameter sheet specifying the type of test logic (boundary scan with internal scan in this case), as well as the ordering of the scan chain. In our example, we shall include all of the sequential cells in the boundary-scan register and order the boundary-scan cells using the pad numbers (in the original behavioral input). Figure 14.32 shows the modified core logic. The test software has changed all the flip-flops (cell names dfctnb ) to scan flip-flops (with the same instance names, but the cell names are changed to mfctnb ). The test software also adds a noninverting buffer to drive the scan-select signal to all the scan flip-flops.
The test software also adds logic to the top level. We do not need a detailed understanding of the automatically generated logic, but later in the design flow we will need to understand what has been done. Figure 14.33 shows a high-level view of the Threegates ASIC before and after test-logic insertion.
- This block is the logic core shown in Figure 14.32 . The Verilog module header shows the “local” and “formal” port names. Arrows indicate whether each signal is an input or an output.
- This is the main body of logic added by the test software. It includes the boundary-scan controller and clock control.
- This block groups together the buffers that the test software has added at the top level to drive the control signals throughout the boundary-scan logic.
- This block is the first boundary-scan cell in the BSR. There are six boundary-scan cells: three input cells for the data inputs, one output cell for the data output, one input cell for the reset, and one input cell for the clock. Only the first (the boundary-scan input cell for a ) and the last boundary-scan cells are shown. The others are similar.
- This is the last boundary-scan cell in the BSR, the output cell for the clock.
- This is the clock pad (with input connected to the ASIC package pin). The cell itself is unchanged by the test software, but the connections have been altered.
- This is the clock-buffer cell that has not been changed.
- The test software adds five I/O pads for the TAP. Four are input pad cells for TCK, TMS, TDO, and TRST. One is a three-state output pad cell for TDO.
- The power pad cells remain unchanged.
- The remaining I/O pad cells for the three data inputs, the data output, and reset remain unchanged, but the connections to the core logic are broken and the boundary-scan cells inserted.
The numbers in Figure 14.34 link the signals in each block to the following explanations:
- The control signals for the input BSCs are C_0, C_1, C_2, and C_4 and these are all buffered, together with the test clock TCK . The single output BSC also requires the control signal C_3 and this is driven from the BST controller.
- The clock enters the ASIC package through the clock pad as .PAD(clk) and exits the clock pad cell as .CIN(up_4_1_CIN1) . The test software routes this to the data input of the last boundary-scan cell as .PI(up_4_1_CIN1) and the clock exits as .PO(up_4_1_cin) . The clock then passes through the clock buffer, as before.
- The serial input of the first boundary-scan cell comes from the controller as .bst_control_BST_SI(test_logic_bst_control_BST_SI) .
- The serial output of the last boundary-scan cell goes to the controller as .bst_control_BST(up4_1_bst_SO) .
- The beginning of the BSR is the first scan flip-flop in the core, which is connected to the TDI input as .a_r_ff_b0_DA(ta_TDI_CIN) .
- The end of the scan chain leaves the core as .a_r_2(uc1_a_r_2) and enters the controller as .bst_control_scan_SO(uc1_a_r_2) .
- The scan-enable signal .bst_control_C_9(test_logic_bst_control_C_9) is generated by the boundary-scan controller, and connects to the core as .taDriver12_I(test_logic_bst_control_C_9) .
The added test logic is shown in Figure 14.35 . The blocks are as follows:
- This is the module declaration for the test logic in the rest of the diagram, it corresponds to block B in Table 14.34 .
- This block contains buffers and clock control logic.
- This is the boundary-scan controller.
- This is the first of 26 IDR cells. In this implementation the IDCODE register is combined with the BSR. Since there are only six BSR cells we need (32 – 6) or 26 IDR cells to complete the 32-bit IDR.
- This is the last IDR cell.
TABLE 14.16 The TAP (test-access port) control. 1
The numbers in Figure 14.35 refer to the following explanations:
- The system clock (CLK, not the test clock TCK) from the top level (after passing through the boundary-scan cell) is fed through a MUX so that CLK may be controlled during scan.
- The signal bst_control_BST is the end (output) of the boundary-scan cells and the start (input) to the ID register only cells.
- The signal id_reg_0_SO is the end (output) of the ID register.
- The signal bst_control_BST_SI is the start of the boundary-scan chain.
The job of the boundary-scan controller is to produce the control signals ( C_1 through C_9 ) for each of the 16 TAP controller states ( reset through update_IR ) for each different instruction. In this BST implementation there are seven instructions: the required EXTEST , SAMPLE , and BYPASS ; IDCODE ; INTEST (which is the equivalent of EXTEST , but for internal test); RUNBIST (which allows on-chip test structures to operate); and SCANM (which controls the internal-scan chains). The boundary-scan controller outputs are shown in Table 14.16 .
There are two very important differences between this controller and the one described in Table 14.5 . The first, and most obvious, is that the control signals now depend on the instruction. This is primarily because INTEST requires the control signal at the output of the BSCs to be in different states for the input and output cells. The second difference is that the logic for the boundary-scan cell control signals is now purely combinational—we have removed the gated clocks. For example, Figure 14.36 shows the input boundary-scan cell. The clock for the shift flip-flop is now TCK and not a gated clock as it was in Table 14.5 . We can do this because the output of the flip-flop, SO , the scan output, is added as input to the MUX that feeds the flip-flop data input. Thus, when we wish to hold the state of the flip-flop, the control signals select SO to be connected from the output to the input. This is called a polarity-hold flip-flop . Unfortunately, we have little choice but to gate the system clock if we make the scan chain part of the BSR. We cannot have one clock for part of the BSR and another for the rest. The costly alternative is to change every scan flip-flop to a scanned polarity-hold flip-flop.
FIGURE 14.36 Input boundary-scan cell (BSC) for the Threegates ASIC. Compare this to the generic data-register (DR) cell (used as a BSC) shown in Figure 14.2 .
Table 14.17 shows the results of running the Compass ATVG software on the Threegates ASIC. We might ask: Why so many faults? and why is the fault coverage so poor? First we look at the details of the test software output. We notice the following:
- Line 2 . The backtrace limit is 30. We do not have any deep complex combinational logic so that this should not cause a problem.
- Lines 4 – 6 . An uncollapsed fault count of 184 indicates the test software has inserted faults on approximately 100 nodes, or at most 50 gates assuming a fanout of 1, less gates with any realistic fanout. Clearly this is less than all of the test logic that we have inserted.
To discover why the fault coverage is 68.25 percent we must examine each of the fault categories. First, Table 14.18 shows the undetected faults.
The ATVG program is generating tests for the core using internal scan. We cannot test the BST logic itself, for example. During the production test we shall test the BST logic first, separately from the core—this is often called a flush test . Thus we can ignore any faults from the BST logic for the purposes of internal-scan testing.
Next we find two redundant faults: TA_TDO.1.I sa0 and sa1 . Since TDO is three-stated during the test, it makes no difference to the function of the logic if this node is tied high or low—hence these faults are redundant. Again we should ensure these faults will be caught during the flush test. Finally, Table 14.19 shows the tied faults.
Now that we can explain all of the undetectable faults, we examine the detected faults. Table 14.20 shows only the detected faults in the core logic. Faults F1–F8 in the first part of Table 14.20 correspond to the faults in Figure 14.16 . The fault list in the second part of Table 14.20 shows each fault in the core and whether it was detected (D) or collapsed and detected as an equivalent fault (CD). There are no undetected faults (U) in the logic core.
Next we generate the test vectors for the Threegates ASIC. There are three types of vectors in scan testing. Serial vectors are the bit patterns that we shift into the scan chain. We have three flip-flops in the scan chain plus six boundary-scan cells, so each serial vector is 9 bits long. There are serial input vectors that we apply as a stimulus and serial output vectors that we expect as a response. Parallel vectors are applied to the pads before we shift the serial vectors into the scan chain. We have nine input pads (three core data, one core clock, one core reset, and four input TAP pads— TMS , TCK , TRST , and TDI ) and two outputs (one core data output and TDO ). Each parallel vector is thus 11 bits long and contains 9 bits of stimulus and 2 bits of response. A test program consists of applying the stimulus bits from one parallel vector to the nine input pins for one test cycle. In the next nine test cycles we shift a 9-bit stimulus from a serial vector into the scan chain (and receive a 9-bit response, the result of the previous tests, from the scan chain). We can generate the serial and parallel vectors separately, or we can merge the vectors to give a set of broadside vectors . Each broadside vector corresponds to one test cycle and can be used for simulation. Some testers require broadside vectors; others can generate them from the serial and parallel vectors.
Table 14.21 shows the serial test vectors for the Threegates ASIC. The third serial test vector is '110111010' . This test vector is shifted into the BSR, so that the first three bits in this vector end up in the first three bits of the BSR. The first three bits of the BSR, nearest TDI , are the scan flip-flops, the other six bits are boundary-scan cells). Since UC1.A_R_FF_B0.Q is a_r and so on, the third test vector will set a_r = 011 where a_r = 0. This is the vector we require to test the function a_r'.a_r + a_r.a_r[2 ] for fault UC1.U2.ZN sa1 in the Threegates ASIC. From Figure 14.31 we see that this is a stuck-at-1 fault on the output of the inverter whose input is connected to a_r . This fault corresponds to fault F1 in the circuit of Figure 14.16 . The fault simulation we performed earlier told us the vector ABC = 011 is a test for fault F1 for the function A'B + BC.
The final step in test-program generation is to format the test vectors for the production tester. As an example the following shows the Sentry tester file format for testing a D flip-flop. For an average ASIC there would be thousands of vectors in this file.
Normally we leave test-vector generation and the production-test program generation until the very last step in ASIC design after physical design is complete. All of the steps have been described before the discussion of physical design, because it is still important to consider test very early in the design flow. Next, as an example of considering test as part of logical design, we shall return to our Viterbi decoder example.