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