SystemVerilog Interface Class的妙用

前言

Interface Class是在SystemVerilog 2012版本中引入的，但目前在验证中几乎很少采用，大多数验证工程师要么不知道它，要么没有看到使用它的任何好处，这使得Interface Class成为一个未被充分使用和不被重视的特性。本文将举两个Interface Class的使用例子，在这些例子中，Interface Class提高了验证环境的灵活性和质量，同时进一步提高了其可维护性和可调试性。

示例1：观察者设计模式

Interface Class用于观察者设计模式(Observer Design pattern)。观察者模式允许你定义一种订阅机制， 可在对象事件发生时通知多个 “观察” 该对象的其他对象。例如验证环境中monitor需要采集interface上的信息，将其组合成某种transaction数据结构，并将其发送给感兴趣的各方组件，例如scoreboard和checker。在这里，monitor也称作publisher，scoreboard和checker称作subscriber或listener。如下图所示。

UVM方法学通过TLM analysis port开发了观察者模式，提供了在publisher和subscriber之间创建连接的方法，实现一对多的连接。这种方式在现在验证环境中大量使用了，但也有许多限制：

• 限制一：这种方式的组件连接是静态的，它们通常在connect_phase就确定了，并且只有uvm_component可以参与连接。
• 限制二：这种通信方式仅限于一种类型的单个事务传输。
• 限制三：subscriber需要多个analysis port时需要求助于UVM宏，或者创建子层次结构来监听transaction。

使用Interface Class实现的观察者模式完美解决了所有这三个问题。下图提供与UVM analysis port非常相似功能的实例。

interface class resolve_listener;
    pure virtual function void new_resolve(txn_resolve resolve);
endclass : resolve_listener

class monitor extends uvm_component;
    local resolve_listener m_resolve_listeners[$];

    function void add_listener(resolve_listener listener);
        m_resolve_listener.push_back(listener);
    endfunction

    virtual task run_phase(uvm_phase phase);
        forever begin
            txn_resolve resolve = get_next_resolve();
            foreach(m_resolve_listeners[i])
                m_resolve_listeners[i].new_resolve(resolve);
        end
    endtask

endclass : monitor

class resolve_checker extends uvm_component implements resolve_listener;

    virtual function void connect_phase(uvm_phase phase);
        super.connect_phase(phase);
        m_config.monitor.add_listener(this);
    endfunction

    virtual function void new_resolve(txn_resolve resolve);
    if (resolve.is_abort())
        `uvm_fatal(get_name(), "Aborts are not expected")
    endfunction

endclass : resolve_checker

图2 使用Interface Class实现通信

首先这个实例使用了动态连接，subscribers可以在仿真过程中的任何时间点向publisher注册自己(并不限制于connect_phase阶段)，并开始订阅transactions。另外，这个实例也允许UVM sequence等非uvm_component直接订阅monitor、BFM和checker等的transactions。下面为reactive sequence直接利用monitor监控到的接口行为产生其它动作的例子，这样的写法使得reactive sequence更容易编写。维护和理解，而不需要借助于sequencer和sequence之间错综复杂的通信通道。

task run_sequence();
    m_done = 0;
    m_config.monitor_l1l2.add_listener(this);
    wait(m_done);
    m_config.monitor_l1l2.remove_listener(this);
endtask

virtual function void new_l1l2_request(txn_l1l2 req);
    // Wait until a request to upgrade line from shared to exclusive is seen and
    // send a snoop request to steal the line away
    if (!m_done && l1l2.req_type() == READ_UNIQUE_HIT_SHARED) begin
        send_snoop(SNOOP_INVALIDATE, l1l2.req_address());
        m_done = 1;
    end
endfunction

图3 使用观察者模式直接订阅monitor的事件

第二个是subscriber和publisher之间的接口并不局限于单个transaction传输。接口函数new_resolve(…)可以传递任何可能对subscriber有用的附加信息，如下面new_resolve新的函数参数。

pure virtual function void new_resolve(txn_uop uop, txn_resolve resolve);

图4 new_resolve新定义

最后，subscriber可以订阅多个publisher的消息，因为Interface Class允许多继承，下图的例子是order检查器一方面订阅正在进行的微操作(micro operation)，另一方面订阅了ACE协议口发出的请求，并检查它们是否是以正确的顺序进行。这样生成的代码比使用UVM analysis port更干净和直接得多，那个函数做什么很清楚。

class ordering_checker extends checker implements uop_listener, ace_listener;

    local txn_uop m_ordered_uops[$];

    // Register ourselves with micro-op and ACE agents
    virtual function void connect_phase(uvm_phase phase);
        super.connect_phase(phase);
        m_config.uop_agent.add_listener(this);
        m_config.ace_agent.add_listener(this);
    endfunction

    // On commits, record micro-ops that need to be ordered
    virtual function void new_commit(txn_uop uop, txn_commit commit);
        if (commit.is_clean() && uop.is_ordered())
        m_ordered_uops.push_back(uop);
    endfunction

    // On ACE requests, compare address and size
    virtual function void new_ace_req(ace_req ace_request);
        txn_uop uop;
        if (!ace_request.needs_to_be_ordered())
            return;
        uop = m_ordered_uops.pop_front();
        check(ace_request.addr().equals(uop.addr()) && (ace_request.size() == uop.size()),
{"ACE request seen doesn¿t match the oldest micro-op: ", uop.covert2string()});
    endfunction

endclass : ordering_checker

图5 checker订阅两个不同的monitor的事件

在某些情况下，用于复杂checker的subscriber的Interface Class定义了许多函数，但并非所有函数都在每个subscriber中用到。一种解决方案是将Interface Class分解为更小的类，但这需要向订阅所有events的subscriber添加额外代码。可以使用一个优雅的解决方案，也就是引入中间层类，中间层类为Interface Class的所有函数提供了空的实现，允许子类只覆盖它需要的函数，如下图所示。

class uop_listener_mixin(type T = uvm_component) extends T implements uop_listener;

    virtual function void new_resolve(txn_uop uop, txn_resolve resolve);
    endfunction

    virtual function void new_commit(txn_uop uop, txn_commit commit);
    endfunction

    virtual function void new_issue(txn_uop uop);
    endfunction

    virtual function void uop_flush(txn_uop uop, flush_cause_e cause);
    endfunction

endclass : uop_listener_mixin


class uop_checker extends uop_listener_mixin#(checker);

    virtual function void new_issue(txn_uop uop);
        check_uop(uop);
    endfunction

endclass : uop_checker

图6 在Interface Class中使用中间层

这种方式的一大优点是，仍然允许中间层继承多个Interface Class，进而订阅多个接口的transactions。order检查器的声明可以写成如下图所示。

class strongly_ordered_checker extends uop_listener_mixin#(l1l2_listener_mixin #(checker));

图7 中间层的嵌套使用

示例2：多继承

在SystemVerilog中缺乏真正的多继承，我们可以使用Interface Class来绕过这个限制，我们以Arm指令类为例。下图左边为带地址的指令，比如load和store指令，右边为不带地址的操作，比如data barrier指令中的DMB和DSB等。但如果引入了Load-Acquire(LDAR)和Store-Release(STLR)指令呢（LDAR和STLR指令的行为就像是二合一指令，它们既是load/store，也是barrier）？那么它们在下图中该处于什么位置呢？

如果支持类多继承的话，LDAR可以从load和data barrier类继承。但缺乏类多继承的情况下，大多数类层次结构只允许LDAR继承自load，并且要么将所有特定于barrier的函数放在共同基本类中，要么在任何地方编写特殊代码来处理此问题，这样会导致代码更难以维护。

然而，有了Interface Class一切就好办了，它允许我们做一些类似于多继承的实现。我们可以定义一个Barrier Interface Class，它声明描述Barrier行为的函数，然后让DataBarrier、LDAR和STLR类实现它。现在，判断一个指令是否是Barrier只需要做一次$cast检查就好了。

interface class barrier;
    // Return 1 if this barrier affects the given uop in a given direction
    pure virtual function bit affects_uop(txn_uop uop, dir_e direction);
    // Perform age comparison between a barrier and a uop
    pure virtual function bit is_barrier_older(txn_uop uop);
    //...
endclass : barrier

class barrier_checker;
    function void check_out_of_order_resolve(txn_uop first, txn_uop second);
        barrier bar;
        if ($cast(bar, second) && bar.affects_uop(first, YOUNGER))
            `uvm_fatal(get_name(), "Uop bypassed a barrier it isn¿t allowed to.")
        endfunction
endclass ：barrier_checker

图9 Barrier Interface Class的使用示例

这种方式可以用于指令类层次结构中的其它指令，比如exclusive指令、atomic指令等等。

总结

本文两个Interface Class用例都会使得验证环境开发更加容易，观察者模式使得transaction传递更加清晰和灵活，这对激励质量有特别积极的影响，sequence可以直接根据monitor中的事件自适应调整激励。多继承模式简化了类的层次结构，使每个类的职责有更清晰的划分。

作者：沪闵菜菜子
文章来源：专芯致志er

推荐阅读

• SystemVerilog Assertion精华知识
• Serdes：channel类型有哪些
• 量产维护 | 芯片失效问题解决方案：从根源找到答案
• INVS利用gatearray实现post-mask的function ECO
• PCIe物理层_CTLE（continuous time linear equalizer）

更多IC设计干货请关注IC设计专栏。欢迎添加极术小姐姐微信（id:aijishu20)加入技术交流群，请备注研究方向。