狀態機的可監控維度該如何考慮

》狀態機該怎么監控

最近遇到一個關于狀態機的問題，具體的業務就不講了。關于FSM怎么寫這種初級問題在這里也不講了。這里我們只關注下在真實的應用場景里，從監控的角度來看，該如何去看待FSM。 FPGA設計里，除了功能實現之外，最重要的一部分就是DFX的設計。畢竟燒錄完之后我們也只能通過DFX來去觀測內部的狀態(說JTAG的請繞過，那頂多是開發階段)。在考慮資源允許的情況下，我們要做的應當是有充分的DFX能夠幫助我們去觀測內部的狀態。一個工程做下來往往是在補DFX時覺得要添加的太多了，而到真實需要定位問題的時候則又會感嘆“當初怎么不多添加些DFX”～ 回到對FSM的處理，一開始想到的可能是：

把FSM的當前狀態添加到DFX中。

沒毛病，我們能夠清楚的觀察到當前狀態機處于什么狀態。但當狀態機如果處于卡死不動的狀態，那我們所需要的就是導致當前狀態卡住的信號的狀態：

把FSM各條件跳轉的判斷信號添加到DFX中。

上面兩條也基本是我們之前設計常常會做的內容。然而這里面只是對下面的場景做了監控：

狀態機卡住的場景——通過狀態跳轉條件的DFX信號去判斷卡住的原因

對于DFX信號，像我們通過PCIe寄存器鏈路去讀取DFX信號時不可能獲取到每拍的結果，因而上面的DFX信號添加方式也就只能針對FSM卡死的情況進行定位判斷。然而很不幸，這一次我遇到了一個狀態機在跳轉，只是沒有跳轉到一個需要響應某個動作的狀態。由于代碼從別人那里接手過來的，看代碼也能對case場景進行一個判斷。但回到監控的角度，只是沒有跳轉到一個需要響應某個動作的狀態這個判斷是我針對看到的DFX抓取信號來判斷得到的結論，然而我并不能自證(當然可以通過仿真構造類似Case來進行驗證，這不提了)，畢竟DFX不是每拍的結果都能看得到的，針對線上的問題，所有的判斷應當都是有充足的證據的，而不是結合觀測加推斷。那么針對這種場景，有必要再增加一種監控手段：

記錄各狀態之間是否有過跳轉發生，軟件可清零。

通過記錄各狀態之間是否發生過跳轉，那么我們可以結合DFX當前狀態來充分說明某個狀態沒有到達。而記錄各狀態之間是否有過跳轉發生，所消耗的資源也非常少。 》example

來看一個簡單的狀態機：

import spinal.lib.fsm._

classTopLevelextendsComponent{
val io = newBundle {
val result = out Bool()
}

val fsm = newStateMachine {
val counter = Reg(UInt(8bits)) init(0)
io.result := False

val stateA : State = newState with EntryPoint {
whenIsActive(goto(stateB))
}
val stateB : State = newState {
onEntry(counter := 0)
whenIsActive {
counter := counter + 1
when(counter === 4) {
goto(stateC)
}
}
onExit(io.result := True)
}
val stateC : State = newState {
whenIsActive(goto(stateA))
}
}
}

這里面會存在三個狀態StateA、StateB、StateC：

StateA——>StateB

StateB——>StateC

StateC——>StateA

那么我們需要記錄的就是：

StateA_to_fsm_stateB_change

StateB_to_fsm_stateC_change

StateC_to_fsm_stateA_change

在SpinalHDL里，這種活兒還是不要手動的好，當然是自動化的處理好。下面給一個Demo，可能有大神有更加優雅的解決方式，歡迎交流。

定義StateExtend：

class StateExtend(implicit stateMachineAccessor: StateMachineAccessor) extends State {
val nextStateBuffer=Set[StateExtend]()
def goto(state:StateExtend)={
nextStateBuffer.add(state)
stateMachineAccessor.goto(state)
}
}

主要是在原有State的基礎上重定義了goto函數，記錄了每個狀態會跳轉的下一狀態。

然后定義FsmMonitor:

caseclassFsmState(monReg:Bool,curState:State,nextState:State)

caseclassFsmMonitor(implicitstateMachineAccessor: StateMachine) extendsArea{
val stateMonMap=Map[State,ArrayBuffer[FsmState]]()
val state_mon_clear=RegInit(False) simPublic()

defgenerateFsmMonitor()={
val current_state_dly=RegNext(stateMachineAccessor.stateReg)
val next_state_dly=RegNext(stateMachineAccessor.stateNext)
for(state<-stateMachineAccessor.states){
??????if(state.isInstanceOf[StateExtend]){
????????for?(nextState <- state.asInstanceOf[StateExtend].nextStateBuffer){
??????????val state_change=RegInit(False) setName (s"${state.getName()}_to_${nextState.getName()}_change")
??????????when(state_mon_clear){
????????????state_change.clear()
??????????}elsewhen((current_state_dly===stateMachineAccessor.enumOf(state))){
????????????when(next_state_dly===stateMachineAccessor.enumOf(nextState)){
??????????????state_change.set()
????????????}
??????????}
??????????stateMonMap.getOrElse(state,ArrayBuffer[FsmState]()).append(FsmState(state_change,state,nextState))
????????}
??????}
????}
??}
}

在generateFsmMonitor中，會針對每個狀態來分別創建跳轉相應的跳轉監控信號，并記錄到stateMonMap中去。state_mon_clear可用于清零狀態所有監控信號。通過regif可講state_mon_clear及stateMonMap中的所有元素添加到寄存器總線中去(也可以直接用regif聲明創建寄存器)。

最終，在使用時如下即可：

case classfsmTest() extendsComponent{
val counter = out(Reg(UInt(8bits)) init (0))

val fsm = newStateMachine {
val stateA = newStateExtend() with EntryPoint setName("StateA")
val stateB, stateC = newStateExtend()
stateA.whenIsActive {
stateA.goto(stateB)
}
stateB.whenIsActive {
stateB.goto(stateC)
}
stateC.onEntry(counter := 0)
stateC.whenIsActive {
counter := counter + 1
when(counter === 3) {
stateC.goto(stateA)
}
}

val fsm_mon=FsmMonitor()
addPrePopTask(()=>{
fsm_mon.generateFsmMonitor()
})
}
}

差別點在于goto換成對應的StateA.goto等顯示調用的形式。通過例化FsmMonitor調用generateFsmMonitor即可注冊所有的狀態跳轉信號：

審核編輯：黃飛