Since Arctic's testing system has grown out of the idea that there are unique advantages to implementing a chip's functional testing system in the same language used to implement the chip itself, these ideas may seem applicable only to gate arrays and other ASICs designed entirely with HDLs like Verilog or VHDL. However, these languages are being used more and more frequently to generate significant amounts of logic in standard cell and full custom chips. We may be approaching the days when entire full custom chips will be designed with derivatives of these hardware description languages that integrate the specification of actual transistors with higher-level specifications. If this were to happen, the ideas in this thesis would be as applicable to full custom designs as they are to gate array designs.
Another key idea in this thesis has been the co-existence of a directed testing system and a randomized testing system. Neither makes a complete testing system by itself, but together the two can give the designer great confidence that a relatively bug-free design is being produced. Since the designs of these systems are related, they may be part of the same system or at least share a large number of modules.
The paramount idea here is that a clear structure is important. It is my belief that without this structure or one very similar to it, we could not have tested Arctic in so many varied ways so quickly, and we could not have weeded out so many design bugs before the first place and route.
In Arctic's functional testing system, quick mode was implemented by abstracting away ``uninteresting'' behavior. Certain functions that read or modified state inside Arctic did so by manipulating the necessary registers directly, rather than going through Arctic's maintenance interface. Thus, an action that changed the value in the configuration registers could be done instantly rather than taking the normal 3000 or more simulated cycles of operation. This is obviously advantageous if actions that use quick mode are common in testing simulations, which, in fact, they are. In an actual Arctic network, the percentage of time spent doing maintenance interface operations would be almost negligible, but in order to test Arctic, functions that configure and control Arctic through this interface are needed very frequently.
This idea can easily be extended to other testing systems. In any testing system, debugging is very important, and in any individual test, it is likely that certain parts can be thought of as ``the test,'' and other parts can be thought of as ``setting up for the test.'' Those parts that are setting up are generally uninteresting, and if they take a very long time to simulate, having a mode where they can run quickly (without much loss of detail) can be a great help.
In fact, both the directed and the randomized testing system suffered from complexity. The directed tester and debugger had confusing file formats that became unmanageable when tests became too large. The random system did not need much of a user interface, but it's complexity has made it very difficult to determine whether or not it generates the wide variety of tests that we expect. These types of problems are fairly common for large software projects. It is important to remember that problems such as these can easily arise in any system that tests a very large and complex chip.
Fortunately, this complexity did not ruin the testing project, because those of us that taught ourselves to live with the complexity of the system were able to perform extensive testing and get valuable experience from the testing system. This experience has taught us a great deal about the functional testing problem and has given us reason to believe that, one day, the ideas in this thesis may be used to make functional testing as tractable as every other part of the ASIC design process.