The current trend in electronic systems design is to push as much functionality as possible into integrated circuits. Newer systems are generally much smaller and much faster than their predecessors, but they also have larger and more complex integrated circuits. These circuits are often called Application Specific Integrated Circuits (ASICs) because they are specific to their own systems. Over the past few years, the number of ASICs fabricated has greatly increased, and the size and complexity of those ASICs has also increased. In order for these chips to remain cost-effective, however, design time must remain fairly short, and this has proven to be a difficult problem.
How can ASIC designers go about shortening design time? Often, designers use Hardware Description Languages (HDLs) such as Verilog and VHDL to design their chips, and synthesis tools such as Synopsis to compile those designs down to gate descriptions, shortening design time. Scannable design methodologies together with Automatic Test Pattern Generators can shorten design time by automatically generating manufacturing tests for integrated circuits. Another part of the design process that could benefit from some automation is functional testing, sometimes called design verification. This part of the process ensures that a design performs its required functions before it is sent to be fabricated. This is at least as important as any other part of the design process, but it is an area that has received little attention. This thesis analyzes this part of the ASIC design process, and presents some experiences with a testing system that may shed some light on the functional testing problem.
Let's begin by looking at the ASIC design process, and seeing how functional testing fits in. The term ``ASIC'' is a rather loose one, and generally refers to low-volume microchips, or chips that are designed for specific systems and are unlikely to find their way into other systems that the designers did not envision. Usually, designers will try to keep these chips simple, to reduce design time, but it is possible to make them as large and as complex as any integrated circuit on the market. Therefore, all three major methods used to design integrated circuits, full custom design, standard cell design, and gate array design, are used to design ASICs.
Full custom designs are the most low-level, requiring the designers to specify the exact location of every wire and transistor. Standard cell designs are a bit simpler; the designer is given a library of fairly simple logic elements and allowed to assemble them in any way. The gate array is the simplest design method. A Gate Array designer simply needs to supply a chip fabricator with a description of the chip in terms of logic gates and state elements, and the fabricator will handle the placement of those gates and the routing of all connecting wires. I will focus on the gate array design process because it is the simplest and because it is the method used to design the chip discussed in this thesis. However, the ideas presented here are general enough to be useful with any design method.
Since designing a Gate Array is as simple as coming up with a gate description of the chip, HDLs and synthesis tools are very popular among gate array designers. A Hardware Description Language provides an easy way to specify the behavior of the chip and provides an environment for simulating this behavioral model. The synthesis tools can turn this model into a gate-level description, and often provide ways to simulate that description as well, thus completing most of the design work.
After choosing a basic design methodology and gathering tools such as HDLs to help in the design process, one last major problem needs to be addressed; how should the chip be tested to ensure that the final product performs the desired functions? Designers ensure that their design is correct with functional tests, many of which are performed before chip fabrication since re-fabrication is costly. Fabricators ensure that their chips are free from manufacturing defects by requiring that the designers come up with some kind of manufacturing tests.
Manufacturing Tests are usually generated in some automated fashion. If the chip has scannable state elements, then it is relatively straightforward to write some kind of Automatic Test Pattern Generator (ATPG) that can generate tests which will detect nearly all common manufacturing defects. Some ATPGs are even available commercially, removing the burden of writing this tool from the designer. If the chip does not have scannable state elements, then some kind of ATPG can still be used. Such generators often create functional tests that are capable of detecting a certain percentage of possible manufacturing defects.
This brings us finally to the issue of functional testing. Every one of the above steps in the ASIC design process has some clear methods or tools associated with it, but there is no clear functional testing method a designer can use to verify that his or her design is correct. With no tools or conventions to help designers along, they must solve this problem from the very beginning each time they begin a new design. This can be a considerable burden when a team is trying to finish a design quickly, because functional testing is very time consuming, and it is very hard to do right. It is very important, however, because every bug that is not discovered in the functional testing phase must be found after fabrication or once the chip is already in a system, at which time fixes are much, much more costly.
Unfortunately, functional testing can be a very daunting task because it needs to accomplish a very large number of things at once. At the highest level, we can say that functional tests should perform design verification, that is, verify that the design fits all specifications. This implies that functional testing should begin before the design is completely correct, and functional testing is therefore, in many cases, debugging. Debugging a system is, in itself, a very haphazard and confusing task, usually accomplished by simulating the system with some set of inputs and monitoring the system's behavior to determine where a problem occurs. Let us assume that debugging and functional testing of ASICs are accomplished with such a system, and look at the form this system should take.
Because the system should perform design verification, it needs to work like a kind of virtual test fixture. A design for the chip is given, a number of tests are run, and the system should say, ``Yes, it's working,'' or ``No, it's not working.'' This implies two things. First, the testing system must be general; that is, it must be capable of exercising every function of the chip and putting the chip in nearly every possible state. Without this condition, it would be impossible to determine whether or not the design worked in every situation. Secondly, tests should be repeatable, so that it will be possible to determine when something that was broken begins to work.
There are two other requirements of a functional testing system that are less intuitive. One requirement is that the functional testing system should work at the lowest level of the design. In other words, the system should work with the actual design and not with some simulation for that design. This requirement is not so easily satisfied if a chip is being designed on paper of if no good simulation tools exist for the actual description of the chip. Some chip designers will write simulations for the behavior of their chips in some higher-level language like Lisp or C, but there is no obvious way to determine whether or not the simulation for the chip will behave exactly as the final design will, and it is therefore necessary to run functional tests on the lowest level description to ensure the proper behavior of the final design.
The other less intuitive requirement of functional testing is that it should be somewhat automated. Automating the functional testing system will give the system itself some of the responsibility for testing the chip. It is necessary to give some of this responsibility to the testing system since it is nearly impossible for a human to think of all the tests needed to determine whether or not a chip is functioning properly. Without some form of automation, the user is left trying to think of every possible input pattern that could result in an erroneous output. The easiest way to automate test selection is to build some kind of random input pattern generators into a testing system. This method, which I will refer to as ``randomization,'' can make the burden of functional testing significantly lighter.
Two final and very important requirements for this system are that it should be very fast and very easy to use. Since it is known that this system will be used as a debugger, it should obviously be fast enough to re-run tests quickly and simple enough that it will not hinder someone puzzling on a design problem. Nothing is more maddening than waiting hours for the results of a simulation that will tell whether or not a simple bug fix worked. Slow tools can be quite an annoyance, and can significantly increase the time needed to create a bug-free design. The same argument applies to the ease of use of those tools. Any design tools must be easy to use or they will be very little help to the design team. Unfortunately, however, building speed and ease of use into a system with the diverse requirements listed above is very difficult.
As an example of the possible tradeoffs in a functional testing system, this thesis presents the approach used to test the Arctic router chip. Arctic is a 4x4 packet routing chip that has been designed to be a part of the *T multiprocessor, a parallel computing project in the Computation Structures Group of the MIT Lab for Computer Science [1]. Arctic has some very complex functions and a rather confusing control scheme. This complexity makes Arctic a good test bed for a number of interesting approaches to functional testing.
There are three main ideas in the approach used to design Arctic's functional testing system. The first is the use of Verilog as an implementation language. This was the natural choice of language for the system since Arctic is a gate array and is being designed entirely in Verilog, but we shall see later that this choice gives a number of other desirable traits to the system. The use of Verilog, for example, ensures that the lowest-level specification for the design is being simulated at all times. Also, and perhaps most importantly, it makes it easy for the testing system to change state inside the chip during simulation which can sometimes allow the system to run many times faster.
The second main idea is the use of virtual testing modules to simulate components of the system outside the chip during tests. The term module, here, refers to the chief method of abstraction in Verilog, and Arctic is designed as one large module. In the testing system, all components that are connected to Arctic are also modeled as different modules, one for each logically distinct entity. For example, each of Arctic's input ports and output ports is connected to a module that knows how to communicate with that port. All signals related to a port are grouped together, giving the designer of the system a clear structure to work with, and giving the user of the system a clear, simple picture of the testing system.
The last major idea used in this functional testing system relates to the organization of the tests themselves. At this point, the reader may be wondering, ``Just what is a `test' anyway?'' In Arctic's functional testing system, a test consists of three parts: a specification for a beginning configuration of Arctic, a set of inputs, and a specification for the state of Arctic after all the inputs have been sent. Together, these three parts form a ``test group,'' the basic testing unit around which the entire system is built. This may seem like common sense, indeed all three of these ideas may seem like common sense, but since there is no conventional way to design a functional testing system, we must state them clearly. This will give us a starting point for discussion about this system, and serve as a reference against which other possible designs can be judged.