題:
PCB設計的新手-為什麼不存在自動放置元件的問題?
Adam
2015-04-26 02:34:30 UTC
view on stackexchange narkive permalink

我所見過的電路設計軟件具有自動在PCB上佈線走線等功能的功能。
但是為什麼該軟件不具有在PCB上自動放置組件的功能以減小電路板的總尺寸呢?
這太複雜了以至於無法自動化嗎?

自動佈線器應能夠根據約束條件來最佳地放置組件(即“按鈕必須在此處”,“ LED可以在該區域的任何地方”)。他們還應該能夠選擇最佳引腳,以用於具有大量等效引腳的部件(即“使用任何具有PWM的io引腳”)。 不幸的是,我從未見過能夠執行這兩個功能的任何一個。也許有一天。
我認為Altium有一個自動放置器,但是有些組件原本打算放置在板上的戰略位置,而該軟件不知道戰略性與否。而且,如果您將電路板的總面積最小化,則可能無法進行乾淨的佈線。我從未使用過自動放置器,也很少使用自動佈線,當我執行自動佈線時,它用於選擇信號(例如接地)。
位置(和方向,柵極交換,引腳交換)非常重要。獲得良好的路由是最重要的。我認為,智能自動放置器應從原理圖放置位置開始,除非原理圖是那些現代的“被網表包圍的盒子”可憎之物之一。
由於不是電路設計的背景,在我看來,老鼠的窩應該足以將所有組件最佳地佈局,也許有一些約束。大多數實際電路是否比這更多的手動設計?
Diptrace具有自動佈局。不過,這令人震驚。
簡而言之,即使沒有考慮到實際的非理想電路的所有考慮因素,對組件進行最佳佈局也是一個非常困難的CS問題。實際上,這是旅行商問題的一個實例,因此,最佳解決方案是不可行的。
相關主題:[此處](http://electronics.stackexchange.com/a/132338/7036)和[此處](http://electronics.stackexchange.com/a/73005/7036)。兩者都是對已經自動佈線的初學者PCB的設計評論。
這個問題讓我感到奇怪,為什麼這些自動佈線器/自動放置器如此糟糕!人們為什麼不投入更多的研究和精力來使他們工作呢?(也許是的,所有這些功能都隱藏在專有軟件包中嗎??)添加一點“該電容帽屬於這些電源引腳”複選框並不難,...
@Gregd'Eon我也想知道。當然,隨著工作量的增加,自動放置器可以了解去耦電容的作用,並模擬電路噪聲等。
@Adam是的,我想這是我們永遠不會回答的另一個問題。為什麼所有的PCB設計軟件都吸得那麼厲害,只比鉛筆+紙好一點?
@Navin,如果您相信這一點,我想知道您用CAD佈置了多少個複雜的設計,以及用鉛筆和紙佈置了多少個?
可能是[將代碼說明轉換為PCB設計的軟件?](http://electronics.stackexchange.com/questions/70818/software-to-translate-code-description-to-pcb-design)
@NickJohnson:實際上並不可行。儘管計算真正的最佳結果在計算上是昂貴的,但是有些算法可以在非常合理的時間內獲得“足夠好”的結果。在大多數情況下,達到最佳解決方案的95%-98%以內將使其減少。其次,如果您願意讓計算機運行一段時間,則取決於有多少組件,獲得最佳解決方案可能是可行的。
@whatsisname是的,您可以大致了解基本TSP。但是,這對於實際電路的設計約束而言要困難得多。
@NickJohnson:那部分是真的,是的,因為在規範中沒有向軟件指示很多重要信息。
@NickJohnson僅評論:在10到30年前的某個範圍內(為您提供了一定的範圍),我記得曾讀過一份有關TSP已解決的報告-在這種情況下任何“解決”的含義。我猜想“已解決”是指要求針對一組約束產生最佳結果的算法或方法。|之後,毫無疑問,他們繼續研究N體問題:-)。
甚至在很久以前,PCD軟件包都具有基本的自動放置功能,該位置不會嘗試最佳地放置組件,但是對於阻止一切以大堆開頭的情況很有用。在以前的DOS Protel時代,我編寫了一個程序,該程序處理基於文本的原理圖輸出文件,以在絲網上重新定位和調整組件標識符的大小,從而使它們位於例如組件足跡內並且不覆蓋任何孔。我主要將其用於兩個引線通孔軸向組件,例如電阻器。用規則集擴展該範圍以將選定的組件移動到適當的位置。
....相對位置只是要做的事情。定義什麼是“困難”。我不知道是否有更現代的軟件可以像基於文本的DOS軟件(無意中)使您獲得和管理組件描述符和屬性的程度。
六 答案:
Whiskeyjack
2015-04-26 03:41:14 UTC
view on stackexchange narkive permalink

我最近一直在設計一些PCB,建議您不要在最終產品中使用自動放置器或自動放置器。 (Proteus具有自動放置器。)

首先-在自動放置或自動佈線時,您的軟件像worm一樣聰明。換句話說,它像土豆一樣愚蠢。 。同樣,自動佈線也不知道將組件稍微向左或向右移動可以使您以更好的方式佈線。這些工具只會為您提供根據電路正確的設計。但是,關於現實世界的性能,情況卻有所不同。例如,

  • 去耦電容器應在物理上靠近IC。
  • 應該有環路
  • 接地平面應盡可能堅固。
  • 任何干擾信號都不應靠近晶體振盪器等。

您的軟件不會遵守這些概念,因為原理圖中未提及這些概念。您只有在製造完PCB之後才能知道它,而且並非一直都能正常工作。我並不是說這行不通。在90%的時間內它可能會起作用,但您也必須考慮到那10%。您始終可以在論壇上發布原理圖和電路板佈局,專家會給您他們的意見/建議。

for和土豆+1。每次我使用自動佈局器和自動佈線器時,我都會做一些關鍵的部分,而讓它變得簡單一些,但即使這樣也太多了:在最後一遍之後放置並佈線了60%的電路板。最好自己做所有事情,除非是針對具有大量可用空間的大型需求設計。
@Mister-是的,您是對的。甚至我不時地使用自動路由器來了解佈線的想法,最後我完成了關鍵部分。但是,這些天我正在使用Eagle,它沒有自動放置器。
錯別字在我上面的評論中:“用於巨大的LOW *需求設計”。顯然,高頻數字頻率在自動路由和自動定位方面表現不佳...
我沒有看到任何理論上的理由來解釋為什麼自動佈線器在自動放置零件時不能考慮所有上述約束和最佳實踐。實際上,理想的自動佈線器應該能夠找到比人類更能滿足這些目標的最佳位置。可以肯定,這是一個很難的問題,但並非不可能,我敢打賭,很快我們將開始看到基於雲的自動路由器和自動放置器,它們甚至可以擊敗最優秀的人。
@bigjosh-您的評論很有道理。正確的佈線和放置有一些指導原則,如果將其分解為簡單的邏輯,則應使計算機的性能優於人類。剩下的可能是數以萬億計的計算-檢查數千個完全佈線的電路板並找出最佳解決方案。對於基於雲的系統,這應該不太困難。讓我們希望一些開源項目能盡快開始實現這一目標。它可能比人類更好,因為一旦人們找到了可行的解決方案,他們就不會真正進行多次迭代-至少我沒有。
如果您手動進行單層PCB上的佈局和佈線會浪費大量時間。我希望應用程序告訴我如何在DIY項目中放置組件以使“空氣線”的數量最少。當然,它應該允許我添加約束,例如固定某些組件的位置。
@dan-我想我們都想要該功能。但是,目前沒有CAD軟件包可以提供可靠的解決方案。就像bigjosh所說的那樣,從理論上講是有可能的,但是到目前為止,您最好自己進行放置。
@Whiskeyjack一些程序確實具有自動放置和自動路由功能。我想,如果它足夠好,那就是每個人都可以決定的。我親自手動放置“重要”組件,然後讓程序放置其餘的組件(+自動路由)。
Some Hardware Guy
2015-04-26 04:01:02 UTC
view on stackexchange narkive permalink

我的路由器有一個放置器,並支持“房間”。這樣一來,您就可以從原理圖中繪製區域並將零件分配給“房間”。自動放置器會將它們分組到分配零件的房間中。可以肯定的是,它對此連接器的支持也應該轉到該位置。還有一個工具可以根據模擬結果自動去耦放置和零件選擇/優化。 b>

自動放置器可以通過這樣將所有內容放在一起節省您一些時間。但是我仍然更喜歡將邏輯示意圖與放置模式下的佈局進行交叉探測。

就像自動路由器一樣,您可以根據約束條件以及如何使用它來了解輸入的內容。如果您只是嘗試在沒有適當限制的情況下使用自動路由器,那麼它將隨處可見。正確設置後,我們將使用它正確路由較大長度的匹配DDR部分。在更大,更密集的板上,這幾乎是必需的,並且肯定是需要速度的佈局服務店的要求。但是,對於一年只做幾個小董事會的人來說,這些事情可能不值得。

您的CAD包裝是什麼?
去耦是高端版本的Allegro,來自節奏控制的Sigrity。我也喜歡護墊。新的基於路徑的自動路由器應該看起來像手動路由,看起來很有趣。
我預感這可能是Cadence。我用它來介紹IC設計,它確實是一個出色的封裝,並且我相信,如果正確地制定了約束條件(取決於經驗/培訓),它的自動佈線器和自動放置器可能只是高效的。
說得好。放置零件和佈線並不是不可能的,這比原理圖捕獲更加困難和模糊。首先,電路圖遠遠不足以自動放置零件的完整輸入。常規的PCB封裝設計用於佈線,而不是自動放置。
Connor Wolf
2015-04-26 11:09:42 UTC
view on stackexchange narkive permalink

您沒有考慮的一件事是原理圖沒有包含足夠的信息來正確佈局電路板

基本上,PCB佈局需要考慮和適應幾十個每部分的佈局要求,這些都沒有在原理圖中進行編碼。僅考慮旁路電容器。為了使自動化系統正確地為每個組件放置旁路電容器,您需要在原理圖上具有一些其他指令,這些指令指示自動佈線器兩個節點之間的走線必須小於一定長度。
大概,然後,您需要進一步的指令來編碼各種網絡的長度最小化的 priority ,指示差分對/受控阻抗,保護線(如果需要)等的內容。
基本上,還有很多其他因素可以驅動佈局,而這些因素通常在原理圖/草稿文檔中根本沒有編碼。

此外,即使您假設具有上述所有設計約束,其絕對大小也是如此。常見佈局的問題空間為巨大的。這等效於嘗試求解具有數千個輸入的方程,其中每個輸入對所有其他輸入具有不同的非線性影響。實際上,從暴力角度來看,這個問題是完全棘手的。因此,任何解決方案都必須涉及某種啟發式機制,該機制具有其自身的複雜性。


實際上,至少沒有更好個自動佈線器的主要原因是只是沒有市場。與許多其他細分市場,專用軟件市場相比,EDA市場規模相對較小,甚至有史以來最好的自動佈線器甚至都不會由實際的人來完成實際的佈局。

在特別無聊的佈局中,我通常會幻想通過設計矢量場和模擬退火來設計自己的自動佈線器,但是即使那樣也只能達到局部最優,而不是一般最佳佈局。

Bob Kerns
2015-04-26 23:28:55 UTC
view on stackexchange narkive permalink

早在1974-1975年間,我在霍尼韋爾的設計自動化部門工作。從那以後問題一直沒有改變:

  1. 優化在計算上並不可行。像大多數全局優化問題一樣,它是NP-Complete,這意味著計算的複雜性急劇增加。由於您不能等待一萬億年(或更糟的時間),因此我們可以認為找不到最佳解決方案。
  2. 對於程序,尚不清楚您要優化的內容。根據您的電路組織模型進行邏輯分組?跡線長度?董事會面積?寄生耦合?傳播延遲?散熱(最高溫度)?從更高功率的部分到對溫度敏感的組件散熱?射頻發射?噪聲?機械性能(例如,在機械支撐件附近放置更多的大型組件?服務特性,例如不使車載連接器比人的手指靠得住更靠近?外部約束,例如連接器的位置,或在可用空間內的裝配)(與案例,粉絲等)
  3. ol>

    有基於AI的方法來處理此類問題,但是,從某種意義上講,設計人員更容易嘗試並獲得向軟件反饋有關他感興趣的設計標準的信息,告訴AI軟件您將面臨無盡的,艱鉅的任務。最終,該軟件必須滿足您,設計師和您的權衡要求。

    但是我預測,只要有人親自關注並關注結果,我們永遠不會看到全自動的佈局。

如此奇異...
@PeterMortensen奇異性之後,人的意見將不再重要。
我認為第2點確實是答案的唯一相關部分。有許多算法可以非常迅速地解決NP完全問題,而且問題的大小很大,並且可以接受的時間成本達到“足夠好”的程度,足夠好通常在最優值的2-3%之內。
關於“足夠好”,這是一個好觀點! 儘管從技術上來說是完全準確的,但我們應該仔細地對“解決”一詞進行限定(就像您所做的那樣)。 但是,當時的CPU和存儲成本是一個巨大的問題。但是,即使問題規模增加了,我們的計算能力也增加了。
Matt Young
2015-04-26 02:54:26 UTC
view on stackexchange narkive permalink

我的軟件有一個放置器。我跑了一次只是為了看看會發生什麼。它在董事會上咆哮咆哮,並獲得了所有組件。當我看著它的時候,到處都是零件。 IC位於一個角落,而去耦電容位於另一個角落。關鍵路徑在整個區域內呈鋸齒狀彎曲。

我的意思是,佈局是佈局中最難正確的部分。首先是機械約束。 ME /工業設計人員希望您的連接器/開關/電位器/ LED /無論其他外部接口組件是否在某個位置脫離電路板。有些組件可能太高而無法放在機箱內的某些區域。電路的某些部分可能需要保持一定的間隙以進行隔離。

可以配置軟件來處理其中的一些因素,但它永遠做不到,也無法以人類能看到的方式直觀地看到問題。在理想的情況下,如果正確放置位置,進行電源,接地和關鍵路徑佈線,那麼自動佈線器的快速通過應該能夠完成佈局。

我喜歡這個答案,儘管在某種程度上看來該軟件還沒有達到應有的水平。
@Adam隨著您獲得更多的經驗,您將更好地理解。放置過程非常複雜,老鼠的窩只能講述故事的一部分。以去耦蓋為例,放置器應該如何知道將其放置在哪裡?就其所關心的而言,這些帽子都可以放置在任意位置。
距離約束似乎是可行的選擇。
您的軟件名稱是什麼?
ThreePhaseEel
2015-04-26 06:16:42 UTC
view on stackexchange narkive permalink

我以前使用過自動放置器,它們的確像一堆石頭一樣笨。您可以瘋狂使用它們的唯一一件事就是解開一堆腳印,這些腳印全部導入到您板上的同一位置;還有其他事情實在是太多了。



該問答將自動從英語翻譯而來。原始內容可在stackexchange上找到,我們感謝它分發的cc by-sa 3.0許可。
Loading...