盡管 Vivado 不支持 “placement cost tale”的功能，InTime 卻有一個相似功能叫做“Placement Exploration”配方（Receipe），并且不會對性能產(chǎn)生任何影響。在本文中，我們將通過展示幾則用戶案例的結(jié)果，來了解這個布局配方的作用以及它能對您有哪些幫助。

1. 什么是“Placement Exploration”配方？

Placement Exploration 這種策略可以將非關(guān)鍵的寄存器位置隨機(jī)化。這樣可以讓 Vivado 探索更多的可能性，使用不同的布局布線計(jì)算來產(chǎn)生不同的結(jié)果，同時不會影響設(shè)計(jì)的功能。

2. 運(yùn)行原理

這個配方需要設(shè)計(jì)有一些非關(guān)鍵的單元（單元已經(jīng)達(dá)到時序路徑），目標(biāo)器件要有一些未使用的 slice。設(shè)計(jì)中未使用的 slice 越多，就有更多的運(yùn)行組合可以創(chuàng)造出來，從而提升隨機(jī)性，取得更好的結(jié)果。

如果這些需要沒有滿足，用戶在運(yùn)行配方的時候會看到下面的報(bào)錯。

這種情況下，您需要重新檢驗(yàn)設(shè)計(jì)，看看是不是沒有假路徑（false path，適用于 InTime 2.2.1以前的版本）或者是不是器件可用的 slice 數(shù)量較少。如果是因?yàn)闆]有假路徑，您可以查看是否可以為設(shè)計(jì)設(shè)置假路徑。

3. 真實(shí)案例
我們繼續(xù)前面案例。下面的代碼可以讓您使用FEP Tcl API 來在云端編譯：

項(xiàng)目一
· Device 器件: xcvu190

· TNS (ns) : -5841.436

· WNS (ns): -0.725

· WHS (ns): 0.016

· CLB Utilization 利用率 (%): 80.15

· Run Time 運(yùn)行時間: 04:46

本設(shè)計(jì)優(yōu)化了兩輪。每輪有20-30次編譯以及結(jié)果。對于 placement exploration，我們從前一輪的結(jié)果中選取最好的WNS 結(jié)果，在這個案例中，是-0.417ns。然后將它設(shè)置成“父版本”來進(jìn)行探索。在下表（log）中，您可以看到結(jié)果中“種子”的作用，WNS 有著非常廣泛的分布值。最好 WNS結(jié)果的平均值是-0.694ns，產(chǎn)生了高達(dá)0.457ns的巨大變化。如果您對比最好 WNS 結(jié)果和上一輪的 Placement Exploration，WNS 顯著提升了43%。

圖一: TNS 盒狀圖

圖二: WNS盒狀圖

項(xiàng)目二
· Device器件: xcvu190-flgb2104

· TNS (ns) : -10229.035

· WNS (ns): -1.203

· WHS (ns): 0.016

· CLB Utilization 使用率(%): 75.71

· Run Time 運(yùn)行時間: 04:33

與項(xiàng)目一相似，項(xiàng)目二也有兩輪優(yōu)化。在第一輪中，目標(biāo)是取得最好的WNS。我們使用上一輪最好的 WNS 結(jié)果（-0.404），運(yùn)行一輪 placement exploration?；?placement exploration 的結(jié)果， 平均值是-0.512ns。最好結(jié)果是-0.187，對于原父版本的結(jié)果來說，325ps是一個高達(dá)53%的巨幅提升。

圖三: 項(xiàng)目二 TNS

圖四: 項(xiàng)目二 WNS

4. 技術(shù)總結(jié)
結(jié)果的提升不言自明。如果您在為最終的300ps提升而奮戰(zhàn)，請考慮使用這個方法，它能幫您在截止日期之前達(dá)到要求。

最后一點(diǎn)需要說明的是，運(yùn)行附加的編譯需要很多計(jì)算能力和運(yùn)行時間。而最好的解決方案是云計(jì)算，您可以使用您自己的云服務(wù)，或者注冊一個 Plunify Cloud 賬戶。

編輯：hfy