Tips for Writing a PCB Design Rule Checker

This article describes a systematic approach to writing a PCB design rule checker (DRC). Once you have a PCB design from a schematic generation tool, you can run the DRC to find any design rule violations. This must be done before further processing begins, and the developer of the schematic generation tool must provide a DRC tool that is easy for most designers to master.

There are many advantages to writing your own PCB design rule checker.

Although it is not easy to design a checker, it is not out of reach. Any designer who is familiar with existing programming or scripting languages ​​can design a checker, and the benefits of this work are immeasurable.

However, the general tools sold on the market are usually not flexible enough to meet specific design needs.

Therefore, customers must reflect new feature requirements to the DRC tool developer, which usually costs money and time, especially when the requirements are constantly changing. Fortunately, most tool developers can provide customers with a convenient way to write their own DRC to meet specific needs. However, this powerful tool has not yet been widely recognized or used. This article provides a practical guide to getting the most benefit from using DRC tools.

Since the DRC must go through the entire schematic of the PCB design, including every symbol, every pin, every net, every attribute, and can create an unlimited number of “supplementary” files if necessary. As described in Section 4.0, the DRC can flag any minor deviations from the design rules. For example, one of the supplementary files might contain all the decoupling capacitors used in the design. If the number of capacitors is lower or higher than expected, red marks will be placed where there may be power line dv/dt problems. These supplementary files may be essential, but not all commercial DRC tools can necessarily create them.

Another advantage of DRC is that it can be easily updated to accommodate new design features (such as those that may affect the design rules). And once you gain sufficient experience in this area, you can implement many other functions.

For example, if you can write your own DRC, you can also write your own bill of materials (BOM) creation tool, which can better handle specific user needs, such as how to obtain “extra hardware” (such as sockets, heat sinks, or screwdrivers) for components that are not part of the schematic database itself. Or designers can write their own Verilog netlist analyzer, which has full flexibility in the design environment, such as how to obtain Verilog models or timing files for specific devices. In fact, since DRC traverses the entire design circuit diagram, it can collect all valid information to output the simulation and/or BOM required for Verilog netlist analysis of PCB design.

It is a bit far-fetched to discuss these topics without providing any program code.

For this reason, we will use a circuit diagram acquisition tool as an example. This article uses the ViewDraw tool developed by Mentor Graphics and attached to the PADS-Designer product line. In addition, we also use the ViewBase tool, which is a simplified C routine library that can be called and access the ViewDraw database. Using the ViewBase tool, designers can easily use C/C language to write complete and efficient DRC tools for ViewDraw. It should be noted that the basic principles discussed here are also applicable to any other PCB circuit diagram tools.

Input Files

In addition to the circuit diagram database, DRC also requires some input files that can describe specific situation processing, such as automatically connecting to the legal power network name of the power plane. For example, if the power net is named POWER, then the power plane will be automatically connected to the power plane using the backend package device (such as ViewDrawpcbfwd). The following is a list of input files that must be placed in a fixed global location so that the DRC can automatically find and read it, and then save this information inside the DRC at runtime.

• The file legal_pwr_net_name is optional. This file contains all the legal net names for the POWER signal, such as VCC, V3_3P, and VDD. In PCB layout/routing tools, names need to be case-sensitive. Generally, VCC is not equivalent to Vcc or vcc. VCC can be a 5.0V power supply, while V3_3P can be a 3.3V power supply. * The file legal_pwr_net_name is optional because the backend package device configuration file usually must contain a set of legal power line net names. If the Cadence Design Systems Allegro routing tool is used, the pcbfwd file name is allegro.cfg and has the following entry parameters:

Ground: VSS CGND GND GROUND

Power: VCC VDD VEE V3_3P V2_5P 5V 12V

If the DRC can read the allegro.cfg file directly instead of the legal_pwr_net_name, better results (i.e. less chance of introducing errors) will be obtained.

Some symbols must have external power pins because they are not connected to the regular power plane. For example, the ECL device VCC pin is either connected to VCC or to GROUND; its VEE pin can be connected to GROUND or -5.0V plane. In addition, the power pin can also be connected to the filter before reaching the power plane.

The power pin is usually not external to the device symbol, instead, an attribute of the symbol (here called SIGNAL) describes which pin is the power pin or ground pin and describes the net name that the pin should be connected to.

SIGNAL = VCC:10

SIGNAL = GROUND:20

DRC reads this property and ensures that the net name is saved in the legal_pwr_net_name file. If the legal_pwr_net_name does not contain the net name, the power pin will not be connected to the power plane, which is a very serious problem.