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