This paper briefly describes a method of programming PCB design rule checker (DRC) system. Once the PCB design is obtained using the circuit diagram generation tool, DRC can be run to find any failures that violate the PCB design rules. This must be done before subsequent processing begins, and the developer of the circuit generator must provide DRC tools that most PCB designers can easily master.

There are many advantages to writing your own PCB design rule checker. While the PCB design checker is not that simple, it is not unmanageable, because any PCB designer familiar with existing programming or scripting languages can do it, and the benefits are inestimable.

However, marketed general-purpose tools are often not flexible enough to meet specific PCB design needs. As a result, new feature requirements must be reported by customers to DRC tool developers, which often takes money and time, especially if the requirements are constantly updated. Fortunately, most tool developers can provide their customers with an easy way to write their own DRC to meet their specific needs. However, this powerful tool is not widely recognized or used. This article provides a practical guide to getting the most out of DRC tools.

Since DRC must traverse the PCB to design the entire circuit diagram, including every symbol, every pin, every network, every attribute, and create an unlimited number of “accessory” files if necessary. As described in Section 4.0, DRC can flag any minor deviation from PCB design rules. For example, one of the attached files may contain all the decoupling capacitors used in the PCB design. If the capacitance number is lower or higher than expected, red marks will be placed where power line DV/DT problems may occur. These ancillary files may be necessary, but they are not necessarily created by any commercial DRC tool.

How to design THE PCB rule checker DRC

Another advantage of DRC is that it can be easily updated to accommodate new PCB design features, such as those that may affect PCB design rules. Moreover, once you gain sufficient experience in the area, there are many other features that you can implement.

For example, if you can write your own DRC, you can write your own BOM creation tool to better address specific user needs, such as how to obtain “additional hardware” (such as sockets, radiators, or screwdrivers) for devices that are not themselves part of the circuit diagram database. Or the PCB designer can write his own Verilog netlist analyzer with sufficient flexibility in the PCB design environment, such as how to obtain Verilog models or time files suitable for a particular device. In fact, because DRC traverses the entire PCB design circuit diagram, it is possible to gather all valid information to output the simulation and/or BOM required for PCB design Verilog netlist analysis.

It would be a stretch to discuss these topics without providing any program code, so we’ll use a circuit diagram retrieval tool as an example. This article uses Mentor Graphics company to develop ViewDraw tool attached to THE product line of PADS-Designer. In addition, we used the ViewBase tool, which is a simplified C routine library that can be called to access the ViewDraw database. With the ViewBase tool, PCB designers can easily write complete and efficient DRC tools for ViewDraw in C/C. It is important to note that the basic principles discussed here apply to any other PCB schematic tool.

The input file

In addition to the circuit diagram database, DRC also needs input files that can describe specific situations, such as the name of a legitimate power network automatically connected to the power plane. For example, if the POWER network is called POWER, the POWER plane is automatically connected to the POWER plane using a back-end package device (as applicable to ViewDrawpcbfwd). The following is a list of input files that must be placed in a fixed global location so that DRC can automatically find and read, and then save this information internally to DRC at run time.

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

A power cable pin is not normally attached to a device symbol. Instead, a property of the symbol (called SIGNAL here) describes which pin is a power or ground pin and describes the network name to which the pin should be connected.

SIGNAL = VCC:10

SIGNAL = GROUND:20

DRC can read this property and ensure that the network name is stored in the legal_pwr_net_name file. If the network name is not included in legal_pwr_net_name, the power pin will not be connected to the power plane, which is a serious problem.

File legal_pwr_net_name Optional. This file contains all legal network names of POWER signals, 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 5.0V power supply and V3_3P can be 3.3V power supply.

The file legal_pwr_net_name is optional, because the backend encapsulation device configuration file must usually contain a set of valid power cable network names. If CadencePCB is used to design Systems’ Allegro wiring tool, 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 DRC could read the allegro.cfg file directly instead of legal_pwr_net_name, it would get better results (i.e. less chance of introducing errors).