1 Tag芯片的功能验证平台的设计黄海蓉

摘要
随着 IC 设计规模的增加，功能验证的复杂程度越来越高，各种新的验证方法
也层出不穷，如何根据不同的 IC 产品来选择适当的验证方法获取最大的工作效
率，仍然是一个值得研究的课题。仿真验证作为传统的验证方法，目前仍然是主
流的验证技术，也是本文采用的验证方法。本文的被验证对象是一个基于 Verilog
语言设计的符合 EPC Gen2 UHF RFID 接口协议的 Tag 芯片。
本文完成了具有自检查功能的 Tag 芯片的功能验证平台。使用 C/C++、
Verilog、PLI 作为验证平台的设计语言，采用 C 语言设计 Reader 模块、Tag 模块、
比较模块，而 DUV 和 Testbench 采用 Verilog 语言设计。设计两个 PLI 程序来实
现 C 与 Verilog 语言之间的通信。最后用 C 程序把这些模块连接起来，完成了 Tag
芯片的功能验证平台的搭建。
另外，论文讨论在软件 Modelsim 环境下 PLI 接口的配置问题，阐明验证平
台的验证过程和应用方法。Tag 芯片顺利通过验证平台的功能验证和后仿真，现
已在流片中。
关键字：射频识别阅读器数字标签 PLI DUV 功能验证

Abstract
With the increasement of the scale in IC design, the functional verification of the IC
design is getting more and more complex and many new verification methods have
emerged one after another. It is an important research topic to choose the appropriate
verification methods for the different IC products in order to obtain the greatest
efficiency. As the traditional verification method, Simulation is still the mainstream
technique which is used in this thesis. The DUV is a Tag chip according to EPC Gen2
UHF RFID based on Verilog. The thesis designs a verification platform to verify Tag
function based on self-test function theory and implementations. The thesis introduces
a new design method which incorporates the self-test function in the basis of
traditional functional verification method and verifies the implementation process.
The verification platform includes Reader model, Tag model, comparison model and
Testbench , of which the first three models use the C language as the design language
whereas the DUV and Testbench uses the Verilog HDL discussing the division of
function module, the connection of each model and the detailed function of each
module. Two PLI programs in PLI interface language have been designed to realize the
communication between C and Verilog language. And then a C program connects all of
these models to fulfill the establishment of the self-test verification platform.
In addition, the thesis introduces PLI application in Modelsim environment, the
verification process of the platform and the usage of it. Through the functional
verification and post-simulation, the tag chip fulfill the design requirements and now
has been taped out.
Keywords: RFID Reader Tag PLI DUV Functional Verification

目录
第一章绪论.....................................................................................................................1
1.1 验证的意义.............................................................................................................1
1.2 验证的概念.............................................................................................................1
1.3 TAG芯片介绍...........................................................................................................3
1.4 论文主要工作及章节安排.....................................................................................5
第二章 EPC GEN2 接口协议 ........................................................................................7
2.1 标签选择、盘存和访问 .........................................................................................7

2.2 R=>T 数据编码 ....................................................................................................22
2.3 T=>R 数据编码 ....................................................................................................23
第三章功能验证平台设计...........................................................................................27
3.1 功能验证 ...............................................................................................................27

3.2 功能验证方法 .......................................................................................................29
3.3 验证平台的设计...................................................................................................29
3.4 被验证对象...........................................................................................................31
第四章 PLI接口程序设计............................................................................................33
4.1 PLI接口语言 .........................................................................................................33

4.2 PLI接口程序设计 .................................................................................................38
第五章验证平台的搭建...............................................................................................51
5.1 TESTBENCH .............................................................................................................51

5.2 参考模型 ...............................................................................................................54
5.3 比较器 ...................................................................................................................58
5.4 READER ..................................................................................................................59
5.5 标签存储器 ...........................................................................................................60
5.6 验证平台的应用...................................................................................................61
5.7 验证结果...............................................................................................................62
第六章结束语...............................................................................................................63
致谢.................................................................................................................................65
参考文献.........................................................................................................................67
第一章绪论 1
第一章绪论
随着 IC 设计复杂度的不断提高和设计规模的不断增大，验证已成为 IC 设计
的瓶颈。由于验证的不充分，流片后的芯片中可能存在致命缺陷，从而增加了设
计的风险和设计重流片的成本，因此验证技术，特别是功能验证技术成为 IC 设计
中一个非常重要的环节。本章介绍验证的概念和意义，阐明本文研究 Tag 芯片的
功能验证，分析 Tag 芯片的逻辑模块和 Tag 验证面临的挑战，再介绍本文的主要
工作和章节安排。
1.1 验证的意义
集成电路行业逐步形成集成电路设计、芯片制造、芯片封装三大行业[1][2][3]。
其中，芯片制造和封装行业发展速度大大超过了 IC 设计行业的发展，设计拖累工
艺进步可能带来的设计规模的提高，出现设计生产鸿沟。而 IC 设计行业中的设计
和验证领域的发展也不平衡，验证的发展水平落后于设计的发展水平，出现设计
验证鸿沟。
随着设计规模和复杂性的不断增加，知识产权(Intellectual Property，简称 IP)
的重用和片上系统(System on Chip，简称 SOC)设计的发展，对功能验证提出了更
高的要求。国际半导体技术发展报告指出：验证已经成为集成电路设计流程中开
销最大的工作。在目前的工程项目中，验证工程师的数目超过了设计工程师，对
于复杂设计更是达到 2：1 或是 3：1 的比率。造成这种局面的原因有：一方面是
设计规模正如摩尔定律所指出的呈指数增长。如果用设计中的状态数目来衡量功
能复杂度，则设计的功能复杂度随着设计规模又呈指数增长。如此惊人的发展速
度，对验证技术的处理能力提出了极大的挑战；另一方面，对设计流程中的其它
环节(如逻辑综合、布局布线)的问题关注颇多，而对验证重视不够，造成验证成
为目前行业发展的瓶颈。如果没有重大突破，验证将成为未来集成电路设计流程
中的重大障碍。因此，对验证方法和技术进行研究对于现阶段集成电路发展有着
重要的意义。
1.2 验证的概念
验证是证明一个设计能正确实现其功能的过程[4]。验证不是一个测试平台，
也不是一系列测试平台(Testbench)，使用汇聚模型可以从概念上清晰地描述验证
过程，如图 1.1 所示。其中变换(Transformation)可以是任何包含有输入输出的过
程，包括根据设计规范(Specification)写出寄存器传输级 RTL 代码、扫描链的插入、
2 Tag 芯片的功能验证平台的设计
把 RTL 级代码综合为门级网表、根据变换
门级网表布局布线等。验证过程是一个
相反的过程，它从变换的结果出发回到
起点。
验证
验证只能证明存在错误，不能证明
不存在错误。即验证的错误类型可分为图 1.1 验证过程
Ⅰ型和Ⅱ型两种，如图 1.2 所示。Ⅰ型
错误(也叫否定错误 False-negative)是比较容易验证的类型，就是在存在错误地方
发现了错误。一旦错误的解释被
证实，验证结果的答案将从否定有错误没错误
到肯定，那么错误就不再存在了。差的类型Ⅱ
设计肯定错误
Ⅱ型错误(也叫肯定错误
False-positive)是最严重的一种，好的类型Ⅰ
设计否定错误
就是把有错的设计认为是没有错
误，带有潜在的危险。所以，验图 1.2 错误类型
证过程一定要避免Ⅱ型错误的发
生[5]。
验证并不是在设计完成后才要进行的工作，而是设计的一部分，IC 验证工作
贯穿整个设计流程[6]。在 IC 设计中，在系统规划阶段就可以定义系统验证。当创
建了系统行为模型后，就需要建立测试平台和测试向量来对模型进行验证。同样，
在开发测试平台的同时也要开发设计对应的系统程序并对行为模型进行测试。这
样就可以使得系统的实现和验证开发同步进行。只有和设计同步执行验证才能保
证不会在设计中引入新的错误，而导致系统失败。
1.2.1 验证在设计中的地位
集成电路的设计经历了从小规模(SSI)、中规模(MSI)到大规模(LSI)、超大规
模(VLSI)的发展，集成电路内晶体管的数量按照摩尔定律高速发展，现在已经进
入了 SOC 的开发阶段。
随着设计规模的扩大，设计方法和各种 EDA 工具也不断的改进。数字集成
电路的设计流程[7]如图 1.3 所示。设计从规范出发，制定出设计规范，然后进行
系统级、行为级和 RTL 级的设计，称为前端设计。RTL 设计保证正确后，利用
EDA 工具进行逻辑综合，将 RTL 代码转换成逻辑单元及互连关系的门级网表。
然后进行版图设计，将门级网表转换成电路描述的设计，并进行布局、布线。这
个过程称为后端设计，最后就是流片封装。从图 1.3 可以看出设计的每一步都有
相应的验证步骤。在进入下一设计步骤之前，必须保证之前的设计正确，否则后
第一章绪论 3
面的设计没有任何意义。
规范制定
规范解析和检验
系统级设计
系统级功能验证
行为级设计
行为级功能验证
前端设计
RTL级设计
功能验证
RTL级功能验证
逻辑综合
时序验证
时序验证
版图设计
时序验证/物理验证物理验证
后端设计流片
芯片测试
封装
图 1.3 集成电路的一般流程
1.2.2 验证的分类
根据设计阶段的不同，验证也相应分为功能验证、时序验证、物理验证。功
能验证属于前端验证，时序验证和物理验证属于后端验证。
(1) 功能验证：检查设计的输入(HDL 语言)是否准确的描述了设计的规范要
求。如果描述存在缺陷或错误，无论后面的环节如何完美，也不可能正确的实现
设计。
(2) 时序验证：检查经过逻辑综合后形成的门级描述是否与综合前的描述等
价，即等价性验证。
(3) 物理验证：检查电路描述是否与门级描述等价，并且要检查布局布线后
提取的参数指标是否满足设计要求。满足后才能进入流片制造环节。
1.3 Tag芯片
射频识别技术，简称 RFID(Radio frequency identification)是利用电波的非接触

自动识别技术。RFID 标签是由平面天线和可以储存信息的 I C 薄片组成的，自
身又不带电源的一种装置。最基本的 RFID 系统由三部分组成：标签 (Tag)：由耦

合元件及芯片组成，每个标签具有唯一的电子编码，附着在物体上标识目标对象；
阅读器(Reader)：读取(有时还可以写入)标签信息的设备，可设计为手持式或固定
式；天线(Antenna)：在标签和读取器间传递射频信号[8]。
鉴于射频识别技术的广泛的应用前景和市场价值[9][10]，国内一些高校和研究
所都展开了对射频识别技术的研究。而对于超高频段(UHF)RFID 芯片，目前国内
还没有正式投入使用，还在实验开发阶段。本课题来源于公司实际项目，该项目
是开发 UHF 频段的 RFID 系统用于管理仓库物流系统，该系统根据 2005 年发布
UHF RFID 接口协议设计，其工作频率为 860MHz~960MHz。其中包括 Reader 设
计、Tag 设计和天线。
Tag 芯片设计是本文的验证对象，Tag 芯片由三部分组成，分别是 RF 射频接
口部分、逻辑控制和存储模块。本文主要工作是验证 Tag 芯片中逻辑控制的功能。
其对应的功能块和各模块之间的数据流如图 1.4 所示：
图 1.4 Tag 芯片的逻辑控制模块图

从图 1.4 可知，射频接口电路输出的解调数据进入数字电路，首先将其送入
PIE 解码模块进行解码，还原成命令代码。解码后的数据被送入指令操作码寄存
器进行指令译码操作，判断是何种命令。与此同时，数据也被送入 CRC 校验模块
进行校验。指令译码后，在有限状态机的控制下，对 EEPROM 进行读或写操作；
相应的操作完毕后，对要返回的数据进行 FM0 或者 Miller 编码，然后进入射频接
口电路中的负载调制电路调制输出。
Tag 芯片结构上的特点给验证工作带来巨大挑战：
(1) 系统功能复杂，集成的模块较多，各个模块的功能也相对比较复杂，如
指令译码、有限状态机。
(2) 多个模块集成在一起时的验证，验证焦点应该是在各个模块得到充分验
证的基础上，查找各个模块集成在一起时的设计错误。
(3) 验证平台比较复杂，特别是对于 Tag 的行为模型的描述，它的正确性是
第一章绪论 5
整个验证平台的关键所在。
以上分析了 Tag 芯片给验证工作带来的挑战，针对这些问题，本文分析研究
Tag 芯片功能验证平台搭建。该平台已用于该芯片的功能验证之中，Tag 芯片已在
流片中。
1.4 论文主要工作及章节安排
本文对 Tag 芯片的功能验证的方法和技术进行研究，在自检查方式的基础上

提出 Tag 功能验证平台的整体设计。分析研究验证平台中各模块的作用和模块之
间的连接。分别完成了 Reader 模块、Tag 模块、PLI 模块、比较器和 Testbench。
通过这些模块就完成了 Tag 功能验证平台的搭建。最后分析研究 Tag 验证平台的
验证过程和应用过程。主要研究内容和组织结构如下:
第一章首先论述了验证意义和概念，然后介绍 Tag 芯片结构及其本文需验证
的逻辑块。
第二章分析研究 EPC Gen2 协议，掌握 RFID 标签与读写器的通信原理和工
作原理。然后分析研究 R=>T 的数据编码和 T=>R 的数据编码。
第三章论述功能验证和验证方法，在自检查方式基础上提出 Tag 功能验证平
台的整体设计，并从整体说明各模块的作用。
第四章首先论述了 PLI 语言，然后分析研究 PLI 接口程序的作用，最后详细
地分析了两个 PLI 程序的设计。
第五章分析研究 Reader 模块、参考模型、Testbench 和比较器的设计。通过
这些模块搭建好本文设计的 Tag 功能验证平台，分析研究 Tag 功能验证平台的验
证过程和该平台的应用。
第六章结束语。
第二章 EPC Gen2 接口协议 7
第二章 EPC Gen2 接口协议
2005 年 1 月 EPC C1G2 提请成为 ISO/IEC 18000-6C, 2006 年 6 月 15 日 EPC

C1G2 正式进入 ISO/IEC 18000-6，成为 ISO/IEC 18000-6C。继 ISO/IEC 18000-6A、
B 之后的 ISO/IEC 18000-6C，它对前两种模式的协议特点进行了一系列有效的修
正和扩充。其中物理层数据编码、调制方式、防碰触算法[11][12]等一些关键技术有
了改进，使得 ISO/IEC 18000-6C 的性能比 A、B 有了很大的提高[13][14]。本文验证
的 Tag 芯片是根据 EPC Gen2[15]协议设计，其工作频率为 860MHz-960MHz。本章
研究 EPC Gen2 协议，分析 Reader 和 Tag 的通信原理和工作原理以及 Tag 输入输
出数据编码方式。
2.1 标签选择、盘存和访问
标签选择、盘存和访问可以被视为分层网络通信系统的数据链路层的最低层。
2.1.1 标签存储器
从逻辑上将标签存储器分为四个存储体，每个存储体可以由一个或一个以上
的存储器字组成。逻辑记忆图如图 2.1 所示。这四个存储体分别是：
·保留内存：保留内存应包含灭活口令和访问口令。灭活口令应存储在 00H
至 1FH 的存储地址内。访问口令应存储在 20H 至 3FH 的存储地址内。若标签不
执行灭活或访问口令，则该标签仍然起作用，而无论标签是否已将永久锁定无法
读取/写入的口令清零，在保留内存中不需要有相应的存储位置。
·EPC 存储器：EPC 存储器包含在 00H 至 1FH 存储位置的 CRC-16、在 10H
至 1FH 存储地址的协议-控制(PC)位和在 20H 开始的 EPC。PC 被划分成 10H 至
14FH 存储位置的 EPC 长度、15H 至 17FH 存储位置的 RFU 位和在 18H 至 1FH
存储位置的编号系统识别(NSI)，CRC-16、PC、EPC 应优先存储 MSB (EPC 的
MSB 应存储在 20H 的存储位置)。
·TID 存储器：TID 存储器应包含 00H 至 07H 存储位置的 8 位 ISO15963 分
配类识别(对于 EPCglobal 为 111000102)、08H 至 13H 存储位置的 12 位任务掩模
设计识别(EPCglobal 成员免费)和 14H 至 1FH 存储位置的 12 位标签型号。标签可
以在 1FH 以上的 TID 存储器中包含标签指定数据和提供商指定数据(例如，标签
序号)。
·用户存储器：用户存储器允许存储用户指定数据。该存储器组织为用户定
义。
所有存储体的逻辑寻址均从零(00H)开始。物理内存映象图为提供商指定。访
问存储的命令有选择该存储体的 MemBank 参数和规定使用 EBV 格式选择该存储

体内特定存储位置的地址参数。若标签反向散射存储内容，则该反向散射应落在
词界上。
MemBank 的定义如下：
002：保留内存；
012：EPC 存储器；
102：TID 存储器；
112：用户存储器。
在一个逻辑存储体中的操作不应访问另一存储体内的存储位置。
MSB LSB
…
10h TID[15:0] 1Fh
00h TID[31:16] 0Fh
MSB LSB
EPC[15:0]
用户存储器
…
TID存储器 20h EPC[N:N-15] 2Fh

10h PC[15:0] 1Fh
EPC存储器 00h CRC_16[15:0] 0Fh
保留内存
MSB LSB
…
30h 访问口令 [15:0] 3Fh

20h 访问口令 [31:16] 2Fh
10h 杀死口令 [15:0] 1Fh
00h 杀死口令 [31:16] 0Fh
图 2.1 逻辑内存映象
询问机可以锁定、永久锁定、不锁定或永久不锁定存储器，以便阻止或允许
更改(视具体情况而定)。灭活口令和访问口令可以单独锁定，EPC、TID 和用户存
储器也是如此。如果灭活口令或访问口令锁定，可以不能以写入或读取的方式显
现(但仍然可为 Kill 和 Access 命令所用)，而不象其它存储体一样，始终可以被读
取而无论是否其处于锁定状态。
(1) 灭活口令
灭活口令为存储在保留内存 00H 至 1FH 的 32 位数值，MSB 优先。默认(未
编程)值应为零。询问机应一次性使用标签的灭活口令灭活标签，使其保持沉默。
如果标签的灭活口令为零，则标签不应执行灭活操作。不执行灭活口令的标签仍
然可以起作用，尽管其零值化的灭活口令被永久读锁定和写锁定。
(2) 访问口令
访问口令为存储在保留内存 20H 至 3FH 的 32 位数值，MSB 优先。默认(未
编程)值应为零。访问口令非零的标签应要求询问机在转为保护状态之前发出该口
令。不执行访问口令的标签仍然可以起作用，尽管其零值化的访问口令被永久读
锁定和写锁定。
(3) CRC-16
CRC-16 为询问机在保护某个特定的 R=>T 命令时所使用的和标签在保护某
个特定的反向散射 T=>R 序列时使用的循环冗余码校验。为生成 CRC-16，询问机
或标签应首先生成如表 2.1 所示的 CRC-16 先驱，然后取生成的先驱的二进制反
码形成 CRC-16。
CRC-16 保护的序列为标签在盘存操作期间反向散射的 PC 位和 EPC。由于询
问机可以发出将全部或部分 CRC-16 包括在 mask 中的 Select 命令，并可以发出
Read 命令以便使标签反向散射 CRC-16，因此 CRC-16 从逻辑上映射到 EPC 存储
器中。上电后，标签应计算 EPC 存储位置 10H 上的 CRC-16，直至 EPC 的末端(不
一定直至 EPC 存储器的末端，但必须直至 PC 中 length field 规定的 EPC 的末端)，
并将所计算的 CRC-16 映射到 EPC 存储器 00H 至 1FH 中，MSB 优先。由于
{PC+EPC}存储在 EPC 存储器词界上，因此应在词界计算该 CRC-16。标签应在间
隔 Ts 或 Ths(视具体情况而定)结束时完成此 CRC-16 计算和存储映象。标签不应
再次计算 CRC-16 以便截断应答。
为便于信息检验，询问机或标签可以将 CRC-16 添加到所传输的信息上，并
重新计算 CRC-16。若该信息仍然可靠，则其余项将是 1D0FH。
表 2.1 CRC 先驱
CRC-16 先驱
CRC 型长度多项式预置余项
16 12 5
ISO/IEC 13239 16 位 X +X +X +1 FFFFh 1D0Fh
(4) 协议-控制(PC)位
PC 位包含标签在盘存操作期间以其 EPC 反向散射的物理层信息。EPC 存储
器 10H 至 1FH 存储地址存储有 16PC 位，PC 位值定义如下：
10H—14H 位：标签反向散射的(PC+EPC)的长度，所有字为：
000002：一个字(EPC 存储器 10H—1FH 存储地址)；

000012：两个字(EPC 存储器 10H—2FH 存储地址)；
000102：两个字(EPC 存储器 10H—3FH 存储地址)；
111112：32 个字(EPC 存储器 10H—20FH 存储地址)；
15H—17H 位：RFU(第 1 类标签为 0002)；
18H—1FH 位：默认值为 000000002 且可以包括如 ISO/IEC 15961 定义的 AFI
在内的计数系统识别(NSI)。NSI 的 MSB 存储在 18H 的存储位置；
默认(未编程)PC 值应为 0000H；
截断应答期间，标签用 PC 位代替 00002。
若询问机在存储器写入期间修改 EPC 长度，并希望标签继续反向散射所修改
的 EPC，那么询问机必须要将新(PC+EPC)或修改后的(PC+EPC)写入标签 PC 的前
五位。若询问机试图将不被该标签支持的(PC+EPC)长度写入该标签 PC 的头五位，
则标签应反向散射错误代码
上电时，标签应通过 PC 前五位指定的(PC+EPC)字数而不是整个 EPC 存储器
长度计算 CRC-16。
(5) EPC
EPC 为识别标签对象的电子产品码。EPC 存储在以 20H 存储地址开始的 EPC
存储器内，MSB 优先。询问机可以发出选择命令，包括全部或部分规范的 EPC。
询问机可以发出 ACK 命令，使标签反向散射其 PC、EPC 和 CRC-16(在特定情况
下该标签可以截断应答)。最后，询问机可以发出 Read 命令，读取整个或部分 EPC。
2.1.2 通话和已盘标记
询问机应支持且标签提供 4 个通话(即 S0、S1、S2 和 S3)。标签应在一个盘

存周期期间参加一个且只参加一个通话。两个或两个以上的询问机可以利用通话
独立盘存共用标签群。通话概念如图 2.2 所示。
标签应为每个通话维持独立的已盘标记。四个已盘标记的每个已盘标记有两
个值，即 A 和 B。各盘存周期开始时，询问机选择盘存 A 或 B 标签，将其存入
四个通话中的其中一个通话。参加某一通话的某盘存周期的标签不可使用或修改
已盘标记从而改变通话。已盘标记为标签独立单独提供给既定通话的唯一来源，
其它标签来源为各通话共享。
通话允许标签将某个独立的已盘标记与各读出器联系在一起。
单化标签后，询问机可以发出命令，使该标签为此次通话转换已盘标记(即 A
→B 或 B→A)。
以下说明了两个询问机如何利用通话和已盘标记独立交错盘存共用标签群：
(1) 打开询问机#1 电源，然后启动一个盘存周期，使通话 S2 中的标签从 A
单化为 B。
(2) 关闭电源；
(3) 打开询问机#2 电源，然后；
(4) 启动一个盘存周期，使通话 S3 中的标签从 B 单化为 A；
(5) 关闭电源。
反复操作本过程直至询问机#1 将通话 S2 的所有标签均放入标签 B，然后，
将通话 S2 的标签从 B 盘存为 A。同样，反复操作本过程直至询问机#2 将通话 S3
的所有标签放入 A，然后再将通话 S3 的标签从 A 盘存为 B。通过这种多级程序，
各询问机可以独立地将所有标签盘存到它的字段中，无论其已盘标记是否处于初
始状态。
标签的已盘标记持续时间应如表 2.2 所示。标签应采用以下规定的已盘标记
打开电源：
S0：已盘标记应设置为 A。
S1：已盘标记应设置为 A 或 B，视其存储数值而定，如果以前设置的已盘标
记比其持续时间要长，则标签应将其 S1 已盘标记设置为 A 打开电源。由于 S1
已盘标记不是自动刷新，因此可以从 B 回复到 A，即使在标签上电时也可以如此。
S2：已盘标记应设置为 A 或 B，视其存储的数值而定，若标签断电时间超过
其持续时间，则可以将 S2 已盘标记设置到 A，打开标签。
S3：已盘标记应设置为 A 或 B，视其存储的数值而定，若标签断电时间超过
其持续时间，则可以将 S3 已盘标记设置到 A，打开标签。
图 2.2 通话图
无论初始标记值是多少，标签应能够在 2 毫秒或 2 毫秒以下的时间将其已盘
标记设置为 A 或 B。标签应在上电时更新其 S2 和 S3 标记，这意味着每次标签断
开电源，其 S2 和 S3 已盘标记的持续时间。当标签正参与某一盘存周期时，标签
不应让其 S1 已盘标记失去其持续性。相反，标签应维持此标记值直至下一个 Query
命令，此时，标记可以不再维持其连续性(除非该标记在盘存周期期间更新，在这
种情况下标记应采用新值，并保持新的持续性)。
2.1.3 选定标记
标签应执行选定标记 SL，询问机可以利用 Select 命令予以确认或取消确认。

Query 命令中的 Sel 参数允许询问机对确认 SL 或取消确认 SL(例如 SL 或～SL)的
标签进行盘存，或者忽略该标记和盘存标签，无论其 SL 值如何。SL 与任何通话
无关，SL 适用于所有标签，无论是哪个通话。
标签的 SL 标记的持续时间如表 2.2 所示。标签应以其被确认的或取消确认的
SL 标记开启电源，视所存储的具体数值而定，无论标签断电时间是否大于其 SL
标记持续时间。若标签断电时间超过 SL 持续时间，标签应以其被取消确认的 SL
标记开启电源(设置到～SL)。标签应能够在 2 毫秒或 2 毫秒以下的时间内确认或
取消确认其 SL 标记，无论其初始标记值如何。打开电源时，标签应刷新其 SL 标
记，这意味着每次标签电源断开，其 SL 标记的持续时间均如表 2.2 所示。
表 2.2 标签标记和持续值
标记应持续时间
S0 已盘标记通电标签：不确定
未通电标签：无
S1 已盘标记 1 通电标签：
标称温度范围：500 毫秒＜持续时间＜5 秒
延长温度范围：未规定
未通电标签：
标称温度范围：500 毫秒＜持续时间＜5 秒
S2 已盘标记 1 通电标签：不确定
未通电标签：
标称温度范围：2 毫秒＜持续时间
S3 已盘标记 1 通电标签：不确定
未通电标签：
选定(SL)标记 1 通电标签：不确定
未通电标签：
注：对于随机选择的足够大的标签群，95%的标签持续时间应符合持续要求，应达到 90%的
置信区间。
2.1.4 标签状态和槽计数器
标签应执行如图 2.3 所示的状态和槽计数器。

(1) 就绪状态
标签应执行就绪状态。就绪可以被视为通电标签被灭活或正参与某盘存周期
的保持状态。进入激励射频场后，未灭活的标签应进入就绪状态。标签应保持其
就绪状态直至收到其已盘参数(Query 命令规定的通话的已盘参数)和 sel 参数与其
当前标记值匹配的 Query 命令。匹配标签应从其 RNG 中抽出 Q 位数，将该数字
载入其槽计数器内，若该数字非零则转换到仲裁状态，若该数字为零则转换到应
答状态。若处于除被灭活之外任何状态的标签电源断电，则应在恢复电源后即返
回就绪状态。
(2) 仲裁状态
标签应执行仲裁状态。仲裁可以被视为参与当前盘存周期但其槽计数器数值
非零的标签的“保持状态”。处于仲裁状态的标签每次收到其通话参数与当前盘存
周期通话匹配的 QueryRep 命令后使其槽计数器减值，当槽计数器达到 0000H 时，
应转换到应答状态。以 0000H 的槽值转换到仲裁状态(例如从应答状态转换)的标
签应使其槽计数器在下一个 QueryRep(附匹配通话)时从 0000H 减值到 7FFFH，由
于其槽值此时非零，因此仍然处于仲裁状态。
(3) 应答状态
标签应执行应答状态。一旦进入应答状态，标签应反向散射 RN16。若标签
收到有效确认(ACK)，则转换到确认状态，反向散射其 PC、EPC 和 CRC-16。若
标签未能接收到 ACK，或收到无效 ACK，则应返回仲裁状态
(4) 确认状态
标签应执行确认状态。处于确认状态的标签可以转换到除灭活之外的任何状
态，视所收到的具体命令而定(参见图 2.3)。
(5) 开放状态
标签应执行开放状态。处于确认状态，其访问口令非零的标签应在收到
Req_RN 命令后即转换到开放状态，反向散射新的询问机应在随后的命令中使用
的和标签在随后的应答中使用的 RN16(标为句柄)。处于开放状态的标签应执行除
Lock 之外的所有命令。处于开放状态的标签可以转换到除确认之外的任何状态，
具体情况视所收到的命令而定(参见图 2.3)。在开放状态下，标签应答和询问机传
输之间的最大延迟不受限制。
(6) 保护状态
标签应执行保护状态。处于确认状态的，其访问口令为零的标签收到 Req_RN
图 2.3 Tag 状态图

命令后应立即转换成保护状态，反向散射新的询问机应在随后的命令中使用的和
标签在随后的应答中使用的 RN16(标为句柄)。处于开放状态的其访问口令非零应
在收到有效 Access 命令即转换到保护状态，保持原来从确认状态转换到开放状态
时反向散射的句柄不变。处于保护状态的标签可以执行所有访问命令。处于保护
状态的标签可以转换到除开放或确认之外的任何状态，具体情况视所收到的命令
而定(参见图 2.3)。在保护状态下，标签应答和询问机传输之间的最大延迟不受限
制。
(7) 灭活状态
标签应执行灭活状态。处于开放状态或保护状态的标签应在收到 Kill 命令后
以有效非零灭活口令和有效句柄进入灭活状态。进入灭活状态后，标签应通知询
问机灭活操作成功，此后不再对询问机作出响应。被灭活的标签应在所有情况下
都处于灭活状态，并在随后的开启电源的操作中立即进入灭活状态。灭活操作具
有不可逆性。
(8) 槽计数器
标签应执行 15 位槽计数器。收到 Query 或 QueryAdjust 命令，标签应将从该
标签的 RNG 中抽出的 0 至 2Q-1 之间的某个数值预见载入其槽计数器内。Q 为该
范围内(0,15)的一个整数。Query 命令规定 Q，QueryAdjust 命令可以从以前的 Query
命令中修改 Q。收到 QueryRep 命令后，标签应使其槽计数器减值。槽计数器应
能够连接计数，这意味着当槽计数下降到 0000H 时，应从 7FFFH 重新开始倒计
数。
2.1.5 标签随机或伪随机数据发生器
标签应执行随机或伪随机数据发生器(RNG)。RNG 应符合不依赖于通电场、
R=＞T 链路速率和存储在标签内的数据(包括 PC、EPC 和 CRC-16)的随机标准。
标签应采用 RNG 生成 16 位随机或伪随机数据(RN16)，并应能够从 RN16 内提取
Q-位子集预先加载到该标签的槽计数器内。打开电源时，标签应能够暂时存储至
少两个 RN16 以便在口令转换期间用作句柄和 16 位加密等。
单个 RN16 的可能性：应采用 0.8/216 < P(RN16 = j)< 1.25/216 对从 RNG 内抽
取 RN16=j 的可能性予以限制。
同时恒等序列的可能：对于数量达 10,000 个的标签群，任意两个或两个以上
标签同时生成同一 RN16 序列的可能性应小于 0.1%，无论标签是否通电。
预测 RN16 的可能性：若在同等条件下进行的前一次抽取结果已知，Tr 结束
后 10 毫秒从标签的 RNG 中抽取的 RN16 的可预测性不应大于 0.025%。
2.1.6 管理标签群
询问机采用图 2.4 所示的三个基本操作管理标签群。每个操作均由一个或一

个以上的命令组成。这三个基本的定义如下：
选择：询问机选择标签群以便于盘存和访问的过程。询问机可以一个或一个
以上的 Select 命令在盘存之前选择特定的标签群。
盘存：询问机识别标签的过程。询问机在四个通话的其中一个通话中传输
Query 命令，开始一个盘存周期。一个或一个以上的标签可以应答。询问机检查
某个标签应答，请求该标签发出 PC、EPC 和 CRC-16。同时只在一个通话中进行
一个盘存周期。
访问：询问机与各标签交易(读取或写入标签)的过程。访问前必须要对标签
进行识别。访问由多个命令组成，其中有些命令执行 R=＞T 链的一次活页加密。
图 2.4 阅读器(Reader)/标签(Tag)操作和标签状态
2.1.7 选择标签群
选择过程要用到命令 Select，询问机可以连续使用 Select 命令选择基于用户

定义标准的标签群、启动单元(U)、相交和基于标签分块的否定(～)。询问机发
送连续 Select 命令执行 U 和操作。Select 命令可以确认或取消确认标签的 SL
标记，或者可以在四个通话的其中一个通话中将标签的已盘标记设置为 A 或 B。
Select 命令含有参数目标(Target)、动作(Action)、存储体(Membank)、指针(Pointer)、
长度(Length)、掩模(Mask)和截断(Truncate)。
目标和动作表示 Select 命令是否修改和如何修改标签的 SL 标记或已盘标记，
若是在已盘标记的情况下，则要看是哪个通话。修改 SL 标记的 Select 命令不应
修改已盘标记，反之亦然。
存储体规定 mask 是否适用于 EPC、TID 或用户存储器。Select 命令适用于单
个存储体。连续发出的 Select 命令可以适用于不同的存储体。

指针、长度、掩模：指针和长度描述存储范围。必须有长度位的掩码同规定
存储范围相比较。
截断规定标签是否反向散射其全部 EPC，或者仅仅在 Mask 后反向散射该部
分 EPC。截断应答始终跟随在 EPC 存储器 00H 至 0FH 存储位置 CRC-16 后，标
签不为截断应答计算此 CRC。
通过发出多个同等 Select 命令后，询问机可以渐近挑选出与选择标准匹配的
所有标签，尽管标签可能会出现短期射频减弱。
Query 命令利用已盘标记和 SL 标记决定标签是否参与盘存。询问机可以盘存
和访问 SL 或～SL 标签，或者可以选择忽略全部 SL 标记。
2.1.8 盘存标签群
盘存指令集包括 Query、QueryAdjust、QueryRep、ACK 和 NAK。Query 启

动一个盘存周期，并确定哪个标签参与该盘存周期(“盘存周期”即为连续 Query
命令之间相隔的时间)。
Query 命令含有槽计数器参数 Q。收到 Query 命令后，参与标签应在(0,2Q-1)
范围内挑选一个随机数值，并应将该数值载入其槽计数器。挑选零数值的标签应
转换成应答状态，并立即应答。挑选非零数值的标签应转换成仲裁状态，并等待
发出 QueryAdjust 或 QueryRep 命令。假设是单个标签应答，访问-应答算法如下：
(1) 当标签进入应答状态后即反向散射 RN16；
(2) 询问机以含有相同 RN16 的 ACK 确认该标签；
(3) 确认的标签转换到确认状态，反向散射其 PC、EPC 和 CRC-16；
(4) 询问机发出 QueryAdjust 或 QueryRep 命令，使所识别出的标签倒转已盘
标记(即 A→B 或 B→A)，转换到就绪状态，使另一个标签启动与该询问机的从上
述(1)开始的询问-应答对话。
若标签没能在时间 T2 内收到(2)步的 ACK，或收到的 ACK 包含有错误的
RN16，则应返回到仲裁状态。
若多个标签按(1)所述应答但询问机通过检测和解决波形一级的冲突可以解
决其中一个标签发来的 RN16，则该询问机可以 ACK 所解决的标签。未解决的标
签收到错误的 RN16，并返回仲裁状态，不反向散射其 PC、EPC 和 CRC-16。
若询问机向处于确认状态下的标签发送有效 ACK(即含正确的 RN16 的
ACK)，则该标签应重新反向散射其 PC、EPC 和 CRC-16。
询问机随时可以发送 NAK，为此所有处于该盘存周期的标记应返回仲裁状
态，其已盘标记不变。
发出 Query 启动一个盘存周期后，询问机一般要发出一个或一个以上的
QueryAdjust 或 QueryRep 命令。QueryAdjust 命令重复以前的 Query 命令，可以令

Q 增值或减值，但不将新的标签引入该盘存周期内。QueryRep 重复以前的 Query
命令，参数不变，也不将新的标签引入该盘存周期。盘存周期可以包含多个
QueryAdjust 或 QueryRep 命令。在某一点上询问机将发出新的 Query 命令，由此
启动新的盘存周期。
处于仲裁或应答状态的收到 QueryAdjust 命令的标签首先调整 Q(增值、减值
或保持不变)，然后在该范围内(0,2Q-1)挑选一个随机数值，将该数值载到槽计数
器内。挑选零数值的标签应转换到应答状态并立即应答。挑选非零值的标签应转
换到仲裁状态，并等待发出 QueryAdjust 或 QueryRep 命令。
处于仲裁状态下的标签每次收到 QueryRep 命令后即将其槽计数器减值，当
槽计数器达到 0000H 时转换到应答状态，并反向散射 RN16。槽计数器达到 0000H
的，作出应答的，未被确认的标签(包括响应原 Query 命令但未被确认的标签)应
在槽值达到 0000H 时返回仲裁状态，并在下一个 QueryRep 时使其槽值从 0000H
减值到 7FFFH，由此有效地阻止连续应答直至该标签将一个新随机数值载入其槽
计数器。标签应在 2Q-1QueryRep 命令中至少回答一次。
尽管标签盘存是以随机协议为基础的，但 Q-参数可以通过允许询问机调整标
签响应的可能性提供网络控制。Q 为该范围(0,15)的整数，因此相关的标签响应可
能性的范围是从 20=1 到 2-15=0.000031。
上述情况均假设某一询问机是在某一通话中操作的。但是，如 2.1.2 所述，询
问机可以在四个通话的其中一个通话中盘存标签群。此外，Query、QueryAdjust
和 QueryRep 命令分别包含有一个通话参数。标签对这些命令的应答方式随命令、
通话参数和标签状态的不同而不同：
(1) Query：Query 命令启动盘存周期，为该盘存周期挑选通话。处于除灭活
状态的任何状态的标签应执行 Query 命令，在规定通话中开始新的盘存周期，并
根据具体情况转换成就绪状态、仲裁状态或应答状态(参见图 2.3)。
若处于确认、开放或保护状态下的标签收到其通话参数与前通话匹配的
Query 命令，则在评估是否转换成就绪、仲裁或应答状态之前倒转其已盘标记(A
→B 或 B→A)。
若处于确认、开放或保护状态下的标签收到其通话参数与前通话不匹配的
Query 命令，则在评估是否转换成就绪、仲裁或应答状态之前保持其前通话的已
盘标记不变。
(2) QueryAdjust, QueryRep：只在命令中的通话参数与启动该盘存周期的
Query 命令的通话参数匹配时，处于除就绪或灭活状态之外的任何状态下的标签
应执行 QueryAdjust 或 QueryRep 命令。标签应忽略通话不匹配的 QueryAdjust 或
QueryRep。
若处于确认、开放或保护状态下的标签收到其通话参数与前 Query 命令中的

通话参数匹配的 QueryAdjust 或 QueryRep，则应倒转其盘存周期(A→B 或 B→A)，
然后转换成就绪状态。
为阐明盘存操作，现举例说明：假设有 64 个处于就绪状态下的通电标签。询
问机首先发出 Select 命令，选择副标签群。假设有 16 个标签与此选择标准匹配。
再进一步假设在这 16 个标签中有 12 个标签将其已盘标记设置为 S0 通话中的 A。
询问机发出 Query 命令规定(SL，Q=4，S0，4)。这 12 个标签的每一个在 0-15 的
范围内选择一个随机数值，然后加载到槽计数器中。选择零的标签立即作出应答。
Query 命令可能会出现以下三个结果：
(1) 无标签应答：询问机可以另外再发一个 Query 命令，或者也可以发出
QueryAdjust 或 QueryRep 命令。
(2) 一个标签应答(参见图 2.5)：标签转换到应答状态，反向散射一个 RN16。
询问机发送 ACK 予以确认。若标签收到的 ACK 包含的 RN16 正确，则反向散射
其 PC、EPC 和 CRC-16，并转换到确认状态。若标签收到的 ACK 所包含的 RN16
错误，则转换到仲裁状态。假设是 RN16 正确的 ACK，则询问机可以访问所确认
的标签，也可以发送 QueryAdjust 或 QueryRep 将该标签的已盘标记从 A 倒转为 B，
并使标签转换到就绪状态(带有前盘存周期匹配通话参数的 Query 命令也将使已
盘标记从 A 倒转为 B)。
符号描述
R=>T发信 P 前同步码（R=>T或=>R）
FS 帧同步
T=>R发信 RN16 16位随机数
P Query P RN16 FS ACK P PC EPC CRC-16 FS QueryRep
图 2.5 一个标签应答
(3) 多标签应答：询问机观察由多个 RN16 组成的反向散射的波形。该询问
机可以解决冲突并发送 ACK；不解决冲突和发送 QueryAdjust 或 QueryRep 命令
或 NAK；或迅速识别冲突并在冲突标签完成反向散射之前发送一个 QueryAdjust
或 QueryRep 命令。在后一种情况下，未在 T2 内观察到有效应答的冲突标签应返
回仲裁状态，并等待发出下一个 Query 或 QueryAdjust 命令。
2.1.9 访问各标签
确认标签后，询问机可以选择访问该标签。访问命令集由 Req_RN、Read、
Write、Kill、Lock、Acces、BlockWrite 和 BlockErase 组成。标签执行确认状态、
开放状态或保护状态的 Req_RN。标签执行开放状态或保护状态的 Read、Write、
Kill、Acces、BlockWriet 和 BlockErase。标签执行保护状态的 Lock。
询问机按以下步骤访问确认状态的标签：
第 1 步：询问机向被确认的标签发送 Req_RN。
第 2 步：标签生成和存储新的 RN16(即句柄)，反向散射该句柄，如果其访问
口令非零的话，转换成开放状态，如果其访问口令为零的话，转换成保护状态。
现在询问机可以发出进一步的访问命令了。
所有发给开放状态或保护状态下的标签的访问命令将该标签的句柄纳为该命
令中的一个参数。若标签处于上述两种状态时，标签应在执行访问命令前确认该
句柄是正确的，并应忽略句柄错误的访问命令。整个访问序列持续期间的句柄值
都是固定的。
处于开放状态下的标签可以执行除 Lock 之外的所有访问命令。处于保护状
态下的标签可以执行所有访问命令。标签对某一访问命令的应答至少应包括该标
签的句柄，该应答也可以包括其它信息(例如，Read 操作的结果)。
询问机可以向处于开放或保护状态下的标签发送 ACK，使该标签反向散射其
PC、EPC 和 CRC-16。
询问机和标签可以在开放或保护状态下无限通信。询问机可以通过发送
Query、QueryAdjust、QueryRep 或 NAK 命令中止通信。标签对 QueryAdjust、
QueryRep 或 NAK 命令的应答参见 2.1.8 所述。NAK 命令使处于该盘存周期的标
签返回仲裁状态，不改变其已盘标记。
Write、Kill 和 Access 命令将 16 位字(数据或半口令)从询问机发送到标签。
这些命令采用一次活页加密隐藏被传输的字，步骤如下：
第 1 步：询问机将 Req_RN 命令发送给标签，标签反向散射一个新 RN16 作
为应答。然后询问机生成一个由 16 位字的按位 EXOP 构成的 16 位密文串，并以
上述新 RN16 传输，MSB 优先，以密文串为一个参数发出该命令。
第 2 步：标签通过执行所收到的带有原 RN16 的 16 位密文串的按位 EXOP，
破译所收到的密文串。
询问机不可用句柄加密。询问机也不可重复使用句柄加密。如果询问机重新
发送含有加密数据的命令，则应重新发送没有更改过的命令。如果询问机改变了
该数据，则应首先发送 Req_RN 命令，获得一个新 RN16，并用这个新 RN16 加
密。
标签通过反向散射其句柄对写入存储器或擦去的命令(即 Write、Kill、Lock、
BlockWrite 和 BlockErase)作出应答，表明该操作成功执行，或者通过反向散射一
个错误代码，表明该操作未成功执行。
灭活标签需要通过多个步骤才能完成，灭活口令为零的标签不执行灭活操作。
发送访问口令给标签也是一个需要多个步骤才能完成的操作。
标签存储器可以锁定也可以不锁定。锁定状态可以改变也可以永久锁定(即永
久不锁定或永久锁定)。询问机可以在开放状态或保护状态下写入不锁定存储器。
询问机只可以在保护状态下写入没有被永久锁定的锁定存储器。
2.1.10 询问机命令和标签应答
询问机对标签命令的格式如表 2.3 所示。

QueryRep 和 ACK 有以 02 开始的 2 位操作码。
Query、QueryAdjust 和 Select 有以 102 开始的 4 位操作码。
其它基本命令有以 1102 开始的 8 位操作码。
扩展命令均有以 11102 开始的 16 位操作码。
QueryRep、ACK、Query、QueryAdjust 和 NAK 的命令长度如表 2.3 所示。
其它命令不应有这样的长度。若标签收到长度不正确的命令，则应忽略该命令。
Query、QueryAdjust 和 QueryRep 包含有一个通话参数。
Query 受 CRC-5 保护， Select、Req_RN、Read、Write、Kill、Lock、Access、
BlockWrite 和 BlockErase 均由 CRC-16 保护。
R=＞T 命令以前同步码或帧同步开始。表 2.3 规定的操作码长度不包括前同
步码或帧同步。
标签应忽略无效命令。总的来说，“无效”指(1)在既定的当前标签状态下不
正确的命令，(2)该标签不支持的命令，(3)参数不正确的命令，(4) CRC 错误的命
令，(5)规定错误通话的命令或(6)未被标签以其它方式确认或执行的命令。对于各
标签状态来说，“无效”的实际定义是状态指定的和定义的。
表 2.3 命令
命令代码长度(位) 是否是强制命保护
令？
QueryRep 00 4 是唯一命令长度
ACK 01 18 是唯一命令长度
唯一命令长度
Query 1000 22 是
和一个 CRC-5
QueryAdjust 1001 9 是唯一命令长度
Select 1010 > 44 是 CRC-16
NAK 11000000 8 是唯一命令长度
Req_RN 11000001 40 是 CRC-16
Read 11000010 > 57 是 CRC-16
Write 11000011 > 58 是 CRC-16
Kill 11000100 59 是 CRC-16
Lock 11000101 60 是 CRC-16
Access 11000110 48 否 CRC-16
BlockWrite 11000111 > 57 否 CRC-16
BlockErase 11001000 > 57 否 CRC-16
由于篇幅的限制，对于各个命令对应的编码和参数，以及在不同状态下状态
的 Tag 的反应和具体的反应此处不再讨论了。由于本论文主要是针对 Tag 的功能
验证，接下来分析研究 Tag 的输入编码和输出编码方式。
2.2 R=>T 数据编码
2.2.1 PIE编码
阅读器到标签的通信采用 PIE 编码，PIE 编码的原理是通过定义脉冲下降沿

之间不同时间宽度来表示 0 和 1。如图 2.6 所示：
图 2.6 PIE 编码
表 2.4 最佳询问机对标签 Tari 值
Tari Tari-Value
Spectrum
Value Tolerance
6.25us +/-1% DSb-ASK
12.5us +/-1% SSB-ASK
25us +/-1% or PR-ASK
时间断的范围为 6.25us 和 25us 之间。由阅读器到标签的通信以帧为单位的，

因此信号必须以帧头或者帧同步信号开始。帧头在“Query”命令之前发出，表明
清点管理循环开始。而所有其它的命令必须以帧同步信号开始。其中帧头由固定
长度的开始分隔符，数据 0 符号，阅读器到标签的刻度符号(Rtcal)和标签到阅读
器的刻度符号(Trcal)组成。
2.2.2 R=＞T前同步码和帧同步
询问机应以前同步码或帧同步开始所有 R=＞T 发信，前同步码和帧同步参见

图 2.7 所示。前同步码应先于 Query 命令，并表明盘存周期开始。其它发信则以
帧同步开始。所有以 Tari 为单位的参数的公差均应为±1%。标签可以将数据-0
的长度与 Rtcal 的长度进行比较以确认前同步码。
前同步码应由固定长度的起始分界符、数据-0 符、R=＞T 校准(RTcal)符和
T=＞R 校准(TRcal)符组成。
Rtcal：询问机应设置 RTcal，RTcal 等于数据-0 符长度加数据-1 符长度

(Rtcal=0length+1length)。标签应计算 RTcal 长度并计算 pivot=Rtcal/2。标签应阐明
后来的询问符比作为数据-0 的 pivot 短，比作为数据-1 的 pivot 长。标签应说明比
4RTcal 长的符号为不良数据。在改变 RTcal 之前，询问机应最少为 8 个 RTcal 传
输 CW。
图 2.7 R=＞T 前同步码和帧同步

Trcal：询问机应分别利用启动盘存周期的 Query 命令的前同步码和有用负荷
中 TRcal 和除法比率(DR)规定标签的反射散射链路频率(其 FM0 数据速率或其
Miller 副载波的频率)。等式(1)规定了反向射散射链路频率(LF)、TRcal 和 DR 之
间的关系。标签应测定 TRcal 的长度，计算 LF，并将其 T=＞R 链路速率调整为
等于 LF。询问机在盘存周期中采用的 TRcal 和 RTcal 应满足等式(2)的限制条件：
LF=DR
TRcal (1)
1.1×RTcal≤TRcal≤3×RTcal (2)
帧同步等同于前同步码减 TRcal 符。在盘存周期期间，询问机在帧同步中使
用的 RTcal 长度应与其在启动该盘存周期的前同步码中使用的长度相同。
2.3 T=>R 数据编码
标签应答将反射散射的数据编为该数据速率的副载波 FM0 基带或 Miller 调

制。询问机发出编码选择的命令。
2.3.1 基带FM0
图 2.8 显示了生成 FM0(两相空间)编码的基本功能和状态图。FM0 在每个边

界倒转基带相位，数据-0 有一个附加的中间符号相位倒转。图 2.8 的状态图描绘
了所发送的 FM0 基本功能的逻辑数据序列。S1-S4 状态标记表明四种可能 FM-编
码符号，代表各 FM0 基本功能的两个相位。这些状态标签还表示键入状态后即传

输的 FM0 波形。状态转换的标签表示被编码的数据序列的逻辑值。例如，从状态
S2 转换到状态 S3 是不允许的，因为由此产生的传输在符号边界上没有相转化。图
2.8 所示的状态图不暗示任何特殊执行。
amplitude
图 2.8 FM0 基本功能和发生状态图

图 2.9 显示了所发生的基带 FM0 符号和序列。在调制器输出时测得的 00 或
图 2.9 FM0 符号和序列

11 序列的工作循环应最低为 45%，最高为 55%，标称值为 50%。FM0 编码有存
储器，因此，图 2.9 中的 FM0 序列的
FM0 发信结束
选择取决于前一次传输。如图 2.10 所
0 dummy 1 0 dummy 1
示，FM0 发信应始终在每次传输结束 1 dummy 1 1 dummy 1
时以”dummy”数据-1 结尾。
图 2.10 中止 FM0 传输
2.3.2 FM0 前同步码
T=＞R 发信应以图 2.11 所示的两个前同步码开始。至于选择哪个前同步码应

FM0 前同步码（TRext = 0）
1 0 1 0 V 1
FM0 前同步码（TRext = 1）
12个前导零（导频音）
…
0 0 0 0 1 0 1 0 V 1
图 2.11 FM0 T=＞R 前同步码

以启动该盘存周期的 Query 命令规定的 TRext 位的数值为准。图 2.11 中所示的“v”

表示 FM0 偏移(即应发生相转化但实际上没有)。
2.3.3 Miller-调制副载波
图 2.12 显示了生成 Miller 编码的基本功能和状态图。基带 Miller 按顺序在两

个数据-0 之间变换相位。基带 Miller 还在数据-1 符号的中间放置一个相转化。图
2.12 所示的状态图描绘了基带 Miller 基本功能的逻辑数据序列。S1-S4 状态标记表
明四种可能 FM-编码符号，代表各 FM0 基本功能的两个相位。这些状态标签还表
示键入状态后即传输的 FM0 波形。状态转换的标签表示被编码的数据序列的逻辑
值。例如，从状态 S2 转换到状态 S3 是不允许的，因为由此产生的传输在数据 0
和数据-1 之间的符号边界上没有相转化。图 2.12 所示的状态图不暗示任何特殊执
行。
amplitude
图 2.12 Miller 基本功能和发生器状态图

如图 2.13 所示 Miller 调制副载波序列，Miller 序列每位应包含 2、4 或 8 个副
载波周期，具体情况视启
动该盘存周期的 Query
命令规定的 M 值而定。
在调制器输出时测得的
0 或 1 符的工作循环最低
为 45%，最高为 55%，
标称值为 50% 。 Miller
编码有存储器，因此，图
2.14 的 Miller 序列的选
择取决于前一次传输。如
图 2.14 示，Miller 发信应
始终在每次传输结束时
以”dummy”数据-1 结尾。
图 2.13 副载波序列
图 2.14 中止副载波传输
2.3.4 Miller副载波前同步码
T=＞R 发信应以图 2.15 所示的两个前同步码开始。至于选择哪个前同步码应

以启动该盘存周期的 Query 命令规定的 TRext 位的数值为准。
图 2.15 副载波 T=＞R 前同步码

第三章功能验证平台设计 27
第三章功能验证平台设计
随着集成电路的广泛应用，验证过程对功能正确性及速度、功耗、可靠性都
有严格的要求。在 IC 验证设计中，功能正确性是最基本要求。所以功能验证是整
个验证过程的重要部分，保证 RTL 级的实现满足设计规范的要求。本章介绍功能
验证的基本概念和验证功能途径，在自检查方式的基础上提出本文验证平台的整
体设计，再阐明文中的被验证对象 Tag 芯片的引脚分布。
3.1 功能验证
2.1.1 功能验证定义
功能验证的经典定义[16]是“Functional verification is demonstrating the intent of

a design is preserved in its implementation” 。即功能验证是证明设计目的与实现
的一致性[17][18][19]。要理解功能验证的概念得首先理解设计目的图，如图 3.1 所示：
规范
B
D
E G
H
设计目标 A C 实现
F
图 3.1 设计目标图
设计目的图有三个部分：设计目标、规范和实现。三者理论上的关系应该是逐步
细化、相互一致的。从设计的过程理解三者的关系，首先从设计目标出发，这里
设计的目标是来自架构工程师把用户要求转换成实际设计的一些初步的想法，即
设计的初始目标或目标行为。此时设计目标可能还只存在于工程师的脑子里或是
用自然语言模糊的描述的，具有很高的抽象级[20][21]。然后，这些设计目标经过系
统工程师的细化过程，成为明确的功能规范。设计团队从规范又可得到一个设计
规范，再用 RTL 语言描述设计规范。
功能验证的目标就是使设计目标、规范和实现三个方面完全重合，但在实际
中，不可能完全实现。
2.1.2 功能验证过程
功能验证过程包括验证计划，搭建验证环境，执行验证和回归测试[22]四个步
骤，下面详细介绍各个部分。
(1) 功能验证计划
验证计划定义了必须要验证的内容和怎样验证。验证计划描述了验证问题的
范围，并作为验证环境的功能规范。验证计划可以有不同的划分原则，分类如下：
·根据内容可分为为：激励产生、响应检查、覆盖评估；
·根据要求层次不同可分为：结构要求和实现要求；
· 根据方式分为：必须被验证的内容(功能或设计规范)和怎样验证(验证环境)
规范。
(2) 搭建验证环境
用已经写好的验证计划作为验证环境的功能规范。验证环境的覆盖、激励和
检查三方面内容都应该预先在验证计划中规定。每部分的结构应该尽量使用可重
用结构来规定。搭建验证环境实质上就是写 Testbench 的过程。
要注意搭建可重用的验证环境。因为可重用设计 IP 的使用成为缩短上市时间
的关键，因此可重用验证 IP 也同样变得很重要。这样在搭建验证环境时有两个原
则可以遵循：首先，尽量利用已有的 Testbench 而不是重新搭建。例如对普通硬
件接口有很多的已有的验证 Testbench 可以利用。也可以提前设计验证 Testbench，
以备以后重复使用；其次，在搭建验证环境时尽量写可重用的验证程序。
(3) 执行验证
执行验证的目的是发现那些致命的错误，虽然设计者在设计 RTL 代码时都会
检查基本的功能，但是很多国外大公司设计和验证是分离的，这是验证工程师第
一次接触设计模块，为了尽快熟悉模块，首先要进行少量的仿真来验证模块的基
本功能。执行内容是设计行为的最基本功能。为了容易诊断错误，每次仿真都比
较严格。验证过程是：先进行假设，然后利用仿真证明假设为真，然后再利用证
明后的假设去做更复杂的假设。
(4) 回归测试
回归测试的目标不是整个设计，而只是感兴趣的那部分。目的是发现那些有
可能在运行过程中注入的错误。可以分为经典回归测试和自动回归测试。
经典回归测试使用由验证计划规定的目标测试集，测试验证设计的某个功能
特性。而回归测试集内测试例的选择标准是：
·验证基本的行为；
·能在较少的时间内执行大量的设计；
·过去发现过错误的测试例。
·自动回归测试由自动验证环境执行，根据一定的算法随机产生激励[23]，每
次的回归测试都会提高覆盖率，直到达到覆盖目标[24]。由于使用由覆盖率驱动的
原理和能自动实现而优于经典的方法[25]。
3.2 功能验证方法
功能验证是使用测试平台测试被验证对象的功能。测试平台是根据设计对象
的规则约束而建立起来的。主要是三种功能验证方法：黑盒验证、白盒验证和灰
盒验证[26]。
3.2.1 黑盒验证
在黑盒验证中，设计被当成一个黑盒子，对验证人员而言不知道内部设计细
节，根据设计规范，验证设计是否符合规范。在这种验证方法中，验证和设计相
分离，验证方案与电路的设计方案完全不挂钩，验证人员只关注规范，列出需要
验证的特性，然后组织适当的用例来验证这些特性。
黑盒验证法可以发现下面类型的错误：
·初始化和中止错误；
·接口错误；
·性能错误；
·未实现的或实现不正确的功能。
由于缺乏可观测性和可控性，黑盒验证法很难发现隐藏在设计内部的错误。
3.2.2 白盒验证法
白盒验证法也可称为结构验证法，为验证人员提供了很好的可控性和可观测
性。由于知道设计的内部细节，容易产生特殊情况的激励来检测内部设计的错误。
验证环境的建立相对明确、简单，具有较强的针对性，结果检查相对来说简单一
些。这种方法被广泛应用于设计验证中。白盒验证法的缺点是验证人员要知道设
计内部的细节。
3.2.3 灰盒验证法
灰盒验证法是介于白盒和黑盒验证之间的一种验证方法。验证人员在关心规
范需求的同时又关心电路的详细设计方案，需要依据两者制定验证方案。如同黑
盒验证法，灰盒验证法通过顶层接口控制和观察整个设计，但是又需要验证一些
重要的特定的设计细节。
本文设计 Tag 功能验证[27][28]平台时，清楚 Tag 芯片设计思路和内部细节。因
此对 Tag 进行功能仿真采用的是白盒验证方法，这样大大有利于激励的设计。
3.3 验证平台的设计
在仿真验证中，设计的有效性必须通过设计对激励响应结果得以体现，有几
种方式可以检查设计的响应是否正确。
(1) 方法一：通过人工观测 DUV 输出波形的结果是否正确是常用的一种方
法，这种方法简单、直观。在出错时，通过人工干预，可以立即停止仿真。但是，
其缺点是工作量大，易出错。
(2) 方法二：通过日志的方式，将一些结果输出到文件中。在仿真结果后，
分析日志文件的结果。这种方式的主要缺点是结果分析需要等到仿真结束。
(3) 方法三：自检查方式，它是在仿真过程中，自动将预期的结果和仿真的
输出的结果进行比较，一旦出差，仿真就自动停止。这种方式的优点是能在仿真
的过程中，并行地自动检查设计的正确性[24][25]。
理想情况下，预期的结果通过参考模型体现。图 3.2 给出参考模型、激励、
DUV 之间的关系。通常，建立一个功能非常完善的参考模型比较困难，需要大量
的时间，对于功能比较复杂的设计，纯用 Verilog 或 VHDL 语言比较难以实现的，
可以使用专用的验证语言，如 Syopsys 公司的 Vera 或 Cadence 公司的 testbuilder
等，也可以使用 C/C++等高级语言构造参考模型。
图 3.2 参考模型、激励和 DUV 之间的关系

本论文设计的验证平台是采用自检查方法来实现验证过程中的自动化，根据
图 3.2 提出的 Tag 功能验证平台整体结构，如图 3.3 所示。在这个验证平台中，参
考模型参采用 C/C++语言实现，而激励也是通过 C/C++语言实现。图 3.2 输出比
较对应于图 3.3 中的比较器，这部分也是用 C/C++语言实现。为了使 C 与 Verilog
之间通信还加了两个 PLI 接口程序。
图 3.3 验证平台
该验证平台是基于 Windows 环境设计，采用 Modelsim 软件来进行仿真，同

时还要应用 VC 软件。下面说明验证平台中各模块的功能：
(1) Reader 模块
Reader 模块好比有一个真实存在的阅读器，其实质是阅读器的软件设计。在
测试过程中，它就相当于一个阅读器，同时也可以是多个阅读器。它的主要任务
是负责发送命令，命令代码参考表 2.3 所述，也即使是说此时发送的命令还是标
准的命令代码。
(2) PLI(RD)模块
PLI(RD)模块主要的任务是把 Reader 发过来的命令转换为 Tag 可以识别的编
码方式，同时需要完成的是 C 跟 Verilog 语言的通信。这部分是用 C 语言和 PLI
共同完成的，生产 DLL(动态链接库)文件，在 C 语言程序可以调用 DLL 里面生成
的函数，而 Verilog 通过系统函数来调用 DLL。
(3) Testbench
Testbench 是由 Verilog 语言实现，Testbench 主要负责产生时钟和复位信号。
接收 Reader 发送的 CMD，同时把 DUV 的反应结果编码后输出给 PLI(WR)模块。
(4) PLI(WR)模块
PLI(WR)模块的作用跟 PLI(WR)模块的作用相似。它的通信方向是由 Verilog
到 C。它的任务是接收 Tag 的反应结果，同时处理结果，转换成 C 程序需要的数
据类型。
(5) 参考模型
参考模型也称为 Tag 模块，在后文记作 S_Tag。采用 C 语言编写的符合 EPC
Gen2 协议要求的 Tag 行为模型。在验证平台中，它就相当于一个预期结果，也就
是要求 DUV 的输出结果跟参考模型产生的结果一致。
(6) 比较器
这部分的主要任务是比较 DUV 的结果跟参考模型产生的结果是否一致。如
果一致，则 Reader 接着发送下一条命令。如果不一致，程序就停下来，并把相关
信息输出，根据这些输出信息来寻找 DUV 或者参考模型的错误。
3.4 被验证对象
本论文的被验证对象(DUV)是一款根据协议 EPC Gen2 设计的标签(Tag)，Tag

芯片可以划分为三部分，分别是 RF 射频接口部分、逻辑控制和存储模块。而被
验证部分只包括逻辑控制，不包括 RF 射频接口部分和存储模块。关于 Tag 的工
作原理在已第二章详细地阐明。在这里主要阐明 Tag 芯片的引脚和各引脚的对应
的意义。然后描述各引脚信号在图 3.3 中各模块之间的数据传送关系，此 Tag 芯
片的引脚图如图 3.4 所示。

左边的引脚为输入引脚，
CLK，Reset 信号由 Testbench 产生，
而 CMD 是 Reader 发送过来的命
令。右边的引脚为输出引脚，其中
S_Ready，S_Arb，S_Reply，S_Ack，
S_open，S_Secured，S_Killed 用来
表示 Tag 的当前状态，它们的编码
方式采用 One-Hot 编码。S0，S1，
S2，S3 为对应的 Session，SL 为
SL flag。MOD 为 Tag 的回复值。
图 3.4 Tag 引脚图
此部分的信息将由 PLI(WR)模块
传送给比较器模块。引脚具体信息
如表 3.1 所述。
表 3.1 Tag 端口说明
端口宽度方向说明
CLK 1 输入 Tag 时钟
Reset 1 输入复位
CMD 1 输入 Tag 输入数据
S_Read 1 输出状态
S_Arb 1 输出状态
S_Reply 1 输出状态
S_Ack 1 输出状态
S_Open 1 输出状态
S_Secured 1 输出状态
S_Killed 1 输出状态
S0 1 输出 Sessions
SL 1 输出 SL flag
MOD 1 输出 Tag 输出数据
图 3.4 中的功能验证平台是根据 Tag 芯片的工作原理设计，同时这个平台也
可以用于 Tag 芯片的后仿真。
第四章 PLI 接口程序设计 33
第四章 PLI接口程序设计
Verilog 语言提供了一组标准的任务，在设计时，经常会遇到一些特殊的情况，
需要通过定义自己的系统任务和函数才能实现设计目标。为了做到这一点，设计
者需要与表示设计的内部数据结构以及 Verilog 仿真器的仿真环境进行交互。编程
语言接口(PLI)提供了一组接口子程序，用于访问(读/写)内部的数据表示，并可以
提取仿真环境信息。用户自定义的系统任务和函数可以通过这组预定义的 PLI 接
口子程序来创建[29]。本章详细阐明 PLI 语言的使用和 PLI 在 Modelsim 环境下的
配置，然后详细分析研究验证平台中两个 PLI 程序的设计原理和设计过程，以及
PLI 与 C 程序之间的数据交换方式和它们之间的联系。
4.1 PLI接口语言
4.1.1 PLI的发展
Verilog 编程语言接口是一个范围相当广泛的研究领域。Verilog PLI 的发展经

历了三代。
(1) 任务/函数(tf)子程序(又称实用子程序)组成了第一代 PLI。这些子程序主
要用于以下几类操作：用户自定义的任务和函数、实用函数、回调机制和把数据
写到输出设备。
(2) 存取(acc_)子程序组成了第二代 PLI。这些子程序可直接在 Verilog HDL
内部数据结构中进行面向对象的数据存取。这些子程序能用于访问和修改 Verilog
HDL 描述的多种对象。
(3) Verilog 过程接口(vpi_)子程序组成了第三代 PLI。这些子程序是 acc_和 tf_
功能扩展的集合[29]。
4.1.2 PLI任务
要理解 PLI 任务怎样应用到 Verilog 仿真中，首先需要理解 PLI 子程序的规范

仿真流程，如图 4.1 所示。
设计者使用标准 Verilog 结构和系统任务来描述设计和激励。也可以在设计和
激励中调用用户自定义系统任务。设计和激励文件经过编译被转换成表示设计的
内部格式，这种内部数据结构通常采用 Verilog 仿真器特定的专利格式，对设计者
不公开，因此无法理解。最后，这一内部数据结构被用于运行实际的仿真并产生
输出。
用户自定义系统任务都被连接到一个用户自定义 C 子程序。该 C 子程序以
PLI 接口子程序标准库的方式实现，它可以存取表示设计的内部数据结构。标准
C 子程序可以用 C 编译器编译，标准 PLI 库由 Verilog 仿真器提供。

如果没有 PLI 接口，那么设计者就不得不设法理解表示设计的内部数据结构，
然后才能访问它。PLI 提供了一个抽象层，它允许通过一个对所有仿真器都统一
的接口来存取内部数据结构，因此即使 Verilog 仿真器内部用于表示设计的数据结
构发生了变化，或者使用了新的 Verilog 仿真器，用户自定义系统任务仍然可以使
用。
用户自定义
系统任务No.1
用户的设计描述+激励用户自定义
（Verilog结构+用户系统任务No.2
自定义系统任务）用户自定义
系统任务No.3
Verilog编译
PLI库子程序
用户自定义
设计的内部表示
PLI库子程序
C子程序No.1
（数据结构）用户自定义
C子程序No.2
用户自定义
C子程序No.3
进行各种操作的
仿真
PLI库子程序
仿真输出
图 4.1 PLI 子程序仿真流程

由于 PLI 允许用户自己定义实用工具来存取(读、写或修改)表示设计的内部
数据结构，因此它具有强大的能力，可以对 Verilog 语言的功能进行扩展。PLI 具
有很多种用途，如下所示：
· PLI 可用于定义其它系统任务和函数。典型的例子有监控任务、激励任务、
调试任务和复杂操作等，这些任务和操作难以用标准的 Verilog 结构实现。
· 一些应用软件，比如翻译器和延迟计算工具，可以用 PLI 编写。
· PLI 可用于提取信息，比如层次、互连、扇出以及特定类型逻辑元件的数
目等。
· PLI 可用于编写专用或自定义的输出显示子程序。波形观察器可用它生产
波形、逻辑互连、源代码浏览器和层次信息。
· 为了仿真，提供激励的子程序也可以用 PLI 编写。激励可以自动生成或者

从其它形式的激励转换而来。
· 普通的基于 Verilog 的应用软件可以用 PLI 子程序编写。这种软件可以与
任何 Verilog 仿真器一起工作。因为 PLI 接口提供了统一的存取方式。
设计者可以通过使用 PLI 库子程序来编写自定义的系统任务，然而 Verilog
仿真器必须知道用户自定义系统任务和相应的用户自定义 C 函数的存在，这是通
过把用户自定义系统任务连接到 Verilog 仿真器来实现的。
为了理解这个过程，以一个简单的系统任务$hello_verilog 来说明这个过程。
当$hello_verilog 这个任务被调用时，它只是简单地输出一条消息“Hello Verilog
World”。实现该任务的 C 子程序必须用 PLI 库子程序定义。定义 hello_verilog.c
中的子程序 hello_verilog 如下所示：
#include "veriuser.h"
int hello_verilog()
{
io_printf("Hello Verilog World\n");
}
hello_verilog 子程序非常简单。其中，io_printf 是 PLI 子程序，其功能类似与
printf。下面介绍定义和使用新的$hello_verilog 系统任务的步骤。
在 Verilog 代码中，任务$hello_verilog 无论什么时候被调用，C 子程序
hello_verilog 都必须执行。仿真器需要意识到存在一个名为$hello_verilog 的新系
统任务，并且该仿真器要连接到 C 子程序 hello_verilog。这一个过程称为把 PLI
子程序连接到 verilog 仿真器。不同的仿真器提供不同的方法来连接 PLI 子程序。
虽然各种仿真器的连接方法不尽相同，但是连接过程的基本原理仍然是相同的。
在连接阶段的最后，生产一个包含$hello_verilog 新任务的特殊二进制可执行
文件。例如，连接生成了一个新的二进制可执行文件，设文件名为 hverilog，这
不是惯用的运用于仿真器的二进制可执行文件。仿真时，不需要运行惯用仿真器
可执行文件，只需要运行 hverilog。
一旦用户自定义任务被连接到 Verilog 仿真器中，它就能像任何其它 Verilog
系统任务那样，通过关键字$hello_verilog 来调用。文件 hello.v 中定义了一个名为
hello_top 的 Verilog 模块，该模块调用了用户自定义任务$hello_verilog，如下所示：
module hello_top;
initial
$hello_verilog;
endmodule
仿真的输出如下所示：
Hello Verilog World

前面讨论了一个简单的 PLI 程序使用过程，解释了用户自定义的系统任务怎
样命名，怎样根据用户自定义 C 子程序实现，如何连接到仿真器中，以及在 Verilog
代码中如何调用它。图 4.2 总结了添加和调用自定义系统任务的典型过程。
命名任务$<任务名>
借助于用户自定义的C程序实
现任务，使用PLI裤子程序
把PLI连接到仿真器
在Verilog程序中任何需要的
地方调用：$< 任务名>
图 4.2 添加和调用 PLI 任务的一般流程
4.1.3 PLI子程序
PLI 库子程序提供了对表示设计的内部数据结构进行存取的标准接口，而定
义用户自己的系统任务而编写的用户自定义 C 子程序是用 PLI 库子程序编写的。
在 4.1.2 中，$hello_verilog 是用户自定义系统任务，hello_verilog 是用户自定义 C
子程序，io_printf 是 PLI 库子程序。
PLI 库子程序有两大类，分别是存取子程序和实用子程序。
存取子程序提供了对内部数据结构访问的接口；它允许用户在 C 程序遍历数
据结构并提取与设计有关的信息；实用子程序主要用于在 Verilog 和编程语言的边
界之间传送数据并做一些日常管理维护工作。图 4.3 展示了 PLI 中存取子程序和
实用子程序各自所扮演的角色。
图 4.3 存取和实用子程序的作用
(1) 存取子程序
存取子程序通常也称为 acc 子程序。存取子程序可以完成的工作有：从内部
数据结构的有关项读取特定对象的信息。把特定对象的信息写入内部数据结构的
有关项。
存取子程序可以读取设计中的对象信息。对象可以是下列类型中的任何一种：
·模块实例、模块端口、模块的端到端路径以及模块之间的路径；
·顶层模块；
·原语实例和原语端口；
·网络类型(net)、寄存器类型(registered)、参数类型(paremeterv or specparam)；
·整型、时间型和实型变量；
·时序检查；
·命名事件。
存取子程序的一些特征如下：
·存取子程序总是以前缀 acc_开头；
·使用存取子程序的用户自定义 C 子程序必须调用子程序 acc_initialize()，以
初始化环境。退出时，用户自定义子程序必须调用 acc_close()；
·如果一个文件中用到了存取子程序，那么必须包含头文件 acc_user.h。所有
存取子程序的数据类型和常量都预定义在文件 acc_user.h 中。
存取子程序的类型如下：
·句柄子程序：它们将句柄返回给设计中的对象，句柄子程序的名字总是以
前缀 acc_handle_开头；
·后继子程序：它们将句柄返回给设计中特定类型对象集合中的下一个对象。
后继子程序总是以前缀 acc_next_开头，而且以引用的对象作为参数；
·值变链接(VCL)子程序：这类子程序使用户的系统任务可以从监视对象值
变化的对象列表中添加和删除对象。VCL 子程序总是以前缀 acc_vcl_开头；
·取值(fetch)子程序：它们能够提取各种对象信息，比如完整的层次路径名、
相对名以及其它属性信息。取值子程序总是以前缀 acc_fetch_开头；
·修改子程序。
(2) 实用子程序
实用子程序是各种各样的 PLI 子程序，用于在 Verilog 与用户 C 子程序边界
的两个方向上传输数据。实用子程序通常也是称为“tf”子程序。
实用子程序的一些特征如下：
·实用子程序总是以前缀 tf_开头；
·如果一个文件中用到了实用子程序，那么必须包含头文件 veriuser.h。所有
实用子程序的数据类型和常量都预定义在文件 veriuser.h 中。
实验子程序可用于下列用途：
·获取 Verilog 系统调用任务的信息；
·获取参数列表信息；获取参数参考值；
·把参数新值回传给调用它的系统任务；
·监视参数值的改变；
·获取仿真时间和被调度事件的信息；
·执行日常管理维护任务，例如保存工作区，保存任务指针；
·执行 long 类型的算术运算；
·显示信息；
·挂起、终止、保存和恢复仿真[29]。
4.2 PLI接口程序设计
本文设计的 Tag 功能验证平台是在 Windows 环境下面实现。使用的软件有

VC6.0 和 ModelSim6.0。为了使用 PLI 接口语言，首先需要配置 ModelSim 的 PLI
适配器[31][32]。PLI 配置分通过以下面三步完成：
(1) 将 pli.lib 文件拷贝到 VC 的库文件夹里，为了 VC 软件能够识别 PLI 的数
据类型和对应的函数库；
(2) 编译 veriuser.c 文件，并生成 novas.dll 文件，把 novas.dll 文件拷贝到系统
的 win32 文件夹或者 ModelSim 安装目录下的 win32 目录里；
(3) 修改 ModelSim 的配置文件 modelsim.ini，打开文件并找到 veriuser 变量，
将其改为 veriuser=novas.dll。
经过以上三步操作就完成 PLI application 的配置，要验证 PLI application 的配
置结果可以用 4.1 节里提到 hello 程序来验证配置结果。
在本文中搭建的验证平台用到两个 PLI 接口程序，
接下来分析研究这两个 PLI
接口程序的设计。
4.2.1 PLI(RD)模块
PLI(RD)模块的主要作用是实现 Reader 到 Tag(R=>T)之间数据的传送。从实

质上说，PLI 程序也是 C 程序，是调用 PLI 库的用户自定义 C 程序。这个 C 程序
会产生一个动态链接库(DLL)文件，在 DLL 文件里产生可以让 Verilog 调用的系统
函数，同时产生 C 程序可以调用函数。在设计这个模块之前，需要研究 PLI 与 C
之间的数据存放问题。因为 C 和 Verilog 二者都可以调用 DLL 文件，这样很容易
使内部数据发生冲突。为了避免数据传输发生冲突，在进程开辟了共享内存[33]。
即在 PLI 程序中有如下一段程序：
#pragma data_seg("shared")
unsigned char rt_string[200]={'\0'};
unsigned char rt_time[200]={0};
int rt_length=0; // PLI 与 C 交换信息的标志信息
#pragma data_seg()
#pragma comment(linker,"/section:shared")
从这段程序中可以看出，进程中开辟了 3 个内存空间，分别是 rt_string、rt_time
和 rt_length。R=>T 的数据采用串行输入，rt_string 存放数据串的值； rt_time 存
放该值对应的时间；rt_length 存放串行输入数据的长度。用这种方法可以表示任
何长度的任何数据串。
从 EPC Gen2 协议可知，R=>T 输入编码采用 PIE 编码，关于 PIE 编码方式在
2.2 节已作了详细的说明。帧头在“Query”命令之前发出，表明清点管理循环开
始。而所有其它的命令必须以帧同步信号开始，其中帧头由固定长度的开始分隔
符组成。对于 PIE 帧同步的输入，在 PLI(RD)模块中的 PLI 程序一开始就定义了，
这部分的程序如下：
// PIE 编码的帧同步
rt_string[0]='0';
rt_time[0]=125;
rt_string[1]='1';
rt_time[1]=9;
rt_string[2]='0';
rt_time[2]=35;
rt_string[3]='1';
rt_time[3]=29;
rt_string[4]='0';
rt_time[4]=35;
rt_length=5;
…
上面这段程序对应的波形是图 2.7 中 R=>T 的同步帧头对应的波形。当同步
码输入后，接下来的输入数据是命令，命令对应的代码和长度参考表 2.3。Query
命令输入时与其它命令输入有所不同，它采用图 2.7 中的 R=>T 的前同步码，比
其它命令多一个 TRCal，故在输入命令时还需要对 Query 进行单独处理。关于这
部分从 C 传送到 PLI 的部分程序主要如下：
…
if(*p & 0xf0==0x80) //判断是否是 Query 命令
{
rt_string[rt_length]='1';
rt_time[rt_length]=45;
rt_length++;
rt_length++;
}
for(i=0;i<length;i++) //输入命令
{
temp=p[i>>3]<<(i&0x07);
if(temp>127)
{
rt_string[rt_length]='1'; //数据为“1”的 PIE 码
rt_length++;
rt_length++;
}
else
{
rt_string[rt_length]='1'; //数据为“0”的 PIE 码
rt_length++;
rt_length++;
}
}
…
从上面的程序可以看出，该部分程序主要分两部分，一部分是区分输入的命
令是否是 Query 命令，如果是 Query 命令，就需要输入 TRcal。如果不是，就输
入命令。在这里，从 C 程序接收到的命令是命令代码对应的一组串行数据，PLI
程序需要将这组串行数据转换为 PIE 编码。另一部分是将数据转换成 PIE 编码。
这部分设计的主要思想是：当命令从 Reader 发送过来时，PLI 程序识别传输过来

的数据“0”或者“1”，然后根据 PIE 的编码设置，将其转换成对应的 PIE 编码，
这样就可以传输给 Tag。
接下来对 rt_string 和 rt_time 的具体意义和作用这里说明一下，因为 R=>T 的
数据传输只有一个 CMD，而 CMD 数据是采用串行输入。为了能够直观表示出它
的波形，分别采用数据的值和对应的时间长度来表示波形。CMD 波形对应的值
赋给变量 rt_string，而这个值对应的时间长度值赋给变量 rt_time。用这样的方式
就可以表示任何数据对应的波形。
为了使 Reader 能够顺利地将命令发送给 PLI 接口程序，在 PLI 接口程序的 C
语言部分定义了两个函数，这两个函数的定义[33]如下：
extern "C" __declspec(dllexport) int __cdecl reader_put_string(unsigned char
*p,int length) //定义 reader_put_string 函数
{
…
}
…
extern "C" __declspec(dllexport) int __cdecl rt_flag() //定义 rt_flag 函数
{
if(rt_length>0)
return 1;
else
return 0;
}
reader_put_string 函数是用来输入命令和转换输入命令的编码，而 rt_flag 函数
是标志函数，用它的信息来确定
是否准备好接收下一次命令。
为了能够理解 PLI(RD)模块
工作过程，先分析 PLI(RD)模块
的流程，如图 4.4 所示。从流程
图可以看出 rt_length 是这个流程
的标志信息。rt_length 记录了传
送过来的命令的长度，即每当 C
图 4.4 PLI(RD)流程图
给 PLI 一个命令后，程序会根据
命令的代码和参数等信息来计算
该条命令的长度。输入的命令采用的编码是 PIE 编码，rt_length 最终表示的长度
是对应命令转换成 PIE 编码后的长度。这个长度也决定了 PLI 取走数据的次数。

PLI 每次只取走一个数据，每当 PLI 取走一个数据时，rt_length 就会自动减 1，当
取走所有信息后，rt_length 为 0，这个时候表示 C 可以准备传送下一次命令。
对于 C 把数据传输给 PLI，在前面的论述中已经有详细地设计，接下来分析
研究如何用 PLI 子程序将数据传输给 Tag。数据从 Reader 传输给 Tag 是运用 PLI
修改子程序和句柄子程序。PLI(RD)模块中的部分 PLI 程序如下：
handle value_cmd; //对应命令的值的句柄
handle time_cmd; //对应命令的时间的句柄
*p_steval_delay delay_s，value_s;
value_cmd =acc_handle_tfarg(1);
time_cmd=acc_handle_tfarg(2);
…
if(rt_length!=0)
{
value_s.format=accIntVal;
delay_s.model=accNoDelay;
delay_s.time.type=accTime;
delay_s.time.low=1;
delay_s.time.high=1;
acc_set_value(value_cmd,&value_s,&delay_s);
rt_length--;
acc_set_value(time_cmd,&value_s,&delay_s);
rt_length--;
}
上面这部分程序调用了两个 PLI 子程序，一个是 acc_handle_tfarg[30]，另一个
是 acc_set_value[30]。acc_handle_tfarg 是 PLI 句柄子程序，该函数返回句柄指向，
启动 PLI 子程序的调用系统任务或者函数变量号。假如在 Testbench 中调用为
$read(cmd_value,cmd_time)，那么以上程序中的变量 value_cmd 就是 cmd_value 对
应的句柄。acc_set_value 的作用是为寄存器或者时序用户自定义原语设置值。上
段程序两次用到这个函数，分别给 cmd_value、cmd_time 赋值。
由于 PLI 是用在 Windows 系统下的 ModelSim，根据 ModelSim 对 PLI
application 配置的要求，还需要定义变量 veriusertfs[29]如下：
S_tfcell veriusertfs[]()={
{usertask,0,0,0, c_dll_funtcion-name,0,$task_system_name}
// c_dll_funtcion-name 为 DLL 文件的文件名
// $task_system_name 为 Testbench 调用的系统函数名

{0} // ModelSim 要求必须是 0 结束
}
综上所述，分别完成了 PLI(RD)模块中的 C 部分和 PLI 部分的程序设计。然
后合并两部分程序生成本文需要的 DLL 文件。因为本文中的验证平台是在
Windows 系统下运行，生产的 DLL 文件就需要在 Windows 系统中的命令窗口下
完成。这里将 PLI(RD)模块产生的 DLL 文件取名为 read.dll，按以下两步就可以
产生对应的 DLL 文件[31]：
(1) cl -c -i<work_fold>\include read.c
(2) link -dll -out: read.dll -nodefaultlib:libcmt –export:init_usertfs read.obj pli.lib
shell32.lib < MODELSIM_INSTALL_DIR >\win32\mtipli.lib
如前文所述，产生本文需要的 read.dll 文件，然后将 read.dll 文件拷贝到系统文件
夹 Win32。C 程序就可以调用 read.dll 产生的函数，而 Modelsim 调用它产生的系
统函数。
下面分析研究 C 程序怎样调用 read.dll 文件中定义的函数。在 read.dll 文件中
产生的两个函数，其作用和定义在前面有详细地阐述，为了方便其它 C 程序直接
调用这两个函数，在产生 read.dll 的程序里定义 read.h 头文件[33]，read.h 头文件定
义如下：
#ifndef _dll_reader
#define _dll_reader
extern "C" __declspec(dllexport)int __cdecl reader_put_string(unsigned char
*p,int length)；
extern "C" __declspec(dllexport)int __cdecl rt_flag()；
#endif
这样定义后，其它任何的 C 程序都可以调用 reader_put_string 和 rt_flag 两个函数。
在 Tag 功能验证平台中，Reader 模块是通过调用这两个函数来给 Tag 发送命令。
4.2.2 PLI(WR)模块
PLI(WR)模块的主要作用是将数据从 Tag 传送到 Reader(T=>R)。从 Tag 传送

到 Reader 的数据比较多，包括 Session、SL flag、 State、MOD, 关于这些信号的
具体含义在第三章已经说明。为了使验证平台自动化，该模块还将 Tag 中的随机
数、槽计数、handle 等一些相关信息传送给 C 程序。PLI 程序通过 PLI 的存取子
程序可以取出需要的寄存器或者端口的值。PLI(WR)模块中 C 程序部分和 PLI 程
序部分的流程如图 4.5 所示：
PLI(WR)模块中的 C 程序与
PLI将数存放
PLI 程序是通过 tr_flag 连接在一 Wait 在共享内存
起的。当 Tag 反应结束后，就把

输出信息传送给 PLI，PLI 将得到否
tr_flag==1 否
的信息存放在公共内存。同时给 end_date!=0
tr_flag 标志位置 1，表示数据已是是

经存放好，C 程序可以取走公共
C从共享内存
tr_flag=1
内存的数据。当 C 程序检测到中取走数据
tr_flag 为 1 时，就取走数据。
C的流程 PLI的流程
对于 C 程序这部分，它不但
要完成接收数据的功能，同时还图 4.5 PLI(WR)流程图
要完成解码的功能。因为
Testbench 传送过来的数据是根据固定时间采样而得到的，Tag 输出的波形采用两
种编码方式，一种是采用 FM0 编码，另一种是采用 Miller 编码，关于这两种编码
在 2.3.2 节和 2.3.3 节里面有详细的介绍。至于输出采用什么编码方式，根据 Query
命令里面的 Mode 的值来确定。对于这两种编码方式，其解码部分的主要程序如
下：
…
if(Mode==0)
{//FM decode
state=1;
j=0;
i=0;
if(TRext!=0)
{
i =24;
}
i=i+12;
while(i<tr_length)
{
temp=(tr_string[i/8] >> (6-i%8)) & 0x03;
temp1=temp1 << 1;
j++;
if(state==1)
{
if(temp==0x01)
{
state=1;
}
else if(temp==0x00)
{
temp1=temp1+1;
state=0;
}
else
{
tr_length=0;
return -1;
}
}
else
{
if(temp==0x02)
{
state=0;
}
else if(temp=0x03)
{
temp1=temp1+1;
state=1;
}
else
{
tr_length=0;
return -1;
}
}
if(j%8==0)
{
p[j/8-1]=temp1;
}
i=i+2;
}
p[(j+7)/8]=temp1<<(8-j%8);
*length=j;
tr_length=0;
}
else if(Mode==1)
{//miller 1 decode
state=2;
…
从上面的程序中可以看出，FM0 的解码是根据图 2.8 的 FM0 编码的状态图来
编写的。至于 Miller 编码也是根据对应的状态图来编写。通过上面程序的解码，
就会把 PLI 采样的 MOD 转换为对应信息。
为了是使 PLI 将 Tag 的信息传送给 C 程序，在 PLI(WR)模块的 C 程序部分定
义了 5 个函数，这 5 个的函数的定义如下：
#include "tag.h"
//定义共享内存
#pragma data_seg("shared")
unsigned char tr_string[200]={'\0'};
*int session={0};
*int state={0};
*int sl_flag={0};
…
int tr_length=0;
#pragma data_seg()
#pragma comment(linker,"/section:shared")
// 定义 reader_get_string 函数用它来分析 MOD 的值
extern "C" __declspec(dllexport) int __cdecl reader_get_string(unsigned char
*p,int *length)
…
// 分别根据同 Mode 值来分析 FM0 编码和 Miller 编码
if(Mode==0)
{//FM decode
state=1;
…
else if(Mode==1)
{//miller 1 decode
state=2;
…
}
…
extern "C" __declspec(dllexport)int __cdecl tr_flag()
{
if(tr_length>0)
return 1;
else
return 0;
}
…
// 定义 reader_get_session 函数用来取 session
extern "C" __declspec(dllexport)int __cdecl reader_get_session(unsigned int
*session)；
{
*session=session_c;
}
// 定义 reader_get_state 函数用来取 state
extern "C" __declspec(dllexport)int __cdecl reader_get_state(unsigned int *state)
{
*state=state_c;
}
// 定义 reader_get_s_flag 函数用来取 SL flag
extern "C" __declspec(dllexport)int __cdecl reader_get_sl_flag(unsigned int *
sl_flag)；
{
*state= sl_flag_c;
}
从这段程序结构可以看出，先定义 C 程序和 PLI 程序的公共内存。公共内存的多
少根据设计的需要。然后定义 5 个函数，C 程序通过这 5 个函数来取公共内存的
数据。
PLI(WR)模块中 PLI 部分主要目的是从 Testbench 里面读出需要的 MOD、

state、session、SL flag 信息，同时把读出来的信息转换成整型。该部分程序的主
要部分如下：
handle session;
char* session_value;
int session_size; //定义 Sessions 对应的句柄，值，大小
handle sl_flag
char* sl_flag_value;
int sl_flag_size; //定义 SL flag 对应的句柄，值，大小
handle state;
char* state_value;
int state_size; //定义 state 对应的句柄，值，大小
handle mod;
char* mod_value;
int mod_size; //定义 MOD 对应的句柄，值，大小
session =acc_handle_tfarg(1);
sl_flag =acc_handle_tfarg(2);
state =acc_handle_tfarg(3);
mod =acc_handle_tfarg(4);
…
//取出 session 的值并转换成整型
session_value= acc_fetch_value(sessions, “%b”, null);
session_size=acc_fetch_size(session);
int session_c= pli_conv(session_value,session_size);
//取出 sl_flag 的值并转换成整型
sl_flag_value= acc_fetch_value(sl_flag, “%b”, null);
sl_flag_size=acc_fetch_size(sl_flag);
int session_c= pli_conv(sl_flag_value,sl_flag_size);
//取出 state 的值并转换成整型
state_value= acc_fetch_value(state, “%b”, null);
state _size=acc_fetch_size(state);
int state_c= pli_conv(state_value,state_size);
//取出 mod 的值并转换成整型
mod_value= acc_fetch_value(mod, “%b”, null);
mod_size=acc_fetch_size(mod);
int mod_c= pli_conv(mod_value,mod_size);

…
//数据类型转换函数
int pli_conv(char * in_string, int bits)
{
int conv=0;
int i=0;
int j=0;
for( i=no_bits-1; i>=0; i=i-1)
{
if (*(in_string+i)==49)
{
bin=1;
}
Else if (*(in_string+i)==120)
{
bin=0;
}
Else if (*(in_string+i)==122)
{
bin=0;
}
else
{
bin=0;
}
conv=con+(1<<j)*bin;
}
return conv;
}
从上面的 PLI 部分程序可以看出，里面用到两个实用存取子程序，分别是
acc_fetch_value 和 acc_fech_size。acc_fetch_value 的作用是取得线网、寄存器和指
定格式变量的逻辑值和强度值。在上面的程序中，是用这个子程序去取寄存器的
逻辑值，它的返回值为 char*；acc_fech_size 的作用是取线网、寄存器和端口的位
数，在这个 PLI 程序中是用这个子程序去取寄存器的位数，它的返回值是整型。
为了把 char* 转换成 int 类型，程序需要一个类型转换函数，即 pli_conv 函数。

通过这个函数就可以将 PLI 得到的 char*转换成 C 程序需要的 int 类型。
综上所述，分别完成 PLI(WR)模块中的 C 部分和 PLI 部分的程序设计。合并
这两个程序生成本文需要的 DLL 文件。PLI(WR)模块生产的 DLL 文件命名为
write.dll。
在 write.dll 文件中产生了 5 个函数，这 5 个函数的作用和定义在前面有详细
地说明，为了方便其它 C 程序直接调用这 5 个函数，在这个 DLL 文件中的 C 程
序部分定义 tag.h 头文件[33]，这文件定义如下：
#ifndef _dll_tag
#define _dll_tag
extern "C" __declspec(dllexport)int __cdecl reader_get_string(unsigned char
*p,int length)；
extern "C" __declspec(dllexport)int __cdecl tr_flag()；
extern "C" __declspec(dllexport)int __cdecl reader_get_session(unsigned int
*session)；
extern "C" __declspec(dllexport)int __cdecl reader_get_state(unsigned int *state)
extern "C" __declspec(dllexport)int __cdecl reader_get_sl_flag(unsigned int
*mod)；
#endif
最后对定义的 5 个函数作简要说明，tr_flag()函数是标志位函数，用来判断
Tag 的反应结果是否处理完成。reader_get_string 函数取走处理好的 MOD 的数据。
reader_get_session 函数取走已经处理好的 Session 的数据。reader_get_state 函数取
走已经处理好的 state 的数据。reader_get_sl_flag 函数取走已经处理好的 SL flag
的数据。其它的 C 程序通过调用这 5 个函数来调用 DLL 文件得到需要的信息。
在比较模块是通过这几个函数来得到对应的值与参考模型的值进行比较。
如前文所述，在完成两个 PLI 程序的设计后，验证平台可以直接运用 PLI 程
序来实现相应的功能。
第五章验证平台的搭建 51
第五章验证平台的搭建
验证平台在整体架构上包括 Testbench、参考模型、比较器、Reader、DUV、
PLI 模块，对于各个模块的作用、功能和它们之间的关系在第三章已经阐明。本
章将从每个模块的功能出发，逐一详细分析研究各个模块的设计原理和相互之间
的联系，以及它们之间内部数据的转换。最后讨论 Tag 功能验证平台的验证过程
和应用过程。
5.1 Testbench
Tag 验证平台中 Testbench 模块的主要作用是产生激励，同时把芯片的输出传

送给 PLI 模块。DUV 有三个输入引脚，分别是 CLK、Reset、CMD。CLK，Reset
由 Testbench 生成，而 CMD 是通过 PLI 模块传送过来的 Reader 命令。输出的信
号有 state、session、MOD 和 SL flag，Testbench 通过调用 PLI 系统函数把这些信
息传送给比较器。
5.1.1 CLK、Reset、CMD
CLK、Reset、CMD 为 Tag 的三个输入，这三个激励在 Testbench 中产生，产

生的代码如下：
`timescale 100ns /1ns
…
reg CLK;
reg Reset;
reg CMD;
reg [7:0] cmd_time;
initial
begin
CLK=0;
Reset=0; //产生复位信号，高电平为有效
#20 Reset=1;
#100 Reset=0;
end
always #5 CLK=~CLK; //产生 1000ns 为周期的时钟
…
$Read_RT(CMD,cmd_time,,); //调用 PLI 系统函数，得到 CMD 的 value 和 time
#cmd_time;
…
从这段程序可以看出，Testbench 验证的 DUV 时钟是以 1000ns 为周期。复位
信号高电平有效，复位信号的主要目的是完成 DUV 的初始化，DUV 的初始化是
整个验证的开始。
命令的输入是由 Reader 发送过来的，是通过 $Read_RT 来完成，调用
$Read_RT(CMD,cmd_time,,)，第一个参数表示的是命令对应的值，即 1 或者 0，
第二个参数是 CMD_time 是这个值对应的时间。在程序中延迟#cmd_time 是让其
值保持 cmd_time 的时间不变。这样就可以产生命令的波形，后面缺省的参数为系
统参数，这里不做说明。
5.1.2 State
Tag 芯片共有 8 个状态，由于状态的输出采用 One-Hot 编码，所以共有 8 个

输出引脚。Tag 处于何种状态，该状态对应的引脚就为 1，而其它引脚为 0。为了
输出方便，在 Testbench 中将这 8 个引脚的值编码后赋给 state，然后将 state 输出
给 PLI。这部分代码如下所示：
reg [2:0] state;
…
always (S_Read or S_Arb or S_Rep or …)
if S_Read
state=0;
else if (S_Arb)
…
从这段代码中可以看出，8 个状态引脚的任何一个值发生变化，就会得到一个新
的状态值 state。
5.1.3 Session 和SL flag
Session：用来表示引脚 S0~S3 的输出，S0~S3 分别表示标签提供的 4 个通话。

在这里定义 session={S3,S2,S1,S0}。引脚 SL 表示 SL flag，表示标签应执行选定标
记。对于 SL 本身是一位数据，不用做任何处理就可以直接输出。
当某一条命令执行完后，session、SL_flag、state 这三个值就确定了。Testbench
调用$Witer_TR(sesisin,SL_flag,state,,)函数，把它们对应信息传送给比较器。该系
统函数的调用时，前 3 个参数对应 session、SL_flag、state 的信息，而后面的参数
为缺省，PLI 默认后面的值为 0。PLI 定义的系统函数时，定义的参数跟调用的参
数是一一对应，而在正式应用中，由于某时刻不需要将所有信息输出，参数可以
选择缺省，对应的值默认为 0。
5.1.4 MOD
MOD：表示引脚 MOD 的数据。为了验证的方便，先假定 T=>R 的数据编码

采用用 FM0 编码的方式。根据 EPC Gen2 协议可知，当输出没有任何值时，MOD
端应该保持为低电平，而当有输出值时，MOD 信号应先输出 T=>R 前同步码(如
图 2.11)，然后再输出信号数据。
关于 FM0 的解码由 PLI(WR)模块完成，在 Testbench
里主要是完成 MOD 信号的数据采样和重组。因为信号只有高低电平之分，
Testbench 通过采样的方式把数据存取下来。采样频率跟输入的时钟有关，可以通
过计算得到，同时也可以根据输出部分波形，测量和计算出最小采样频率。通过
计算，选择以 1000ns(Query 设置命令 TRext=1 时)作为采样周期。数据重组的代
码如下：
reg []15:0] mod_value;
reg [1:0] date_counter;
reg [5:0] counter;
…
always ()
#10 if (MOD) begin //MOD=1 的情况
date_counter=0;
if (counter==16) begin //当 MOD 重组后有 16 位数据时输出给 PLI
$Witer_TR(,,,mod_value,,); //调用 PLI 系统函数
counter=1;
mod_value= MOD;
else begin
counter=counter+1;
mad_value={mod_value<<1,MOD};
end
end //MOD=0 的情况
else if (date_counter==3) begin //输出连接有 3 个 0，这表明此时没有输出
if(counter==0) begin
counter=3
end
else begin
counter=0;
$Witer_TR(,,,mod_value,,);
end
else begin
date_counter=date_counter+1;
if (counter==16) begin //当 MOD 重组后有 16 个数据时，输出给 PLI
$Witer_TR(,,,mod_value,,);
counter=1;
mod_value= MOD;
else begin
counter=counter+1;
mad_value={mod_value<<1, MOD };
end
…
根据编码的规则可知，由于 MOD 的值和长度都是不定，则 mod_vlalue 的长
度也是不定的，在输出 MOD 时需要计算 MOD 的长度。为了配合 PLI 对 mod_value
的解码，重组 MOD 时定义 mod_value 的长度为 16，对应的 MOD 值由多个
mod_value 反映。当 counter 为 16 时，就把 mod_value 的值送给 PLI 一次。另一
方面，用 date_value 来记录 MOD 连续出现 0 的次数，当 date_value 的值为 2 时，
表明 MOD 在连续三个时钟的内为低电平时，这就表明 MOD 输出信号已经结束
或者没有输出信号。当 MOD 输出表示已经结束时，Testbench 还将把余下的 MOD
数据传送给 PLI，通过以上过程，完成了一次 MOD 数据输出。MOD 保持低电平
表明没有输出信息，程序会继续等待下一次输出。
mod_value 的值通过调用$Witer_TR(,,,mod_value,,)传递给 C 程序，从这个函
数的调用可以看出，前 3 个参数为缺省值，在 PLI(WR)模块中规定了前三个参数
对应的值应该是 sesisin、SL_flag、state，当不需要输出这三个值时，选择缺省。
这是因为 mod_value 的值在一个命令执行完后，一次输出不能将所有信息输出，
它输出的次数是由输出的数据多少决定。而 sesisin、SL_flag、state 在一条命令执
行完后其值是固定的，一次就可以输出给 PLI。它们的下一次变换需要等到下一
条命令执行完后。所以一般选择这三个信息一起输出，而 mod_value 与它们分开
输出。在$Witer_TR 系统函数中，第 4 个参数才是 mod_value，顺序由 PLI 接口程
序决定。所以在调用系统函数时，参数的顺序要严格按照 PLI 接口的规定的顺序
来调用。
5.2 参考模型
参考模型也称 Tag 模块，是用 C/C++完成的 Tag 行为模型，是符合 EPC Gen2

协议的 Tag 标签。为了方便后面说明，记作 S_Tag。这个模块是验证平台最重要
的一部分，它的正确性直接关系到验证平台的正确与否。它的设计思路和工作原
理完全依据 EPC Gen2 协议。
参考模型主要包括两部分，一部分是解码部分，这部分的主要目的是分清接
收到的命令是什么命令和所对应的参数；另一部分是命令模块，Tag 在不同命令
下的反应是不同的，命令模块根据不同的命令来设计对应命令下的状态反应和回
复值。参考模型的设计流程如图 5.1 所示，从流程图可以看出参考模型中的解码
部分在分析命令的同时还需要区分命令的有效性。
本文的 DUV 设计包括 QueryRep、ACK、Query、QueryAdjust、Select、NAK、
Req_RN、Read、Write、Kill、Lock 等 11 个基本命令，参考模型也是根据这 11
个命令来设计。
在参考模型中，解码模块根据表 2.3 的命令代码区分这 11 个命令和各个命令
对应的长度和所对应的参数，来区分在该参数下的命令是否有效。而命令模块也
会根据 Tag 在这 11 个不同的命令下作出的不同反应来设计所对应 11 个命令模块。
命令模块的设计包括 S_Tag 分别在这 11 个命令下的状态反应、session 反应、MOD
反应、Slot flog 反应，还包括某些系统参数的反应，甚至还包括 EPC 和用户存储
器的读写。参考模型中解码模块和命令模块都比较多，为了分析研究 S_Tag 的设
计，这里仅以 Query 命令来分析研究对应的解码模块和命令模块的设计。
图 5.1 参考模型设计流程
5.2.1 解码模块
S_Tag 的设计原理根据图 2.3 的状态图实现。假如 S_Tag 处于 Ready 状态时，

它可以接收任何命令，这些命令包括无效的和有效的。S_Tag 标签需要通过解码
模块来区分无效的和有效的命令，而标签应忽略无效命令，总的来说，
“无效”是
指，(1)在既定的当前标签状态下不正确的命令，(2)该标签不支持的命令，(3)参数
不正确的命令，(4) CRC 错误的命令，(5)规定错误通话的命令，(6)未被标签以其
它方式确认或执行的命令。而对于有效命令，则应该按照图 2.3 执行。图 2.3 的状
态图是从整体上来反应状态之间的变化，对于某个具体的命令和对应的参数没有
详细说明。
S_Tag 的所有的命令代码参考表 2.3。Query 命令的参数如表 5.1 所述。它的
命令代码为 4 位，即 1000，接下来是参数 DR、M、Trext、Sel、Session、Target、
Q 和 CRC-5。解码模块需要定义这些对应的变量来存放其对应参数的值。当 S_Tag
接收的代码为 1000 时，命令模块就会确定该命令为 Query 命令，然后根据 Query
命令的要求来确定该命令是否有效。由于 Query 命令的长度要求为 22，当长度不
等于 22 时，说明这个命令是无效的；当长度为 22 时，就根据各个参数的长度来
确定各个参数的值。再根据对应的参数是否符合对应的参数要求，需根据不同命
令的要求而定。在 Query 命令中具有 CRC 校验，通过 CRC-5 来判断输入的命令
是否有效。
表 5.1 Query 命令参数
命令 DR M TRext Sel 通话目标 Q CRC-5
位号 4 1 2 1 2 2 1 4 5
描述 1000 0: DR=8 00: M=1 0:无导 00:全部 00: S0 0: A 0–15
1: 01: M=2 频音 01:全部 01: S1 1: B
DR=64/3 10: M=4 1: 采用 10: ~SL 10: S2
11: M=8 导频音 11: SL 11: S3
对于其它的命令，区分其是否有效，也按上述类似的方法来确定。各个命令
对应的要求按照 EPC Gen2 协议的规定来确定。
5.2.2 命令模块
在参考模型中共设计了 11 个命令模块，根据 QueryRep、ACK、Query、

QueryAdjust、Select、NAK、Req_RN、Read、Write、Kill、Lock 等 11 个命令来
设计的。命令模块是参考模型中最重要的部分。
EPC Gen2 协议中规定了每个命令的反应，包括状态变化和回复数据。命令模
块根据协议规定来设计。为了方便理解命令模块的原理，这里还是以 Query 命令
来分析命令模块的设计。
经过解码模块后，收到有效的 Query 命令，Sel 和目标匹配的标签在(0,2Q-1)
的范围内挑选一个随机数，将该数值载入其槽计数器。如果响应该 Query 命令的
标签以零载入其槽计数器，则该标签对 Query 命令的应答应按表 5.2 所示，否则
该标签应保持沉默。
Query 命令可以启动新通话中的或以前通话中的盘存周期。如果处于确认状
态、开放状态或保护状态的标签收
表 5.2 标签应答 Query 命令
到的 Query 命令的通话参数与前通应答
话匹配，则应为该通话倒转其已盘位号 16
标记(即 A→B 或 B→A)。如果处于描述 RN16
确认状态、开放状态或保护状态的
标签收到的 Query 命令的通话参数与前通话不匹配，则应在开始新的盘存周期时
保持前通话的已盘标记不变。处于除灭活状态之外任何状态下的标签应执行
Query 命令，处于灭活状态下的标签应忽略 Query 命令。对应的 Query 应答如表
5.3 所示。设计 Query 命令模块根据表 5.3 来设计。该模块的流程根据当前的状态
来设计，即先确定当前处于什么状态，然后根据当前状态来编写当前 Tag 应该具
有的反应。这里包括比较不同的参数，这些参数符合某种条件，Tag 作出对应条
件下的应答和次状态的改变。这里需要对槽计数器作出说明，由于 DUV 中槽计
数器是通过随机数模块来产生的，所以其值是不确定的。为了使 DUV 的槽计数
表 5.3 Query 应答表
始态条件应答次状态
槽＝0；匹配已盘标记和 SL
反向散射新 RN16 应答
标记
就绪、仲裁、应答槽＜＞0；匹配已盘标记和 SL
－仲裁
标记
其它条件－就绪
反向散射新 RN16；仅当
槽＝0；匹配已盘标记和 SL 新通话与前通话匹配时，
应答
标记状态才从 A 盘存到 B 或从
B 盘存到 A
仅当新通话与前通话匹
确认、开放、保护槽＜＞0；匹配已盘标记和 SL
配时，状态从 A 盘存到 B 仲裁
标记
或从 B 盘存到 A
仅当新通话与前通话匹
其它条件配时，状态从 A 盘存到 B 就绪
或从 B 盘存到 A
灭活全部灭活
注：Query 命令(在除灭活命令的任何状态)开始一个新盘存周期，并可以改变该通话。Query
命令指示标签将新的随机数值载入其槽计数器内。
跟参考模型中的槽计数一致，参考模型则不产生随机数，而是直接使用 DUV 的
槽计数。为了得到这个槽计数，验证平台通过 PLI 把 DUV 的槽计数的值传递过
来，这样使两者保持一致。
对于其它的命令模块，也是按照上述的方法设计。不同的命令对应不同的反
应，其细节上，这里不再作说明。在系统上，其的流程根据图 5.1 设计。这样就
完成了参考模型的设计。
5.3 比较器
比较器是用来比较 DUV 设计的 Tag 反应和参考模型中设计的行为模型的 Tag

反应结果是否一致。为了方便说明，用 V_Tag 表示 DUV 中设计的 Tag，用 S_Tag
表示参考模型中设计的 Tag。为了能够准确比较二者的反应是否一致，在比较器
中定义 state、session、MOD、SL_flag、handle、RN16 等 6 个变量。state 表示 Tag
的当前状态；session 表示当前通话；Sl_flag 表示当前 SL flag；handle 在某些命令
出现，Reader 在发送命令时需要有效的 handle，所以将 handle 输出给比较器，一
方面为了 Reader 发送命令需要，另一方面增大了对比参数，方便出错时找寻错误
原因。RN16 是 Tag 由随机数参数的，这个参数的输出作用跟 handle 的作用类似。
这两个参数是由 Tag 随机产生，不可以估计，所以在验证时以 V_Tag 产生的随机
数为准，保证二者的统一性，这样在方便找出错误的同时，也方便设计验证平台
的自动化。
比较 V_Tag 输出的 6 个参数和 S_Tag 输出的 6 个参数的值，当 6 个参数中的
某一值不相等时，程序暂停，同时输出当前 V_Tag 的 6 个参数和 S_Tag 的 6 个参
数。错误有可能是在 V_Tag 里面，也有可能是在 S_Tag 里面。根据输出的错误信
息确定错误处出在何处，从而达到验
证芯片和参考模型的目的。比较器的输入
流程图如图 5.2 所示，从图中可知，6

个参数是按照一定的顺序依次比较，
否
当某个参数不匹配时，输出如下： State match?
V_Tag compare S_Tag: MISmatch 是
Command: 10000000 01000010 01010

Session 否
State mismatch match?
停止/输出
V_Tag: 是
State:Ready 否
…
Session: S0=1；S1=1；S2=0；S3=0
是
…
S_Tag:
继续/输出
State: Ack
Session: S0=1；S1=1；S2=0；S3=0 图 5.2 比较器流程图
…
从上面的显示可以可知，V_Tag 与 S_Tag 的状态不同，所以程序暂停。这样就需
要去查看错误原因在于何处。当匹配时，程序会继续向下运行，同时也会输出这
六个参数的当前值。输出这些参数是为寻找下一次错误做准备。在查错时，由于
错误的原因不同，错误程度不同，有的错误仅仅靠当前的错误信息是发现不了的，
还需要靠前一次的反应结果来找出错误。有的错误比较隐形，甚至要追溯到前几
次的反应。
5.4 Reader
Reader 是一个符合 EPC Gen2 接口协议要求的阅读器，其实质是用 C++编写

的阅读器的软件设计。对于这个验证平台而言，它的主要目的是发送命令。它跟
Tag 的关系属于主从关系，也就是说只有当 Reader 发送命令给 Tag 时，Tag 才会
有反应。Reader 发送的命令参数根据表 2.3 定义。
Reader 的设计思想也是根据命令设计，Reader 里面设计了 11 个命令函数。
当需要发送某一个命令时，就直接调用这个命令函数，而命令中的某些参数可以
根据设计者的需要预先给出这些参数的值，同时有的参数可以通过随机数来产生。
发送命令的部分程序如下：
for(int i=0;i<1000;i++) //循环 1000，重复 1000 次
{
srd.Select(); //发送 Select 命令
srd.RandAllCommand(); //产生 Select 命令里面参数的随机数
srd.Inventory();
srd.Get_EPC();
srd.RandAllCommand();
srd.read(); //发送 Read 命令
srd.RandAllCommand(); //产生 Read 命令里面参数的随机数
srd.write(); //发送 Write 命令
srd.RandAllCommand(); //产生 Write 命令里面参数的随机数
srd.lock(); //发送 Lock 命令
srd.RandAllCommand(); //产生 Lock 命令里面参数的随机数
srd.kill(); //发送 Kill 命令
srd.RandAllCommand(); //产生 Kill 命令里面参数的随机数
srd.Show_state();
}
…
上面这段程序来自于部分验证命令。发送的命令直接影响验证激励的产生，
为了提高验证的有效性和效率，对于命令的方式顺序和参数都是有所要求。Tag
的工作状态如图 2.3 所示，假如当前 Tag 的状态为 Ready，当接收到的命令不同
时，它的下一个状态不同。即使接收到两个 Query 命令时，也可能因为参数的不
同，其状态和执行的动作都会有所不同。为了提高验证的完整性，发送命令按照
下面几种情形来分类验证：
(1) 先分命令验证。Tag 设计包括 11 个基本命令，对于这 11 个命令，需要逐
一验证，每个命令对应的参数也需要遍历一遍；
(2) 再根据不同状态来验证同一个命令。由于同一个命令在不同的状态下的
反应是不同，所以验证时先确定其状态，即要求在 Ready 状态下，将一个命令所
有相关的参数遍历一遍。验证完一个状态后，换到下一个状态，又将一个命令的
所有相关参数遍历一遍。当在所有的状态下把一个命令的所有参数都遍历一遍，
就表示验证完一个命令；
(3) 为了避免边角情形，在验证过程中，将所有命令的顺序以及参数都采用
随机方式来产生，这样就能验证不可以预料状况和非法命令。
5.5 标签存储器
Readr 向 Tag 发送的命令涉及到 EPC、PC、Kill password 和 Access password

等信息。Reader 需要对 Tag 的存储器读写数据， Tag 存储器的存储体名和对应的
地址分配如图 2.1 所示。详细定义和说明参考 2.1.1 节所述。存储器的大小根据用
户的需要来定义。在被验证的 DUV 设计里面并不包括 Tag 的存储器设计，存储
器是由 foundry 提供的存储器模块来完成的。所以在 DUV 的功能验证中，还需要
存储器的行为模块。
根据 EPC Gen2 协议可知，用户存储器的长度是未知的，它根据用户的需要
来设定。在设计存储器时，定义用户存储器的长度为 16*8，即长度为 128 位。为
了方便验证，需要一个初始化的存储器模块。所以在设计存储器模块时，就直接
给给 Tag 的保留内存，EPC 存储器，TID 存储器都赋了初始值。有了初始值能确
定 EPC、PC、Kill password 和 Access password 的初值，这样才能分析命令的正确
性。
Tag 存储器模块的设计包括存储器的地址分配，读写有效，还需要完成存储
器定义和赋值，这部分程序用 Verilog 实现，部分程序如下：
module EPC_mem(…)；
…
reg [15:0] Mem_user [width_U:0]; //定义四个存储器
reg [15:0] TID [width:0];
reg [15:0] EPC [width:0];

reg [15:0] Mem_pw [width:0];
…
initial
begin
Mem_pw[0]=16’bABCD; //设置 32 位 Kill pasaword
Mem_pw[1]=16’b1234;
Mem_pw[2]=16’bABCD; //设置 32 位 Access pasaword
Mem_pw[3]=16’b1234;
EPC[0]=16’b4231; //设置 PC EPC CRC16
…
end
5.6 验证平台的应用
通过前几节分析，讨论了整个验证平台中各个模块的功能和作用，并分析研
究了各模块的设计思想和工作原理。通过这些模块可以搭建本文的验证平台。接
着本节主要分析验证平台的验证过程和如何使用这个验证平台。
5.6.1 验证过程
验证平台搭建好后，验证过程可以通过如下步骤来完成：
(1) 初始化。初始化包括对 V_Tag 的初始化和 S_Tag 的初始化。对于 V_Tag，
它的初始化是初始化所有触发器和存储器，是由 Testbench 给出的 Reset 信号来完
成 DUV 的初始化；对于 S_Tag 的初始化是程序自身完成。两者的初始化是否一
致直接影响到程序的运行。
(2) Reader 发出命令。当 S_Tag 和 V_Tag 都初始化后，Reader 开始向 Tag 发
送命令。
(3) S_Tag 和 V_Tag 执行命令。当 S_Tag 和 V_Tag 接收到 Reader 发送的命令
后，就执行该命令。
(4) 结果比较。S_Tag 和 V_Tag 执行完的结果传送到比较器中，比较器比较
它们的结果。当结果不一致时，程序就会暂停并打印相关信息；当结果一致时，
返回(2)继续执行下一条命令。
(5) 发完命令。当所有命令都通过验证时就可以结束了。
5.6.2 验证平台的使用
本文的验证平台是在 Windows 系统下完成的，主要应用的软件有 VC6.0 和

ModelSim6.0。这里直接阐述怎样使用这个验证平台。从 5.6.1 节中的验证过程可

知，系统运行时应该先初始化 V_Tag，而且要保证 V_Tag 的初始化时间长度。所
以在运行时先运行 ModelSim，然后再运行 VC。
验证平台的使用步骤按下列几步完成：
(1) 配置 PLI，配置步骤参考 4.2；
(2) 两个 PLI 程序分别生产两个 DLL 文件，分明命名为 read.dll，write.dll；
然后将这两文件拷贝到 windows/system/win32 目录下；
(3) 运行 ModelSim，在 ModelSim 的命令窗口下输入命令如下：
vsim –pli write.dll –pli read.dll testbench //testbench 为 Testbench 模块名
运行这条命令是为了加载 write.dll 和 read.dll 两个 PLI 接口，这样就可以利用
$Read_RT，$Write_RT 两个系统函数；
(4) 运行 V_Tag。此时它先完成初始化，然后等待命令；
(5) 运行 VC。这部分包括了 Reader 发送命令和比较结果部分。
按照上面的步骤，这个验证平台就可以自动化运行。
5.7 验证结果
运用验证平台验证
Tag 芯片，其验证过程的
部分显示如图 5.3 所示。
其报告给出了当前验证
的命令数目和命令。同时
也给出了结果和相关参
数的值。DUV 顺利通过
了 Tag 功能验证平台的
自动化验证。验证了不同
的情况包括在不同的状
态下相同命令的反应、在
固定的状态下不同的命
令反应和命令随机发送
图 5.3 验证显示图
下的反应。Tag 通过了这
3 种情况下的验证，这表明 Tag 芯片的功能符合 EPC Gen2 协议的要求，同时这个
平台也可以用于 Tag 的后仿真。Tag 芯片顺利通过功能验证和后仿真，现已在流
片中。
第六章结束语 63
第六章结束语
国外 RFID 芯片得到广泛应用，而目前国内 RFID 在 UHF 频段应用规模较小，

还有很多技术需要解决。本课题源于公司开发 UHF 频段的 RFID 系统，本文研究
Tag 功能验证是一次 UHF 频段的 RFID 芯片的重大探索，对于促进 RFID 技术的
研究具有重大的意义。
本论文的被验证对象是符合 EPG Gen2 协议的 Tag 芯片。采用仿真来验证 Tag
芯片的功能，在自动检查的方式的基础提出 Tag 功能验证平台的整体设计。讨论
了验证平台中各模块的功能和作用。分析研究了各模块的设计思想和工作原理。
本文首先研究 EPC Gen2 接口协议，分析 Reader 和 Tag 之间的通信原理和工
作原理。根据协议设计了 Tag 行为模型和 Reader 模型。采用 C/C++完成了验证平
台中的 Tag 行为模块、Reader 模块和比较器的设计。
验证平台中的 Testbench、DUV 和 Tag 内部存储器的行为模型都采用 Verilog
语言实现。通过 PLI 程序实现了 Reader 跟 Testbench 之间的数据传送，
和 Testbench
跟比较器之间的数据传送。本文先分析了 R=>T 数据编码和 T=>R 数据编码方式，
根据这两种编码分别设计了对应的 PLI 程序。然后分别分析研究这两个 PLI 的设
计和相关的应用方法。这两个 PLI 程序的目的是完成 C 与 Verilog 语言的通信问
题，是验证平台能自动化运行的关键所在。
完成了各模块的设计就完成了验证平台的搭建。本文最后还分析了 PLI 在
Modelsim 的配置问题和应用。然后分析这个验证平台的在 Windows 系统下的使
用方法，最后还说明了这个验证平台的验证过程。Tag 芯片顺利通过了验证平台
的验证现已在流片中。
为了提高 Tag 验证平台的效率还需要在有些方面继续探索。其中包括：Tag
模块是验证平台的参考模型，它的正确性对验证平台起着关键性重要；另外，
Reader 模块用来产生激励，在设计中某些命令参数采用随机数产生，所以好的随
机数会大大提高验证有效性和效率。对于随机数还需要探索。
由于本人能力有限，文章难免存在缺点和错误，恳请各位专家批评指正。希
望本文能给后来的研究者提供有益的基础和帮助。
致谢 64
致谢
值此论文完成之际，谨向给予过我指导、关心和帮助的人们表示最衷心的感
谢。
首先要感谢我的导师杨银堂教授几年来对我辛勤的培养和真挚的关怀。杨老
师渊博的知识、严谨的治学态度、诲人不倦的精神使我受益匪浅，并将继续激励
着我在今后的工作中积极探索。
本论文是在导师杨银堂教授的关心和悉心指导下完成的。感谢杨老师给了我
这样的机会，使我能接触到最前沿的科研工作。并由衷地感谢他对本课题的热心
指导，从他那里，我不仅学到了严谨、求实的治学作风，更学到了许多做人的道
理，这些将使我终身受益。
感谢课题组的刘毅老师、付俊兴老师给我们营造了良好的学习、科研氛围，
为我们的科研课题顺利完成提供了充足的条件，也要感谢他们在本论文完成过程
中的大力支持和帮助。对课题组的杨孝峰、孟令勇、阳颖、黄丽芳、路璐等同学
在课题的探索、研究及论文的写作过程中所给予的帮助表示真诚的谢意，和他们
在一起学习和工作的日子是我最值得回忆的。
衷心感谢父母对我的养育，感谢家人对我理解和支持。感谢他们在背后默默
的支持我，才能有今天的一点成绩。
最后，向所有关心、爱护、帮助过我的人们表示最衷心的感谢!
参考文献 65
参考文献
[1] Michael M.K. Lin, Charles V Trappey. The Development of Taiwan's integrated
circuit industry. Components Packaging and Manufacturing Technology, Part C,
IEEE Transactions on, Volume 20, Issue 4. Oct,1997. pp. 235-242.
[2] Zhenghua Jiang.The development of integrated circuit industry in China. Design
Automation Conference 2005, Proceedings of the ASP-DAC 2005, Asia and
South Pacific Volume 2.Jan,2005. pp.VI-VIII.
[3] 王琪. 半导体集成电路标准概述.信息技术与标准化. 2006 年第 6 期. pp.
25-28.
[4] Janick Bergeron. Writing Testbenches: Functional Verification of HDL Models.
Kluwer Academic Publishers. 2000. pp. 1-20.
[5] 张多利. 基于功能信息的验证工程学及若干验证技术研究. 合肥工业大学博
士论文.
[6] Andrew Piziali. Functional Verification Coverage Measurement and Analysis.
Kluwer Academic Publishers. 2004. pp. 15-30
[7] 蔡金青. 功能验证和 MCU 软核测试技术的研究. 合肥工业大学硕士学位论
文. 2004. pp. 12-24.
[8] 张殿东. 无线射频识别(RFID)技术. 电信技术. 2005,2. pp. 86-88.
[9] 雷震洲. RFID 标记技术及其应用. 信息网络. 2004,12. pp. 14-18.
[10] 陈志雄.射频识别技术 RFID 发展的前景及应用分析.金卡工程.2004. pp.
49-52.
[11] Oberli, Christian, Landau, Dan. Performance evaluation of UHF RFID
technologies for real-time passenger tracking in intelligent public transportation
systems. Wireless Communication Systems. 2008 ISWCS '08. IEEE
International Symposium . Oct 2008. pp108 -112.
[12] Zalbide I, VicarioJ, Velez, I. Power and energy optimization of the digital core of
a Gen2 long range full passive RFID sensor tag. RFID, 2008 IEEE International
Conference. April, 2008.pp.125 -133.
[13] 武岳山. EPC C1G2 进入 ISO18000-6C 的进程—更新的 ISO/IEC 18000-6 国
际标准[J],中国自动识别技术，2007 年第 1 期. pp. 38-43.
[14] 张纲，杨庆森，程君侠. ISO/IEC 18000-6(CD)研究综述[J],信息技术与标准化，
2004 年第 4 期. pp. 23-28.
[15] EPCTM Radio-Frequency Identity Protocols Class-1 Generation-2 UHF RFID
Protocol for Communications at 860MHz-960 MHz Version 1.0.9. EPCglobal.

January 2005.
[16] Andrew Piziali. Functional Verification Coverage Measurement and Analysis.
Kluwer Academic Publishers. 2004. pp. 15-30.
[17] Radu M.E, Sexton S.M. Integrating Extensive Functional Verification Into
Digital Design Education Education, IEEE Transactions on Volume 51, Issue
3, Aug. 2008 . pp. 385-393.
[18] Xianyang Jiang, Xiaomin Li,Yue Tian. Kai Wang;NICFlex: A Functional
Verification Accelerator for An RTL NIC Design Field-Programmable
Technology, 2007. ICFPT 2007. International Conference on. Dec 2007. pp.
281-284.
[19] Rancea I., Sgarciu V. Functional verification of digital circuits using a software
system. Automation, Quality and Testing, Robotics, 2008. AQTR 2008. IEEE
International Conference on. May 2008. pp.152-157.
[20] Petlin O, Snyder W. Functional Verification of SiCortex Multiprocessor
System-on-a-Chip. Design Automation Conference, 2007. DAC '07. 44th
ACM/IEEE 4-8. June 2007. pp. 906 -909.
[21] Adamov A., Mostovaya K. Syzonenko I., Melnik. A. Electronic System Level
Models for Functional Verification of System-on-Chip. CAD Systems in
Microelectronics, 2007. CADSM '07. 9th International Conference. 2007.
pp.348-350.
[22] Radu M.E, Sexton S.M. Integrating Extensive Functional Verification Into
Digital Design Education Education, IEEE Transactions on Volume 51, Issue
3, Aug. 2008 . pp. 385-393.
[23] Yingbiao Yao, Jianwu Zhang, Bin Wang, Qingdong Yao. A Pseudo-Random
Program Generator for Processor Functional Verification. Integrated Circuits,
2007. ISIC '07. International Symposium. Sep. 2007.pp. 441-444.
[24] Tun Li, Guo Yang, SiKun Li, Wei Dong, RangYu Deng. Experiences Teaching
Functional Verification Techniques with Practical Designs. Microelectronic
Systems Education, 2007. MSE '07. IEEE International Conference. June 2007.
pp. 93-94.
[25] Serrestou Y, Beroulle V, Robach C. Functional Verification of RTL Designs
driven by Mutation Testing metrics. Digital System Design Architectures,
Methods and Tools, 2007. DSD 2007. 10th Euromicro Conference. Aug. 2007.
pp. 222 -227.
参考文献 67
[26] 杜慧敏, 李宥谋, 赵全亮. 基于 Verilog 的 FPGA 设计基础. 西安：西安电子

科技大学出版社, 2006. pp. 132-178.
[27] Janek. A, Steger C, Weiss R, Preishuber-Pfluegl J, Pistauer M. Functional
Verification of Future Higher Class UHF RFID Tag Architectures based on
Cosimulation. RFID, 2008 IEEE International Conference. April 2008. pp. 336-
343.
[28] Assasi H, Farmahini-Farahani A, Hamzeh M, Mohammadi S. Lucas C.
Input Stimuli Evolution for RFID Tag Functional Verification. RFID Eurasia,
2007 1st Annual. Sep 2007. pp.1-6.
[29] 夏宇闻，胡燕祥，刁岚松等译. Verilog 数字设计与综合. 北京：电子工业出
版社, 2004. pp.184-200.
[30] Verilog-HDL PLI Reference Manual version1.0. 1991.
[31] Readme for PLI for debussy 5.3 PLI. pp.63-65.
[32] Modelsim user’s Manual verssion6.0. 2004. pp. 534-576.
[33] 潘爱民，王国印等译. Visual C++技术内幕. 北京：北京清华大学出版社，
2003. pp. 426-448.

1 Tag芯片的功能验证平台的设计 黄海蓉

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

1 Tag芯片的功能验证平台的设计 黄海蓉

Uploaded by

Copyright:

Available Formats

摘要

关键字： 射频识别 阅读器 数字标签 PLI DUV 功能验证

Keywords: RFID Reader Tag PLI DUV Functional Verification

第二章 EPC GEN2 接口协议 ........................................................................................7

2.1 标签选择、盘存和访问 .........................................................................................7

3.1 功能验证 ...............................................................................................................27

4.1 PLI接口语言 .........................................................................................................33

5.1 TESTBENCH .............................................................................................................51

射频识别技术，简称 RFID(Radio frequency identification)是利用电波的非接触

身又不带电源的一种装置。最基本的 RFID 系统由三部分组成：标签 (Tag)：由耦

图 1.4 Tag 芯片的逻辑控制模块图

本文对 Tag 芯片的功能验证的方法和技术进行研究，在自检查方式的基础上

第二章 EPC Gen2 接口协议

2005 年 1 月 EPC C1G2 提请成为 ISO/IEC 18000-6C, 2006 年 6 月 15 日 EPC

问存储的命令有选择该存储体的 MemBank 参数和规定使用 EBV 格式选择该存储

TID存储器 20h EPC[N:N-15] 2Fh

30h 访问口令 [15:0] 3Fh

000002：一个字(EPC 存储器 10H—1FH 存储地址)；

询问机应支持且标签提供 4 个通话(即 S0、S1、S2 和 S3)。标签应在一个盘

标签应执行选定标记 SL，询问机可以利用 Select 命令予以确认或取消确认。

标签应执行如图 2.3 所示的状态和槽计数器。

图 2.3 Tag 状态图

询问机采用图 2.4 所示的三个基本操作管理标签群。每个操作均由一个或一

选择过程要用到命令 Select，询问机可以连续使用 Select 命令选择基于用户

个存储体。连续发出的 Select 命令可以适用于不同的存储体。

盘存指令集包括 Query、QueryAdjust、QueryRep、ACK 和 NAK。Query 启

QueryAdjust 或 QueryRep 命令。QueryAdjust 命令重复以前的 Query 命令，可以令

若处于确认、开放或保护状态下的标签收到其通话参数与前 Query 命令中的

P Query P RN16 FS ACK P PC EPC CRC-16 FS QueryRep

询问机对标签命令的格式如表 2.3 所示。

2.2 R=>T 数据编码

阅读器到标签的通信采用 PIE 编码，PIE 编码的原理是通过定义脉冲下降沿

时间断的范围为 6.25us 和 25us 之间。由阅读器到标签的通信以帧为单位的，

询问机应以前同步码或帧同步开始所有 R=＞T 发信，前同步码和帧同步参见

Rtcal：询问机应设置 RTcal，RTcal 等于数据-0 符长度加数据-1 符长度

图 2.7 R=＞T 前同步码和帧同步

2.3 T=>R 数据编码

标签应答将反射散射的数据编为该数据速率的副载波 FM0 基带或 Miller 调

图 2.8 显示了生成 FM0(两相空间)编码的基本功能和状态图。FM0 在每个边

码符号，代表各 FM0 基本功能的两个相位。这些状态标签还表示键入状态后即传

图 2.8 FM0 基本功能和发生状态图

图 2.9 FM0 符号和序列

示，FM0 发信应始终在每次传输结束 1 dummy 1 1 dummy 1

2.3.2 FM0 前同步码

T=＞R 发信应以图 2.11 所示的两个前同步码开始。至于选择哪个前同步码应

FM0 前同步码 （TRext = 1）

图 2.11 FM0 T=＞R 前同步码

以启动该盘存周期的 Query 命令规定的 TRext 位的数值为准。图 2.11 中所示的“v”

图 2.12 显示了生成 Miller 编码的基本功能和状态图。基带 Miller 按顺序在两

图 2.12 Miller 基本功能和发生器状态图

T=＞R 发信应以图 2.15 所示的两个前同步码开始。至于选择哪个前同步码应

图 2.15 副载波 T=＞R 前同步码

功能验证的经典定义[16]是“Functional verification is demonstrating the intent of

图 3.2 参考模型、激励和 DUV 之间的关系

该验证平台是基于 Windows 环境设计，采用 Modelsim 软件来进行仿真，同

本论文的被验证对象(DUV)是一款根据协议 EPC Gen2 设计的标签(Tag)，Tag

片的引脚图如图 3.4 所示。

Verilog 编程语言接口是一个范围相当广泛的研究领域。Verilog PLI 的发展经

要理解 PLI 任务怎样应用到 Verilog 仿真中，首先需要理解 PLI 子程序的规范

C 子程序可以用 C 编译器编译，标准 PLI 库由 Verilog 仿真器提供。

图 4.1 PLI 子程序仿真流程

· 为了仿真，提供激励的子程序也可以用 PLI 编写。激励可以自动生成或者

1 Tag芯片的功能验证平台的设计黄海蓉

1 Tag芯片的功能验证平台的设计黄海蓉

关键字：射频识别阅读器数字标签 PLI DUV 功能验证

FM0 前同步码（TRext = 1）

tr_flag 标志位置 1，表示数据已是是