仿真验证中的聚合仿真浅谈

关于仿真，最传统的仿真莫过于写Testbench，写纯粹的时序激励，也不分离行为，这种不易维护，也不易复用；经过长时间演化，则有参数化验证形式，可以初步对同类似的Testbench进行合并；后面结合PLI出现，使得Verilog可以被C++的OOP特性驱动，逐步改进，使其可以实现各种OOP的工厂模式；逐步OOP被引入verilog形成和C++一样被吐槽的不伦不类的SystemVerilog。

SystemVerilog的引入，使得分离硬件设计的仿真的功能点得到精细的划分，出现序列生成模块(Sequence)，接口驱动模块(Interface Driver)和接口监视模块(Interface Monitor)；随着设计结构的复杂化，接口驱动模块又出现了新的划分，形成序列接收缓存(Sequencer)、序列驱动(Sequence Driver)和接口时序模块(Interface)；接着UVM或者它的前驱者之类的出现，给这些特定做出相应的API接口，这些接口使用起来似乎不如纯软件模式下易于理解，也可能本身就不是从软件角度考量，伴随着设计复杂化，对于功能也出现类似于软件设计标准的高内聚低耦合的特点，出现了模块(Agent)，模块的出现实际上也就是对原来的Interface Driver和Interface Monitor进行了重新整合，形成新的结构，同时对于原来的混叠做出了细小化分离。

针对稍微复杂模块，比如I2C，对于它的规范上描述，它是一个单层协议，但从实际工程角度，它是一个两层协议，我姑且命名为寄存器传输层和物理协议层；一般单层协议，Sequence-Sequencer-Driver模式是完全满足的，那么多出的一层该在哪个组件插入，事实上也属于序列的一部分，也是在Sequence端插入，但是这样会导致Sequence的设计目的不明确，或者如果出现基于IIC上我做其他层，则一，不可以直接利用，二代码设计会变得混叠；如此出现layer sequence的做法，但我认为这达不到理想的高内聚；我认为，可以做如此方式的改动，原本的Seuence-Squencer-Driver是否可以重新审视，基于二层协议，我是否可以认为一层之下只是个Driver，这样实现Driver内嵌Agent，有多少层协议，就多少层的内嵌，若想抽离基于那一层做二次开发，工程量上也是相对容易的。

上述只是简单聊了一下UVM目前模式，针对于本文只是一个基础而已，本文所阐述的聚合仿真，需要以通信为基础，诸如现在UVM支持的tlm1.0，它可以实现组件间的通信，但是缺点是SystemVerilog自身语言的局限性，它无法支持socket，当然也可以通过PLI来接入C Socket，但是在我使用过程中，这种方式体验非常差；而在TLM2.0时代，通过Socket与SystemC通信有着卓越的发展，由此可实现新的仿真方式，类似于数据中心和边缘设备的关系，针对于一个超大型Soc，我们可以基于他们基本元件使得基础性仿真依托于各个设备节点，可能使用Simulator，也可能使用Emulator，然后构造在一个足够抽象的中心仿真器Centerlator，实现高通量复杂仿真，针对于仿真逻辑耗时由边缘仿真器承担时损，并且终端越多，时损越小，Centerlator只要有足够性能，一定可以加速到仿真速度的饱和度，也就是单个边缘设备独自仿真时间，形成最大板效率。

【免责声明】：本站部分文章为转载或网友发布，目的在于传递和分享信息，并不代表本网赞同其观点和对其真实性负责；文章版权归原作者及原出处所有，如涉及作品内容、版权和其它问题，我们将根据著作权人的要求，第一时间更正或删除。