标签: DRC

本文为硬件原理图设计的通用规范，主要从基本的设计角度，总结一般公司的设计要求，整合而成。 1. 原理图各页内容依次为：封面、目录、电源、时钟、CPU、存储器、逻辑、背板（母板）接口等。 2. 原理图上所有的文字方向应该统一，文字的上方应该朝向原理图的上方（正放文字）或左方（侧放文字）。 下图分别为符合规范和不符合规范的例子。 文字都向上或者向左，符合规范 文字方向不一致，有文字向右，字符重叠，不合规范 标注文字方向向下，不合规范。 3. 原理图上的各种标注应清晰，不允许文字重叠。 原理图上包括网络名、位好、器件管脚号等各中字符都不允许重叠下面是不符合规范的例子 4. 元器件的位号要显示在该元件的附近位置，不应引起歧义。 5. 芯片的型号和管脚标注，精密电阻、大功率电阻、极性电容、高耐压电容、共模电感、变压器、晶振，保险丝等有特殊要求的器件参数要显示出来，LED应标示型号或颜色。 6. 有确定含义的低电平有效信号采用*或者_N（引入逻辑的需要用_N）后缀结尾。“有确定含义”包括但不限于如下信号：片选，读写，控制，使能。 7. 所有的时钟网络要有网络标号，以CLK 字符结尾，以便于SI分析、PCB布线和检查；非时钟信号禁止以CLK等时钟信号命名后缀结尾。时钟信号命名应尽量体现出时钟频率信息。 为了方便信号完整性分析和布线约束制定，并保证不引起歧义，时钟信号必须以规定的CLK后缀结束。其他信号，例如时钟使能信号等，一律禁止以该信号命名后缀结束。时钟信号命名还应体现出时钟频率。根据绘图者的习惯，可以体现出时钟的流向、用途、来源等信息。 例如：FPGA1_8K_CLK，FPGA2_33M_CLK，OIB0_52CHIP_TCLK都是符合规范的命名。 串联端接时钟网络的命名参见串联端接网络的绘制和命名 8. 在PCB布线时有特殊要求的网络要定义网络名，推荐在原理图上注明要求。 9. 采用串联端接的信号（包括时钟），串阻在原理图上应就近放置于驱动器的输出端。串阻和驱动器之间不放置网络标号，串阻后的网络进行命名（时钟信号必须命名并满足时 钟信号的命名规范）。 对于源端端接网络，正确的画法应该是将串阻直接画在驱动器件的输出端，串阻和驱动器件之间的网络可以不进行命名，串阻之后的网络进行命名。如下图所示为一个正确的范例。 如果将串阻放在接收端，或者在串阻之前的信号进行命名，串阻之后的信号不进行命名，都会使得布线的分析和检查困难，甚至会造成串阻被放置在接收端而未被查出的结果，导致信号完整性较差。如下图是不正确的范例。 10 提供各单点网络列表和未连接管脚列表，并一一确认 关于单节点网络和浮空管脚的检查 可以通过Cadence附带的原理图规则检查工具Rules Checker对原理图进行规则检查。我们最常用的是单节点（Single_node_net）和浮空管脚（Unconnected_instance）检查。 启动Rules Checker的方法是选择Allegro Project Manager的菜单Tools – Rules Checker。在Logic Rules一项中选择net_name_checks.rle中的single_node_net和Property_checks.rle中的unconnected_instance选项（根据需要可以继续选择nets_shorted等选项），运行Rules Checker。 运行完成的结果可以通过读取文本文件的方式检查，也可以通过View Marker直接在原理图上定位确认。 在设计中出现单节点和浮空管脚是很正常的事情，例如单板静电泄放模块中有很多单节点。本条目要求的是对所有的单节点和未连接管脚进行确认，确保没有漏接网络或者遗留未处理的CMOS输入管脚、器件控制管脚。

Do you want to see a really cool video -- one in which something works first time? Well in that case it's "Happy Dance" time because I'll show you one in just a moment, but first let me set the scene...   First of all, I would like to introduce the Simblee, which encompasses a whole bunch of "stuff," including the Simblee Cloud, the Simblee Ecosystem, and Simblee Modules.   The thought of using Bluetooth Low Energy (BLE) Simblee Modules in conjunction with Simblee apps running on my iPad to control my various hobby projects is very exciting. The first such project that sprang to mind was my Bodacious Acoustic Diagnostic Astoundingly Superior Spectromatic (BADASS) Display.   This prompted me to leap into action to finish the display, which -- now I come to think about it -- was instigated during my trip to ESC Silicon Valley almost a year ago as I pen these words. The image below shows the little scamp standing in the drive outside our house just after I'd finished mounting all of the brass washers and Fresnel lenses on the main display panel (the reason it's in the drive is that I was working in the garage at the time).     The small control panel at the bottom was originally intended to provide a simple menu system that will allow me to select between various lighting effects. The red button will cause us to enter the menu system; the four black buttons will allow us to navigate through the system; and the green button will lock in the current selection and return us to the main display. I'm still going to implement this, of course (there's no point having a bunch of buttons if you can't make something interesting happen when you press them), but I'm also going to use a Simblee BLE Module and a Simblee app to allow me to replicate this functionality on my iPad, thereby allowing me to control the little beauty from the comfort of my armchair.   In the case of the main display panel, we have an array of 16 rows and 16 columns, which equals 256 elements. (This didn't seem like a particularly large number when I started -- I had contemplated using a lot more -- but having to do everything 256 times almost brought me to my knees.) Each of these elements is powered by a tri-colored pixel presented in the form of NeoPixel Strips from Adafruit.     So, as I say, this past weekend I leapt into action to get this little scamp up and running. The image below shows the inside of the cabinet just after I'd completed the wiring. Actually, I took a whole bunch of photos and videos documenting this part of the construction process, but the memory card in my camera messed up and I lost them all (sad face).     The vertical columns are formed from 16 NeoPixel Strips, each containing 16 NeoPixels. Attaching these made me realize that my hot glue gun really is one of my best friends. In the bottom left-hand corner of the cabinet we see a 5V power supply that can deliver up to 24A. Each NeoPixel can consume up to 60mA (20mA each for the red, green, and blue sub-pixels), so when all 256 of the little rascals are full on, we can be burning ~15.5A. This explains my "Power Bus" -- the chunky 10 gauge red and green wires running left-to-right along the bottom of the cabinet with tap points for the individual strips as illustrated below.     A slightly more detailed view of the insides of the cabinet is shown below. My Arduino Mega is on the bottom, with a Uno-sized prototyping board sitting on the top. On the one hand I'm quite proud of my wiring harness; on the other hand I know that the folks who create such harnesses professionally will be rolling around on the floor laughing hysterically at my pathetic attempt (feel free to post a comment telling me this is not so).     In fact, the Uno-sized prototyping board is just acting as a place-holder for the purposes of creating the wiring harness. My chum Duane Benson is currently in the process of taking the original breadboard prototype of my audio spectrum analyzer and creating a custom Arduino Shield. This will be open source, of course, plus Duane will be offering them for sale to anyone who wants one. The image below shows the current state of this design as it arrived in my email just a few minutes ago at the time of this writing. The red indicated traces on top of the board; the blue indicates copper (traces and ground plane) on the bottom of the board. We decided to use the large ground plane to provide as much shielding as possible from noise.   Duane even managed to squeeze in a small prototyping area on the left-hand side of the shield. I've just performed a LVS (layout versus schematic) check by eyeballing everything, so as soon as Duane has performed a final DRC (design rules check), he will be sending this little ragamuffin of to the board shop. I can’t wait!   One final point of interest before we look at the video is that my Arduino Mega has been modified to run off the same 5V power supply as the NeoPixels, because I prefer to have just one power supply and to not have to consider potential power sequencing issues ( click here for details as to how to perform these modifications).   Now, as I said earlier, I took a bunch of videos of the display sitting on the kitchen table when I first powered it up, just after I'd finished creating the wiring harness, but my silly camera lost them. Thus, this video was actually taken yesterday evening in our spare bedroom (where I'm storing it out of the way when I'm not working on it), but it's a true recreation of the way things went down.     Normally, when I power one of my projects up for the first time, if I'm lucky... nothing happens (if I'm unlucky, there may be sparks and smoke and strange sounds). In this case, I expected things to mostly work, but I also fully anticipated a few glitches along the way, like one or more columns of NeoPixels failing to light up or individual pixels not working as well as expected.   In the event, everything worked first time. As we see in the above video, all I've done thus far is to run a really simple test that lights each pixel in turn and switches between different colors. Now the fun stuff starts on the programming side. Watch this space for future updates...

　　编写属于自己的PCB设计规则检查器具有很多优点，尽管设计检查器并不那么简单，但也并非高不可攀，因为任何熟悉现有编程或脚本语言的设计人员完全能够设计检查器，这项工作的好处是不可估量的，本文介绍编写PCB设计规则检查器的技巧。 　　本文阐述了一种编写PCB设计规则检查器(DRC)的系统方法。利用电路图生成工具得到PCB设计后，即可运行DRC以找到任何违反设计规则的故障。这些操作必须在后续处理开始之前完成，而且开发电路图生成工具的开发商必须提供大多数设计人员都能轻松掌握的DRC工具。 　　然而，市场销售的通用工具通常不具备足够的灵活性以满足特定的设计需要。因此，客户必须将新特性需求反映给DRC工具开发商，而这通常需要耗费一定的资金和时间，尤其当需求不断更新时。幸运的是，大多数工具开发商均可为客户提供编写属于自己的DRC以满足特定需求的便捷方法。但是，这种具有强大功能的工具尚未得到广泛认同或使用。本文提供了利用DRC工具获取最大收益的实用指南。 　　由于DRC必须遍历 PCB设计的整个电路图，包括每个符号、每个引脚、每个网路、每种属性，如有必要还能创建数目不限的“附属”文件。如4.0节所述，DRC可以标示出任何违反设计规则的细微偏差。例如其中一个附属文件就可能包含设计用到的全部去耦电容。如果电容数低于或高于期望值，就将在可能出现电源线dv/dt问题的地方标注红色记号 。这些附属文件或许必不可少，但并非任何商用DRC工具都一定能创建这些文件。 　　DRC的另一优势是便于更新，以适应新设计特性(如那些可能影响设计规则的新特性)的需要。而且，一旦在该领域获得充分经验，那么还能实现许多其它功能。 　　例如，如果能编写属于自己的DRC，那么就能编写属于自己的物料清单(BOM)创建工具，这样就能更好地处理特定用户需求，如如何获取本身不属于电路图数据库一部分的器件“额外硬件”(如插座、散热装置或螺丝刀)。或者设计人员可以编写属于自己的Verilog网表分析器，该分析器在设计环境下具有充分的灵活度，如怎样获取适用于特定器件的Verilog模型或时间文件。实际上，由于DRC遍历了整个设计电路图，因此可以收集全部有效信息以输出PCB设计Verilog网表分析所需的仿真和/或BOM。 　　在不提供任何程序代码的前提下讨论这些话题实在有些牵强，为此，我们将以一种电路图获取工具为例进行说明。本文采用了 Mentor Graphics公司开发的附属于PADS-Designer产品线的ViewDraw工具。此外，我们还采用了ViewBase工具，这是一个可被调用并对ViewDraw数据库进行存取操作的简化C例行程序库。利用ViewBase工具，设计人员可以轻松地采用C/C++语言为ViewDraw编写完整且高效的DRC工具 。需要注意的是，这里讨论的基本原则同样适用于任何其它的PCB电路图工具。 　　输入文件 　　除了电路图数据库，DRC还需要一些可以描述特定情况处理的输入文件，如自动连接到电源平面的合法电源网路名称。例如，如果电源网路名为POWER，那么电源平面将采用后端封装设备(如适用于ViewDraw的pcbfwd)自动连接到电源平面。下面给出了输入文件列表，这些文件必须放在固定的全局位置，这样DRC就能自动找到并读取，然后在运行时将这些信息保存在DRC内部。 　　* 文件legal_pwr_net_name可选，该文件包含POWER信号全部合法网路名称，如VCC、V3_3P和VDD。在PCB布局/路由工具中，需要对名称的大小写进行区分，一般VCC并不等同于Vcc或vcc。VCC可以是5.0V的电源，而V3_3P则可以是3.3V的电源。 　　* 文件legal_pwr_net_name可选，因为后端封装设备的配置文件通常必须包含一组合法电源线网路名称。如果采用Cadence设计系统公司的Allegro布线工具，那么pcbfwd的文件名则为allegro.cfg并且具有如下入口参数： 　　接地：VSS CGND GND GROUND 　　电源：VCC VDD VEE V3_3P V2_5P +5V +12V 　　如果DRC可以直接读取allegro.cfg文件，而非legal_pwr_net_name，那么将能得到更好的结果(即引入误差的几率较小)。 　　电源线引脚通常并不外接到器件符号上，相反，该符号的一个属性(这里称为SIGNAL)描述了哪个引脚是电源引脚或接地引脚并描述引脚应当连接的网络名称。 　　SIGNAL = VCC:10 　　SIGNAL = GROUND:20 　　DRC可读取该属性并确保网路名称保存在legal_pwr_net_name文件中，如果legal_pwr_net_name中不包含网路名称，那么电源引脚将不会连接到电源平面，而这个问题确实非常严重。  　　一些符号必须具有外接电源线引脚，因为这些符号并不连接到常规电源线层。例如，ECL器件的VCC引脚要么连接到VCC，要么连接到GROUND；其VEE引脚则可连接到GROUND或-5.0V平面。此外，电源线引脚在到达电源线层之前也可连接到滤波器。 　　引脚与滤波器之间的网路可具有任意名称，而DRC很难检测到这一点。DRC可以错误形式汇报这一点，而用户则必须将其标示出或在legal_pwr_net_name文件中添加该网路名称。这就是我们需要类似legal_pwr_net_name文件的一个原因。最后，DRC 将读取legal_pwr_net_name，以1)找到上拉电阻，2)在设计中检查POWER网路名称的大小写，3)检测任何与POWER直接相连但尚未使用的引脚。 　　* 包含GROUND信号(如GROUND、VSS和F_GND)中所有合法网路名的legal_gnd_net_name文件可以随意创建。而需要再次注意的是，符号的大小写可能会对一些PCB布线工具产生影响。而且，如果DRC可以直接读取上述allegro.cfg文件，而非 legal_gnd_net_name文件的话，无疑可以得到更好的设计结果。 　　legal_gnd_net_name不仅具有与legal_pwr_net_name相同的功能，而且DRC还可读取该文件，以1)找到下拉电阻，2)检查POWER网路名称的大小写，3)检测任何与POWER直接相连但尚未使用的引脚。 　　* 包含全部合法符号库路径和名称的legal_lib_path_name文件可以随意创建，这一点非常重要。例如，一个常见的严重错误是使用未授权程序库中的符号。在PCB设计阶段，根据测试需要，通常要求创建临时器件符号并保存在本地符号库目录中。最终用到的器件符号来源于此并将保存在联合或全局的程序库目录中，这些符号具有一些不同于本地器件符号的重要特征。设计人员通常会因为没有采用共同符号取代本地符号而引入设计错误。 　　legal_lib_path_name可选，因为对于大多数电路图工具，程序库信息包含在启动工具所需的初始化文件中。对于ViewDraw工具，该文件称为viewdraw.ini，当工具启动时，该文件就自动创建(利用脚本程序)：目录 /corp_lib/pcb/symbol_libraries/viewdraw/fct (fct)。 　　Fct(快速CMOS技术)是ViewDraw众多子库中的一个，也是fct器件各符号的来源。如果初始化文件存在，那么DRC不仅可以而且也应当直接读取该文件，因为设计人员可以及时地添加新程序库。 　　* 可以创建包含合法上拉电阻的legal_pullup_res文件以检测那些被终止以及未被使用的输入引脚。通常，可以限定一组设计人员能使用的电阻，当然电阻值本身也是一个重要因素。如果上拉了未使用的输入引脚，那么该电阻的阻值将为5K或更高。 　　* 可以创建包含合法下拉电阻的legal_pulldown_res文件以检测那些被终止以及未被使用的输入引脚。如果下拉了未使用的输入引脚，那么阻值将会很小以阻止任何电流泄漏，从而使引脚电压高于触发阀值。 　　* 可以创建包含合法去耦电容的legal_decoup_cap文件，而且公司还可要求设计人员只使用特定的合格器件以满足电源线dv/dt要求。 　　* 可以创建一个包含器件符号全部属性的legal_comp_attr文件，如PART_NO、GEOM、REFDES和SIM_CLASS。BOAM创建工具、Verilog网表分析器及其它工具都能使用这些属性。 　　* 可以创建一个包含器件符号全部引脚属性的legal_pin_attr文件，如PIN_NAME、PINTYPE和PIN_NO。 　　设计目录结构 　　运行DRC必须满足的第二个条件就是需要可被所有PCB设计共享的单独设计目录结构。没有该目录结构，DRC将难以确定如何找到电路图数据库并存储输出文件。该架构可以极复杂的分层架构支持全部PCB设计业务，如设计规则检查、BOM创建、Verilog仿真、静态时序分析、信号完整性分析、布线、PAL/FPGA设计(综合与仿真)及文档控制。但对于DRC本身，如果采用了ViewDraw，那么下述条件就完全充分： 图1：目录结构。 　　pcb_info应最少包含两个文件：design_def和design_type。design_def应包含PCB器件(组合)数目及其它所需信息，这不仅仅对于DRC，对于其它所有工具也同样如此。design_type应当包含设计类型信息，即PCB信息。如果其它类型的设计(如ASIC或FPGA)可以共享该设计目录结构，那么design_type将指定该目录，这样设计自动化工具将能根据不同的设计类型进行适当的操作。如果没有pcb_info目录或该目录内容为空，这就意味着设计目录并非标准设计目录。在这种情况下，DRC应当退出并发送出错信息。  　　Schem目录包含电路图数据库并可由DRC使用的ViewBase直接存取。sch子目录包含了在图表上描述符号位置的电路图文件及其它信息，wir子目录则包含设计网表分析及全部符号属性。ViewBase例程可直接存取这些内容。drc目录应存储DRC输出文件。 　　封装程序 　　本文提出的DRC工具采用C语言和C例程ViewBase库编写，C例程ViewBase库可提供对ViewDraw电路图数据库进行存取的便捷方法。每个例程均对一个数据项进行存取或在两个数据项之间建立联系。但DRC不能直接运行：DRC应“包装”在一个采用Perl或 UNIX命令解释语言编写的封装程序中。该封装程序具有如下形式： 　　* 检查如图1所示的PCB设计目录结构是否有效。 　　* 可以运行后端封装程序(如应用于ViewDraw的pcbfwd)。该程序可检测一些违反规则的设计缺陷(如网路名称的数目和类型特性)，而这通常很难采用DRC工具检测。此外，还能赋值给那些尚未赋值的符号参考标志符特性 (如R4)。 　　* 检测2.0.1节中讨论的输入文件是否存在，并将其注入DRC。 　　* 找到PCB设计名称并将其注入DRC。 　　* 将其输出文件的路径和名称注入DRC。 　　* 建立所需的工具环境变量，如用于ViewDraw和ViewBase的WDIR。 　　* 调用DRC程序。 　　* 按需求打印帮助信息。 　　* 打印用户和运行时间信息。 　　* 执行后处理。这既可以像修正控制工具检测DRC输出文件那样简单，也可以像主动处理DRC输出文件那样复杂(如从其它数据源添加更多的信息或执行排序操作)。C或许不是最佳的数据排序或文件分析工具，因为如果按数字顺序排列文件，采用UNIX排序命令更为简单：sort +1n source_file sorted_file。 　　DRC开发：main()函数 　　可以调用DRC程序drc.c，该文件具有两个主要函数：drc_net()和drc_inst()。drc_net()遍历了全部网路而drc_inst()则遍历所有的元件(符号)，这样就能检测任何有违规则的设计缺陷。这两个函数都能产生附属的输出文件，可以参见1.0 节和4.0节。 　　drc.c首先应当包含全部由C、ViewBase和用户创建的头文件，如stdio.h、viewbase.h和 viewbase.h。现在可以设定drc.c接收输入参数，这样不仅能为输入和输出文件声明变量和文件指针，还可使ViewBase指向 ViewDraw数据库，并创建链接列表和散列表以存取从输入文件读入的信息。下面给出了main()函数的部分代码实现。 　　当DRC封装程序激活DRC时，将导入输入和输出文件名及PCB设计名 (参见3.0.1节)。数据结构Str_list_elem和Hash_table定义在drc.c包含的头文件中，而GROUPS则是ViewBase数据类型。 　　下一步，main()函数可以通过检验argc的取值从而确保输入参数数目正确。如果参数值正确，那么将为变量分配正确的输入参数。 　　此时，main()函数可以初始化ViewBase数据结构，并使ViewBase指针pcb-ptr指向PCB设计。如果该设计存在并有效，那么main()函数应当： 　　* 打开全部输入文件，读取信息并将信息存储到内部数据结构(如Str_list_elem和Hash_table)中， 然后关闭输入文件。 　　* 打开所有输出文件以写入信息，这些文件可以是设计规则错误/警告文件，也可以是附属文件。 　　* 调用drc_net()和drc_inst()函数执行实际操作。 　　* 关闭所有输出文件。 　　main()函数中完成上述功能的C和ViewBase代码如下： 　　 　　这里，iwinit()和iw1level()是ViewBase例程。前者初始化全部载入例程(这也是必须的)，而后者则载入整个PCB设计。为了保证只载入一张电路图，可以调用iw1sheet()例程(本文的DRC工具并不使用该例程)。需要注意的是，正确的设计指针、文件指针、链接列表、变量名称等必须传入drc_net()和drc_inst()函数： 　　drc_inst(pcb_ptr, pcb_name, drc_error, list_legal_pwr_name, ...); 　　drc_inst(pcb_ptr, pcb_name, drc_error, list_legal_pwr_name, ...);  　　如果设计采用分层结构及不同的器件符号，那么还必须确保DRC能正确处理这些器件。 　　DRC开发：drc_net()函数 　　drc_net()在PCB设计中遍历所有网路并检测任何违反设计规则的故障，然后创建附属的输出文件。实现上述功能的基本代码如下： 　　 　　这里，iggrpnet()和ignetnxt()函数是在PCB设计中检查每个网路的ViewBase 例程。ignetnam()函数也是检查网路名称的ViewBase例程。ViewBase中的数据类型包括NETS、PINS、COMPONENTS、 SYMBOLS和ATTRIBUTES。drc_net()函数可检测下述违反设计规则的错误： 　　* 非法网路名。如果网路名由ViewDraw自动分配，那么将具有如下格式：$#...#N#...#，第一个#...#表示图表编号，第二个#...#则表示网路号。PCB设计人员指定的网路名必须以字母开头，其后的字符数不多于30。 　　drc_net()函数应调用legal_net_name()函数执行该任务。在UNIX系统中，利用包含在DRC程序中的regexp.h头文件可以极大地简化采用C语言编写的常规表达式匹配/校验程序。drc_net()应将网路名称变量和违反设计规则的文件指针存储在 legal_net_name()函数中，该函数具有如下形式： 　　 　　后端封装工具pcbfwd也可检测非法网路名，但其功能受限于简单的常规表达式。上述代码可处理任何常规表达式，同样地，如何在运行pcbfwd工具之前或之后找到非法网路名称也需要权衡。对于简单的网路名称，可以使用pcbfwd。 　　* 网路上的总线竞争也是严重问题。总线竞争有两类：一类是图腾柱输出间的总线竞争，而另一类则是图腾柱与三态输出间的总线竞争。基本代码实现如下所示： 　　 　　这里，ignetpin()和igpinnnx()函数是在网路上检查每个引脚的ViewBase例程。 igpinown()例程返回引脚实例(系主)指针。函数get_inst_attr()、get_pin_attr() 和get_sheet_num()则返回请求实例属性(参考标志符REFDES)、引脚属性(PINTYPE)及引脚实例所在的图表编号。 get_pin_attr()函数的基本代码如下： 　　 　　get_inst_attr()函数的基本代码如下： 　　 　　get_sheet_num()函数的基本代码如下： 　　 　　* POWER和GROUND网路中的非法名称。这些名称将与存储在内部数据结构中的信息(如链接列表)进行比较。 　　* 报告那些具有负载但不具有驱动程序或者具有驱动程序但不具有负载的网路。这可以通过标注网路上每个引脚的类型加以实现。网路应当带有1个输出引脚或多个三态输出引脚及最少一个输入引脚，此外还可提供与网路全部器件和引脚相关的参考标志符和符号。 　　* 报告那些不带上拉电阻或所带上拉电阻未连接到POWER的所有集电极开路输出。 　　* 一旦网路的负载超过常规数目(良好的信号完整性条件下限额为8)，那么将打印警告信息。 　　DRC开发：drc_inst()函数 　　drc_inst()函数与drc_net()函数类似，不同的是，前者遍历了全部电路图表及PCB设计中电路图表上的所有实例，从而检测违反规则的设计缺陷或创建附属的输出文件。其代码实现如下： 　　 　　上面关于drc_net()函数的讨论提供了充分的C和ViewBase代码示例，这里就不在赘述。下面给出了drc_inst()函数可检测的部分违反规则的设计缺陷： 　　* 非法或遗漏的符号库混淆。PCB设计中的所有符号必须来自共同符号库，使用来自错误符号库的符号是一个极为常见的错误，尤其是对于那些只依赖于符号进行设计的后端处理工具。 　　* 遗失符号和/或引脚属性，例如那些描述器件几何结构和引脚类型(in、out、bi和tri)的特性。 　　* 非法的符号和/或引脚属性。例如，引脚类型可具有IN值，但不包括INPUT值。这将对后端封装工具(如pcbfwd)如何为布线工具(如Allegro)提供信息产生影响。 　　* 符号上的参考标志符值，尤其是对于串行器件(如电阻、电容和电感)。大多数信号完整性工具需要这些器件以字母R、C和L开头，因此可将这些器件作为串联元件而非离散器件进行分析。类似地，drc_inst()函数可将其值同描述的属性进行对比以保证两者完全匹配。 　　* 非法去耦电容。这可能导致POWER线dv/dt问题。* 非法上拉和下拉电阻。  　　* 不与符号POWER或GROUND平面相连的POWER或GROUND引脚。 　　* 未使用的输入引脚不被电阻上拉或下拉，或者该电阻不与POWER或GROUND网路直接相连。 　　* 当单个电阻器上拉或下拉1个以上输入引脚时发出警告信息。 　　* 对于直接与POWER或GROUND网路相连的非专用POWER和GROUND引脚发出警告信息。 　　如果采用了标记技术，那么将检验该标记是否注明了正确的可选器件，例如型号是否有效及其几何结构是否与默认的器件规格匹配。 　　DRC不应当具备的功能 　　尽管DRC能够实现很多功能，但仍然可以采用其它方法以期更好更便捷地加以实现。后端封装工具可为布线工具封装PCB设计，因此可提供有效帮助。在ViewDraw中，pcbfwd可用来检测诸多违反规则的设计缺陷和设计错误。 　　DRC和pcbfwd可检测的问题之间存在重叠，因此何时检测何种设计问题就需要进行折衷考虑。DRC通常在设计完成之后及 pcbfwd运行之前才能正确地运行。理想情况下，运行pcbfwd只为了封装设计，因此更多的DRC可以得到更好的检测结果。但设计人员仍然需要在其投入精力开发具有超强功能的DRC与pcbfwd现有的免费功能之间取得平衡。这一节简单地讨论了这些问题。 　　pcbfwd由配置文件控制，如果布线工具为Allegro，那么配置文件名为allegro.cfg。配置文件中的 BeginChkRules - EndChkRules部分可用来检测众多错误，如相同符号的重复属性、非法网路和网路属性名称、损坏的异质封装、异质符号上的冲突属性及遗漏属性。例如，为了在异质符号上获取冲突的属性，可以在allegro.cfg文件中添加如下内容： 　　CHKBRD _HETERO_ATT ERR 0 　　但仍有一些问题既不能采用DRC，也不能采用pcbfwd进行检测，如PCB设计中的预期冗余。假定器件包含4个完全相同的部分，其中两个部分用于设计，那么这些部分既可以封装在相同器件中，也可以出于冗余考虑将其封装在两个器件中。如果只需要一个器件，那么两部分用到的符号将具有相同的参考标志符(如U4)；如果需要两个器件，那么符号将具有不同的参考标志符(如U4和U5)，设计人员必须有意识地加以标注。目前尚无检测这类问题的便捷方法，因此只有通过严谨的设计进行保障。 　　此外，尽管DRC和/或pcbfwd可以检测符号是否具有所需的几何属性GEOM，但并不能检测其值是否与电路图符号相匹配。例如，ViewDraw符号指定的引脚数目就有可能与Allegro覆盖区的引脚数目不匹配。 　　这类特殊错误可由Allegro的dev_check进行检测。首先，在ViewDraw电路图上运行pcbfwd工具，创建Allegro设备文件，该文件连同Allegro覆盖区文件将导入至dev_check。假定引脚68、69和70位于Allegro覆盖区而不在 ViewDraw上，那么dev_check就能检测到该错误。这些引脚可以是不相连引脚，安装孔引脚，甚至是由于失误而仍留在ViewDraw 符号外的POWER/GROUND引脚。不相连引脚和/或安装孔引脚必须赋以NC属性，而POWER/GROUND引脚则必须赋以SIGNAL属性。按这种方式修正符号，然后重新运行pcbfwd 和dev_check。 　　最后，DRC输出的质量取决于电路图质量。例如，如果输入引脚被错误地指定为OUT属性，那么DRC将产生错误的出错消息。器件的符号质量应仔细而系统地进行控制，因为该质量将影响其它所有工具。 　　DRC的其它功能 　　除了检测违反规则的设计缺陷，DRC还可以创建有助于设计分析的附属输出文件，如前所述。输入切换可通知DRC在每次运行时是否创建这些文件。尽管这些文件并不包含DRC出错或警告消息，但仍然能标示出潜在的设计问题。例如，一个文件包含了所有网路及每个网路上的负载数目信息。如果负载数目超出允许值，那么就有可能导致信号完整性问题。PCB设计人员可以迅速地检查该文件以找到潜在的错误。设计人员可以获得尽可能多的附属文件，下面给出了部分列表。 　　* 按网路名称排序的网路列表及每个网路所在图表的列表。此外，还可能包含引脚编号和网路连接的符号类型(及其参考标志符)。该文件由drc_net()函数创建并可用于查找网路所在的图表。 　　* 包含所有网路及每个网路上负载数目的列表，由drc_net()函数创建。为了获取更好的信号完整性，网路上的负载数不应超过8个。 　　* 跨越图表边界的网路列表。这有助于设计人员在调试中调整设计。 　　* 具有网路属性的网路及其属性。设计人员可以检验网路是否具有正确的属性，该文件由drc_net()函数创建，其基本代码实现如下：  　　 　　这里，ignetatt()和igattnxt()是可以获取网路属性的ViewBase例程。igattnam()获取属性名，而net_att则是输出文件的文件指针。 　　* 未使用引脚列表，这些引脚可以是上拉引脚或下拉引脚。该文件由drc_inst()函数创建，可以报告上拉电阻和下拉电阻信息。 　　* 所有去耦电容及其容值列表，此外还可能包括这些电容所在的电路图表。设计人员应迅速检验该文件以确保PCB上具有足够多的去耦电容 。该文件由drc_inst()函数创建。 　　* 所有离散器件及其值的列表，如上拉/下拉电阻、传输线终端匹配电阻/电容。此外，还可能包含这些器件所在的电路图表。设计人员可迅速检查器件数目是否合理，该文件由drc_inst()函数创建。 　　该列表的另一项重要应用则是PCB设计的信号完整性和时序分析 。该领域的大多数工具可以通过将所谓的串行元件功能合并为传输线分析结果并从输出文件中取出这些元件，从而自动处理这些串行元件。图2中的R1就是一个串行终端匹配电阻。当信号完整性工具报告网路延迟时，由于 R1的存在，延迟将由u1.z到u2.i，而不是先从u1.z到 R1.1，再由R1.2到u2.i。这是正确处理时序分析的方法。 图2：串联终端匹配电阻 　　然而，为了使信号完整性工具自动识别串行元件，必须满足一些条件。例如，电阻的参考标志符必须以字母R开头，后面紧跟数字，而电容则必须以字母C开头。另一条件则是每个串行元件符号都必须具有属性值为DISCRETE 的TYPE属性。没有这些条件，这些元件就无法得到正确地处理。 　　被许多其它的PCB复制的模板设计也是一个常见问题。为了避免可能的参考标志符冲突，模板设计中的电阻和电容通常可称为 XR1和XC1。在信号完整性工具数据库中，这些器件都必须更改为R10001和C10001(编号略大于原始PCB设计中使用的任何参考标志符)。设计人员可采用由DRC创建的离散器件列表检查到XR和XC参考标志符。 　　参考文献： 　　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).