Bringing test patterns for your ARM core or other core-level blocks together for chip-level test of your SoC can present significant challenges. Whether your core-level test patterns are scan-based or functional, eventually they will likely end up in IEEE 1450 STIL format. At this point you may opt to make some modifications to these ASCII STIL files with Perl scripts or similar to prepare them for chip-level application. The scripts may seem simple at first - maybe you simply rename signals for chip-level access. But soon your requirements expand and your Perl scripts can quickly become a support nightmare. The intricate STIL syntax can make parsing a constant headache. As new projects leverage more core-level test patterns, more requirements are heaped upon your Perl scripts. Eventually, script maintenance starts consuming more time than the actual test conversion process.
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 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.
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?
Mark Chadwick is the Director of Marketing for Test Systems Strategies Inc. (TSSI). He was worked in the areas of electronic design automation and IC test for over 20 years. He holds a BSEE from the University of Wisconsin-Madison.