<dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><s id="yhprb"><strike id="yhprb"></strike></s></dfn><small id="yhprb"></small><dfn id="yhprb"></dfn><small id="yhprb"><delect id="yhprb"></delect></small><small id="yhprb"></small><small id="yhprb"></small> <delect id="yhprb"><strike id="yhprb"></strike></delect><dfn id="yhprb"></dfn><dfn id="yhprb"></dfn><s id="yhprb"><noframes id="yhprb"><small id="yhprb"><dfn id="yhprb"></dfn></small><dfn id="yhprb"><delect id="yhprb"></delect></dfn><small id="yhprb"></small><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn> <small id="yhprb"></small><delect id="yhprb"><strike id="yhprb"></strike></delect><dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"><s id="yhprb"><strike id="yhprb"></strike></s></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn>

新聞中心

EEPW首頁(yè) > EDA/PCB > 設計應用 > 用Synplify Premier加快FPGA設計時(shí)序收斂

用Synplify Premier加快FPGA設計時(shí)序收斂

作者: 時(shí)間:2012-07-03 來(lái)源:網(wǎng)絡(luò ) 收藏

傳統的綜合技術(shù)越來(lái)越不能滿(mǎn)足當今采用 90 納米及以下工藝節點(diǎn)實(shí)現的非常大且復雜的 設計的需求了。問(wèn)題是傳統的 綜合引擎是基于源自 ASIC 的方法,如底層規劃、區域內優(yōu)化 (IPO,In-place Optimization) 以及具有物理意識的綜合 (physically-aware synthesis) 等。然而,這些從 ASIC 得來(lái)的綜合算法并不適用于 的常規架構和預定義的布線(xiàn)資源。

最終的結果是,所有的三種傳統 FPGA 綜合方法需要在前端綜合與下游的布局布線(xiàn)工具之間進(jìn)行多次耗時(shí)的設計反復,以獲得。這個(gè)問(wèn)題的解決方案是一種基于圖形的獨特物理綜合技術(shù),能夠提供一次通過(guò)、按鈕操作的綜合步驟,不需要 ( 或者需要很少 ) 與下游的布局布線(xiàn)引擎的設計反復。而且,基于圖形的物理綜合在總體的時(shí)鐘速度方面可以將性能提高 5% 到 20% 。 先進(jìn) FPGA 物理綜合工具就是這樣一種工具,專(zhuān)門(mén)針對那些設計很復雜的高端 FPGA 設計工程師而定制,他們的設計需要真正的物理綜合解決方案。

本文首先介紹了主要的傳統綜合方法,并說(shuō)明這些方法存在的相關(guān)問(wèn)題,然后介紹基于圖形的物理綜合概念,并指出這種技術(shù)如何滿(mǎn)足當前先進(jìn) FPGA 的設計需求。

傳統綜合解決方案存在的問(wèn)題

對于 2 微米的 ASIC 技術(shù)節點(diǎn)以及上世紀 80 年代早期以前來(lái)說(shuō),電路單元 ( 邏輯門(mén) ) 相關(guān)的延時(shí)與互連 ( 連接線(xiàn) ) 相關(guān)延時(shí)的比例約 80:20 ,也就是說(shuō)門(mén)延時(shí)約占每個(gè)延時(shí)路徑的 80% 。這樣一來(lái),設計師可以用連線(xiàn)負載模型來(lái)估計互連延時(shí),在連線(xiàn)負載模型中,每個(gè)邏輯門(mén)輸入被賦予某個(gè) “ 單位負載 ” 值,與某個(gè)特定路徑相關(guān)的延時(shí)可以作為驅動(dòng)門(mén)電路的強度和連接線(xiàn)上的總電容性負載的函數來(lái)計算得出。

類(lèi)似地,當在上世紀 80 年代后期 ( 大約引入 1 微米技術(shù)節點(diǎn)的時(shí)候 ) 第一個(gè) RTL 綜合工具開(kāi)始用在 ASIC 設計中的時(shí)候,電路單元的延時(shí)與連線(xiàn)延時(shí)相比還是占主導地位,比例約為 66:34 。因此,早期的綜合工具還是基于它們的延時(shí)估計方法,并使用簡(jiǎn)單的連線(xiàn)負載模型進(jìn)行優(yōu)化。由于電路單元的延時(shí)占據主導,因此初期綜合引擎使用的基于連線(xiàn)負載的時(shí)序估計足夠準確,下游的布局布線(xiàn)引擎通常能在相對較少的幾次反復 ( 在 RTL 和綜合階段之間 ) 條件下實(shí)現設計。

然而,隨著(zhù)每個(gè)后續技術(shù)節點(diǎn)的引入,互連延時(shí)大大地增加 ( 事實(shí)上,就 2005 年采用 90 納米技術(shù)實(shí)現的標準單元 ASIC 來(lái)說(shuō),電路單元與互連的延時(shí)比例現在已經(jīng)接近 20:80) 。這使得綜合引擎的延時(shí)估計與布局布線(xiàn)后實(shí)際延時(shí)的關(guān)聯(lián)性越來(lái)越低。

這具有一些很重要的牽連性,因為綜合引擎在不同的優(yōu)化方法之間選擇,以及在實(shí)現功能的替代方法 ( 諸如基于它們的時(shí)序預測的加法器 ) 之間選擇。例如,假設某個(gè)包含一個(gè)加法器 ( 以及其它組件 ) 的特定時(shí)序路徑被預知具有一些 ( 時(shí)序 ) 裕量,這種情況下,綜合工具可以選擇一個(gè)占用芯片面積相對較小的較慢加法器版本。但是,如果時(shí)序估計與實(shí)際的布局布線(xiàn)后延遲情況出入比較大的話(huà),這個(gè)路徑可能最后非常慢。這樣一來(lái),不準確的延時(shí)估計意味著(zhù)綜合引擎最后才對不正確的對象進(jìn)行優(yōu)化,只有在完成了布局布線(xiàn)后你才發(fā)現問(wèn)題并不是像你 ( 或綜合引擎 ) 所想的那樣,其結果是獲得所需的工作量將大大地增加,因為從前端到后端的設計反復次數大大增加了。

為了解決這些問(wèn)題,有必要了解在綜合過(guò)程中與設計相關(guān)的物理特性。因此,隨著(zhù)時(shí)間的推移, ASIC 綜合技術(shù) ( 緊跟著(zhù) FPGA 綜合技術(shù) ) 采用了一系列的方法 ( 某些情況下也拋棄了一些方法 ) ,例如下面討論的底層規劃、 IPO 和具有物理意識的綜合。

底層規劃

對于 ASIC 的 RTL 綜合,底層規劃技術(shù)在上世紀 90 年代早期出現,稍晚于綜合技術(shù)本身的問(wèn)世。底層規劃工具允許設計師在器件上定義物理區域,通過(guò)手工或者使用自動(dòng)交互技術(shù)來(lái)對這些區域布局,并將設計的不同部分分配到這些區域。

底層規劃涉及到逐個(gè)模塊地綜合和優(yōu)化設計,然后在最后將所有東西 “ 縫合 ” 在一起 ( 早期底層規劃工具使用的綜合算法都是基于連接線(xiàn)負載模型 ) 。這意味著(zhù)底層規劃工具不能按每個(gè)單元優(yōu)化邏輯,只能影響邏輯模塊的布局。而且,在定義上,底層規劃工具不會(huì )全局性地考慮布線(xiàn)資源,在設計完全布線(xiàn)完成之前,它不可能準確分析所有的時(shí)序路徑。這會(huì )導致在前端和后端工具之間的大量耗時(shí)的設計反復。盡管這種方法可以提高 ASIC 設計的時(shí)序性能和降低功耗,但它需要對設計的復雜分析和很高的專(zhuān)業(yè)技術(shù)水準。

圖 1 : FPGA 的主流架構。


在早期,采用 ASIC 底層規劃有下面幾個(gè)原因:作為一種獲得時(shí)許收斂的方法解決有限容量的問(wèn)題,并支持基于逐個(gè)模塊的遞增變化。最近,底層規劃不再被認為是一種其本身能獲得的方法;底層規劃依然是一種有用的方法,但只是在與其它方法 ( 例如物理優(yōu)化 ) 結合的時(shí)候才有用,使用綜合后門(mén)級網(wǎng)表的底層規劃依然需要非常多的專(zhuān)門(mén)技術(shù)。

對于 FPGA 來(lái)說(shuō),直到上世紀 90 年代晚期,底層規劃技術(shù)還沒(méi)有成為主流應用。平均而言,在一個(gè) FPGA 設計中,關(guān)鍵路徑一般會(huì )經(jīng)過(guò) 3 個(gè)區域。由于 FPGA 一般用到的設計方法,如果使用綜合后 (“ 門(mén)級 ”) 網(wǎng)表來(lái)執行底層規劃,即使對 RTL 的相對較小的改變都可能導致先前所做的底層規劃工作付之東流。解決這個(gè)問(wèn)題的方法是在 RTL 級進(jìn)行底層規劃。然而,為了更有用,這必須和某種形式的物理優(yōu)化相結合,源于 ASIC 的物理綜合算法并不適合于 FPGA 的常規架構以及預定義的布線(xiàn)資源。

布局優(yōu)化

隨著(zhù)底層規劃在 ASIC 領(lǐng)域的作用逐漸弱化,在上世紀 90 年代中期, IPO 技術(shù)對其進(jìn)行了強化 / 或者替代。這再次地涉及到時(shí)序分析和估計是基于連接線(xiàn)負載模型的綜合。

在這種情況下,所產(chǎn)生的網(wǎng)表被傳遞到下游的布局布線(xiàn)引擎。在布局布線(xiàn)和寄生提取之后,實(shí)際的延時(shí)被背注到綜合引擎。這些新值觸發(fā)器在綜合引擎中的遞增優(yōu)化,例如邏輯重構和復制。其結果是得到一個(gè)被部分修改的新網(wǎng)表。然后,這個(gè)網(wǎng)表被遞交到遞增布局布線(xiàn)引擎,產(chǎn)生一個(gè)改進(jìn)的設計拓撲。

基于 IPO 流程所得到的最后結果比那些采用底層規劃方法獲得的通常更好。然而,這種方法同樣可能需要在前端和后端工具之間進(jìn)行很多次設計反復。而且基于 IPO 方法的一個(gè)重要的問(wèn)題是對布局布線(xiàn)的修改可能導致新的關(guān)鍵路徑,這個(gè)路徑在前一次反復中是看不到的,即修正一個(gè)問(wèn)題可能會(huì )激起其它的問(wèn)題,這可能導致收斂的問(wèn)題。

對于 FPGA 設計,基于 IPO 的設計流程大約在 2003 年開(kāi)始受到主流關(guān)注。然而,盡管這樣的流程已經(jīng)可用,但那時(shí)這些流程并沒(méi)有以一種有意義的方式得到采用,因為單個(gè)地優(yōu)化時(shí)序路徑的 IPO 技術(shù)通常導致其它路徑時(shí)序的劣化和時(shí)序收斂不完全。設計師需要可使他們在不犧牲之前設計版本獲得的成果的基礎上對設計進(jìn)行改變的可靠結果。但是基于 IPO 的方法并不能在多次設計反復之上產(chǎn)生穩定的結果,因為在一次反復中優(yōu)化關(guān)鍵路徑會(huì )在下一次反復中產(chǎn)生新的關(guān)鍵路徑。類(lèi)似地,增加約束以改進(jìn)一個(gè)區域的時(shí)序可能使其它的區域的時(shí)序惡化。

具有物理意識的綜合

當前先進(jìn)的 ASIC 綜合技術(shù)是具有物理意識的綜合,這種綜合技術(shù)在大約 2000 年開(kāi)始受到主流關(guān)注。不考慮實(shí)際的技術(shù) ( 有幾種不同的算法 ) ,具有物理意識的綜合的基本概念是在一次性完成的過(guò)程中結合布局和綜合。

這在 ASIC 領(lǐng)域中的實(shí)踐效果很好,因為了解布局的綜合引擎能根據已布局的單元的周邊和 Steiner 以及 Manhattan 布線(xiàn)估計進(jìn)行時(shí)序的預估。這種綜合方法在 ASIC 中效果很好的原因是連接線(xiàn)有序地布置。這意味著(zhù)與最后的布局和布線(xiàn)設計相關(guān)的延時(shí)與綜合引擎所估計的結果具有非常好的相關(guān)性。


上一頁(yè) 1 2 下一頁(yè)

評論


相關(guān)推薦

技術(shù)專(zhuān)區

關(guān)閉
国产精品自在自线亚洲|国产精品无圣光一区二区|国产日产欧洲无码视频|久久久一本精品99久久K精品66|欧美人与动牲交片免费播放
<dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><s id="yhprb"><strike id="yhprb"></strike></s></dfn><small id="yhprb"></small><dfn id="yhprb"></dfn><small id="yhprb"><delect id="yhprb"></delect></small><small id="yhprb"></small><small id="yhprb"></small> <delect id="yhprb"><strike id="yhprb"></strike></delect><dfn id="yhprb"></dfn><dfn id="yhprb"></dfn><s id="yhprb"><noframes id="yhprb"><small id="yhprb"><dfn id="yhprb"></dfn></small><dfn id="yhprb"><delect id="yhprb"></delect></dfn><small id="yhprb"></small><dfn id="yhprb"><delect id="yhprb"></delect></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn> <small id="yhprb"></small><delect id="yhprb"><strike id="yhprb"></strike></delect><dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn><dfn id="yhprb"><s id="yhprb"><strike id="yhprb"></strike></s></dfn><dfn id="yhprb"><s id="yhprb"></s></dfn>