在线视频高清免费观看,天美传媒tm0065,亚洲精品综合网

對于前端設計人員，經常會需要一個MUX來對工作模式，數據路徑進行明確（explicit）的聲明，這個對于中后端工程師下約束也很重要。這里介紹一種巧用的RTL原語，實現MUX的方法。

為了在最終網表里邊實現確實的MUX，通常有兩種方式。

RTL designer采用了手動實例化(instance)工藝的MUX來實現MUX。但是對于RTL在不同工藝下使用，卻造成了一些不便。

一種使用腳本替換的方法，即在綜合elaboration的數據庫上進行對標工藝的硬替換（replace），這樣也需要一套腳本流程。

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

RTL原語

DC在做HDL分析，解析（analyze，elaboration)的時候，會對RTL里邊的一些原語進行識別，譬如在verilog里邊，可以這樣使用：

verilog_code // synopsys RTL_primitive

這里的primitive是一整套RTL配置，里邊有一個功能就是可以對RTL的MUX功能進行有效映射。所以，通過這個RTL 原語，就可以實現設計出MUX的訴求。

帶入RTL原語的elaborate

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

使用case搭建的語句：DC 默認會處理成SELECT_OP類型

沿觸發/電平觸發的時序邏輯語句：DC 默認會處理成SEQGEN類型（這里暫不作展開）

對于SELECT_OP類型的邏輯轉化，通常來自于類似下列的語句：

DC對于上述語句在elaborate階段，將其轉換成為了SELECT_OP，至于最終實現的器件類型，并不明確。

按照DC的規則：compile會根據實際的時序，面積等考慮，DC會決斷把SELECT_OP實現為一個與或非邏輯或者是一個MUX邏輯。相對于RTL實例化一個MUX而言，這里就會帶來一些不確定性。

基于此，通過對RTL進行原語級別的配置，讓elaborate對case的結果進行約束。示例語法如下：

可以看到，這里的采用了infer_mux （infer：推斷）的原語。這個原語可以指導DC對這里的case語句進行MUX_OP實現方式的推斷，而非使用默認的SELECT_OP作替換。

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

不使用infer_mux，映射為SELECT_OP_4.1_4.1_1: 四輸入一輸出的組合邏輯結構

使用infer_mux，映射為MUX_OP_4_2_1：四輸入，二選擇，一輸出的MUX結構由于DC的compile/compile_ultra命令是基于elaborate的映射結果，所以，這里距離完全實現目標就剩compile一個步驟了。

被改善compile結果

Compile完成后，通過verdi打開，可以很方便的查驗到結構圖：

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

DC這樣做是有它的道理的，在本案例中，穿過dout[0]和dout[1]的時序都是滿足的，這個時候DC會有先使用面積小的進行實現dout[1]邏輯，但是會依賴infer_mux的指引實現dout[0]上的邏輯：

dout[0]上的MUX4面積： 98.76

dout[1]的與或非邏輯面積：70.092 所以，在原語的控制下，DC強制使用了MUX，而對于其他部分，DC其實是做了更為優化的選擇，譬如這里的面積優先選擇機制。

MUX樹的創建

除過RTL代碼保持平滑度的好處外，原語的另一個好處是可以讓工具自動選擇合適的MUX進行結果構建。譬如當前工藝庫最大提供了四輸入MUX，如果是一個較大扇入（fan-in）的MUX需求，DC工具可以友好的進行自動“拓展”，靈活構建一個MUX Tree 達到用戶需要的結果譬如下例：RTL書寫了一個八輸入MUX

elaborate后，DC將它正確識別成了：八輸入，三控制，一輸出的MUX：MUX_OP_8_3_1_1 工藝庫并沒有八輸入這個大的MUX，這個時候如果使用手動構建會比較復雜。但是DC卻可以做自動“拓展”，使用了兩個MUX4外加一個MUX2，完成了這個MUX tree的構建， compile完成后，通過查看網表可以看到，這里最終是一個MUX tree來實現這個八輸入MUX，見下圖：

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