Estimated reading time: 4 minutes

Dana on Data: Nuke the Netlist

I bet that title caught your attention. Has Korf finally lost his mind?

The central theme of my I-Connect007 columns, as well as presentations at PCB technical meetings, has focused on improving data package quality sent from designers to manufacturers. The goal is to transfer the design information to manufacturing and build the PCBs as-is. No semi-automated DFM, stackup generation, CAM editing, or data quality analysis should be needed.

Late last year, I started thinking about the IPC-D-356 netlist. Why do we generate it? What is its purpose? Why are there so many issues using it?

A Little History
In the 1980s, we were moving from sending mylar film-based design data (artwork) to digital data based on the EIA-RS-274-D data format via 1200 – 2400 bps modems. The data transfer was not always perfect, primarily because the Gerber aperture file was separate from the data file. There were errors reading the data due to wrong/bad aperture lists being sent and used. The industry required a method to confirm that the electrical connectivity was correct.

A netlist format, IPC-D-356, was developed as part of the IPC D-350 data effort. It was initially released in March 1992. The last update was released in October 2002. The combination of these files significantly reduced the error rate. The current electrical test standard, IPC-9252 (which superseded IPC-ET-652A), was released in February 2001. This recommends that a netlist check be used for Gerber data transfer.

Today’s Experience
In September 1998, an updated Gerber file version, EIA-RS-274X, was released. This was a significant improvement because it embedded the aperture list with the data file. The aperture list to data file errors was significantly reduced.

ODB++ intelligent data was released in the late 1990s and IPC-2581 intelligent data was released in 2004. These formats don’t require a secondary netlist to confirm their data transfer quality. But the industry continues to this day to send a separate netlist with these data formats. The fabricator still compares the supplied netlist to an extracted netlist because that’s the way it’s always been done. The problem is that the comparison fails, not because the data is bad, but because the netlist is bad.

Oh no! The netlist that was originally developed to solve a problem is now the problem. Why?

Here are the most common problems:

• Netlist revision is different than the design data. Example: The netlist is extracted in the morning and the final edits are completed in the afternoon.
• Data has intentional net opens or shorts. Example: The analog ground net is connected to the digital ground net at a common point.

Both ODB++ and IPC-2581 formats allow identification of intentionally shorted or open nets. IPC-D-356 has not been updated to allow for this. The Gerber based data package architecture implicitly requires that several files be extracted from CAD data then packaged together, allowing for wrong file revisions to be zipped together. It will be tough to change this practice as it has been used for decades. IPC-9252 needs to be updated to allow ODB++ and IPC-2581 to be used without a netlist. An IPC Project Initiation Notification (PIN) is currently being prepared to propose to update the standard. Contact me if you want to be added to the proposal team.

Should We Nuke (Eliminate) the Netlist?
It depends. Some things/people do get better with age: wine, whiskey, Harrison Ford. Some things don’t get better with age: apples, bananas, IPC standards. Fruits rot and the electronics industry improves with innovative design and manufacturing technologies. Currently, electrical test equipment requires a netlist to generate the test program, fixtures, and flying probe flight path. Without a designer’s data package, how will the test equipment get a netlist?

Most data-supplied data packages require CAM edits to prepare them for manufacturing after incorporating provided design updates. After the editing is complete, a netlist is extracted and compared to the original netlist to confirm that only approved changes have been made. The extracted netlist generally gets sent to final test, not the original one. (Not all front-end processes follow this method). So, a netlist based on the edited data must still be produced.

So, yes. It will still require a netlist, but a correct one.

Time to Modernize
Let’s define an IPC-2581-derived intelligent netlist and formally retire IPC-D-356. There are multiple operations that can use an intelligent netlist vs. having humans enter the requirements into production documentation/databases. Which operations could use an intelligent netlist?

• Automated optical inspection (AOI): Conductor isolation/continuity, thickness, tolerances, and defect allowances
• Impedance test: Coupon/board test point locations, impedance models, values, conductor length, width, thickness, and tolerances
• Continuity and isolation test: Conductor isolation/continuity, thickness, tolerances, and connectivity

Let’s move from the 1990s to the 2020s to improve the test specification data transfer, quit providing netlists when not required or incorrect, and generate an intelligent netlist for all conductor inspection operations. Manufacturing costs will decrease, and better products will be produced.

Dana Korf is the principal consultant at Korf Consultancy LLC.