Test engineers must join ASIC flow early

Test engineers must join ASIC flow early
By Paul B. Taubman, EEdesign
February 14, 2002 (8:29 p.m. EST)
URL: http://www.eetimes.com/story/OEG20020214S0057

Paul Taubman is a senior design engineer for Tality Corp., Cadence Design Systems' services organization. In this article he shows how test engineers should interact with designers in order to minimize test costs and silicon re-spins.

The ASIC design flow presents a difficult challenge for the test engineer. The linear progression of the ASIC design flow suggests that the test engineer's job begins when silicon arrives. Yet, test is heavily reliant upon information from processes and decisions that occurred early in the ASIC design flow. Verification data and package blueprints simply do not travel with the device through fabrication.

The problem is compounded due to the potential distances between design and test engineering groups, and the substantial time lapse that occurs from the verification of the design to the arrival of silicon. Regardless of how a company defines the role of the test engineer, one aspect is certain. The su ccess of the project depends on the test engineer being proactive by taking on an information gathering and management role.

Granted, the test engineer is still an engineer, with the responsibly of determining if the design has been successfully implemented on silicon. However, the ultimate objective of the test engineer is to report the outcome on the test systems or lab equipment. If the ASIC flow is only viewed linearly, the question of what to do when the device does not work is not really addressed.

With the exception of Focused Ion Beam repair (FIB), most test groups cannot fix silicon. Ultimately, the results of test need to be given to someone capable of verifying the device failure and mending the design. Oddly, this is seems to be where the communication breakdown occurs in many ASIC flow processes. The ASIC design flow, when viewed in a linear progression, hides the required interaction of processes (see Figure 1, below). The prototyping of a device requires information from earlier processes such as verification in addition to silicon from the neighboring fabrication process.

Figure 1 - ASIC Design Flow

This reactive approach, though the easiest procedure on paper, can yield extremely inefficient and frustrating results. Consider a scenario in which a company does not consider test and characterization until their new device is in the process of being fabricated. The moment the test group is informed of their new task, test is already behind schedule. Issues that immediately need addressing are a developing test plan; fabricating load boards and probe cards; gathering details regarding the package to determine the socket; determining test platform; obtaining specifications to understand the general functionality of the device; and accumulating vectors.

Efforts to collect vector sets from the functional verification simulations performed se veral months earlier are difficult at best. Verification engineers have moved on to other projects. Some may have left the company, while others may not understand the limitations necessary to successfully port their simulation vectors to the Automated Test Equipment (ATE).

Program management is also in a quandary. Lack of funds or the limited availability of engineering resources hinders the test engineer's request for assistance. Morale becomes a factor as individuals who are several months removed from the project take offense at the test engineer's inquiries regarding the usability of their vectors. After several attempts to string together vectors by harping on the verification engineers to provide "suitable" vectors, the test engineer is able to use the existing software tools to get the vectors into a shape and form that are usable on an ATE.

As the silicon arrives, it has been a rough five weeks trying to set up test. However, the problems have not abated. The vectors may have loaded on the ATE, but the only test passing is continuity. To make matters worse, DFT (Design For Test) issues were not considered. The designers were behind schedule and the chip was already pushing the limits for place and route utilization. Verification designers, who do not have the time to decipher the vector failures, simply throw more vectors at the test engineer as a temporary appeasement, none of which aid in the detection of the failure nor allow the device to pass.

Through persistence and reading of the specification, the test team makes an all-out effort to determine the cause of failure. And sure enough, they are able to gather enough information to support a theory that the chip truly has a defect. Verification engineering is claiming that no such failure exists because they thoroughly checked the device. At wit's end, the test team drags the program managers, designers and verification engineers to the test floor to explain to them why the device will not work.

Despite all of their e xcuses, they are reminded that the test team cannot fix the device but can only report the problems. Reluctantly, they buy in to the failure theory, and sure enough, they return with a confirmation of the test team's discovery. The design is sent for a respin. Though there is a reprieve of a few weeks, the silicon will arrive with another fight at hand.

Analyzing the breakdown
Fortunately, the nightmare can be avoided altogether. Consider these thoughts:

• The test engineer never had a fair chance. From the moment the test engineer was assigned to the project, a massive rush was required to ensure that the basic elements of test such as a test plan, load board, an ATE capable of handling the device, and vectors were available upon the arrival of silicon.
• Verification engineers were never out to make enemies. Unfortunately, the inherent nature of the ASIC design flow, when viewed linearly, puts the verification engineer on the defensive. First, demands are being made on the verification engineer, who is already several months removed from the project. Second, if the verification engineer is not privy to the requirements of tests, he may have created vectors that are unsuitable for the ATE and may require a tremendous amount of rewriting. Third, the physical limitations of test are not readily apparent to the verification engineer.
• Design engineers are also far removed from test, both in terms of time lapse between design and test and knowledge of the test requirements. Design engineers who once practically walked the design through to production 20 years ago now tend to be isolated to their specific job in the ASIC flow. As a result, logic that may not be specifically mentioned in the specification but could aid the test flow, tend to be given less priority.

Granted, there are tools and specifications that can inject the DFT logic into the device. However, there are other features that can be added that are not defined in any IEEE specification for JTAG. F or example, one mechanism that can be used is an internal counter that multiplexes with an input bus. Rather than supplying the entire input bus unique in formation, a few control lines and a clock could perform the same test function internally. These bypasses and custom test logic allow the failures to be isolated and quickly identified.

There is a fundamental difference between test and those who create the device prior to fabrication. Test deals with the real physical world, where the signals are less than perfect and ATE systems have limitations. Designers live in a simulation domain. Their world is based upon the results obtained from tools that are trying to model the physical world. This is both a blessing and a curse. It is the only way a design containing several million gates can be created within a year's time. Unfortunately, it is highly reliant upon approximations, is susceptible to human error, and tends to hide real-world limitations such as the accessing and probing of internal n ets.

The main thought to consider is that this nightmarish scenario was never the malicious plan of any party involved in the design of the chip. A poor understanding of the ASIC design flow plays a tremendous role in the scenario. However, communication and a proactive response by the test engineer -- and project management -- can prevent this situation from occurring.

A better way
Though the test engineer is not the project manager per se, this individual has a management role in the project. There are deliverables expected from various groups of the ASIC design flow. There are two aspects to consider: Which groups or individuals is providing information needed to test the device and do they know their role in the test process? For example, many functional verification engineers know that they are supposed to deliver vectors to the test engineer. But do these individuals know the limitations associated with ATE systems or the importance of their vectors?

As shown in Figure 2 be low, communication between the test engineer and other groups in the ASIC design flow can yield savings in cost and time, in addition to removing obstacles between processes.
Figure 2 - Design and Test Communications

Ultimately, the test engineer needs to be part of the original team dedicated to developing the project. Some of the most fundamental and problematic issues can be resolved at this early phase. For example, a company that wishes to increase the speed of their process by going to an asynchronous state machine may not have realized that their decision may have jeopardized their test, characterization and production of this product on a standard ATE system. Mixed system issues, pin count, temperature requirements, and speed requirements all have a tremendous influence.

The test engineer's focus during the early stage of the project is to simply usher the theory of the design into a feasible physical test world. By the time the design team is ready to begin developing the logic, test feasibility, whether it is due to an unruly device or physical tester or equipment limitation, should not be an issue.

Prior to the start of most logic designs, a general block diagram is created. This is where test savvy can come into play. Bypass logic, internal counters and multiplexers can add a tremendous amount of testability to the device. This added logic could aid the verification engineers in their quest to validate the design. The point that needs to be stressed to the design and verification engineers is that in the physical test world, the test engineer can only access the device from the periphery. That general concept tends to be overlooked when simulators allow an engineer to see any net within the device.

The concepts of DFT are generally left for tools that implement after general functionality has been created. The role of the test engineer is to ensure that DFT is considered and that it can be implemented. There are certain logic structures that do not allow automated DFT tools from creating the proper paths for JTAG. There is also a tendency, especially when a project starts to slip in its schedule, to want to leave out the DFT aspects of the design.

However, the loss of time associated with debugging a device on an ATE without such test elements tends to be more difficult and more time consuming than the time gained by eliminating DFT logic. If the scan chain on a device does not work, that alone provides a tremendous amount of information as to the source of the failure. Additional scan chain vectors can quickly be created to confirm failure location. This is not true for a design that requires functional vectors that may take several thousand cycles to finally trigger the failing event.

The functional verification of the device serves two purposes. First, it validates the logic of the design. Its second purpose, which tends cause the most issues with test, is the creation of test vectors f or the ATE. There needs to be commitment by verification engineering to stay on the project long after their role of verifying the device is complete.

During the simulation phase, the test engineer can prevent a number of problems by working with the verifications throughout the development of the vectors. The test engineer can take sets of vectors and run them through their ATE conversion tools while the verification process is in progress. By doing so, the limitations of the ATE can be conveyed without overwhelming or surprising the verification engineer long after the design has been has released from their processes.

The processes of place and route, and the eventual fabrication of the device, do not necessarily require the interaction of the test engineer. However, continual communication with the test engineer has its benefits. Primarily, it reminds the others in the flow that the ultimate test has yet to come, and that their services may be called upon if a design flaw that been detected . The completion of place and route can also confirm the size and temperature strength of the package required to house the chip.

When silicon arrives, the test engineer should not be considered a solo or separate entity. The results of the test, whether it passed or failed, need to be communicated to all other members of the project. If there is a failure, cooperation should be expected from both design and verification to isolate and determine the cause. The decision to respin is expensive, in terms of time and cost. This decision has to be done on a professional level. This can rapidly degenerate into a finger-pointing contest if unity was never forged early on in the project.

In conclusion, a test engineer has the opportunity to be proactive in the project rather than being the victim of an ASIC flow that tends to be over-simplified. Some may argue that having a test engineer involved in a project from the start may be an added expense. However, the time savings to market, the cooperati on between groups, and potential morale improvements may be worth the cost. The "silos" that the ASIC flow tends to create can be kept to a minimum.