從校園畢業(yè)從事邏輯設計也有三年時光了，對于邏輯設計，最大的感受就是在設計中DFX的重要性。無論你自己的設計多么牛逼，仿真多么到位，全面的DFX仍舊是必不可少，尤其是跨部門多團隊合作里，好的DFX能夠在系統(tǒng)上線及運維上有極大的幫助。在一些系統(tǒng)設計里，我們往往會對模塊的各路數(shù)據(jù)接口添加狀態(tài)信息DFX以及一些輔助性能分析的工具。這里以Axiite4為例，我們以如下模塊作為待監(jiān)控模塊：

　　這里我們假定對inPort端口添加一些監(jiān)控信息，我們設計如下模塊作為AxiLite4總線的一個通用監(jiān)控模塊（只是舉例說明，非真實應用）：

　　這里我們定義了一個AxiLite4Mon的Component，監(jiān)控aw,w,b,ar,r五路通路的狀態(tài)。這里值得注意的是對于AxiLite4Mon而言，alite接口的所有信號都是輸入。故其書寫形式為in（AxiLite4（32,32））。也正因如此，當我們在BundleTest中去例化AxiLite4Mon時你會發(fā)現(xiàn)采用<>對alite接口進行連線時生成RTL時會報錯：

　　原因無他，對于AxiLite4Mon的aite接口而言，其全部為輸入信號，而對于inPort接口而言，其既有輸出信號又有輸入信號，從而導致工具無法推斷具體的連接關系。

　　對于SpinalHDL了解的小伙伴也許能夠想到，這里把AxiLite4Mon定義擴展為Area而非Component：

　　case class AxiLite4Mon（alite:AxiLite4,state:Bits） extends Area{

　　state:=alite.aw.fire##alite.w.fire##alite.b.fire##alite.ar.fire##alite.r.fire

　　}

　　此時在BundleTest中例化就可以寫成：

　　AxiLite4Mon（io.inPort,io.state）

　　誠然，這種方式從SpinalHDL的角度來講更簡潔，但對接口做一個好的DFX監(jiān)控不是像這里的這么簡單一行代碼。而且尤其當合作中有人采用Verilog來作為開發(fā)語言時最終你生成的代碼功能代碼和這些DFX代碼混合在一起給人看起來代碼過長，難以閱讀（當然我基本不直接閱讀生成的RTL代碼）。因此像這種總線接口的DFX代碼，個人還是傾向于采用Component進行封裝。

　　》assignAllByName

　　像上面的問題，如果你手動對alite接口展開賦值那我也不攔著，只能說沒學好SpinalHDL。在SpinalHDL里這些復雜的接口都集成擴展于Bundle。但凡你打開過Bundle的代碼實現(xiàn)，你就會發(fā)現(xiàn)這里面有一個assignAllByName的方法實現(xiàn)很符合我們的需求：

　　我們在Bundle中聲明的信號接口都存儲于elements中，elements的定義形式為：ArrayBuffer[（String, Data）]。這里僅需要根據(jù)定義的信號名字找到對應的接口信號進行連接即可，這也是assignAllByName所做的事情，相信有點兒Scala基礎上面的代碼并不難理解。此時像上面的代碼我們就可以輕松實現(xiàn)了：

　　這才是SpinalHDL的正確書寫形式。

　　除了assignAllByName，Bundle中也定義了下面兩種用于連線賦值的API：

　　assignSomeByName相比于assignAllByName，其允許that中的部分信號為null，而bundleAssign則可以讓我們自定義連接賦值函數(shù)。

　　通過這些，相信能基本滿足日常代碼設計需求。

更多信息可以來這里獲取==>>電子技術應用-AET<<