從校園畢業(yè)從事邏輯設(shè)計也有三年時光了，對于邏輯設(shè)計，最大的感受就是在設(shè)計中DFX的重要性。無論你自己的設(shè)計多么牛逼，仿真多么到位，全面的DFX仍舊是必不可少，尤其是跨部門多團(tuán)隊合作里，好的DFX能夠在系統(tǒng)上線及運(yùn)維上有極大的幫助。在一些系統(tǒng)設(shè)計里，我們往往會對模塊的各路數(shù)據(jù)接口添加狀態(tài)信息DFX以及一些輔助性能分析的工具。這里以Axiite4為例，我們以如下模塊作為待監(jiān)控模塊：
這里我們假定對inPort端口添加一些監(jiān)控信息，我們設(shè)計如下模塊作為AxiLite4總線的一個通用監(jiān)控模塊（只是舉例說明，非真實應(yīng)用）：
這里我們定義了一個AxiLite4Mon的Component，監(jiān)控aw,w,b,ar,r五路通路的狀態(tài)。這里值得注意的是對于AxiLite4Mon而言，alite接口的所有信號都是輸入。故其書寫形式為in（AxiLite4（32,32））。也正因如此，當(dāng)我們在BundleTest中去例化AxiLite4Mon時你會發(fā)現(xiàn)采用<>對alite接口進(jìn)行連線時生成RTL時會報錯：
原因無他，對于AxiLite4Mon的aite接口而言，其全部為輸入信號，而對于inPort接口而言，其既有輸出信號又有輸入信號，從而導(dǎo)致工具無法推斷具體的連接關(guān)系。
對于SpinalHDL了解的小伙伴也許能夠想到，這里把AxiLite4Mon定義擴(kuò)展為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)控不是像這里的這么簡單一行代碼。而且尤其當(dāng)合作中有人采用Verilog來作為開發(fā)語言時最終你生成的代碼功能代碼和這些DFX代碼混合在一起給人看起來代碼過長，難以閱讀（當(dāng)然我基本不直接閱讀生成的RTL代碼）。因此像這種總線接口的DFX代碼，個人還是傾向于采用Component進(jìn)行封裝。
》assignAllByName
像上面的問題，如果你手動對alite接口展開賦值那我也不攔著，只能說沒學(xué)好SpinalHDL。在SpinalHDL里這些復(fù)雜的接口都集成擴(kuò)展于Bundle。但凡你打開過Bundle的代碼實現(xiàn)，你就會發(fā)現(xiàn)這里面有一個assignAllByName的方法實現(xiàn)很符合我們的需求：
我們在Bundle中聲明的信號接口都存儲于elements中，elements的定義形式為：ArrayBuffer[（String, Data）]。這里僅需要根據(jù)定義的信號名字找到對應(yīng)的接口信號進(jìn)行連接即可，這也是assignAllByName所做的事情，相信有點(diǎn)兒Scala基礎(chǔ)上面的代碼并不難理解。此時像上面的代碼我們就可以輕松實現(xiàn)了：
這才是SpinalHDL的正確書寫形式。
除了assignAllByName，Bundle中也定義了下面兩種用于連線賦值的API：
assignSomeByName相比于assignAllByName，其允許that中的部分信號為null，而bundleAssign則可以讓我們自定義連接賦值函數(shù)。
通過這些，相信能基本滿足日常代碼設(shè)計需求。
更多信息可以來這里獲取==>>電子技術(shù)應(yīng)用-AET<<
