對(duì)于前端設(shè)計(jì)人員，經(jīng)常會(huì)需要一個(gè)MUX來(lái)對(duì)工作模式，數(shù)據(jù)路徑進(jìn)行明確（explicit）的聲明，這個(gè)對(duì)于中后端工程師下約束也很重要。這里介紹一種巧用的RTL原語(yǔ)，實(shí)現(xiàn)MUX的方法。

為了在最終網(wǎng)表里邊實(shí)現(xiàn)確實(shí)的MUX，通常有兩種方式。

RTL designer采用了手動(dòng)實(shí)例化(instance)工藝的MUX來(lái)實(shí)現(xiàn)MUX。但是對(duì)于RTL在不同工藝下使用，卻造成了一些不便。

一種使用腳本替換的方法，即在綜合elaboration的數(shù)據(jù)庫(kù)上進(jìn)行對(duì)標(biāo)工藝的硬替換（replace），這樣也需要一套腳本流程。

上述方法可以實(shí)現(xiàn)MUX，但是靈活度不是很好，也需要額外的流程和代碼量。這里看看DC的解決策略。

RTL原語(yǔ)

DC在做HDL分析，解析（analyze，elaboration)的時(shí)候，會(huì)對(duì)RTL里邊的一些原語(yǔ)進(jìn)行識(shí)別，譬如在verilog里邊，可以這樣使用：

這里的primitive是一整套R(shí)TL配置，里邊有一個(gè)功能就是可以對(duì)RTL的MUX功能進(jìn)行有效映射。所以，通過(guò)這個(gè)RTL 原語(yǔ)，就可以實(shí)現(xiàn)設(shè)計(jì)出MUX的訴求。

帶入RTL原語(yǔ)的elaborate

DC的綜合階段，首先是嘗試把RTL的邏輯關(guān)系影射成為功能描述庫(kù)，也就是我們常說(shuō)的GTECH庫(kù)。但是對(duì)于下列兩種情況會(huì)做較特殊的處理

使用case搭建的語(yǔ)句：DC 默認(rèn)會(huì)處理成SELECT_OP類型

沿觸發(fā)/電平觸發(fā)的時(shí)序邏輯語(yǔ)句：DC 默認(rèn)會(huì)處理成SEQGEN類型 （這里暫不作展開(kāi)）

對(duì)于SELECT_OP類型的邏輯轉(zhuǎn)化，通常來(lái)自于類似下列的語(yǔ)句：



DC對(duì)于上述語(yǔ)句在elaborate階段，將其轉(zhuǎn)換成為了SELECT_OP，至于最終實(shí)現(xiàn)的器件類型，并不明確。

按照DC的規(guī)則：compile會(huì)根據(jù)實(shí)際的時(shí)序，面積等考慮，DC會(huì)決斷把SELECT_OP實(shí)現(xiàn)為一個(gè)與或非邏輯或者是一個(gè)MUX邏輯。相對(duì)于RTL實(shí)例化一個(gè)MUX而言，這里就會(huì)帶來(lái)一些不確定性。

基于此，通過(guò)對(duì)RTL進(jìn)行原語(yǔ)級(jí)別的配置，讓elaborate對(duì)case的結(jié)果進(jìn)行約束。示例語(yǔ)法如下：

可以看到，這里的采用了infer_mux （infer：推斷）的原語(yǔ)。這個(gè)原語(yǔ)可以指導(dǎo)DC對(duì)這里的case語(yǔ)句進(jìn)行MUX_OP實(shí)現(xiàn)方式的推斷，而非使用默認(rèn)的SELECT_OP作替換。

通過(guò)上例可以看到，同樣的代碼，在使用infer_mux和不使用的情形下，DC的elaborate給出了不同的答案。

不使用infer_mux，映射為SELECT_OP_4.1_4.1_1: 四輸入一輸出的組合邏輯結(jié)構(gòu)

使用infer_mux，映射為MUX_OP_4_2_1：四輸入，二選擇，一輸出的MUX結(jié)構(gòu) 由于DC的compile/compile_ultra命令是基于elaborate的映射結(jié)果，所以，這里距離完全實(shí)現(xiàn)目標(biāo)就剩compile一個(gè)步驟了。

被改善compile結(jié)果

Compile完成后，通過(guò)verdi打開(kāi)，可以很方便的查驗(yàn)到結(jié)構(gòu)圖：



可以看到，DC工具在infer_mux的dout[0]通路上使用了一個(gè)四輸入的MUX做了實(shí)現(xiàn)，但是在dout[1]的通路上選擇的常規(guī)的與或非邏輯作實(shí)現(xiàn)。

DC這樣做是有它的道理的，在本案例中，穿過(guò)dout[0]和dout[1]的時(shí)序都是滿足的，這個(gè)時(shí)候DC會(huì)有先使用面積小的進(jìn)行實(shí)現(xiàn)dout[1]邏輯，但是會(huì)依賴infer_mux的指引實(shí)現(xiàn)dout[0]上的邏輯：

dout[0]上的MUX4面積： 98.76

dout[1]的與或非邏輯面積：70.092 所以，在原語(yǔ)的控制下，DC強(qiáng)制使用了MUX，而對(duì)于其他部分，DC其實(shí)是做了更為優(yōu)化的選擇，譬如這里的面積優(yōu)先選擇機(jī)制。

MUX樹(shù)的創(chuàng)建

除過(guò)RTL代碼保持平滑度的好處外，原語(yǔ)的另一個(gè)好處是可以讓工具自動(dòng)選擇合適的MUX進(jìn)行結(jié)果構(gòu)建。譬如當(dāng)前工藝庫(kù)最大提供了四輸入MUX，如果是一個(gè)較大扇入（fan-in）的MUX需求，DC工具可以友好的進(jìn)行自動(dòng)“拓展”，靈活構(gòu)建一個(gè)MUX Tree 達(dá)到用戶需要的結(jié)果 譬如下例：RTL書(shū)寫(xiě)了一個(gè)八輸入MUX



elaborate后，DC將它正確識(shí)別成了：八輸入，三控制，一輸出的MUX：MUX_OP_8_3_1_1 工藝庫(kù)并沒(méi)有八輸入這個(gè)大的MUX，這個(gè)時(shí)候如果使用手動(dòng)構(gòu)建會(huì)比較復(fù)雜。但是DC卻可以做自動(dòng)“拓展”，使用了兩個(gè)MUX4外加一個(gè)MUX2，完成了這個(gè)MUX tree的構(gòu)建， compile完成后，通過(guò)查看網(wǎng)表可以看到，這里最終是一個(gè)MUX tree來(lái)實(shí)現(xiàn)這個(gè)八輸入MUX，見(jiàn)下圖：



可以看到，DC先是放了兩個(gè)平行的四輸入的MUX進(jìn)行選擇，然后進(jìn)入到一個(gè)兩輸入的MUX做最后的決斷。

作為比對(duì)，這里的dout[4]，并未采用infer_mux 作實(shí)現(xiàn)，可以看到DC使用了常規(guī)的與或非結(jié)構(gòu)進(jìn)行了實(shí)現(xiàn)



使用RTL原語(yǔ)的方法，對(duì)于設(shè)計(jì)人員的工作量大為減少，并且可以不依賴工藝庫(kù)，DC工具甚至可以自動(dòng)構(gòu)建MUX tree，達(dá)到了事半功倍的效果。

== =【敲黑板劃重點(diǎn)】===

RTL原語(yǔ)是DC對(duì)于RTL的一個(gè)特殊指令，通過(guò)這套系統(tǒng)可以對(duì)elaborate進(jìn)行顯性（explicity ）的干預(yù)，設(shè)計(jì)人員可以靈活使用，將設(shè)計(jì)理念完整的傳遞到中后端。






審核編輯：劉清