編寫屬于自己的PCB設計規則檢查器

編寫屬于自己的PCB設計規則檢查器具有很多優點，盡管設計檢查器并不那么簡單，但也并非高不可攀，因為任何熟悉現有編程或腳本語言的設計人員完全能夠設計檢查器，這項工作的好處是不可估量的，本文介紹編寫PCB設計規則檢查器的技巧。

本文闡述了一種編寫PCB設計規則檢查器(DRC)的系統方法。利用電路圖生成工具得到PCB設計后，即可運行DRC以找到任何違反設計規則的故障。這些操作必須在后續處理開始之前完成，而且開發電路圖生成工具的開發商必須提供大多數設計人員都能輕松掌握的DRC工具。

然而，市場銷售的通用工具通常不具備足夠的靈活性以滿足特定的設計需要。因此，客戶必須將新特性需求反映給DRC工具開發商，而這通常需要耗費一定的資金和時間，尤其當需求不斷更新時。幸運的是，大多數工具開發商均可為客戶提供編寫屬于自己的DRC以滿足特定需求的便捷方法。但是，這種具有強大功能的工具尚未得到廣泛認同或使用。本文提供了利用DRC工具獲取最大收益的實用指南。

由于DRC必須遍歷 PCB設計的整個電路圖，包括每個符號、每個引腳、每個網路、每種屬性，如有必要還能創建數目不限的“附屬”文件。如4.0節所述，DRC可以標示出任何違反設計規則的細微偏差。例如其中一個附屬文件就可能包含設計用到的全部去耦電容。如果電容數低于或高于期望值，就將在可能出現電源線dv/dt問題的地方標注紅色記號[1]。這些附屬文件或許必不可少，但并非任何商用DRC工具都一定能創建這些文件。

DRC的另一優勢是便于更新，以適應新設計特性(如那些可能影響設計規則的新特性)的需要。而且，一旦在該領域獲得充分經驗，那么還能實現許多其它功能。

例如，如果能編寫屬于自己的DRC，那么就能編寫屬于自己的物料清單(BOM)創建工具，這樣就能更好地處理特定用戶需求，如如何獲取本身不屬于電路圖數據庫一部分的器件“額外硬件”(如插座、散熱裝置或螺絲刀)。或者設計人員可以編寫屬于自己的Verilog網表分析器，該分析器在設計環境下具有充分的靈活度，如怎樣獲取適用于特定器件的Verilog模型或時間文件。實際上，由于DRC遍歷了整個設計電路圖，因此可以收集全部有效信息以輸出PCB設計Verilog網表分析所需的仿真和/或BOM。

在不提供任何程序代碼的前提下討論這些話題實在有些牽強，為此，我們將以一種電路圖獲取工具為例進行說明。本文采用了Mentor Graphics公司開發的附屬于PADS-Designer產品線的ViewDraw工具。此外，我們還采用了ViewBase工具，這是一個可被調用并對ViewDraw數據庫進行存取操作的簡化C例行程序庫。利用ViewBase工具，設計人員可以輕松地采用C/C++語言為ViewDraw編寫完整且高效的DRC工具[2] [3]。需要注意的是，這里討論的基本原則同樣適用于任何其它的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，當工具啟動時，該文件就自動創建(利用腳本程序)：目錄 [r] /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，那么下述條件就完全充分：

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代碼如下：

[列表3]

這里，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設計中遍歷所有網路并檢測任何違反設計規則的故障，然后創建附屬的輸出文件。實現上述功能的基本代碼如下：

[列表4]

這里，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()函數中，該函數具有如下形式：

[列表5]

后端封裝工具pcbfwd也可檢測非法網路名，但其功能受限于簡單的常規表達式。上述代碼可處理任何常規表達式，同樣地，如何在運行pcbfwd工具之前或之后找到非法網路名稱也需要權衡。對于簡單的網路名稱，可以使用pcbfwd。

* 網路上的總線競爭也是嚴重問題。總線競爭有兩類：一類是圖騰柱輸出間的總線競爭，而另一類則是圖騰柱與三態輸出間的總線競爭。基本代碼實現如下所示：

[列表6]

這里，ignetpin()和igpinnnx()函數是在網路上檢查每個引腳的ViewBase例程。igpinown()例程返回引腳實例(系主)指針。函數get_inst_attr()、get_pin_attr() 和get_sheet_num()則返回請求實例屬性(參考標志符REFDES)、引腳屬性(PINTYPE)及引腳實例所在的圖表編號。get_pin_attr()函數的基本代碼如下：

[列表7]

get_inst_attr()函數的基本代碼如下：

[列表8]

get_sheet_num()函數的基本代碼如下：

[列表9]

* POWER和GROUND網路中的非法名稱。這些名稱將與存儲在內部數據結構中的信息(如鏈接列表)進行比較。

* 報告那些具有負載但不具有驅動程序或者具有驅動程序但不具有負載的網路。這可以通過標注網路上每個引腳的類型加以實現。網路應當帶有1個輸出引腳或多個三態輸出引腳及最少一個輸入引腳，此外還可提供與網路全部器件和引腳相關的參考標志符和符號。

* 報告那些不帶上拉電阻或所帶上拉電阻未連接到POWER的所有集電極開路輸出。

* 一旦網路的負載超過常規數目(良好的信號完整性條件下限額為8)，那么將打印警告信息。

DRC開發：drc_inst()函數

drc_inst()函數與drc_net()函數類似，不同的是，前者遍歷了全部電路圖表及PCB設計中電路圖表上的所有實例，從而檢測違反規則的設計缺陷或創建附屬的輸出文件。其代碼實現如下：

[列表10]

上面關于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()函數創建，其基本代碼實現如下：

[列表11]

這里，ignetatt()和igattnxt()是可以獲取網路屬性的ViewBase例程。igattnam()獲取屬性名，而net_att則是輸出文件的文件指針。

* 未使用引腳列表，這些引腳可以是上拉引腳或下拉引腳。該文件由drc_inst()函數創建，可以報告上拉電阻和下拉電阻信息。

* 所有去耦電容及其容值列表，此外還可能包括這些電容所在的電路圖表。設計人員應迅速檢驗該文件以確保PCB上具有足夠多的去耦電容
。該文件由drc_inst()函數創建。

* 所有離散器件及其值的列表，如上拉/下拉電阻、傳輸線終端匹配電阻/電容。此外，還可能包含這些器件所在的電路圖表。設計人員可迅速檢查器件數目是否合理，該文件由drc_inst()函數創建。

該列表的另一項重要應用則是PCB設計的信號完整性和時序分析[4]。該領域的大多數工具可以通過將所謂的串行元件功能合并為傳輸線分析結果并從輸出文件中取出這些元件，從而自動處理這些串行元件。圖2中的R1就是一個串行終端匹配電阻。當信號完整性工具報告網路延遲時，由于R1的存在，延遲將由u1.z到u2.i，而不是先從u1.z到 R1.1，再由R1.2到u2.i。這是正確處理時序分析的方法。

然而，為了使信號完整性工具自動識別串行元件，必須滿足一些條件。例如，電阻的參考標志符必須以字母R開頭，后面緊跟數字，而電容則必須以字母C開頭。另一條件則是每個串行元件符號都必須具有屬性值為DISCRETE 的TYPE屬性。沒有這些條件，這些元件就無法得到正確地處理。

被許多其它的PCB復制的模板設計也是一個常見問題。為了避免可能的參考標志符沖突，模板設計中的電阻和電容通常可稱為XR1和XC1。在信號完整性工具數據庫中，這些器件都必須更改為R10001和C10001(編號略大于原始PCB設計中使用的任何參考標志符)。設計人員可采用由DRC創建的離散器件列表檢查到XR和XC參考標志符。