马上注册，结交更多好友，享用更多功能，让你轻松玩转社区。
您需要 登录 才可以下载或查看，没有账号？注册
x
先说一下这个帖子的由来….. 之前写了一个介绍我们公司验证流程和任务的内部文档，让新带项目验证的同事学习。在给同事介绍的时候提意见\建议\问题的同事基本是“资深的加入公司不太久的同事”。我想既然这样不如把文档改成帖子发出来，让行业里的同仁们也提提意见，大家共同讨论、共同进步。
提醒： 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 | 
/3 
eetop公众号
创芯大讲堂
创芯人才网
发表于 2015-10-20 18:23:47
