描述
开 本: 16开纸 张: 胶版纸包 装: 平装-胶订是否套装: 否国际标准书号ISBN: 9787121339011
1.1 功能验证简介
1.2 验证的处境
1.2.1 验证语言的发展
1.2.2 验证面临的挑战
1.3 验证能力的5个维度
1.3.1 完备性
1.3.2 复用性
1.3.3 高效性
1.3.4 高产出
1.3.5 代码性能
1.4 验证的任务和目标
1.4.1 按时保质低耗
1.4.2 芯片研发与客户反馈
1.4.3 缺陷增长曲线
1.5 验证的周期
1.5.1 验证周期中的检查点
1.5.2 功能详述
1.5.3 制定验证计划
1.5.4 开发验证环境
1.5.5 调试环境和HDL文件
1.5.6 回归测试
1.5.7 芯片生产
1.5.8 硅后系统测试
1.5.9 逃逸分析
1.6 本章结束语
第2章 验证的策略
2.1 设计的流程
2.1.1 TLM模型的需求和ESL开发
2.1.2 传统的系统设计流程
2.1.3 ESL系统设计流程
2.1.4 语言的抽象级比较
2.1.5 传统的系统集成视角
2.1.6 ESL系统集成视角
2.2 验证的层次
2.2.1 模块级
2.2.2 子系统级
2.2.3 芯片系统级
2.2.4 硅后系统级
2.3 验证的透明度
2.3.1 黑盒验证
2.3.2 白盒验证
2.3.3 灰盒验证
2.4 激励的原则
2.4.1 接口类型
2.4.2 序列颗粒度
2.4.3 可控性
2.4.4 组件独立性
2.4.5 组合自由度
2.5 检查的方法
2.6 集成的环境
2.6.1 验证平台
2.6.2 待验设计
2.6.3 运行环境
2.6.4 验证管理
2.7 本章结束语
第3章 验证的方法
3.1 动态仿真
3.1.1 定向测试
3.1.2 随机测试
3.1.3 基于覆盖率驱动的随机验证
3.1.4 基于TLM的随机验证
3.1.5 断言检查
3.2 静态检查
3.2.1 语法检查
3.2.2 语义检查
3.2.3 跨时钟域检查
3.2.4 形式验证
3.3 开发环境
3.3.1 Vim开发环境
3.3.2 商业SV开发环境——DVT
3.4 虚拟模型
3.5 硬件加速
3.6 效能验证
3.6.1 功率和能量
3.6.2 静态功耗和动态功耗
3.6.3 节能技术
3.6.4 效能验证
3.6.5 功耗预测与优化
3.7 性能验证
3.7.1 设定目标
3.7.2 测试环境
3.7.3 验证方法
3.8 趋势展望
3.8.1 技术之间的横向跨越
3.8.2 层次之间的纵向复用
3.9 本章结束语
第4章 验证的计划
4.1 计划概述
4.2 计划的内容
4.2.1 技术的视角
4.2.2 项目的视角
4.3 计划的实现
4.3.1 邀请相关人员
4.3.2 开会讨论
4.3.3 确定测试场景
4.3.4 创建验证环境
4.4 计划的进程评估
4.4.1 回归测试通过率
4.4.2 代码覆盖率
4.4.3 断言覆盖率
4.4.4 功能覆盖率
4.4.5 缺陷曲线
4.5 本章结束语
第5章 验证的管理
5.1 验证周期的检查清单
5.2 验证管理的三要素
5.2.1 时间管理
5.2.2 人力资源安排
5.2.3 任务拆分和重组
5.3 验证的收敛
5.3.1 回归流程
5.3.2 回归质量
5.3.3 回归效率
5.4 让漏洞无处可逃
5.5 团队建设
5.6 验证师的培养
5.6.1 全硅能力
5.6.2 不做假设
5.6.3 专注力
5.6.4 逻辑性
5.6.5 “战鼓光环”
5.6.6 降低复杂度
5.7 验证的专业化
5.7.1 对验证的偏见
5.7.2 验证面临的现状
5.7.3 验证标准化
5.7.4 验证经验的积累和突破
5.8 本章结束语
第6章 验证的结构
6.1 测试平台概述
6.2 硬件设计描述
6.2.1 功能描述
6.2.2 设计结构
6.2.3 接口描述
6.2.4 接口时序
6.2.5 寄存器描述
6.3 激励发生器
6.4 监测器
6.5 比较器
6.6 验证结构
6.6.1 项目背景
6.6.2 MCDF验证进度安排
6.7 本章结束语
第7章 SV环境构建
7.1 数据类型
7.2 模块定义与例化
7.2.1 模块定义
7.2.2 模块例化
7.2.3 参数使用
7.2.4 参数修改
7.2.5 宏定义
7.3 接口
7.3.1 接口连接方式1
7.3.2 接口连接方式2
7.3.3 接口的其他应用
7.4 程序和模块
7.4.1 Verilog设计竞争问题
7.4.2 SV的仿真调度机制
7.4.3 module数据采样示例1
7.4.4 module数据采样示例2
7.4.5 program数据采样示例
7.5 测试的始终
7.5.1 系统函数调用方式结束
7.5.2 program隐式结束
7.5.3 program显式结束
7.6 本章结束语
第8章 SV组件实现
8.1 激励发生器的驱动
8.1.1 激励驱动的方法
8.1.2 任务和函数
8.1.3 数据生命周期
8.1.4 通过接口驱动
8.1.5 测试向量产生
8.1.6 仿真结束控制
8.2 激励发生器的封装
8.2.1 类的封装
8.2.2 类的继承
8.2.3 成员覆盖
8.2.4 虚方法
8.2.5 句柄使用
8.2.6 对象复制
8.2.7 对象回收
8.3 激励发生器的随机化
8.3.1 可随机的激励种类
8.3.2 约束求解器
8.3.3 随机变量和数组
8.3.4 约束块
8.3.5 随机化控制
8.3.6 随机化的稳定性
8.3.7 随机化的流程控制
8.3.8 随机化的系统函数
8.4 监测器的采样
8.4.1 Interface clocking简介
8.4.2 利用clocking事件同步
8.4.3 利用clocking采样数据
8.4.4 利用clocking产生激励
8.4.5 monitor的采样功能
8.5 组件间的通信
8.5.1 通知的需求
8.5.2 资源共享的需求
8.5.3 数据通信的需求
8.5.4 进程同步的需求
8.5.5 进程通信要素的比较和应用
8.6 比较器和参考模型
8.6.1 异常检查
8.6.2 常规检查
8.6.3 时序检查
8.6.4 组件连接
8.7 测试环境的报告规范
8.7.1 信息报告库
8.7.2 信息库使用场景
8.8 本章结束语
第9章 SV系统集成
9.1 包的意义
9.2 验证环境的组装
9.2.1 封装验证环境的方式
9.2.2 模块环境的复用考量
9.2.3 比较器的复用考量
9.2.4 顶层环境的实现
9.3 测试场景的生成
9.3.1 动态控制激励
9.3.2 调度多个激励器
9.3.3 线程的精细控制
9.3.4 动态测试向量
9.3.5 向量群落的并发控制
9.4 灵活化的配置
9.4.1 Agent的两面性
9.4.2 各个组件的模式配置
9.4.3 验证结构的集成顺序
9.5 初论环境的复用性
9.5.1 复用的策略
9.5.2 水平复用的应用
9.5.3 垂直复用的应用
9.6 本章结束语
第10章 UVM世界观
10.1 我们所处的验证时代
10.2 类库地图
10.3 工厂机制
10.3.1 工厂的意义
10.3.2 工厂提供的便利
10.3.3 覆盖方法
10.3.4 确保正确覆盖的代码要求
10.4 核心基类
10.4.1 域的自动化
10.4.2 复制
10.4.3 比较
10.4.4 打印
10.4.5 打包和解包
10.5 phase机制
10.5.1 phase执行机制
10.5.2 如何开始UVM仿真
10.5.3 如何结束UVM仿真
10.6 config机制
10.6.1 interface传递
10.6.2 变量设置
10.6.3 config object传递
10.6.4 config机制
10.6.5 其他配置方法
10.6.6 uvm_resource_db的使用
10.7 消息管理
10.7.1 消息方法
10.7.2 消息处理
10.7.3 消息机制
10.8 宏的优劣探讨
10.9 本章结束语
第11章 UVM结构
11.1 组件家族
11.1.1 uvm_driver
11.1.2 uvm_monitor
11.1.3 uvm_sequencer
11.1.4 uvm_agent
11.1.5 uvm_scoreboard
11.1.6 uvm_env
11.1.7 uvm_test
11.2 把DUT装进TB分几步
11.2.1 MCDF顶层验证环境方案1
11.2.2 MCDF顶层验证环境方案2
11.3 构建环境的内经
11.3.1 环境构建的四要素
11.3.2 环境元素分类
11.4 本章结束语
第12章 UVM通信
12.1 TLM通信概论
12.2 单向、双向及多向通信
12.2.1 单向通信
12.2.2 双向通信
12.2.3 多向通信
12.3 通信管道应用
12.3.1 TLM FIFO
12.3.2 Analysis Port
12.3.3 Analysis TLM FIFO
12.3.4 Request ＆ Response 通信
管道
12.4 TLM2通信
12.4.1 接口实现
12.4.2 传送数据
12.4.3 时间标记
12.4.4 典型使用
12.5 同步通信元件
12.5.1 uvm_event应用
12.5.2 uvm_barrier应用
12.5.3 uvm_callback应用
12.6 本章结束语
第13章 UVM序列
13.1 新手上路
13.2 Sequence和Item
13.2.1 Sequence Item
13.2.2 Flat Sequence
13.2.3 Hierarchical Sequence
13.3 Sequencer和Driver
13.3.1 双方的TLM端口和方法
13.3.2 事务传输
近年来，我国集成电路（IC）产业高速蓬勃发展，与发达国家的技术差距不断缩小。国家集成电路产业基金起到了积极的推动作用。产业基金的第二期将重点投资在集成电路设计领域，预计规模有望达2000亿元。设计领域的投入，将会围绕人工智能、物联网、5G通信、智能汽车、智能电网等国家战略和新兴行业，创造出科技含量更高、能够实现进口替代的高端集成电路芯片。
在这一时代背景下，我国集成电路企业正呈现出数量和规模迅速增长、竞争日趋激烈的态势。在大量资本投入的背景下，企业对IC设计工程型专业人才的需求非常迫切，形成了巨大的人才需求缺口。需求差距表现在两个方面，一方面高校每年毕业的IC设计人才无法满足数量需求。另一方面，毕业生的专业IC技能与企业的实际需求也存在一定欠缺。因此，为了全面推动创新型复合IC工程人才的培养，作为人才培养主力军的高校和集成电路企业之间就需要进行资源共享与深度产学合作，共同推动我国IC人才培养质量的提升。
在产学合作方面，十多年来西安电子科技大学微电子学院通过与英特尔等行业骨干企业的密切合作，积累了丰富的经验，在合作机制、课程体系、教学方法等方面形成了鲜明的特色，为IC创新人才培养奠定了坚实的基础。2015年，微电子学院与本书作者及其所在的英特尔公司携手开展IC教学内容改革与协同育人的产学合作项目，邀请作者到我院客座讲授集成电路芯片验证课程，并在课程结束后优选学生到英特尔和其他众多国内高端IC公司参加实习，进行项目实践并完成工程论文。可以说，将企业实践经验引入教学体系，搭建起良好的产学协同育人平台，使得我院学生在知识体系和实践能力方面获得了显著提升，大大提升了我院人才培养的行业适应度和满意度。我院与英特尔公司建立的研究生培养基地被评为2017年度全国专业学位研究生培养示范基地。
在与作者交流时，得知作者计划将此书作为IC验证工程类教材，我感到非常高兴。我校已经和作者达成一致，将这三年以来逐渐打磨完善的芯片验证课程推广至中国大学慕课（MOOC）在线教育平台，将合作多年形成的优秀工程实践课程成果与全国其他高校分享，共同推进我国IC专业人才培养质量的提升和教学模式改革创新。
作者一直工作在企业研发的一线，是国际IC行业领导者英特尔公司的资深验证专家，具有丰富的工程经验，深知目前IC验证人才所需的知识与能力要求。同时，作者在我校和西安交通大学客座讲授芯片验证课程多年，对验证理论有很深的理解。因此，我相信本书将会成为集成电路验证理论与实践高度融合的不可多得的著作。作者能够坚持多年在我校开展芯片验证工程教学，在校企合作培养集成电路工程型人才中起到带头示范作用，在此我对作者长期致力于产学结合推动高校教育事业的奉献精神表示由衷的感谢与敬意。
在本书出版前夕，我应邀为本书作序，感到非常荣幸。希望本书能为我国集成电路行业的创新型工程人才培养发挥重要的促进作用；希望作者进一步将本书和芯片验证课程向全国推广，为中国集成电路人才培养贡献更大的力量。
张进成
教育部长江学者特聘教授
西安电子科技大学微电子学院副院长
序（二）
数字集成系统的验证，是提高设计芯片一次流片成功的关键。验证工作与设计仿真工作不同，仿真的目的是证明设计方案的正确性，用仿真的方法证明设计方案符合拟定的设计规范；验证工作则是证明设计方案中不存在错误。理想情况下，存在任何设计错误的方案都不应该进入流片，换句话说，进入流片环节的设计方案中不应该存在已知错误。验证过程的目标就是找出设计方案中可能存在的错误。
设计错误很容易造成芯片完全不能工作，而修正错误重新流片不但需要投入额外的费用，更会大大推迟将芯片上市时间，这些风险对于芯片产品的开发来说都是不可接受的。随着芯片制造工艺的更加精细，芯片制造费用的不断增加，芯片功能越来越复杂，验证的重要性也日益增加。
本书作者2010年在瑞典皇家理工学院毕业后，一直从事芯片验证工作，本书是其多年实际工作经验的结晶。全书的内容涉及验证方法及流程设计，也涉及常用数字单元的验证经验。相信本书的内容有益于高等学校数字集成系统设计的高年级学生和研究生的学习，有益于集成电路领域从事数字系统设计的工程师的工作，更有益于直接从事集成电路验证工作的工程技术人员的工作。
中国集成电路产业的发展，正在进入新的高速发展阶段。相信本书的出版定会给集成电路设计行业带来新的知识、成熟的经验，为行业的发展带来新的动力。
王志华
清华大学教授，IEEE Fellow
2018年3月于清华园
前 言
在我有限的工作生涯中值得我庆幸的是，刚进入工作岗位时的第一任老板给了我选择的权利——设计岗还是验证岗？因为当时我已经在国外学习了芯片验证的相关知识，也了解了验证的相关事务，于是便选择了验证岗并一直从事到现在。与国内多数验证工程师的入职经历不同的是，我当时是有更多选择的，而选择验证岗，并不是被公司指派到了验证岗。这中间的差别在于，一家认可验证工程师贡献的公司是将验证岗位与其他岗位同等看待的，甚至由于依赖验证质量而会给予验证更多的褒奖。从这两年芯片设计行业的招聘数据来看，验证工程师与设计工程师的薪资是看齐的。尽管验证工程师的春天已经到来，不过我们还需要在芯片设计产业链上制定自己的从业标准，提高验证工程师的从业形象，继而才能摆脱多年以来设计为主，验证为辅的陈旧思想。
参考清华大学魏少军教授在2017年SEMICON大会上的讲稿内容，我国在2020年的芯片设计从业人数需求将从现有的13万人急速增长到28万人，而全国高校每年培养的各类集成电路人才还不到1万人。这中间的人才数量差距对于高校人才培养和企业用人单位都已是严峻的问题。在这么大的人才资源挑战面前，2015年国家教育部发布了关于支持有关高校建设示范性微电子学院的通知，其中包括9所高校建设示范性微电子学院，17所高校筹备建设示范性微电子学院。在提高教学质量、扩充从业人才的同时，该通知要求加快培养集成电路产业急需的工程型人才，建立学院新型用人机制，鼓励教师潜心育人并主动开展产学合作，聘请一定比例的企业专家授课或担任指导教师，引进国外高水平专家，建立一支由专职教师、企业专家和兼职教师组成的师资队伍，推动示范性微电子学院国际化发展。
同样也是在2015年春季，我应西安交通大学微电子学院梁峰教授的邀请，为集成电路专业的硕士研究生开设了“SoC系统验证”英文课程。同年，应西安电子科技大学微电子学院史江义教授的邀请，为集成电路专业的硕士研究生开设了“SystemVerilog芯片验证”课程，到现在已然度过三个春秋。随着课程内容体系的不断打磨完善，以及每学期上百人的课程反馈，院方和学生都一致认为应该将这门课推广到全国。因此在本书出版的同时，我也在积极同西安电子科技大学微电子学院对接，希望通过结合验证课程和本书的出版，在不久的将来通过中国大学MOOC（慕课）网可以让更多集成电路相关专业的学生了解验证的知识，扩大产学结合的影响。让更多在校学生能够接触主流的芯片验证知识，同时也使得芯片设计企业可以获得具备相关技能的人才，达到校企双赢的目的。
响应国家集成电路产业战略是IC从业者的幸事。在与高校展开校企合作的不久，我于2016年春季开始计划将验证课程做成精品课程，从高校教育出发来影响芯片行业对验证岗位的认识，并且为企业输送合格的工程类人才。为了配合这一计划，我创办了“路科验证”的技术订阅号。我创办这个订阅号的初衷一方面是为了督促自己能够定期地输出文章，另外一方面也是可以从验证技术文章中早一点获得读者的反馈来修正本书内容。在2017年夏季，本书的所有内容完成，有赖于张国强先生的引荐，我得以与电子工业出版社签订著作出版合同。不过与计划有点出入的是，此书原本是计划在2017年秋季面市的，这可以为我的学生们提供配套的验证课程教材，也是为了给我的女儿大蒙庆祝生日。结果由于企业项目的压力和对出版过程的乐观估计，一直将此书延迟到了2018年的春季，以至于我的二女儿小蒙已然半岁了。
路科验证订阅号在2017年秋季校招期间发布了一篇文章——《面对这份2017年的IC应届薪资表，我真想再毕业一次！》，引起了验证从业人员的广泛评论和转载。这篇文章也让即将从事验证的大学生们认识到国内IC行业的朝阳形势。我相信，只有正确引导大学生对验证的认识，才可能在未来让这些从事IC行业的精英们将验证的重要性铭记在心，而不论他们将来进入设计岗位、验证岗位又或者是项目管理等其他岗位。
面对日益复杂的芯片系统设计和IP的高度集成方式，验证的重要性日益突出。验证工程师们不再仅仅掌握某一种工具或者某一种语言就可以确保芯片的功能正确。他们需要掌握多种工具和多种语言，并且在项目环节中需要选择合适的工具和方法才有可能满足紧张的项目节点和复杂的设计功能要求。同时，功能正确也不再是芯片的唯一指标，在移动化时代，芯片的低功耗和高性能两大要求也被摆在同样重要的地位。可以说，验证工程师即使掌握了十八般武艺，还需要将它们灵活应用，最终才能做好芯片的“守护人”，为高成本流片扫清障碍，降低流片的风险。
验证工程师的经验提高得比较快，这与他们从事于近似软件代码编写的工作性质有关。验证工程师可以通过快速训练、试错并且再纠正来提升经验。基于这一背景，近些年验证方法学一直借鉴软件开发的手段，不断地在提升验证效率。这也意味着在接下来的时间，验证行业将因为与芯片设计复杂度不断加大的效率代沟而需要不断推出新的工具、语言和方法学来提升其效率。验证岗位的知识“半衰期”要比同行业的其他岗位更短，验证工程师因此需要保持不断学习的心态来武装自己。同时对于高校毕业生，验证岗位的招聘要求也将不断提高。可以预见到是，将来的芯片设计行业需求矛盾在于，需要数量巨大的验证工程师来为芯片质量保驾护航，但日益提高的岗位技能要求又使得高校无法很好地培养验证人才。相比于设计工程师，验证工程师是更趋近于工程型的人才，因此如何能
评论
还没有评论。