At Automata, an extensive DRC is performed on every part number coming into the plant. Issues are definitely found. These issues range from spacing problems to broken/shorted nets. An extensive review of the design before committing the part to production reduces the number of cycles that the customer may need to go through along with many of the hassles associated with debugging design problems. Performing a simple DRC will also ensure that there are no failure-modes in the design itself. It's certainly not an enjoyable prospect to manufacture a board and have it fail electrical test because of two circuits being placed 1 mil apart! Automata does a fair amount of prototype work (3, 5, and 10 day turnaround). On this type of work, designers have a tendency to be rushed by deadlines on their end and sometimes are forced to overwrite the design rules to get the job complete. If they cannot accurately perform DRC, either they get potentially bad product from the fab house or the fab house acts as a last line of defense and performs the DRC on their supplied gerber data. Working with the customer and helping him understand items that can be improved on the design to create a more cost-effective product is part of the job of any good front end team. Along with the gerber data, it is becoming crucial to the success of a DRC to have the customer provide a schematic netlist. This net list is then compared against a netlist extraced from the supplied gerber data. The Netlist Comparison will determine if the designer has broken nets, shorted nets, unmatched CAD points, or duplicate CAD points. For most fab houses who do any type of Netlist Compare, the process is to (1) extract a netlist from the Gerber data provided, (2) all authorized modifications are performed, (3) another netlist is extracted from the modified data, and (4) a pre/post netlist compare is performed to ensure that the fab house did not change the intent of the design in any way. Unfortunately this does not perform any value added function to the customer and does not gives the electrical testing operation traceability back to the schematic. Automata's method for performing netlist comparison is to request a schematic netlist from the customer as part of the incoming data package. If the customer does not know about netlists or does not know how to extract one from their design system, we will give them step-by-step instructions on how to do so. Once a schematic netlist is received, the netlist comparison is made between the schematic netlist and the netlist extracted from the production-ready database. Since the fixtures are programmed and built from the production-ready database AND the production-ready database has been successfully compared to the schematic netlist, there is absolute traceability between the schematic netlist and the testing program. Another benefit is that this comparison also verifies that the design has not been violated in some way by the fab house. Automata's approach to net list comparison is to insure that we have the capability to interpret net list formats from any design system and to know our customers and their methodology well enough so that the netlist comparison is a transparent process to them. In our experience, the numerically largest error types that we see are naming convention errors. These are easily found and understood and tend to be design system related. Most of the net list naming issues tend to be either related to test points or planes. I think that the key to the whole net list comparison issue is to know your customer and how they do business and adapt to match their individual needs. Steve Silbert Product Engineering Manager [log in to unmask] p. 703-450-0548