The problem with this approach can be identified by spelling out the STIL acronym—“Standard Test Interface Language.” The 1450 IEEE standard says that STIL “facilitates the transfer of digital test vector data.” In other words, STIL is intended for transfer of test data—not a medium for manipulation. Even changes that seem trivial can risk data corruption. For example, it’s quite easy to accidentally create duplicate signal names or use STIL reserved words. You may be fortunate if a problem in your script produces a clear syntax error in STIL which is identified early. But in the worst case, erroneous patterns make it all the way to the automatic test equipment (ATE) where your tests start failing, severely impacting your test development schedule.
A More Controlled Test Pattern Conversion Process
A safer approach is to avoid editing STIL files. Instead, you can do your test pattern editing within a controlled test data structure, and use STIL only as a test data transfer mechanism. Automatic test pattern generation (ATPG) scan tools often offer some capabilities for manipulating patterns before they output STIL; your ATE platform may also have some of these capabilities. However, you may experience some limitations if the test patterns of various cores come from different EDA tools.
One way to address this situation is by utilizing a test data structure that gathers up all your core-level test patterns, prepares them for chip-level application, outputs ATE-ready patterns, and facilitates final verification of the patterns. Using a reliable STIL input parser that does consistency checking is a good start. Once the test patterns are in the controlled data structure, it’s easier to safely manipulate them. Pattern verification can also be simplified by directly accessing the test patterns within the data structure with a Verilog PLI, while executing a simulation including a model of the DUT (device under test), and possibly even a model of the ATE.
Basic Test Pattern Operations
A set of basic test pattern operations can be quite effective for bringing all your core-level patterns together, ready for chip-level application.
In many cases, a preamble may be required for preparing the core for chip-level test access. Therefore, it will be necessary to prepend it to the core-level patterns. Since the preamble is functional in nature, it can be derived by cyclizing a Verilog VCD output, or if it is simple enough, it can be specified by a simple bit pattern.
A white paper is available from TSSI that describes “full-chip pattern integration” with TDS in more detail.
To illustrate the methodology, you can view a YouTube video (above or click) of a step-by-step demo that illustrates how to prepare an example set of scan patterns for an ARM core so they are ready for chip-level operation.
What are your views about the IEEE 1500 standard for core testing? Have you used it?
ARM welcomes its wealth of Partners in the ARM Connected Community (CC) to submit guest blogs to be published on our multiple community blogs. If interested in participating please submit email inquiries to Tell.Us@arm.com.
The ARM Connected Community (CC) is an extensive ecosystem covering all aspects of ARM processor-based design, from chip implementation through to system and device design. The CC provides a platform for collaborative innovation, with multiple types of forums for members to work with one another, and with customers, to solve industry challenges, all with the purpose of enabling designers to focus on differentiating features and an accelerated time-to-market for ARM powered solutions.
0 Comments On This Entry
Please log in above to add a comment or register for an account
The Server in Your Hand - and the three new interfaces inside it
on May 09 2013 08:54 PM
A DATE with Computing Destiny
on Mar 18 2013 06:57 PM
CDNLive Paper Preview: RTL Performance Analysis of ARM Interconnect IP
on Mar 11 2013 01:40 PM
Low Power and its Future?
on Feb 11 2013 08:02 PM
ARM Cortex-A50 Processor Series Wins ‘Product of the Year’ Award
on Feb 08 2013 07:48 PM