网站首页  英汉词典  古诗文  美食菜谱  电子书下载

请输入您要查询的图书:

 

书名 芯片验证漫游指南(从系统理论到UVM的验证全视界)
分类 科学技术-工业科技-电子通讯
作者 刘斌
出版社 电子工业出版社
下载 抱歉,不提供下载,请购买正版图书。
简介
编辑推荐

《芯片验证漫游指南:从系统理论到UVM的验证全视界》适用于高校集成电路相关专业学生使用,可以作为芯片验证课程的教材,也适用于验证人员提高自身能力学习之用。

作者简介

刘斌(路桑)目前是Intel公司的资深验证专家。在Intel移动通信事业部主持验证架构规划和方法学研究,担任过几款亿门级通信芯片的验证经理角色。在工程领域之外,他在西安电子科技大学和西安交通大学客座讲授芯片验证课程。创办的验证技术订阅号“路科验证”,目前已有超过10000名的订阅者。多次在设计验证行业国际会议和展览中发表论文,并做了富有特色的演讲。在西安交通大学取得微电子专业学士学位,在瑞典皇家理工学院取得芯片设计专业硕士学位。

内容简介

资深验证专家刘斌(路桑)向您全面介绍芯片验证,从验证的理论,到SystemVerilog语言和UVM验证方法学,再到高级验证项目话题。这本综合性、实用性的验证理论和编程方面的图书,针对芯片验证领域不同级别的验证工程师,给出由浅入深的技术指南:学习验证理论来认识验证流程和标准,学习SystemVerilog语言和UVM方法学来掌握目前主流的动态验证技术,了解高级验证话题在今后遇到相关问题时可以参考。

目录

第1章 芯片验证全视

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 事务传输

精彩书摘

package更多的意义在于将软件(类、类型、方法等)封装在不同的命名空间中,以此来与全局的命名空间进行隔离。package可以容纳各种数据、方法和类的定义。

library是编译的产物,在没有介绍软件之前,硬件(module、interface、program)都会编译到库中,不指定编译库则被编译进默认的库中。从容纳的类型看,库既可以容纳硬件类型也可以容纳软件类型,例如类和方法,包括package。

从上面的联系来看,不同package之间可能存在同名的类,不同library之间也可能存在同名的moduie(硬件)或package(软件)。如果上面的例子在不同package中遇到同名的类,可以通过“::”显式调用具体的类;如果遇到的是不同library中的同名的module或package等,怎么解决呢?常见的方式是通过HDL语言的config文件(VHDL、Verilog、SV均有该特性)指定具体模块从哪个library中选取。默认情况下采取“就近原则”,即调用该重名模块的上层模块位于哪个library,仿真器优先从该library中寻找调用模块。这个原则也适用于package,即使用该重名package的module或interface优先寻找它们所在的library。如果想让其优先搜寻其他的库,要在config文件中指定要寻找的库名和顺序。

前言/序言

序(一)

近年来,我国集成电路(IC)产业高速蓬勃发展,与发达国家的技术差距不断缩小。国家集成电路产业基金起到了积极的推动作用。产业基金的第二期将重点投资在集成电路设计领域,预计规模有望达2000亿元。设计领域的投入,将会围绕人工智能、物联网、5G通信、智能汽车、智能电网等国家战略和新兴行业,创造出科技含量更高、能够实现进口替代的高端集成电路芯片。

在这一时代背景下,我国集成电路企业正呈现出数量和规模迅速增长、竞争日趋激烈的态势。在大量资本投入的背景下,企业对IC设计工程型专业人才的需求非常迫切,形成了巨大的人才需求缺口。需求差距表现在两个方面,一方面高校每年毕业的IC设计人才无法满足数量需求。另一方面,毕业生的专业IC技能与企业的实际需求也存在一定欠缺。因此,为了全面推动创新型复合IC工程人才的培养,作为人才培养主力军的高校和集成电路企业之间就需要进行资源共享与深度产学合作,共同推动我国IC人才培养质量的提升。

在产学合作方面,十多年来西安电子科技大学微电子学院通过与英特尔等行业骨干企业的密切合作,积累了丰富的经验,在合作机制、课程体系、教学方法等方面形成了鲜明的特色,为IC创新人才培养奠定了坚实的基础。2015年,微电子学院与本书作者及其所在的英特尔公司携手开展IC教学内容改革与协同育人的产学合作项目,邀请作者到我院客座讲授集成电路芯片验证课程,并在课程结束后优选学生到英特尔和其他众多国内高端IC公司参加实习,进行项目实践并完成工程论文。可以说,将企业实践经验引入教学体系,搭建起良好的产学协同育人平台,使得我院学生在知识体系和实践能力方面获得了显著提升,大大提升了我院人才培养的行业适应度和满意度。我院与英特尔公司建立的研究生培养基地被评为2017年度全国专业学位研究生培养示范基地。

在与作者交流时,得知作者计划将此书作为IC验证工程类教材,我感到非常高兴。我校已经和作者达成一致,将这三年以来逐渐打磨完善的芯片验证课程推广至中国大学慕课(MOOC)在线教育平台,将合作多年形成的优秀工程实践课程成果与全国其他高校分享,共同推进我国IC专业人才培养质量的提升和教学模式改革创新。

作者一直工作在企业研发的一线,是国际IC行业领导者英特尔公司的资深验证专家,具有丰富的工程经验,深知目前IC验证人才所需的知识与能力要求。同时,作者在我校和西安交通大学客座讲授芯片验证课程多年,对验证理论有很深的理解。因此,我相信本书将会成为集成电路验证理论与实践高度融合的不可多得的著作。作者能够坚持多年在我校开展芯片验证工程教学,在校企合作培养集成电路工程型人才中起到带头示范作用,在此我对作者长期致力于产学结合推动高校教育事业的奉献精神表示由衷的感谢与敬意。

在本书出版前夕,我应邀为本书作序,感到非常荣幸。希望本书能为我国集成电路行业的创新型工程人才培养发挥重要的促进作用;希望作者进一步将本书和芯片验证课程向全国推广,为中国集成电路人才培养贡献更大的力量。

张进成    

教育部长江学者特聘教授    

西安电子科技大学微电子学院副院长

序(二)

数字集成系统的验证,是提高设计芯片一次流片成功的关键。验证工作与设计仿真工作不同,仿真的目的是证明设计方案的正确性,用仿真的方法证明设计方案符合拟定的设计规范;验证工作则是证明设计方案中不存在错误。理想情况下,存在任何设计错误的方案都不应该进入流片,换句话说,进入流片环节的设计方案中不应该存在已知错误。验证过程的目标就是找出设计方案中可能存在的错误。

设计错误很容易造成芯片完全不能工作,而修正错误重新流片不但需要投入额外的费用,更会大大推迟将芯片上市时间,这些风险对于芯片产品的开发来说都是不可接受的。随着芯片制造工艺的更加精细,芯片制造费用的不断增加,芯片功能越来越复杂,验证的重要性也日益增加。

本书作者2010年在瑞典皇家理工学院毕业后,一直从事芯片验证工作,本书是其多年实际工作经验的结晶。全书的内容涉及验证方法及流程设计,也涉及常用数字单元的验证经验。相信本书的内容有益于高等学校数字集成系统设计的高年级学生和研究生的学习,有益于集成电路领域从事数字系统设计的工程师的工作,更有益于直接从事集成电路验证工作的工程技术人员的工作。

中国集成电路产业的发展,正在进入新的高速发展阶段。相信本书的出版定会给集成电路设计行业带来新的知识、成熟的经验,为行业的发展带来新的动力。

王志华         

清华大学教授,IEEE Fellow

2018年3月于清华园  

随便看

 

Fahrenheit英汉词典电子书栏目提供海量电子书在线免费阅读及下载。

 

Copyright © 2002-2024 frnht.com All Rights Reserved
更新时间:2025/11/24 6:39:38