多媒体类SoC项目Verification-Project-Leader工作内容介绍（讨论）

先说一下这个帖子的由来…..

之前写了一个介绍我们公司验证流程和任务的内部文档，让新带项目验证的同事学习。在给同事介绍的时候提意见\建议\问题的同事基本是“资深的加入公司不太久的同事”。我想既然这样不如把文档改成帖子发出来，让行业里的同仁们也提提意见，大家共同讨论、共同进步。

提醒：

1）
我们公司主要是多媒体视频编解码类的SoC主控芯片，我相信帖子里大部分内容是共通的，但是肯定还是有一些是特别针对某一类特殊芯片研发工作的。

2）
每个公司的版本管理工具不同，有CVS SVN GIT等等等等，我帖子里就以CVS为例

3）
每个公司做提交任务的工具不同，有LSF GridEngine等等等等，我以LSF为例

说明：

1）
帖子里的verification是说动态仿真验证，不包括FPGA和静态验证

2）
verification project leader是指的项目中验证工作的负责人

3）
project leader是指的项目的研发负责人

----------------------- 帖子内容---------------------

目的：

1）
更好的了解SoC的验证流程

2）
验证的工作很繁杂，verificationproject leader的工作内容更是琐碎，项目进展过程中verification project leader可以参考这个文档检查自己和他人的工作

按照项目的开发时间节点来介绍每个时间段要做的事情。注意：每个时间段里所列工作内容没有必然的时间先后顺序。

研发开始前的准备

1参与《MarketingRequirement Document》讨论，制定典型应用场景

2项目基本环境变量和EDA工具版本管理（很多公司使用module这个免费工具管理）

3基本脚本的移植（提交仿真、regression等核心脚本）

4组织验证人员对新模块做模块文档-Review和Testplan-Review（有可能会推迟到下一阶段做）

5新模块要做Testbench结构-Review ，确定检查机制（有可能会推迟到下一阶段做）

6个别模块可能需要做单独的模块级环境，这类模块要注意避免成为verification的bottle-neck

7安排验证人员学习IP的文档，数字IP通常需要跑IP自带的仿真环境（了解设计以及准备和系统级环境case做比对debug，设计组同事也可能会负责跑IP自带仿真环境）

8完成初版本的模块任务分割表，核心模块以及新模块要保证有安排人员，重用度极高的模块可以暂时不安排，但是分割表上不要遗漏模块

9项目如果重用度较高，要组织验证人员review上一个类似项目的 遗漏问题列表

10 如果项目要考虑带宽问题，这个阶段要开始和负责架构的同事一起准备bandwidth估算文件

11人员管理方面：如果verification人手严重不足的话，与peoplemanager讨论是否需要安排招聘或从其他项目组或其他验证组借人。

12根据资源（预估）与ProjectLeader讨论验证的schedule （我个人建议多做几个计划，一个乐观的，一个悲观，一个常规）

13如果是继承性的项目，需要确认旧项目的CVS-Tree是好的，并把旧项目的Testbench移植到新项目的CVS-Tree里

14根据项目规模安排自己的任务（这里要特别注意一下，个人推荐方案：如果项目比较大，verification project leader需要把不少精力放在参加会议讨论和项目管理上，这样不建议承担工作量太大的模块。做一些琐碎的工作比较好，一旦verification project leader发现自己精力不够用的时候，这类工作容易交给别人承担。如果项目比较小，verification project leader应该承担一个工作量比较大的模块）

项目启动但未提供第一版integration的代码

1根据soc顶层RTL来写顶层integration的文件(注意可能需要asic与fpga两个版本)

2必要的仿真模型的integration

3准备内存等CPU访问地址空间的verilog读写函数

4组织验证人员根据模块文档开始搭建各自负责模块的testbench

5组织验证人员检查算法模块的算法代码（或算法可执行文件）。有的算法模块可能没有算法模块，为了保证模块的随机验证，要与项目的Project Leader沟通由谁负责写（验证or设计or算法）

6准备soc项目的Firmware框架（注意有application和bootloader两套），汇编代码、Makefile等.

7向服务器管理员申请验证人员项目工作权限，特别申请一个icv_proj的用户。该用户只有该proj项目权限，保证文件所属正确与安全。

8创建所有验证人员共同维护的文件

提供第一版integration代码

注意：该版本是顶层集成好，包括了必要的总线拓扑和总线Slave设备，可以用来调仿真环境和基本CPU地址空间访问。

可以参考我以前写的《SetupBasic SoC TestBench Step by Step》

1安排验证人员调试cpu访问地址空间（ddr初始化要通过，这时ddr可以不用training）。

2构建mini-regression,用来检查tag

3保证简化版本的bootloader正常可用。

4解决cpu firmware打印的问题

5保证ddr等cpu访问空间的后门读写函数正确

6检查rtl模块的dummy文件，保证*ready等信号默认值不要影响其他模块仿真（提醒模块设计负责人提供各自负责模块的dummy文件）

7对于可以验证的模块开始组织仿真验证

8安排人员调试通过加速仿真的替代方案

9开始组织regression,用icv_proj账号定期跑regression

10组织function coverage/Assertionreview

11及时总结项目开发过程中的工作疏漏（不限于本阶段）

拿到基本包括所有RTL代码的版本

1部分模块应该已经基本验证完成了，组织这类模块的code coverage review

2确认哪些访存模块需要用slave-vip做特殊case.保证这些case的覆盖。

3组织验证人员分析所负责访存模块的访存行为，组织一个表格供performance monitor的同事使用

4针对典型应用进行case构造，为后面跑门仿准备。

5针对典型应用做case，供performance分析

6针对fpga上发现的rtl bug要重点分析和总结

7组织人员搭建0deley的gls环境

8保证ddr_training通过

9组织所有新增和改动大的模块的code coveragereview \ function coverage review

10验证内部组织testplancoverage review

11组织学习真实的bootloader，并准备bootloader的验证case

12与bootloader提供人员沟通仿真重点覆盖的部分，部分功能点如果仿真跑太慢要考虑是否可以简化。

13 performance case的tb performancemonitor统计结果与rtl内部的performance monitor要能对应上。performance的统计要与理论分析对应上，对应不上的要分析。

14组织写项目performancesimulation报告

15 review所有的force是否合理

16检查是否所有模块的regressioncase都提交

17不带reset端的dff的force(或$deposit)

18不check timing的cdc逻辑的dff列表

拿到第一轮regression全部跑过的RTL代码

注意：前述的review持续较长，可能会在此阶段完成

该阶段重点是regression和gls环境

该阶段部分验证人员工作量会降低很多，要及时做项目工作总结。

1 及时通知people manager哪些人员工作loading不饱满，好让peoplemanager安排其他工作和学习。

2 提供power分析的saif或vcd

3考虑到gls时间，注意想办法缩短门级仿真case

4该阶段可能有regression大量任务（可能导致机器负载过大），需要留意是否需要为Power分析的case申请特别服务器资源，避免出现Power这种长case由于“out of memory”导致crash

5 regression结果review

6继续增加case

拿到最终版本的RTL代码

备注：如果上一个版本质量足够高的话，可能有些项目可能不会有该版本。

1regression和sdf反标的gls

2可能需要提供irdrop分析的vcd

3完成项目TO review表格中验证部分

4每个模块如果有testplan未覆盖的情况要逐条说明。

5 double check rom的bootloaderscf文件

6如果有function eco要组织验证人员总结，构建有针对性的Testcase. 并要跟进ECO等价性比对结果。

7与Project Leader沟通BC和TC情况下的个别模块的最高频率是否要超过sign-off标准

8 组织验证人员做项目的验证总结

9 内部代码review

TO后到芯片返回前

1如果在前面阶段有向服务器管理员申请项目专用的计算资源，此时应该请管理员收回

2参加项目中其他team的总结会

2验证组内部总结会

3量产function pattern仿真（一直持续到SV和量产完成）

4确保项目CVS-Tree是好的

芯片返回以后

注意：看芯片实测需求，一般会有仿真任务。

1芯片如果功耗过大，可能需要再次组织reviewpower case以及重新仿真

2芯片如果performance达不到需求，可能需要再次reviewperformance case.以及重新仿真

3总结芯片测试发现的function bug，及时组织验证人员分析遗漏原因。

4芯片测试过程中如果怀疑有timing问题，可能需要构造专门的反标SDF的门级仿真case

精贴！跪谢

写的非常好！

赞原创，写的很细致很好，除了技术能力之外，组织和管理能力也是很重要的，学习了。
还想问小编几个小问题，小编目前的一个芯片project，规模有多大，大概需要多少verification engineer完成，大概需要多少时间? 先谢谢了

经验之谈，感谢分享！

请问之前写的SetupBasic SoC TestBench Step by Step在哪里呢

感谢小编分享经验

小编，上个帖子能贴下地址吗?这每个时间阶段的大致时间有划分吗