浅谈IC验证者眼中的FS

FS者，Feature SPEC也。

Feature者，芯片的功能与特性也。

特性者，Functionality和Performances也。

就像小孩过满月，亲朋好友欢聚一堂，举杯同庆，为新生儿送上期许和祝福。在芯片的设计初期，也需邀请市场、客户和产品等多方专家共聚一室，共同讨论，为待研发的芯片，送上期望和需求。汇聚成册，形成Original Request文档。这些需求，可大致分为功能和规格的需求、性能需求、电气特性需求、功耗和面积的需求等等。

明确需求，形成OR文档是芯片研发诸多环节中，比较重要的一步，但只是第一步。

接下来，众人退去，芯片系统工程师（System Engineer，SE）粉墨登台。根据需求文档（OR），SE开发芯片的特性规格文档，即Feature SPEC。

从应用的角度看，也从规格和特性角度看，FS是芯片唯一最全面和最权威的技术文档。其他芯片的业务文档，可以从FS中裁剪或细化而得到。例如，芯片的用户手册可以是FS的裁剪版（部分特性不对用户开放，而裁剪），电路结构实现的技术文档（Architecture SPEC, AS）是对FS的细化和实现，由IC设计者依据FS进行撰写。

在IC验证者看来，FS通常要包括芯片的业务场景，规格特性，以及业务相关的报文结构、业务处理流程、算法协议等。也包括芯片的微架构图（micro Architecture），以及各个接口的协议、总线协议、子系统和模块的划分和连接、相关信号的列表和时序。也包含芯片的系统工作频率，芯片主频，时钟复位以及低功耗特性等。

详细说来，大致可分为以下五点。

其一、业务功能和应用场景。

或许，这是FS最重要的内容。

SE定义一颗芯片，首先是从芯片的功能开始。简单而独立的功能直接定义即可。复杂的功能通过抽象和归纳，可成为芯片的业务和特性。这些都是站在芯片本身来看。若是站在用户的角度看，每个功能、业务和特性都会有对应的应用场景。芯片的功能分简单和复杂，应用场景也分简单场景和复杂场景。通过描述用户（通常是指软件）如何使用这些功能、业务和特性，可将业务功能和应用场景结合起来。这包括不限于：数据流和控制流如何流动，软件和硬件如何交互和配合。

因此，从一个验证者角度看：SE撰写这部分FS内容时，“要把一碗水端平”，既要站在芯片电路实现的角度思考，也要站在芯片用户使用的角度思考。既要考虑芯片电路的可实现性，也要考虑芯片业务的可验证性。

其二、业务处理流程和相关的报文。

IPO模型通常用来描述业务的处理流程，即 Input-Process-Out。在FS中描述业务的处理流程时，也可遵从IPO的规则。输入的报文，经过怎样的处理和转换，最终以怎样的数据格式或报文进行输出。如果SE能在芯片的微架构图中，用箭头将业务包含的数据流和控制流标注出来，就像战争地图中描述行军路线那样，那真是太好了。

此处的描述只是在抽象度较高的事务级层面，对报文的处理步骤或过程进行抽象的描述。可阐述相关的算法处理和信息转换，而不必涉及到实现的细节。SE需要把握好这个“度”，太宽泛不好，太深入也不好。既不能只见树木不见森林，也不能只见森林不见树木。

其三、微架构图：子系统、模块的组合划分、接口描述和连接关系。

顾名思义，芯片微架构图主要是展示芯片的微架构。芯片的整体功能是由多个小功能组合而成。因此，芯片微架构图就应该由多个较为独立的功能模块构成。对于功能较为紧密的多个模块，可组成子系统。多个子系统和模块可由片上网络相连，通过接口与片外通讯。这些组合成芯片的微架构。

微架构的最小单位是功能模块，其次是子系统。模块或子系统的关键参数可标注到微架构中，但是模块内部的实现细节，不应在微架构中体现。

连接各个子系统和模块的总线，也可看作是一个模块或子系统。例如AMBA。芯片的接口分为通用外设接口（低速）、业务数据传输的Serdes接口（高速）、Debug接口。存储模块分为片内和片外。若是在片内，通常挂在总线上。若是片外，通常由芯片接口与之相连。

验证者可根据微架构图，明确芯片的内部结构，划分验证层次和制定验证策略。

其四、芯片顶层接口的协议：报文、信号和时序。

顶层接口对验证而言，非常重要。毕竟，验证产生的激励需要从接口输入。芯片处理的结果要从接口输出，验证要从接口进行采样。

验证者关注接口，实际上就是关注接口对应的信号位宽、传输方向、关键信号之间时序关系和接口信号所传输的信息报文。

接口信息应该用表格呈现，信号时序需要画出时序图。

其五、芯片的时钟频率、reset、低功耗和DFX设计。

芯片的非主业务的功能也是验证者关心的内容。首要的是时钟和复位。只有给到正确的clock和reset，芯片才能正常工作。所有支持的clock频率和reset信号的组合，都应该被验证过。在业务中间进行复位的场景（在线复位），也是重要的一种验证场景。低功耗特性是芯片中较为常见的特性。伴随clock和power的关闭和打开，芯片进入和退出低功耗状态，而逻辑电路在这个过程通常容易出错。因此，这些是验证者需要重点关注的场景。

如果SE能在FS中重点说明这些场景，那就太好了。比心。

DFX是芯片专门设计的定位手段。SE设计DFX时，要全面而精准的覆盖关键逻辑电路，但不能过于冗余。做到这点，需要SE对芯片的逻辑电路有深入的理解，对芯片的问题定位有丰富的经验。

以上五点就是从验证角度看，FS应该包含的内容。然而，理想很丰满，现实很骨感。现实中有些FS的写法，在验证者看来，是存疑的，是不合时宜的，是有待商榷的。

举例说明：

1.在FS中将业务相关的信号名称、模块（module）名称、寄存器以及各个域的名称都定义。

窃以为，FS应该是从业务和应用层面对业务功能的描述，相对于设计实现，有一定的抽象性。实现细节相关的内容，应在数字逻辑详细设计文档中体现。寄存器相关内容应在寄存器表单中定义，而寄存器表单的制定和设计，应归类为数字逻辑的详细设计。撰写者，应是数字设计工程师（Design Engineer, DE），而非SE。

FS不需要详细到可以编码，但是FS要能够通过细化 和分解 ，可用于代码的实现。不能写出来的 过于抽象 ，细化 时 ，实现不了。也不能写出来的就是细化后的设计文档 。 要求SE要同时具备宏观业务场景的精准把握和微观设计实现的****了然于胸。

2.根据IP支持的最大频率，设定芯片的工作频率（主频）。此频率通常会大于真实应用场景所需要的频率。SE之所以这样做，或是为了芯片的下一版做性能提升的预研。或是为了给后端收敛时序时，预留了降频的空间。方便了后端，方便了数字设计，也方便了自己，唯独苦了验证。

窃以为，FS应该根据应用场景和业务来确定芯片的工作频率。验证者保障芯片本身的特性的正确性，不应保障芯片集成的IP的全部特性的正确性。

3.集成IP的芯片的FS，IP相关内容直接在FS中插入IP的用户手册。

窃以为，不妥，原因同第2点。

4.时序图包含了数字逻辑内部的信号的时序。

窃以为，FS中接口部分的时序图，主要包含接口信号的时序。若需要加内部信号的时序，请在时序图中将该信号与接口信号的时序的关系标注出来。否则，对于这种非接口信号的时序，让验证者有种奇妙的感觉：前不着村后不着店，丈二和尚摸不着头脑。

5.FS中罗列芯片特性时，不分类。

窃以为，FS的Feature有大有小，应分类罗列。耦合度高的多个小特性，可归纳到一个大特性。对于复杂的特性，FS要通过专门的章节进行说明。涉及到的算法原理，处理流程，也要有专门的章节说明。

6.FS冻结之后，仍有源源不断的FS变更。有些变更只有SE和DE知道，验证者被蒙在鼓里，直到TO之后样片回来，被测试出来。

窃以为，FS冻结之后，不能随随便便再修改了。如果非要改，要知会到所有相关的人，并且要征得他们的同意才行。

以上六点是验证者眼中的FS的瑕疵之处。虽说瑕不掩瑜，但美玉无瑕，更加令人喜欢。

验证者嘴里常常嘟囔：“无文档不验证”。须知，此处的“文档”就是写的好的FS。