Source_III
Newbie level 4
We at Source III have been searching for a way we can help contribute to EDA board, since monitoring for relevant posts/questions is often a challenge. Yet we wanted a way to more actively help testers, especially since we know that many people have questions about WGL, STIL, etc, that they simply do not ask, or they try to solve the issue in-house. We thought perhaps it would be welcome to start sharing information relevant to test engineers as a post, rather than wait for people to ask questions, and hopefully people will find it helpful.
Recently, one of our VTRAN clients contacted us for help with WGL scan data structures, and so we created this long post about it. Hopefully this is welcome, and if so we'll add more in the future when topic ideas come up:
~~~~
In today’s DFT tools, the use of scan insertion to improve test coverage and reduce test pattern volume is very common. 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:
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:
SCAN CHAIN is comprised of the SCI scanin pin, the ordered list of scan cells in the chain (with inversions indicated) and SCO is 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:
As illustrated in the discussion above, it is easy to misunderstand the concept of cell data vs. shift data and how this can affect the translation of scan data present in the scanstate block of a WGL file to shift data that all ATE require.
A second issue that can affect the resulting data mapping between cell data and shift data is when different scan chains share scan cells. Obviously this would require that ones with shared cells are not used at the same time, but we have seen cases where this restraint was not observed and cell data from one scanstate load overwrites that from another.
The third issue listed above arises when there are duplicated scan cells in the same scan chain. In one case on a scan chain for example, we found that at the end of the chain (just before the last cell) there were 10 cells duplicated, preceded by another 10 cells duplicated. However when you specify in the scanstates an assignment of 001100110011......001100110011 the 10 data bits after the first one are all being assigned to the same cell - only the last one will stick. It is not clear why the WGL file has these duplicated cells in some scan chains - perhaps to make the total scan lengths equal, or because the names were written without a bus index, or some other reason. But the scanstate data being assigned to them will not result in the shift patterns you would normally expect.
Other issues we see that can affect how scanstate data ends up getting mapped to shift data are related to the practice of not assigning the scan cell data directly to the cells individually, but rather to cell groups which are usually specified as the reverse order of the scan chain cells. This is so that the order of the scanstate data looks more like a shift order (left-most bit is first bit in/out). In any case, this opens up an additional possible affect when the reverse order group has an error - so the cell data does not end up in the expected cell.
Finally, when performing a scan operation in WGL all other non-scan signals are held in a constant state (of course clocks can be running). One interesting byproduct of this is that WGL syntax has a difficult time implementing a JTAG protocol which usually requires one non-scan signal to change state during the last scan bit. The attempts to get around this that we have seen are often incorrect or violate the WGL semantics rules.
(This article was reposted in its entirety from SourceIII.com.)
If you have any other questions about WGL, STIL, ATPG/ATE conversions, etc., feel free and let us know and we'll see if we can answer it in a future post (or in the thread below).
Recently, one of our VTRAN clients contacted us for help with WGL scan data structures, and so we created this long post about it. Hopefully this is welcome, and if so we'll add more in the future when topic ideas come up:
~~~~
In today’s DFT tools, the use of scan insertion to improve test coverage and reduce test pattern volume is very common. 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 ‘!’ 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 3 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:
SCAN CHAIN is comprised of the SCI scanin pin, the ordered list of scan cells in the chain (with inversions indicated) and SCO is 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:
- Not taking logic inversions between scan cells into account properly
- Sharing of scan cells between different scan chains
- Having duplicated cell names appear in a single chain
As illustrated in the discussion above, it is easy to misunderstand the concept of cell data vs. shift data and how this can affect the translation of scan data present in the scanstate block of a WGL file to shift data that all ATE require.
A second issue that can affect the resulting data mapping between cell data and shift data is when different scan chains share scan cells. Obviously this would require that ones with shared cells are not used at the same time, but we have seen cases where this restraint was not observed and cell data from one scanstate load overwrites that from another.
The third issue listed above arises when there are duplicated scan cells in the same scan chain. In one case on a scan chain for example, we found that at the end of the chain (just before the last cell) there were 10 cells duplicated, preceded by another 10 cells duplicated. However when you specify in the scanstates an assignment of 001100110011......001100110011 the 10 data bits after the first one are all being assigned to the same cell - only the last one will stick. It is not clear why the WGL file has these duplicated cells in some scan chains - perhaps to make the total scan lengths equal, or because the names were written without a bus index, or some other reason. But the scanstate data being assigned to them will not result in the shift patterns you would normally expect.
Other issues we see that can affect how scanstate data ends up getting mapped to shift data are related to the practice of not assigning the scan cell data directly to the cells individually, but rather to cell groups which are usually specified as the reverse order of the scan chain cells. This is so that the order of the scanstate data looks more like a shift order (left-most bit is first bit in/out). In any case, this opens up an additional possible affect when the reverse order group has an error - so the cell data does not end up in the expected cell.
Finally, when performing a scan operation in WGL all other non-scan signals are held in a constant state (of course clocks can be running). One interesting byproduct of this is that WGL syntax has a difficult time implementing a JTAG protocol which usually requires one non-scan signal to change state during the last scan bit. The attempts to get around this that we have seen are often incorrect or violate the WGL semantics rules.
(This article was reposted in its entirety from SourceIII.com.)
If you have any other questions about WGL, STIL, ATPG/ATE conversions, etc., feel free and let us know and we'll see if we can answer it in a future post (or in the thread below).