最近看到一个比较有意思的东西，深入了解了一下，记录分享一下。软硬件协同仿真验证，就是将UVM验证方法学与FPGA相结合，通过将DUT在FPGA上实现，在PC端搭建UVM验证平台，将二者连接就可以实现仿真验证的加速效果。这其中最关键的部分就是如何将FPGA与PC端的UVM验证平台连接起来进行通信。如果你比较厉害，你可以想到使用UVM中的TLM通信实现，但靠自己实现起来还是太难了。所以accellera提供了一种标准的硬件协同仿真和验证的标准接口协议SCE-MI（Standard Co-Emulation Modeling Interface），下面介绍一下SCE-MI协议的具体内容。
1. SCE-MI协议简介
SCE-MI（Standard Co-Emulation API: Modeling Interface）是一种标准化的协同仿真建模接口协议，旨在为SoC设计验证提供高效的硬件仿真与软件模型协同工作环境。该协议基于SystemVerilog DPI接口扩展而来，通过多通道通信机制支持非时序软件模型与RTL或门级硬件模型的无缝连接，特别优化了硬件仿真器和快速原型验证环境下的性能表现。SCE-MI采用消息/事务导向的通信方式而非事件驱动，有效避免了传统接口在高速仿真环境中的通信瓶颈，同时支持事务级模型在仿真和仿真环境间的双向迁移，为EDA行业提供了统一的验证接口标准，解决了不同厂商API不兼容导致的验证工具互操作性问题。
SCE-MI标准直接支持三种主要使用模型（图4.1），用于连接HDL编写的模型与工作站上运行的模型。每种使用模型都通过相应的接口实现：第一种是基于消息传递的宏接口，第二种是基于SystemVerilog DPI的新型函数接口，第三种是新型管道接口。这三种接口构成独立的使用模型，只要接口实现支持对应规范，采用任一接口的模型都能与对端通信。
图4.2展示了SCE-MI如何将非时序软件模型与结构化硬件事务器和DUT模型互连的高层视图。
SCE-MI为每个通道在仿真器和工作站之间提供传输基础设施，将仿真器中的事务器模型与工作站上的C（非时序或RTL）模型互连。"仿真器"一词可与任何能够执行RTL或门级模型的仿真器互换使用，包括软件HDL仿真器。
这些互连以消息通道的形式提供，运行在SCE-MI基础设施的软件端和硬件端之间。每个消息通道有两个端点：软件端的称为消息端口代理，是提供通道API访问的C++对象或C函数；硬件端的称为消息端口，实例化在事务器内部并连接到事务器中的其他组件。每个消息通道相对于硬件端是输入或输出通道。
消息通道不是硬件信号意义上的单向或双向总线，而更像是使用消息传递协议的网络套接字。事务器的作用是作为抽象垫片，将从软件端输入通道到达的消息分解为可以时钟驱动到DUT的周期精确事件序列。对于另一个方向的流，事务器将从DUT来的事件序列重新组合成消息，通过输出通道发送到软件端。
此外，SCE-MI基础设施在基于宏的使用模型中提供时钟（和复位）生成以及与事务器的共享时钟控制握手信号。这使得事务器在执行消息组合和分解操作时可以"冻结"受控时间。
2.基于宏的消息传递接口（Macro-based Message Passing Interface）
基于宏的消息传递接口运行时环境由一组接口组件组成，这些组件位于接口的硬件侧和软件侧，每个组件提供不同级别的功能。
硬件侧接口组件：
SCE-MI硬件侧呈现的接口组件由一小部分宏组成，这些宏提供事务器和SCE-MI基础设施之间的连接点。这些紧凑定义且易于使用的宏向事务器和DUT完整呈现了接口的所有必要方面。这些宏简单地表示为空的SystemVerilog或VHDL模型，具有明确定义的端口和参数接口。这类似于定义API调用函数原型而不显示其实现的软件API规范。
简而言之，四个宏向事务器和DUT呈现以下接口：
消息输入端口接口、消息输出端口接口、受控时钟和受控复位生成器接口、非受控时钟、非受控复位和时钟控制逻辑接口
软件侧接口组件：
SCE-MI基础设施向软件侧呈现的接口由一组C++对象和方法组成，提供以下功能：
版本发现、参数访问、初始化和关闭、消息输入和输出端口代理绑定和回调注册、与硬件侧的会合操作、基础设施服务循环轮询函数、消息输入发送函数、消息输出接收回调分派、消息输入就绪回调分派、错误处理。
除了C++面向对象的接口外，还为纯C应用程序提供了一组C API函数。
3. 基于函数的接口(Function-based interface)
SCE-MI的基于函数接口设计以无预定义API为核心思想，允许用户直接在一种语言中定义函数并在另一种语言中调用，形成跨语言事务通道。这种设计充分利用SystemVerilog DPI（IEEE 1800）的标准化特性，将函数调用本身作为最小事务单元，其输入/输出参数自然构成事务的数据成员，避免了传统消息传递中繁琐的位切片操作。在数据类型映射上，SystemVerilog的固定宽度类型（如int=32位）与C的兼容类型（如int32_t）直接对应，而位向量通过svBitVecVal实现映射，但需注意ANSI C整数宽度的灵活性可能要求用户处理数据掩码和填充问题。
上下文处理是跨语言调用的关键技术挑战。由于C函数缺乏面向对象的上下文（如C++的this指针），SCE-MI通过作用域绑定机制解决：在初始化阶段，使用svPutUserData将HDL模块实例的作用域（通过svGetScopeFromName获取）与用户数据（如C++对象指针）关联；在函数调用时，通过svGetScope动态获取调用者作用域，再以svGetUserData提取关联对象，确保事务在正确的上下文中执行。这一机制在SystemVerilog HVL与HDL的交互中尤为重要，其三层架构（HVL→C层→HDL）通过自动生成的C层代码实现无缝桥接。
SV-Connect架构专门针对SystemVerilog HVL与HDL的集成设计。EDA工具利用VPI解析HVL侧的DPI函数声明，自动生成精简的C中间层：
入站调用（HVL→HDL）时，C层传递HDL实例的作用域句柄chandle，使HVL侧能精确定位目标事务器；
出站调用（HDL→HVL）时，C层通过svGetScope()捕获HDL调用者作用域，切换至HVL包作用域后调用目标函数。HVL侧通过静态作用域映射表（如static ProxyClass proxyMap[chandle]）将作用域与代理对象绑定，实现事务的定向分发。
基于函数接口的核心优势在于其标准化和零时间事务特性：基于成熟的SystemVerilog DPI标准，函数调用不消耗仿真时间，规避了时钟同步问题，同时无缝集成SystemC/UVM等验证方法学。典型应用包括事务级验证（连接非时序测试平台与RTL DUT）、IP复用（事务器实现者预封装函数接口）以及混合仿真环境移植，为复杂SoC验证提供高效、可移植的解决方案。
4.基于管道的接口（Pipe-based interface）
SCE-MI管道接口（Pipe-based Interface）是针对流式数据传输和可变长消息设计的核心通信机制，其设计融合了UNIX流式处理与套接字通信的精髓。管道作为单向事务通道，支持两种数据可见性模式：延迟可见性模式下，生产者写入的数据需等待管道填满或显式刷新（flush）后才对消费者可见，适用于批量传输优化；即时可见性模式则确保数据写入后立即可见，消费者下次获得执行控制权即可访问，适用于实时交互场景。管道在语义上兼具UNIX文件流的缓冲传输与刷新机制、UNIX命名管道的唯一标识性（通过HDL层级路径绑定），以及套接字式单向消息传递的简洁性，但规避了复杂绑定流程。
与传统TLM FIFO相比，管道具备显著差异：FIFO需用户预设固定缓冲深度并依赖自动同步机制，而管道由实现定义动态缓冲深度（支持运行时优化），用户通过显式flush控制同步点，且仅支持阻塞操作以保证确定性。这种设计使管道天然适配流式数据与可变长消息场景，例如支持数据整形机制——漏斗模式允许生产者宽位宽发送（如整帧100字节）、消费者窄位宽处理（逐字节接收），实现高效批量传输；喷嘴模式则支持生产者窄位宽发送（逐字节）、消费者宽位宽接收（整帧处理），满足随机访问需求。配合EOM（消息结束）标记，生产者可通过eom=1标识消息边界，基础设施确保跨位宽转换时EOM仅出现在末位元素（如喷嘴模式中消费者读取整帧时置位），解决了可变长消息的边界同步问题。
针对RTL验证的时序挑战，管道引入时钟绑定机制：传统管道在状态机中可能因异步唤醒引发时序失配，而时钟管道（如scemi_input_pipe #(..., .IS_CLOCKED_INTF=1) input_pipe(clock);）通过绑定时钟信号，使receive/send操作严格同步于时钟边沿。如图4.11/4.12所示，该机制可直接集成到RTL状态机，避免非阻塞轮询（try_receive）的复杂性，确保周期精确的事务处理。例如在以太网帧传输中，C端可逐字节发送可变长帧（eom标记帧尾），HDL端通过时钟管道整帧接收并处理，实现软件模型（非时序）与RTL模型（周期精确）的无缝桥接。
实现层面，管道采用分层架构：用户层提供阻塞式send/receive等易用接口，基础设施层则提供线程中立的回调函数，支持适配SystemC等多线程环境。其参考实现可基于DPI函数构建，确保跨平台一致性；优化实现则允许厂商针对硬件加速器深度定制批处理与并发传输。需注意的是，基础设施不防范应用层死锁（如HDL等待空管道但C端未发送数据），且所有实现必须严格遵循标准语义以保证行为确定性。典型应用包括流式数据传输（如文件流注入）和混合抽象层桥接，通过动态缓冲深度优化流式场景，显式指定深度满足FIFO需求，成为复杂SoC验证中连接事务级测试平台与RTL DUT的核心基础设施。