network logoeetimestechonlineembedded

Write your own PCB design rule checker
Luke L. Chang
(09/05/2003 2:34 PM EDT)
URL: http://www.eetimes.com/showArticle.jhtml?articleID=164900383
 
1.0 Introduction

This paper presents a systematic approach to writing a design rule checker (DRC) for PCB design. After a PCB design is captured in a schematic tool, a DRC must be run to find any design rule violations. This must be done before backend processing starts. Usually, the vendor of the schematics tool provides a DRC and most designers simply just use that.

However, vendor tools are general-purpose and may not always be flexible enough to handle certain unique requirements. Requests for new features to be added into the DRC may be sent to the vendor, but that would cost money and time, especially if this has to be done more than once. Fortunately, most tool vendors provide easy-to-use mechanisms for you to write your own DRC to better meet your unique requirements. Unfortunately, this powerful tool has not been widely recognized or utilized. In this paper, we provide some practical guidance on how to utilize it to your fullest benefit.

Because a DRC must walk through the entire schematics of a PCB design, including every symbol, every pin, every net, and every attribute, an unlimited number of useful "by-products" can be generated, if necessary. As Section 4.0 explains, they may very well flag subtle design rule violations. For example, one by-product file could contain all decoupling capacitors found in the design. If the number is much smaller or bigger than expected, this can raise a red flag for possible power line dv/dt problems [1]. These by-product files may very well be required, but they are definitely not generated by any commercially available DRC.

Another benefit of this DRC is that it can be easily and quickly updated to accommodate new design features, such as new attributes that affect design rules. Also, once enough experience has been gained in this area, then many other possibilities will present themselves.

For example, if you can write your own DRC, you can certainly write your own Bill of Material (BOM) generation tool, which again can better handle certain unique requirements, such as where to pick up a component's "extra hardware" (sockets, heat sinks, or screws) that is not part of the schematics database. Or you can write your own Verilog netlister that is flexible enough for your design environment, such as where to pick up the Verilog models or timing files for certain unique components. As a matter of fact, as the DRC walks through the design schematics, it can collect all necessary information to output a Verilog netlist for simulation and/or a BOM for PCB manufacturing.

It would be difficult to discuss these topics without providing some programming code. To do that, we need to use a schematics capturing tool as an example. In this paper, we use ViewDraw from Mentor Graphics, which is part of the PADS-Designer product line. In addition, we use ViewBase, which is simply a library of C routines that one can call to access the ViewDraw database. With ViewBase, you can easily write a complete and useful DRC in C/C++ [2] [3] for ViewDraw. Note that the principles that we discuss here are applicable to any other PCB schematics tool.

2.0 Starting out

2.0.1 Input Files
In addition to the schematics database, a DRC needs some input files to tell it how to handle certain situations, such as legal power net names for automatic connection to the power plane. For example, if a power net is called POWER, then it is automatically connected to the power plane by the backend packaging utility, such as pcbfwd for ViewDraw. The following is a list of these input files, which should be put at a fixed global location so that DRC can automatically find/read them and store the information internally as it runs.

  • Optionally create a file called legal_pwr_net_name that contains all legal net names for POWER signal, such as VCC, V3_3P, VDD. Note that letter case may matter to some PCB layout/route tools and in general VCC is not the same as Vcc or vcc. VCC may be the 5.0V power and V3_3P may be the 3.3V power.

    legal_pwr_net_name is optional because the configuration file of the backend packaging utility usually must contain the list of legal power/ground net names. If Allegro from Cadence Design Systems is the placement/layout tool, this file is called allegro.cfg for pcbfwd and it must have entries like these:

    Grounds VSS CGND GND GROUND
    Powers VCC VDD VEE V3_3P V2_5P +5V +12V

    It would be better (less chance of introducing errors) if the DRC can directly read allegro.cfg instead of legal_pwr_net_name.

    Normally, power/ground pins are not brought out on a component symbol. Instead, the symbol has an attribute (which could be called SIGNAL) that specifies which pin is power or ground and specifies the name of the net this pin should be connected to:

    SIGNAL = VCC:10
    SIGNAL = GROUND:20

    DRC can read this attribute and make sure that the net name is one found in the legal_pwr_net_name file. If not, this power pin will not be connected to the power plane, and this is a very serious error.

    Some symbols must have the power/ground pins brought out, because they are not connected to normal power/ground plane. For example, an ECL part's VCC pin can be connected to either VCC or to GROUND; its VEE pin can be connected either to GROUND or to -5.0V plane. Also, a power/ground pin can be connected to a filter first before going to power/ground plane.

    The net between this pin and the filter can have any name and DRC will have difficulty checking this. DRC can report this as an error and the user must screen it out, or add the net name to legal_pwr_net_name file only for this design. This is one reason that a file like legal_pwr_net_name may be required. Finally, legal_pwr_net_name will be read in by DRC to 1) find pull-up resistors, 2) check for the letter case of POWER net names in the design, and 3) detect any unused pins directly tied to POWER.

  • Optionally create a file called legal_gnd_net_name that contains all legal net names for GROUND signal, such as GROUND, VSS and F_GND. Again, note that letter case may matter for some PCB layout/route tools. Also, it would be better if DRC can directly read allegro.cfg file mentioned above instead of legal_gnd_net_name.

    legal_gnd_net_name serves the same purpose as legal_pwr_net_name discussed above. In addition, it will be read in by DRC to 1) find pull-down resistors, 2) check for the letter case of GROUND net names, and 3) detect any unused pins directly tied to GROUND.

  • Optionally create the legal_lib_path_name file that contains all legal symbol library paths and names. This is very important because a common as well as serious error is to use a symbol from an unauthorized library. During PCB design phase, temporary component symbols are often created and put in local symbol library directory for testing purposes. Final versions will come out of this and be put in the corporate or global library directory, and they may differ in important ways from local versions. Designers usually forget to replace local symbol with the corporate one and introduce design errors.

    legal_lib_path_name is optional because for most schematics tools the library information is contained in an initialization file required for bringing up that tool. For ViewDraw, the file is called viewdraw.ini and is automatically created (by a script) when the tool is brought up. A library specification entry looks like:

    DIR [r] /corp_lib/pcb/symbol_libraries/viewdraw/fct (fct)

    fct is one of the many ViewDraw's sub-libraries from where symbols for fct (fast CMOS technology) parts can come. DRC can and should directly read this initialization file, if it exists, because new libraries can be added on the fly by the designer.

  • Create a file called legal_pullup_res that contains legal pull-up resistors for terminations and unused input pins. Usually, there is a list of resistors that a company has qualified and allows its designers to use. Also, the resistor value is important too. If an unused input pin is pulled up, then that value should be 5K or higher.

  • Create a file called legal_pulldown_res that contains legal pull-down resistors for terminations and unused input pins. If a resistor is used to pull down an unused input pin, then its value should be small to prevent any leakage current to increase the pin voltage above triggering threshold.

  • Create a file called legal_decoup_cap that contains legal decoupling capacitors. Again, a company may require its designers to use only certain qualified parts that meet the power line dv/dt requirements.

  • Create a file called legal_comp_attr that contains all required attributes that a component symbol should have, such as PART_NO, GEOM, REFDES, SIM_CLASS. They can be used by the BOM generation tool, the Verilog netlister, and other tools.

  • Create a file called legal_pin_attr that contains all required pin attributes that a component symbol should have, such as PIN_NAME, PINTYPE, PIN_NO.

    2.0.2 Design directory structure

    A second condition for DRC to run is a fixed, single design directory structure that is shared by all PCB designs. Without it, DRC would not know where to find the schematics database and where to store the output files. This structure can be very complex and have many hierarchical levels in order to support all PCB design activities, such as design rule checking, BOM generation, Verilog simulation, static timing analysis, signal integrity analysis, placement/layout, PAL/FPGA design (synthesis and simulation), and document control. But for DRC alone, the following is sufficient, if ViewDraw is used:


    Figure 1 -- Directory structure

    The pcb_info directory should contain at least two files. The first is design_def and the other design_type. design_def should contain the PCB part (assembly) number and other required information, not just for DRC but for all other tools. design_type should contain design type information, which is PCB. If this design directory structure is shared by other types of design, such as ASIC or FPGA, then design_type should specify it so that design automation tools can take appropriate actions for different design types. If pcb_info directory is missing or empty, this means the design directory is not a standard one. In that case, DRC should exit and give an error message.

    The schem directory contains the schematics database and is accessed directly by ViewBase, which our DRC uses. The sch sub-directory contains schematic files that describe symbol locations on a sheet and other information. The wir sub-directory contains the netlist of the design and all symbol attributes. ViewBase routines can access them directly.

    The drc directory should store DRC's output files.

    3.0 A PCB DRC

    3.0.1 The wrapper program
    Our DRC is written in C and the ViewBase library of C routines. The latter provides easy and direct access to the ViewDraw schematics database. Each of its routines accesses one data item or traverses one relation between two data items. But DRC should not be run directly: it should be "wrapped" in a wrapper program written either in Perl or a UNIX shell language. The wrapper program does the following:

  • Checks whether the PCB design directory structure depicted in Figure 1 is valid.
  • Optionally runs a backend packaging program, such as pcbfwd for ViewDraw. This program can check for some of the design rule violations that would be hard to check in DRC, such as number and type of characters allowed for net names. It can also assign values (such as R4) to symbols' reference designator attributes that have no values assigned yet.
  • Checks the existence of required input files discussed in Section 2.0.1 and feeds them into DRC.
  • Finds the PCB design name and feeds it into DRC.
  • Feeds into DRC the paths and names of its output files.
  • Sets up required tool environmental variables, such as WDIR for ViewDraw and ViewBase.
  • Invokes the DRC program.
  • Prints help messages upon request.
  • Prints user and runtime information.
  • Performs post-processing. This can be as simple as checking DRC's output files into a revision control tool, or it can be as complicated as actively processing DRC's output files, such as adding more information from other data sources or performing sorting. C may not be the best tool for sorting data or for parsing files. For example, to sort a file numerically by using the second field, it is much easier to use the UNIX sort command as follows:

    sort +1n source_file > sorted_file

    3.0.2 DRC development: the main() function
    Let's call the DRC program drc.c and it can have two major functions: drc_net() and drc_inst(). The former walks through all nets and the latter all instances (symbols), looking for design rule violations. Both functions can also generate by-product output files, which are discussed in Section 1.0 and Section 4.0.

    drc.c should first include all the C, ViewBase and user created header files, such as stdio.h, viewbase.h and hash_table.h. Now set up drc.c to receive input arguments, to declare variables and file pointers to both input and output files, to have ViewBase point to the ViewDraw database, and to create linked lists and hash tables to store the information read in from input files. A portion of its main() function is given below.

    The input and output file names and the PCB design name are fed in by DRC's wrapper program (see Section 3.0.1) when it invokes the DRC. Data structures Str_list_elem and Hash_table are defined in the header files included by drc.c. GROUPS is a ViewBase data type.

    Next, the main() function should make sure correct number of inputs are passed in by checking whether argc is equal to the expected number. If yes, assign input arguments to the variables:

    At this time, main() function can initialize ViewBase data structures and make ViewBase pointer pcb_ptr point to the PCB design. If the design exists and is valid, then main() function should:

  • Open all input files for reading and store their information into internal data structures, such as Str_list_elem and Hash_table. Close the input files.
  • Open all output files for writing. They can be design rule error/warning files as well as the by-product files.
  • Call drc_net() and drc_inst() functions to do real work.
  • Close all output files.

    An outline of the C and ViewBase code inside main() that does this is:

    Here, iwinit() and iw1level() are ViewBase routines. The former initializes all loader routines and it is required. The latter loads one level of the PCB design (the entire design). To load just one sheet, use the iw1sheet() routine (which is not used in our DRC). Note that correct design pointers, file pointers, linked lists, variable names, etc., must be passed into drc_net() and drc_inst() functions:

    drc_inst(pcb_ptr, pcb_name, drc_error, list_legal_pwr_name, ...);

    If your design is hierarchical and uses heterogeneous component symbols, then make sure DRC can handle them properly.

    3.0.3 DRC development: the drc_net() function
    drc_net() walks through all the nets in the PCB design and looks for design rule violations and/or generates by-product output files. The code outline is as follows:

    Here, iggrpnet() and ignetnxt() are ViewBase routines for grabbing every net in the PCB design. ignetnam() is also a ViewBase routine for finding the name of a net. NETS, PINS, COMPONENTS, SYMBOLS, and ATTRIBUTES are ViewBase data types. drc_net() can look for the following design rule violations:

  • Illegal net names. If a net name is automatically assigned by ViewDraw, its format is $#...#N#...#, where the first #...# is sheet number and the second #...# is net number. Net names assigned by PCB designer must begin with a letter, which is followed by 30 or less characters.

    drc_net() should call a function legal_net_name() to perform this task. Regular expression matching/checking in C is greatly simplified in UNIX by the regexp.h header file, which must be included in the DRC program. drc_net() should pass the net name variable and the design rule violation file pointer into legal_net_name(), which looks like:

    The backend packaging tool pcbfwd can also check for illegal net names, but its ability is limited to simple regular expressions. The code given above can handle just about any regular expression. Also, whether to find illegal net names before or after running pcbfwd is a trade-off issue. For simple net names, use pcbfwd.

  • Bus contention on a net, which is a serious error. There are 2 kinds. One is contention among totem-pole outputs and the other among totem_pole and tristate outputs. The code outline is as follows:

    Here, ignetpin() and igpinnnx() are ViewBase routines that grab each pin on a net. igpinown() routine returns pointer to the pin's instance (owner). Functions get_inst_attr(), get_pin_attr() and get_sheet_num() return the requested instance attribute (reference designator REFDES), pin attribute (PINTYPE) and sheet number the pin's instance is on, respectively. The outline of the get_pin_attr() function is given below:

    The outline of the get_inst_attr() function is given below:

    The outline of the get_sheet_num() function is given below:

  • Illegal names for POWER and GROUND nets. They are compared against the information stored in internal data structures, such as linked lists.
  • Report nets that have load(s) but no driver or the other way around. This is done by keeping track of the pin type of each pin on a net. There should be 1 output pin or multiple tristate output pins and at least 1 input pin. Also, provide the reference designators and symbols of all the components on this net and the pins involved.
  • Report all open-collector outputs that either miss pull-up resistors or whose pull-up resistors are not tied to POWER.
  • Print a warning if a net has more than the usual number of loads, which should be less than 8 for good signal integrity.

    3.0.4 DRC development: the drc_inst() function
    The drc_inst() function is similar to drc_net(), except that the former walks through every schematic sheet and all instances on it in a PCB design to look for design rule violations or to generate by-product output files. Its code outline is:

    Our previous discussion of the drc_net() function provides ample C and ViewBase code examples, which will not be repeated here. Below is a partial list of design rule violations that drc_inst() can check:

  • Illegal or missing symbol library aliases. All symbols in a PCB design must come from corporate symbol library. Using symbols from wrong libraries is a very common source of errors, especially for backend processing tools which rely solely on symbols to process the design.
  • Missing symbol and/or pin attributes, such as those that specify component geometry and the type of a pin (in, out, bi, tri).
  • Illegal values of symbol and/or pin attributes. For example, pin type can have a value of IN, but not INPUT. This affects how a backend packaging tool, such as pcbfwd, provides information to the placement/layout tool, such as Allegro.
  • Values of reference designators on symbols, especially for series components, such as resistors, capacitors, and inductors. Most signal integrity tools require these values to start with letter R, C and L so that they can be analyzed as series elements instead of as discrete components. Also, drc_inst() can check their values against the description attribute to make sure the two match.
  • Illegal decoupling capacitors. This can cause POWER line dv/dt problems.
  • Illegal pull-up and pull-down resistors.
  • A symbol's POWER or GROUND pins not tied to POWER or GROUND plane.
  • Unused input pins not pulled up or down by a resistor or this resistor is not tied directly to POWER or GROUND net.
  • Give warnings if more than 1 unused input pins are pulled up or down by a single resistor.
  • Give warnings on non-dedicated POWER and GROUND pins that are tied directly to POWER or GROUND net.
  • If tabbing is used, check whether it references correct alternative components, such as whether their part numbers are valid and whether their geometries match that of the default component.

    3.0.5 What DRC should not do
    Although our DRC can do a lot, some things can be better and easier checked with other means. A great and necessary helper is the backend packaging utility that packages the PCB design for placement/layout tools. For ViewDraw, it is pcbfwd, which can be set up to check many design rule violations and design errors.

    There is an overlap between what DRC and pcbfwd can check, and it is a trade-off issue to decide when to check what. DRC is usually run right after the design is completed and before pcbfwd is run. Ideally, pcbfwd should be run only to package the design, so the more DRC can check the better. But you should balance the efforts in developing a super powerful DRC with pcbfwd's existing capabilities that come for free. This section briefly discusses these issues.

    pcbfwd is controlled by its configuration file, which is called allegro.cfg, if Allegro is the placement/layout tool. Its BeginChkRules - EndChkRules section can be used to check many errors, such as duplicate attribute on the same symbol, illegal net and net attribute names, bad heterogeneous package, conflicting attributes on heterogeneous symbols, and missing attributes. For example, to catch conflicting attributes on heterogeneous symbols, put the following line into allegro.cfg:

    CHKBRD _HETERO_ATT ERR 0

    There are things that neither DRC nor pcbfwd can check, such as intended redundancy in PCB designs. Suppose a component contains 4 identical parts and 2 are used on a design, then they can either be packaged into the same component or into 2 components for redundancy. If one component is required, symbols for both parts must have the same reference designator, such as U4. If 2 components are required, then the symbols must have different reference designators, such as U4 and U5, which must be conscientiously added by the designer. There is no known easy way to catch errors of this kind and a careful designer is probably the only guarantee.

    Another example is that although DRC and/or pcbfwd can check whether a symbol has the required geometry attribute GEOM, they can not check whether its value matches the schematic symbol. One mismatch can be between the number of pins specified on the ViewDraw symbol and that on the Allegro footprint.

    This particular error can be caught by Allegro's dev_check utility. First, run pcbfwd on ViewDraw schematics to create Allegro device files, which together with Allegro footprint files are fed into dev_check. Suppose pins 68, 69 and 70 are on Allegro footprint but not on ViewDraw symbol, then dev_check can catch this. These pins may be no-connect or mounting holes or even POWER/GROUND pins that are left out of the ViewDraw symbol by mistake. No-connect and/or mounting holes pins must be assigned to the NC attribute and POWER/GROUND pins to SIGNAL attribute. Modify the symbol in this way and re-run pcbfwd and dev_check.

    Finally, the quality of DRC outputs depends on schematics' quality. For example, if pin type is wrongly specified to be OUT for an input pin, DRC will generate wrong error messages. Component symbol quality should be carefully and systematically controlled, since it affects all other tools.

    4.0 Beyond DRC

    In addition to checking for design rule violations, DRC can also generate useful by-product output files, as has been previously discussed. An input switch can tell DRC whether to generate them for each run. Although these files do not contain DRC error or warning messages, they can flag potential design problems. For example, one file can contain a list of all nets and the number of loads on each. If that number exceeds a reasonable value, it may cause signal integrity problems. PCB designer can quickly go over this file and look for such issues. The number of these by-product files can be as many as required. A partial list is given below.

  • A list of all nets ordered by net name and the sheet each net is on. Additional information may include the pin number and type of the symbol (and its reference designator) this net is connected to. This file is created by the drc_net() function. It can be used to find which sheet(s) a net is on.
  • A list of all nets and the number of loads on each. This is generated by the drc_net() function. For good signal integrity, a net should have no more than 8 loads.
  • A list of nets that cross sheet boundary. This helps designer to debug the design in the laboratory.
  • A list of nets with net attributes and their attributes. Designer can check whether these nets have the correct attributes. This file is generated by the drc_net() function and the code outline is:

    Here, ignetatt() and igattnxt() are ViewBase routines to get every attribute on a net. igattnam() gets the attribute name. net_att is the file pointer to the output file.

  • A list of all unused pins, which should be pulled up or down. Report the pull-up and pull-down resistors. This file is generated by the drc_inst() function.
  • A list of all decoupling capacitors and their values. Additional information may include the schematic sheets they are on. The designer should quickly check this file to make sure enough decoupling capacitors are on the PCB. This file is generated by the drc_inst() function.
  • A list of all discrete components and their values, such as pull-up/pull-down resistors, transmission line termination resistors/capacitors. Additional information may contain the schematic sheets they are on. Designer can quickly check whether the number is reasonable. This file is generated by the drc_inst() function.

    Another important use of this list is in signal integrity and timing analysis of the PCB design [4]. Most tools in this area can automatically handle the so-called series elements by combining their effects into the transmission line analysis results but take them out of the output files. One such element is R1 in Figure 2, which is a series termination resistor. When a signal integrity tool reports the net delay, it will be from u1.z to u2.i with R1's effect included instead of from u1.z to R1.1 and continue on from R1.2 to u2.i. This is the correct thing to do for timing analysis.


    Figure 2 -- Series termination resistor

    However, in order for a signal integrity tool to automatically recognize a series element, some conditions must be met. For example, the reference designator of a resistor must start with letter R followed by numerical digits and that of a capacitor with letter C. Another condition is that each series element symbol must have a TYPE attribute with a value of DISCRETE. Without these conditions, these elements can not be handled correctly.

    One common problem is with a template design that is copied by many other PCBs. In order to avoid possible reference designator conflicts, a resistors and capacitor in the template design are usually called XR1 and XC1. They must be changed to R10001 and C10001 (the number should be bigger than any possible reference designators used in the original PCB design) in the database of the signal integrity tool. One can find the XR and XC reference designators by using the discrete components list generated by our DRC.

    5.0 Conclusion

    Clearly, there are many advantages and necessities of writing your own PCB design rule checker. Although this effort is not trivial, it is not rocket science either and can be done by anyone with a good knowledge of existing programming or scripting languages. The benefits are unlimited and can greatly outweigh the efforts.

    6.0 References

    1. Luke L. Chang, "Transient Analysis of the VAX 9000 Memory Power Distribution System", Digital Power Systems, Fall/Winter 1990

    2. Brian W. Kernighan & Dennis M. Ritchie, "The C Programming Language", 2nd Edition, Prentice Hall, 1988

    3. Bjarne Stroustrup, "The C++ Programming Language", 3rd Edition, Addison-Wesley, 1997

    4. Luke L. Chang, "Static Timing Analysis of High-speed Boards", IEEE Spectrum, March 1997

    Luke L. Chang is a Senior Verification Leader in the Storage Component Division of Intel (Hudson, MA). Previously, he has held both engineering and management positions at several high-tech companies, in the areas of hardware design/verification and of electronic design automation (EDA).

    • All materials on this site Copyright © 2009 TechInsights, a Division of United Business Media LLC. All rights reserved.
    Privacy Statement | Your California Privacy Rights | Terms of Service | About