微波EDA网,见证研发工程师的成长!
首页 > 研发问答 > 微电子和IC设计 > IC验证交流 > 多媒体类SoC项目Verification-Project-Leader工作内容介绍(讨论)

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

时间:10-02 整理:3721RD 点击:

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

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


提醒:

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在哪里呢

感谢小编分享经验

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

Copyright © 2017-2020 微波EDA网 版权所有

网站地图

Top