Here is a look at a number of common problems and misunderstandings when it comes to WGL files with scan present.
Scan insertion to enhance test coverage and reduce test pattern volume is quite common in Design for Test (DFT) tools nowadays. All of the major ATPG tool vendors (Synopsys, Cadence, and Mentor) offer this approach in their product suites. And indeed this approach has proven to be very effective, together with some other pattern compression techniques, in helping design/test engineers meet the challenges for today's complex devices.
The way in which scan is handled within WGL files is often a source of confusion for engineers using this language as the medium for pattern expression. One primary reason for this confusion is that the scan data expressed in the WGL file is cell data, not shift data. This means that when translating these patterns into an actual test program for ATE, a mapping must be done by the translation tool because real device test programs must have shift data. It is this mapping which can cause confusion and sometimes errors.
Let's look at how the scan information is represented in a WGL file:
• First of all, there is a scancell block which identifies all of the scan cells by name (some of which can get very long with hierarchy) and also here there can be scan cell groups defined. One popular vendor's tool creates groups which correspond to those cells which are contained in each scan chain.
• The next block as part of scan structures in WGL is the scanchain block. Here each scan chain is specified with a name, the scan-in pin, then an ordered list of the cells (by name) followed by the scan-out pin. All scan chains must have at least a scan-in signal or a scan-out signal or both. Included in the cell list can be '<img alt="' characters which indicate that there is a logic inversion between the cells it separates.
• Finally there is the scanstate block which typically specifies the actual scan data to be assigned to each cell in a scan chain (or scan chain group) for each scan operation. A unique name is specified for each set of scan data so the assignment of this data can be called out at each scan operation. Now, the information in these three blocks can be used with a "scan" statement within the pattern section of the file to execute a scan load/unload operation on the device.
Let's take a look at these in more detail. As mentioned above, when you assign data specified in the scanstates section of the WGL file it is cell data, not shift data. As a result any inversions in the scan chain between each cell and the scan-in or scan-out pins must be taken into account when converting from cell data to shift data.
For example, if a cell has 2 inversions between itself and the input scan pin, then the cell data will be the same as the shift data for that pin. If there are 3 inversions then it must be inverted when translating from cell data to shift data. This rule is applied to each cell individually, on both input and output shift data. It is not just the overall total number of inversions from scan-in to scan-out that matters, it is the number of inversions for each cell from scan-in pin and to scan-out pin that matters. This can cause strange mappings of the data when translating from cell data to shift data. In the following example the character in the scan chain represents a logic inversion between the cells:
[EDNAOL 2016JUN07 TA 01Fig1]" src="https://images.contentful.com/7jb0g1eg08yi/1Lln4sk3VikEeWmMSuYkKi/d3f269b1293ab64059fde35ab48be756/EDNAOL_2016JUN07_TA_01Fig1.gif" />
SCAN CHAIN is comprised of the SCI scanin pin, the ordered list of scan cells in the chain (with inversions indicated), and SCO – the scan-out pin. LOAD CELL DATA are the states specified in the scanstate block for these cells; we want to end up with this data in the cells. SHIFT-IN DATA is the translated shift data that will give us the desired cell data after shifting. Here, the left-bit is shifted in first to SCI. UNLOAD CELL DATA are the states in the cells prior to the shift process. We expect to see these come out on the SCO pin. Here the SCAN-OUT DATA is left-bit shifted out first from SCO. As you can see, the cell data (as presented in the WGL file scanstates block) looks quite different when mapped to the shift data which is needed by all ATE.
Here is a cycle-by-cycle view of this shift process:
In summary, when looking in the scanstate block data in this example for the scan load operation, one would see the desired cell data 11100 whereas the translated shift data for loading these states into the cells would be 10011. Similarly for the unloading process the expected cell states of 11100 would show-up on the SCO pin after translation as 01100.
Some common issues
Having looked at a very large number of WGL files with scan present, there are a number of common problems/misunderstandings which seem to fall into one of the following categories: