編寫自己的PCB設計規則檢查器
1.0簡介

本文介紹了編寫設計規則檢查器（DRC）的系統方法用于PCB設計。在原理圖工具中捕獲PCB設計后，必須運行DRC以查找違反設計規則的行為。這必須在后端處理開始之前完成。通常，原理圖工具的供應商提供DRC，大多數設計人員只是使用它。

但是，供應商工具是通用的，可能并不總是足夠靈活，可以處理某些獨特的要求。可以將要添加到DRC的新功能的請求發送給供應商，但這將花費金錢和時間，特別是如果必須多次執行此操作。幸運的是，大多數工具供應商都提供易于使用的機制，您可以編寫自己的DRC以更好地滿足您的獨特需求。不幸的是，這個強大的工具還沒有被廣泛認可或利用。在本文中，我們提供了一些有關如何充分利用它的實用指南。

因為DRC必須遍歷PCB設計的整個原理圖，包括每個符號，每個引腳，每個網絡，如有必要，可以生成每個屬性，無限數量的有用“副產品”。正如第4.0節所解釋的那樣，它們可以很好地標記出微妙的設計規則違規。例如，一個副產品文件可能包含設計中的所有去耦電容。如果數字遠小于或大于預期，這可能會引發可能的電源線dv/dt問題的紅旗[1]。這些副產品文件可能非常需要，但它們是絕對不是由任何商用DRC生成的。

此DRC的另一個好處是可以輕松快速地更新它以適應新的設計功能，例如影響設計規則的新屬性。此外，一旦在這個領域獲得了足夠的經驗，那么許多其他可能性將出現。

例如，如果您可以編寫自己的DRC，您當然可以編寫自己的物料清單（BOM）生成工具，這又可以更好地處理某些獨特的要求，例如在哪里獲取組件不屬于原理圖數據庫的“額外硬件”（插座，散熱片或螺釘）。或者您可以編寫自己的Verilog netlister，它足夠靈活，適合您的設計環境，例如在哪里可以獲取Verilog模型或某些獨特組件的計時文件。事實上，當DRC遍歷設計原理圖時，它可以收集所有必要的信息，以輸出用于模擬的Verilog網表和/或用于PCB制造的BOM。

這將很難討論這些主題沒有提供一些編程代碼。為此，我們需要使用原理圖捕獲工具作為示例。在本文中，我們使用來自Mentor Graphics的ViewDraw，它是PADS-Designer產品系列的一部分。此外，我們使用ViewBase，它只是一個C例程庫，可以調用它來訪問ViewDraw數據庫。使用ViewBase，您可以輕松地在C/C ++[2] [3]中為ViewDraw編寫完整且有用的DRC。請注意，我們在此討論的原則適用于任何其他PCB原理圖工具。

2.0開始

2.0.1輸入文件
除了原理圖數據庫之外，DRC還需要一些輸入文件來告訴它如何處理某些情況，例如自動連接到電源平面的合法電源網名。例如，如果電源網稱為POWER，則它會通過后端打包實用程序自動連接到電源平面，例如ViewDraw的 pcbfwd 。以下是這些輸入文件的列表，這些文件應放在固定的全局位置，以便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 Design Systems的Allegro是放置/布局工具，則該文件名為allegro.cfg，用于 pcbfwd ，它必須具有以下條目：

接地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文件中的名稱。如果沒有，該電源引腳將不會連接到電源層，這是一個非常嚴重的錯誤。

某些符號必須帶有電源/接地引腳，因為它們未連接到正常電源/接地層。例如，ECL器件的VCC引腳可以連接到VCC或GROUND;其VEE引腳可以連接到GROUND或-5.0V平面。此外，電源/接地引腳可以在進入電源/接地平面之前首先連接到濾波器。

此引腳和過濾器之間的網絡可以有任何名稱，DRC將無法檢查此信息。 DRC可以將此報告為錯誤，用戶必須將其篩選出來，或者僅為此設計將網名添加到legal_pwr_net_name文件中。這是可能需要legal_pwr_net_name等文件的一個原因。最后，legal_pwr_net_name將被DRC讀入1）找到上拉電阻，2）檢查設計中POWER網名的字母大小寫，以及3）檢測任何未使用的引腳直接連接到POWER。

可選擇創建一個名為legal_gnd_net_name的文件，其中包含GROUND信號的所有合法網絡名稱，例如GROUND，VSS和F_GND。再次注意，字母大小寫可能對某些PCB布局/路由工具很重要。此外，如果DRC可以直接讀取上面提到的allegro.cfg文件而不是legal_gnd_net_name，那將更好。

legal_gnd_net_name與上面討論的legal_pwr_net_name具有相同的目的。此外，它將被DRC讀入1）找到下拉電阻，2）檢查GROUND網絡名稱的字母大小寫，以及3）檢測直接連接到GROUND的任何未使用的引腳。

（可選）創建legal_lib_path_name文件，其中包含所有合法符號庫路徑和名稱。這非常重要，因為常見和嚴重的錯誤是使用未經授權的庫中的符號。在PCB設計階段，通常會創建臨時組件符號并將其放在本地符號庫目錄中以進行測試。最終版本將從此出來并放在公司或全局庫目錄中，它們可能與本地版本的重要方式不同。設計人員通常忘記用公司符號替換本地符號并引入設計錯誤。

legal_lib_path_name是可選的，因為對于大多數原理圖工具，庫信息包含在啟動該工具所需的初始化文件中。對于ViewDraw，該文件名為viewdraw.ini，并在工具啟動時自動創建（通過腳本）。庫規范條目如下所示：

DIR [r]/corp_lib/pcb/symbol_libraries/viewdraw/fct（fct）

fct是眾多ViewDraw中的一個子可以來自fct（快速CMOS技術）部件符號的庫。 DRC可以而且應該直接讀取此初始化文件（如果存在），因為設計人員可以動態添加新庫。

創建一個名為legal_pullup_res的文件，其中包含合法的上拉電阻用于端接和未使用的輸入引腳。通常，公司有資格并允許其設計人員使用的電阻列表。此外，電阻值也很重要。如果未使用的輸入引腳被上拉，則該值應為5K或更高。

創建一個名為legal_pulldown_res的文件，其中包含用于端接和未使用輸入引腳的合法下拉電阻。如果使用一個電阻來拉低未使用的輸入引腳，則其值應該很小，以防止任何漏電流將引腳電壓增加到觸發閾值以上。

創建一個名為legal_decoup_cap的文件，其中包含合法的去耦電容。同樣，公司可能要求其設計人員僅使用符合電源線dv/dt要求的某些合格零件。

創建一個名為legal_comp_attr的文件，其中包含組件符號應具有的所有必需屬性，例如PART_NO，GEOM，REFDES，SIM_CLASS。它們可以由BOM生成工具，Verilog網表和其他工具使用。

創建一個名為legal_pin_attr的文件，其中包含組件符號應具有的所有必需的引腳屬性，例如PIN_NAME，PINTYPE，PIN_NO 。

2.0.2設計目錄結構

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的輸出文件。

3.0 A PCB DRC

3.0.1包裝器程序
我們的DRC是用C語言和C例程的ViewBase庫編寫的。后者提供了對ViewDraw原理圖數據庫的輕松直接訪問。它的每個例程訪問一個數據項或遍歷兩個數據項之間的一個關系。但是DRC不應該直接運行：它應該“包裝”在用Perl或UNIX shell語言編寫的包裝程序中。包裝器程序執行以下操作：

檢查圖1中描述的PCB設計目錄結構是否有效。

可選擇運行后端打包程序，例如 pcbfwd 用于ViewDraw。該程序可以檢查在DRC中難以檢查的一些設計規則違規，例如網絡名稱允許的字符數和類型。它還可以將值（例如R4）分配給尚未分配值的符號參考指示符屬性。

檢查第2.0.1節中討論的所需輸入文件是否存在，并將它們提供給DRC。/li>

查找PCB設計名稱并將其提供給DRC。

向DRC輸入其輸出文件的路徑和名稱。

設置所需的工具環境變量，例如用于ViewDraw和ViewBase的WDIR。

調用DRC程序。

根據請求打印幫助消息。

打印用戶和運行時信息。

執行后期處理。這可以像檢查DRC的輸出文件到修訂控制工具一樣簡單，也可以像主動處理DRC的輸出文件一樣復雜，例如從其他數據源添加更多信息或執行排序。 C可能不是排序數據或解析文件的最佳工具。例如，要使用第二個字段以數字方式對文件進行排序，使用UNIX排序命令要容易得多：

sort + 1n source_file> sorted_file

3.0.2 DRC開發：main（）函數
讓我們調用DRC程序drc.c，它可以有兩個主要功能：drc_net（）和drc_inst（）。前者遍歷所有網絡，后者遍歷所有實例（符號），尋找設計規則違規。這兩個函數還可以生成副產品輸出文件，這將在第1.0節和第4.0節中討論。

drc.c應該首先包括所有C，ViewBase和用戶創建的頭文件，例如stdio.h，viewbase.h和hash_table.h。現在設置drc.c以接收輸入參數，聲明變量和文件指針指向輸入和輸出文件，使ViewBase指向ViewDraw數據庫，并創建鏈接列表和散列表以存儲從輸入文件讀入的信息。 main（）函數的一部分如下所示。

輸入和輸出文件名以及PCB設計名稱在調用DRC時由DRC的包裝程序（參見第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可以正確處理它們。

3.0.3 DRC開發： drc_net（）函數
drc_net（）遍歷PCB設計中的所有網絡，查找違反設計規則和/或生成副產品輸出文件。代碼大綱如下：

這里，iggrpnet（）和ignetnxt（）是ViewBase例程，用于抓取PCB設計中的每個網絡。 ignetnam（）也是一個用于查找網絡名稱的ViewBase例程。 NETS，PINS，COMPONENTS，SYMBOLS和ATTRIBUTES是ViewBase數據類型.drc_net（）可以查找以下設計規則違規：

非法網絡名稱。如果ViewDraw自動分配了網絡名稱，其格式為$＃...＃N＃...＃，其中第一個＃...＃是工作表編號，第二個＃...＃是網絡編號。 PCB設計人員分配的網絡名稱必須以字母開頭，后跟30個或更少字符。

drc_net（）應調用函數legal_net_name（）來執行此任務。在UNIX中，regexp.h頭文件大大簡化了C中的正則表達式匹配/檢查，該文件必須包含在DRC程序中。 drc_net（）應該將網名變量和設計規則違規文件指針傳遞給legal_net_name（），它看起來像：

后端打包工具 pcbfwd 還可以檢查非法網名，但其功能僅限于簡單的正則表達式。上面給出的代碼可以處理任何正則表達式。此外，在運行pcbfwd之前或之后是否查找非法網名是一個權衡問題。對于簡單的網絡名稱，請使用pcbfwd。

網絡上的總線爭用，這是一個嚴重的錯誤。有2種。一個是圖騰柱輸出之間的爭用，另一個是圖騰柱和三態輸出之間的爭論。代碼大綱如下：

這里，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個輸出引腳或多個三態輸出引腳和至少1個輸入引腳。此外，請提供此網絡上所有組件的參考標志和符號以及所涉及的引腳。

報告所有未接通上拉電阻或其上拉電阻未連接的集電極開路輸出POWER。

如果網絡的負載超過正常負載，則應打印警告，為了獲得良好的信號完整性，該負載應小于8.

3.0.4 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（）可以根據description屬性檢查它們的值，以確保兩者匹配。

非法去耦電容。這可能導致POWER線路dv/dt問題。

非法的上拉和下拉電阻。

符號的POWER或GROUND引腳未連接到POWER或GROUND平面。

未使用的輸入引腳沒有通過電阻上拉或下拉，或者此電阻沒有直接連接到POWER或GROUND網絡。

如果上拉或下拉超過1個未使用的輸入引腳，則發出警告

在直接連接到POWER或GROUND網絡的非專用POWER和GROUND引腳上發出警告。

如果使用Tab鍵，請檢查它是否引用了正確的替代方案組件，例如它們的部件號是否有效以及它們的幾何形狀是否與默認組件的幾何形狀匹配。

3.0.5 DRC不應該做什么
雖然我們的DRC可以做很多事情，有些東西可以通過其他方式更好更容易地檢查。一個偉大而必要的幫手是后端封裝實用程序，它為放置/布局工具打包PCB設計。對于ViewDraw，它是 pcbfwd，，可以設置它來檢查許多設計規則違規和設計錯誤。

DRC和 pcbfwd之間存在重疊 pcbfwd 運行之前運行。理想情況下， pcbfwd 應僅運行以打包設計，因此DRC可以檢查得越多越好。但是你應該平衡開發超級強大的DRC與免費提供的 pcbfwd的現有功能的努力。本節簡要討論了這些問題。

pcbfwd 由其配置文件控制，如果Allegro是放置/布局工具，則稱為allegro.cfg。其BeginChkRules - EndChkRules部分可用于檢查許多錯誤，例如同一符號上的重復屬性，非法網絡和網絡屬性名稱，錯誤的異構包，異構符號上的沖突屬性以及缺少的屬性。例如，要捕獲異構符號上的沖突屬性，請將以下行放入allegro.cfg：

CHKBRD _HETERO_ATT ERR 0

有些事情既不是DRC也不是 pcbfwd 可以檢查，例如PCB設計中的預期冗余。假設一個組件包含4個相同的部件，2個用于設計，那么它們可以打包到同一個組件或2個組件中以實現冗余。如果需要一個組件，則兩個組件的符號必須具有相同的參考標號，例如U4。如果需要2個組件，則符號必須具有不同的參考標志，例如U4和U5，必須由設計人員認真添加。沒有已知的簡單方法來捕捉此類錯誤，而精心設計師可能是唯一的保證。

另一個例子是雖然DRC和/或 pcbfwd 可以檢查是否symbol具有所需的幾何屬性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將生成錯誤的錯誤消息。組件符號質量應該仔細和系統地控制，因為它會影響所有其他工具。

4.0超越DRC

除了檢查設計規則違規，DRC還可以生成有用的副產品輸出文件，如前所述。輸入開關可以告訴DRC是否為每次運行生成它們。雖然這些文件不包含DRC錯誤或警告消息，但它們可以標記潛在的設計問題。例如，一個文件可以包含所有網絡的列表以及每個網絡上的負載數量。如果該數量超過合理值，則可能導致信號完整性問題。 PCB設計人員可以快速瀏覽此文件并查找此類問題。這些副產品文件的數量可以是所需數量。部分列表如下。

按網名排序的所有網絡列表以及每個網絡所在的工作表。附加信息可能包括該網絡連接的符號的引腳號和類型（及其參考標號）。該文件由drc_net（）函數創建。它可用于查找網絡所在的工作表。

所有網絡的列表以及每個網絡的負載數量。這是由drc_net（）函數生成的。為了獲得良好的信號完整性，網絡應該不超過8個負載。

跨越工作表邊界的網絡列表。這有助于設計人員在實驗室中調試設計。

具有網絡屬性及其屬性的網絡列表。 Designer可以檢查這些網絡是否具有正確的屬性。此文件由drc_net（）函數生成，代碼大綱為：

此處，ignetatt（）和igattnxt（）是ViewBase例程以獲取網絡上的每個屬性。 igattnam（）獲取屬性名稱。 net_att是指向輸出文件的文件指針。

所有未使用的引腳的列表，應該上拉或下拉。報告上拉和下拉電阻。該文件由drc_inst（）函數生成。

所有去耦電容及其值的列表。附加信息可能包括它們所在的原理圖表。設計人員應快速檢查此文件，以確保PCB上有足夠的去耦電容。該文件由drc_inst（）函數生成。

所有分立元件及其值的列表，例如上拉/下拉電阻，傳輸線終端電阻/電容。附加信息可能包含它們所在的原理圖表。設計師可以快速檢查數字是否合理。該文件由drc_inst（）函數生成。

此列表的另一個重要用途是PCB設計的信號完整性和時序分析[4]。該領域的大多數工具都可以自動處理所謂的系列元素，通過將它們的效果組合到傳輸線分析結果中，但將它們從輸出文件中取出。一個這樣的元件是圖2中的R1，它是串聯終端電阻器。當信號完整性工具報告凈延遲時，它將從u1.z到u2.i，包含R1的效果，而不是從u1.z到R1.1，并從R1.2繼續到u2.i.這是正確的時序分析。

圖2 - 串聯終端電阻

但是，為了一個信號完整性工具自動識別一系列元素，必須滿足一些條件。例如，電阻的參考標志必須以字母R后跟數字和字母C的電容開始。另一個條件是每個系列元素符號必須具有值為DISCRETE的TYPE屬性。沒有這些條件，這些元素就無法正確處理。

一個常見問題是模板設計被許多其他PCB復制。為了避免可能的參考標志沖突，模板設計中的電阻和電容通常稱為XR1和XC1。必須在信號完整性工具的數據庫中將它們更改為R10001和C10001（數字應大于原始PCB設計中使用的任何可能的參考標志符號）。通過使用我們的DRC生成的離散組件列表，可以找到XR和XC參考標志。

5.0結論

顯然，有編寫自己的PCB設計規則檢查器的許多優點和必要條件。盡管這項工作并非微不足道，但它也不是火箭科學，也可以由對現有編程或腳本語言有深入了解的任何人完成。好處是無限的，可以大大超過努力。

6.0參考文獻

1。 Luke L. Chang，“VAX 9000存儲器配電系統的瞬態分析”，數字電源系統，1990年秋/冬

2。 Brian W. Kernighan＆amp; Dennis M. Ritchie，“C編程語言”，第2版，Prentice Hall，1988年

3。 Bjarne Stroustrup，“The C ++ Programming Language”，3rd Edition，Addison-Wesley，1997

4。 Luke L. Chang，“高速電路板的靜態時序分析”，IEEE Spectrum，1997年3月

Luke L. Chang是英特爾存儲元件部門的高級驗證負責人（哈德遜，馬薩諸塞州）。在此之前，他曾在多家高科技公司擔任過工程和管理職位，涉及硬件設計/驗證和電子設計自動化（EDA）領域。