自研的regression脚本yrun都有哪些东西呢？

yrun是处芯积律自研的regression脚本，yrun都有哪些东西呢？

1.通过 cmpfile 将不同版本的compile需求集中管理

2. 通过 testfile 将test集中起来管理。

3.可以通过 yrun 跑 testfile里面的test 的regression

yrun -testfile soc_test

4. 可以通过ycheck 检查 历史regression的状态

中间状态

跑完状态

更多内容！请看下面项目介绍

SOC3.0 项目都有哪些东西：

模块升级

SOC V3.0在2.0项目的基础上增加了Jtag、iCache、CNN 和PWM模块。

Jtag：

Jtag是联合测试工作组（Joint Test Action Group）的简称，目前最主要用在集成电路的测试，也可以通过JTAG结合DM(Debug Module) 实现芯片的调试，为软件开发者提供了一个芯片内部的后门。

Jtag 状态机

DM（Debug module）：

DM 称为调试模块，该电路集成在芯片内部，方便开发者编程、调试、异常处理等功能，已经是芯片不可或缺的电路。

下图是RISCV的debug module。

上述JTAG和DM在我们SOC V3.0里面已经集成。

以下是我们在环境中跑的test的部分波形：

CNN：

CNN是Convolutional neural network (CNN)的简称，在图像识别、语音识别、大语言模型中广泛的使用。

CNN的应用

典型的CNN结构由卷积层、池化层、连接层组成。

典型的CNN网络

在我们的SOC V3.0里面，我们集成了一个简单的CNN网络。

其中包含卷积运算、池化运算、线性运算。

卷积运算

PWM：

PWM是Pulse Width Modulation的简称，在灯光调节、电机控制等各个领域有广泛的应用。

PWM控制不同占空比

在我们SOC V3.0中，我们集成了PWM模块。

下面是我们PWM模块跑出来的波形。

工具升级

在SOC V3.0的环境上，我们研发了yrun 、ycheck、ygpt 等脚本工具。

yrun：

yrun支持跑编译、仿真、回归等多个功能。

详细功能介绍：

简洁的test 添加机制；

simulation和compile 分开管理；

支持只编译模式；

支持只simulation模式；

支持特定的 test list的 regression；

支持同时跑不同的regression；

支持 simulation 进行时在终端上打印log；

支持simulation 在后台运行；

支持特定 test list 中 特定test的 simulation；

支持 fail test的rerun机制；

支持中间查看特定regression的运行状态；

支持将regression的结果通过mail的方式发给指定的用户；

支持将regression的fail test的error 显示在regression的结果中；

支持用户定义FPGA simulation，Gate lever simulation，UPF simulation等。

在SOC V3.0里面，我们提供了yrun使用的demo，用户可以根据自己的需要将yrun应用到自己的IP和SOC验证环境中。

注意！！！ 在我们提供的demo里面，yrun的源代码是提供给大家的。SOC V3.0验证环境里面的yrun由于做了更多的开发，我们对部分代码进行了加密处理。

ycheck： ycheck 是用于检查regression的状态使用。

使用方法如下：

ygpt： ygpt是将GPT引入到芯片的研发中，通过GPT读取代码，用户可以根据自己需求向GPT获取信息。例如：制定 testplan，写 testbench 等等。

下面是ygpt 使用的案例：

验证环境升级

目前我们SOC V3.0 包含了 :

基于UVM的IP验证方法学

基于C的SOC验证方法学

基于UVM的SOC验证方法学

基于Formal的验证方法学

下面我们详细介绍: 基于UVM的IP验证方法学 在我们日常的IP验证中，IP分为10大类，他们是:

处理器IP：包括中央处理器（CPU）和图形处理器（GPU。

通信IP：如USB、Ethernet、PCI Express等。

存储IP：如存储控制器、闪存控制器等。

数字信号处理IP：如图像处理等。

模拟IP：如模拟-数字转换器（ADC）和数字-模拟转换器（DAC）等。

安全IP：如加密引擎、随机数生成器等。

电源管理IP：包括用于管理电源和能效的电源管理单元。

时钟IP：包括时钟生成器和分配网络，用于同步和时序控制。

外设IP：包括各种外设，如UART、SPI、I2C等，用于与其他设备进行通信。

自定义IP：一些芯片制造商或设计团队可能会开发自定义的IP。

在这些IP里面，我们根据验证采用的不同策略可以将其归为四大类:

第一类 : 协议类IP，如USB，UART，时钟IP等;

第二类 : 算法类IP，如ISP，CNN等;

第三类 : 处理器IP，如CPU，GPU等;

第四类 : 模拟IP，如ADC，DAC等。

在我们SOC V3.0 项目中，我们开发了协议类IP的验证环境和算法类IP的验证环境。

协议类IP 验证环境—QSPI

QSPI 采用UVM验证即可，其验证框架如下

QSPI验证环境

QSPI 验证环境包括APB Agent，Register Model，Register Adapter, QSPI Scoreboard，QSPI Monitor，Sequencer 等。

算法类IP 验证环境—ISP

ISP 采用UVM+C的验证方式，UVM和C的交互有多种方式，在ISP环境中，我们选择将C编译成可执行文件，然后通过UVM环境调用可执行文件生成带有预期的数据的txt文件，UVM 环境通过读取预期数据的txt文件与观测到值进行比对，从而判断设计的正确性。

ISP验证环境

算法类IP 验证环境—CNN

CNN也是采用UVM+C的验证方式，不同于ISP，在CNN环境中，我们采用DPI的方式调用C文件，scorboard在拿到观测数据之后，直接通过DPI 调用 C函数获取预期的值。

CNN验证环境

基于C的SOC验证方法学

SOC环境集成了CPU，为了让CPU能够跑起来，一个简单的做法是让CPU直接吃指令执行，但是纯粹的机器指令可读性很差。采用C写test，然后用工具链编译成机器指令给CPU执行是一种常规的操作。 在SOC V3.0中，我们提供基于C的SOC验证环境。



基于C的SOC验证环境 我们提供了包括UART，I2C，SPI，CNN，ISP在内的诸多IP的C test。用户可以通过仿真了解C的编译和执行过程，对芯片的运行有个更加系统的理解。

基于UVM的SOC验证方法学

在SOC环境中，采用C生成机器码让CPU执行的过程会占用大量的仿真时间，特别是一些复杂的大芯片，另外考虑到IP验证环境开发过类似的test，很多公司希望在SOC环境中能够复用这些test，那么一套基于UVM的SOC验证环境就非常有必要。

在我们SOC V3.0环境中，我们集成了基于UVM的SOC验证环境，用户在拿到我们代码后，可以通过仿真了解了UVM是和如何SOC协同完成SOC验证。



基于UVM的SOC验证环境

基于Formal的验证方法学

采用simulation 只能打到部分的场景，这个过程不免有些bug遗漏。基于数学推算的Formal 可以完美的解决这个问题。



在我们SOC V3.0中我们集成了一个基本的Formal验证环境，方便大家理解Formal验证的思想。

完善设计流程

芯片的前端设计涉及到语法检查，综合以及形式验证。在SOC V3.0 里面，我们提供了语法检查，综合以及形式验证的脚本及相关的工艺库文件。

综合过程

形式验证

我们还做了哪些事情？

除上述之外，我们还在SOC V3.0中集成了SOC V1.1的改动:

补全了I2C_DEV 和UART_DEV；

2. 实现C代码中字符串打印；

3. 完善的QSPI验证计划，验证用例和coverage数据；

4. 提供了QSPI 和CNN的问题代码，让大家在debug中理解项目。

审核编辑：刘清