index.html

MultiSite testing has one singular purpose: To improve testing throughput. MultiSite simply means that multiple devices are tested concurrently. The Dragon and the Griffin support concurrent testing of 2, 4, 8 and 16* identical devices.

MultiSite invariably implies increased hardware along with increased hardware cost. While the price of the tester increases with number of sites, the improved performance will typically far outweigh the extra cost. For instance, a 25% increase in tester cost may yield an 800% improvement in throughput performance. Moreover, adding to the savings, the higher throughput also improves utilization of equipment tied to the tester.

The resources associated with MultiSite are:

1) Pin Electronic Modules to support total pin requirements.

2) Multiple Power supplies to allow for concurrent testing.

3) Multiple PMUs for concurrent DC tests.

The allocation of these resources, while obviously limited by hardware, may to some extent be confined by software. The following allocation, which is a sufficient condition for MultiSite, has restrictions - essentially dictated by software - that serve two important purposes: Clarity and Simplicity.

In the case of the Dragon tester, pin resource requirements are proportional to the number of pins used, regardless of a pin being a functional duplicate of another pin. Furthermore, the allocation of pins is tied to “site granularity”, which for Dragon is 16-pins per site. This means that the size of each site must be a multiple of 16. Hence, the MultiSite size of a 256-pin system is either 16-pins (allowing up to 16 sites), 32-pins (allowing up to 8 sites), 64-pins (allowing up to 4 sites) or 128-pins (allowing two sites). Also, for every 16 pins there is one power supply and a precision DC PMU available; these resources also determine the parallelism of the system (the more DC PMUs, the better the throughput). The number of available power supplies also increases with site size. The need for two power supplies per site is relatively common, although for large site sizes, chances are that not all supplies will be needed.

Table 1 illustrates the MultiSite configurations available with a Dragon System.

*Note: The 128-pin Dragon chassis supports a maximum of 8 sites only.

Pins	Sites Size PS Pmu	Sites Size PS Pmu	Sites Size PS Pmu	Sites Size PS Pmu
128	8 16 1 1	4 32 2 2	2 64 4 4	(N/A)
256	16 16 1 1	8 32 2 2	4 64 4 4	2 128 8 8

Table 1 –MultiSite Configurations (shown for 128 and 256 pin systems)

For Griffin (or G100/G150), the pin resource requirements are the same except for being at a 32-pin granularity. Therefore, the maximum number of sites on a 512-pin system is 16 but with 32 pins per site. Table 2 describes the MultiSite configurations for the Griffin.

Pins	Sites Size PS Pmu	Sites Size PS Pmu	Sites Size PS Pmu	Sites Size PS Pmu
512	16 32 1 1	8 64 2 2	4 128 4 4	2 256 8 8

Table 2 –MultiSite Configurations (shown for Griffin, G150, and G100)

Note that our description of the MultiSite Test System applies fully to AutoTest and the Interactive Test Mode. However, using ASP C code with ACT, the user could potentially allocate resources in ways that might enhance utilization of tester resources at the expense of complexity. Another reason for confining MultiSite to the topology of the hardware is MATCHMODE.

MATCHMODE implies that the execution of the test program is not 100% deterministic. The device needs to wait for an internal condition before advancing to the next level of testing (i.e., the next vector); the extent of the wait may be unknown (though within a maximum value). Supporting the most general form of MATCHMODE per site is a challenging proposition that entails an independent state machine per site. However, a “poor man’s MultiMatch” is a standard HiLevel feature. Employing the concept of a branch tree, the tester advances to a new node of the tree if and when a site is ready. Upon detection of 1) all sites ready, 2) one or more but not all sites ready, or 3) no sites ready (after the prescribed time-out), the program will continue in a distinct path to signify which, if any, of the sites are ready (that is, the DUT is operating properly). Hence, for a four-site system, fifteen distinct paths can be traversed for testing, and one path in the event no good DUT is detected. This means that if the test vectors for a single site is 1K, the test vectors needed for 4 sites are approximately16K (given 4M or 64M of vector memory that may not necessarily amount to a problem).

As indicated above, in the optional “Hardware MatchMode per Site”, each site has its own program memory for controlling vector sequencing. Essentially, each site is an independent state machine with its own resources to test when a DUT is ready to continue testing. The increased power may be required for some DUTs (e.g. SmartCard).

Figure 1 shows the Dragon PMPMS, the MultiSite resource for Power and DC PMU. Figure 2 depicts the Dragon PMPMS mounted on a PEM (Pin Electronics Module).

MultiSite Testing