一種<>也不好使的場(chǎng)景，該assignAllByName上場(chǎng)了。

》出于監(jiān)控的需求 從校園畢業(yè)從事邏輯設(shè)計(jì)也有三年時(shí)光了，對(duì)于邏輯設(shè)計(jì)，最大的感受就是在設(shè)計(jì)中DFX的重要性。無(wú)論你自己的設(shè)計(jì)多么牛逼，仿真多么到位，全面的DFX仍舊是必不可少，尤其是跨部門(mén)多團(tuán)隊(duì)合作里，好的DFX能夠在系統(tǒng)上線(xiàn)及運(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總線(xiàn)的一個(gè)通用監(jiān)控模塊(只是舉例說(shuō)明，非真實(shí)應(yīng)用)：

這里我們定義了一個(gè)AxiLite4Mon的Component，監(jiān)控aw,w,b,ar,r五路通路的狀態(tài)。這里值得注意的是對(duì)于A(yíng)xiLite4Mon而言，alite接口的所有信號(hào)都是輸入。故其書(shū)寫(xiě)形式為in(AxiLite4(32,32))。也正因如此，當(dāng)我們?cè)贐undleTest中去例化AxiLite4Mon時(shí)你會(huì)發(fā)現(xiàn)采用<>對(duì)alite接口進(jìn)行連線(xiàn)時(shí)生成RTL時(shí)會(huì)報(bào)錯(cuò):

原因無(wú)他，對(duì)于A(yíng)xiLite4Mon的aite接口而言，其全部為輸入信號(hào)，而對(duì)于inPort接口而言，其既有輸出信號(hào)又有輸入信號(hào)，從而導(dǎo)致工具無(wú)法推斷具體的連接關(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
}

AxiLite4Mon(io.inPort,io.state)

像上面的問(wèn)題，如果你手動(dòng)對(duì)alite接口展開(kāi)賦值那我也不攔著，只能說(shuō)沒(méi)學(xué)好SpinalHDL。在SpinalHDL里這些復(fù)雜的接口都集成擴(kuò)展于Bundle。但凡你打開(kāi)過(guò)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的正確書(shū)寫(xiě)形式。

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

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

通過(guò)這些，相信能基本滿(mǎn)足日常代碼設(shè)計(jì)需求。