設計中DFX的重要性表現(xiàn)

一種<>也不好使的場景，該assignAllByName上場了。

》出于監(jiān)控的需求 從校園畢業(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
}

AxiLite4Mon(io.inPort,io.state)

像上面的問題，如果你手動對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ù)。

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