Estimated reading time: 4 minutes

Dana on Data: Automating DFX Transfer and Analysis Using IPC-2581C

We are inching closer to a world where a complete intelligent PCB data transfer is realized. Revolutionary PCB technology changes tend to take 20+ years from inception to becoming commonplace. Data formats are no exception to this unwritten rule. The first commercially intelligent data format, Valor ODB++, was initially released in the late 1990s. The non-proprietary evolution of ODB++(X) was released by iNEMI Data Exchange Convergence Project in 2002. It was later moved to IPC standardization as IPC-2581. New functional requirements were identified and added as more software developers and users adopted and implemented IPC-2581 formatted data.

The IPC 2-16 Digital Product Model Exchange (DPMX) Subcommittee has just sent revision C out for IPC-2581 Consortium review with final industry approval targeted for this June. The C revision has several significant additions that get us closer to a 100% intelligent data transfer eliminating more supplemental ePaper documents. The significant additions are:

• Complete flex PCB description
• Complete rigid-flex description
• Intentional netlist shorts designation
• DFX bi-directional communication

Let’s focus on the DFX communication functionality.

A manufacturing data package is sent from the designer or purchasing agent to manufacturers to quote and/or initiate production tooling. The data package is reviewed by a pre-production or quoting engineer to ensure that it is complete, conforms to required specifications, and compares it against the facility capability. All issues found manually or with automated design rule checks (DRCs) are noted in a technical query (TQ) report using the supplier’s standard ePaper format (e.g., Excel or Word). It is then sent to the ordering company’s indicated technical person for resolution. This file is edited and sent back and forth until all issues are resolved, and approval for each deviation is noted. The TQ file is then stored in an email or a TQ archive server. In some cases, the specific TQ items are also stored in a database.

Large OEMs often have a specific DFX format that they require the TQs to be supplied in. This standard format helps their technical person have a standardized format from all suppliers to reduce their response time. Some companies will then load these files into a TQ database that is analyzed to improve the data quality and reduce the number of TQs generated.

The manufacturer pre-production engineer must either translate their internal format into the customer’s format or just enter the deviations into their format directly. This creates an inefficiency at the supplier as new engineers must be trained on when and how to use the many formats. Storing these differing TQ formatted documents makes it very difficult to automatically load these into a database to perform trend analysis to help reduce the number of issues. Manual analysis is often required.

The IPC-2581C revision defines the format for transmitting the TQ line items and approvals. This eliminates the use of ePaper forms that are emailed back and forth after adding responses. TQ items can be stored in a database, and an automated file can be generated and sent to review (Figure 1).

Figure 1: IPC-2581 versus Excel/Word-based TQ communication.

The format allows documentation, fabrication, assembly, and test issues to be incorporated. There is significant intelligent information that can be incorporated. For example:

• Defect locations designated in rules versus specific locations
• Communication issues, such as conflicting fab notes versus acceptance specification requirements
• Drill hole quantity indicated on fab print versus actual data
• Links to design data
• Defect marks, such as circles and arrows, tied to each TQ line
• External references to URLs, external files, etc.
• Embedded images, documents, firmware, and/or executables entered as base64 encoded files

The existing Excel, Word, etc., files move from being the communication method to report viewers. The designer can use a custom report or GUI format that is totally independent of the viewing format that their suppliers use. This improves response times and standardizes viewing/data entry formats at both ends.

Another practical use will be including approved manufacturing DFX deviations and edits in the IPC-2581 file; let’s call this Rev. A. Many new revision PCB datasets may have multiple supplier-specific TQ approvals. These approved deviations and edits are not generally incorporated into Rev. B. The Rev. B data is then sent to the suppliers. The DFM process is run, and a TQ is sent back to the technical contact with the request to apply the approved TQs from Rev. A. This may take 1–2 days to get the approval to apply the previous TQs, thus losing 1–2 days in the NPI cycle time.

The approved DFX data can just be added to the Rev. B data when it is initially distributed. Then, the supplier can proceed to implement the items without sending the new TQ and not losing the 1–2 days cycle time. It will also reduce having to contact the designer, who is most likely already working on the next design.

I encourage all IPC members to review the new IPC-2581 revision C changes and implement them during 2020 to help reduce the NPI cycle time and enable more automated data quality improvement projects.

Dana Korf is the principal consultant at Korf Consultancy LLC.