用设计模式重新思考(类FSM)验证：从混乱到优雅

在数字设计的世界里，Finite-State Machine（FSM）就像一个城市的交通信号系统。每个状态都有自己的规则，每个转换都需要精确的条件。而对于验证工程师来说，如何优雅地验证这些状态机，一直是个让人头疼的问题。

传统方法的困境

大多数工程师在处理FSM验证时，会选择最直观的方法：用一个enum来表示状态，然后写一个巨大的switch/case语句来处理所有逻辑。这种方法就像把所有鸡蛋放在一个篮子里——看起来简单直接，但问题很快就会暴露出来。

class FSMExample;
    local fsm_t currentState;
    function new(fsm_t initState); currentState = initState; endfunction
    function void doAction(Input inputs);
        case (currentState)
            fsm_reset: begin
                doActionForState_reset(inputs);
                currentState = calculateNewState(currentState, inputs); end
            fsm_init: begin
                doActionForState_init(inputs);
                currentState = calculateNewState(currentState, inputs); end
            …
        endcase
    endfunction
    protected function void doActionForState_reset(Input inputs); endfunction
    protected function void doActionForState_init(Input inputs); endfunction
    …
    local function fsm_t calculateNewState(fsm_t currentState, Input inputs); endfunction
endclass

这种紧耦合的实现方式有个致命问题：所有的逻辑都纠缠在一起。状态的结构、行为和转换逻辑混在一个地方，就像一团理不清的毛线球。当你需要添加新状态或修改现有逻辑时，往往牵一发而动全身。

设计模式的智慧

软件开发领域有句话："没有什么问题是加一层抽象解决不了的。"设计模式的本质就是通过合理的抽象来解决重复出现的问题。对于FSM验证，我们可以运用几个经典的设计模式来化解复杂性。