软硬件协同仿真和验证的标准接口协议SCE-MI简介

最近看到一个比较有意思的东西,深入了解了一下,记录分享一下。软硬件协同仿真验证,就是将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 proxyMapchandle)将作用域与代理对象绑定,实现事务的定向分发。

基于函数接口的​​核心优势​​在于其标准化和零时间事务特性:基于成熟的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的核心基础设施。

相关推荐
仲南音17 小时前
Xilinx FPGA——时钟IP核MMCM、PLL
fpga开发
I'm a winner1 天前
基于Xilinx FPGA的LVDS高速串行通信系统(三)--数据训练及握手机制【文末源码】
fpga开发
upper20201 天前
coremark移植坑之-nostartfiles -nostdlib参数
学习·fpga开发·coremark移植·riscv设计
Eloudy2 天前
Vivado 纯命令行构建 FPGA 项目教程
fpga开发
Rambo.xia2 天前
AXI跨时钟域与数据一致性——CDC FIFO深度不够、写后读冒险、多Master仲裁、乱序返回,出了Bug根本查不出来
fpga开发·bug
upper20202 天前
FPGA部署卷积神经网络识别MINST图片
fpga开发·卷积神经网络·minst·minst识别·部署神经网络·神经网络识别图片
你是我的解忧王子2 天前
嵌入式 ADC采样 原始数据分析上层(平均值 波动率 正态分布 线性补偿 系统误差)
fpga开发·数据挖掘·数据分析
9527华安3 天前
FPGA纯verilog代码ISP图像处理培训教程,基于IMX214,提供工程源码+视频教程+FPGA开发板
图像处理·fpga开发·isp·imx214·mipi
千寻xun3 天前
二、实战篇-NVME SSD控制之ZYNQ实现(六)-读写NVME SSD硬盘数据
fpga开发·nvme·nvme ssd
千寻xun3 天前
二、实战篇-NVME SSD控制之ZYNQ实现(三)
fpga开发·nvme ssd·nvme协议