PCB Blog - Writing PCB Board Design Rule Checker Tips

This paper describes a systematic approach to writing a PCB board design rule checker (DRC). Once the PCB design is obtained with the schematic generation tool, DRC can be run to find any design rule violations. These operations must be completed before subsequent processing can begin, and developers of development schematic generation tools must provide DRC tools that are easily accessible to most designers.

There are many advantages to writing your own PCB design rule checker. Although the design checker is not that simple, it is not unattainable, because any designer familiar with existing programming or scripting languages can design a checker. The advantage of this job is that inestimable.

However, general-purpose tools that are marketed are often not flexible enough to meet specific design needs. Therefore, customers must reflect new feature requirements to DRC tool developers, which usually takes a certain amount of money and time, especially when the requirements are constantly updated. Fortunately, most tool developers provide customers with a convenient way to write their own DRC to meet specific needs. However, this powerful tool has not been widely recognized or used. This article provides a practical guide to using DRC tools to gain benefits.

Since the DRC must traverse the entire circuit diagram of the PCB board design, including every symbol, every pin, every net, every attribute, and if necessary, create an unlimited number of "attached" files. As described in Section 4.0, the DRC can flag any minor deviations that violate the design rules. For example, one of the accompanying files might contain all the decoupling capacitors used in the design. If the number of capacitors is lower or higher than expected, a red mark will be marked [1] where there may be a power line dv/dt problem. These side files may be necessary, but not any commercial DRC tool will necessarily be able to create them.

Another advantage of DRC is that it can be easily updated to accommodate new design features, such as those that may affect design rules. Moreover, once sufficient experience in the field is gained, many other functions can be implemented.

For example, if you can write your own DRC, then you can write your own bill of materials (BOM) creation tool, which can better handle specific user needs, such as how to obtain device "extra hardware" that is not itself part of the schematic database (eg socket, heat sink, or screwdriver). Alternatively, designers can write their own Verilog netlist analyzer with full flexibility in the design environment, such as how to obtain a Verilog model or time file for a specific device. In fact, since the DRC traverses the entire design circuit diagram, all valid information can be collected to output the simulation and/or BOM required for the Verilog netlist analysis of the PCB design.

It's a bit far-fetched to discuss these topics without providing any program code, so we'll use a circuit diagram acquisition tool as an example. This article uses the ViewDraw tool developed by Mentor Graphics, which is attached to the PADS-Designer product line. In addition, we have adopted the ViewBase tool, a library of simplified C routines that can be called to access and access the ViewDraw database. Using the ViewBase tool, designers can easily use C/C language to write a complete and efficient DRC tool for ViewDraw [2] [3]. It is important to note that the basic principles discussed here apply equally to any other PCB schematic tool.

input file
In addition to the circuit diagram database, the DRC also needs some input files that can describe specific situations to handle, such as automatic connection to the power plane with valid power net names. 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 (as applicable for ViewDrawpcbfwd). Given below is a list of input files that must be placed in a fixed global location so that DRC can automatically find and read it, and then store this information inside DRC at runtime.

The file legal_pwr_net_name is optional, this file contains all legal net names of POWER signal, such as VCC, V3_3P and VDD. In PCB layout/routing tools, names need to be case-sensitive. Generally, VCC is not the same as Vcc or vcc. VCC can be a 5.0V power supply, and V3_3P can be a 3.3V power supply. * The file legal_pwr_net_name is optional, as the backend wrapper device configuration file must usually contain a set of legal powerline 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 supply: VCC VDD VEE V3_3P V2_5P 5V 12V
If the DRC can read the allegro.cfg file directly, instead of legal_pwr_net_name, it will get better results (ie less chance of introducing errors).

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

The power line pins are usually not externally attached to the device symbol. Instead, an attribute of the symbol (called SIGNAL here) describes which pin is a power or ground pin and describes the net name that the pin should be connected to.
SIGNAL = VCC:10
SIGNAL=GROUND:20

The DRC can read this property and ensure that the net name is saved in the legal_pwr_net_name file, if the net name is not included in the legal_pwr_net_name then the power pins will not be connected to the power plane, which is really a serious problem on PCB board.