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。
FS写好了，SE就可以像云中的仙鹤，偶尔朝人间鸣叫几声。只有少量的情况，需要向IC验证者和电路设计者，答疑解惑。轻轻点拨，就会令人茅塞顿开，豁然开朗。
FS写的不好，SE就会变成梁间的燕子，飞入寻常百姓之家，细品人间的烟火之气。穿梭在验证者和设计者之间，被大量的问题萦绕着，牵绊着。
FS写好了，验证者可以像迁徙的鸿雁，在天空之中，在白云之间，在霞光之间，从容不迫，向南飞翔。也终能如期抵达温暖的南方。
FS写的不好，验证者就只能做林间的麻雀了，叽叽喳喳，四处乱窜。喋喋不休，忙忙碌碌的提问、讨论、确认、和多轮评审。
作者： 一只特立独行的猪
文章来源：IC验证者之家
推荐阅读
- Jetson Nano上运行OpenCV C++
- Cupkee，让硬件简单、好玩！
- 南大王利民团队新作 | MixFormerV2: 首个基于ViT并在CPU设备实时运行的目标跟踪器！
- 首篇基于Occupancy的单目3D模型 | 让单目3D也搭上最前沿列车
更多嵌入式AI干货请关注嵌入式AI专栏。欢迎添加极术小姐姐微信（id:aijishu20)加入技术交流群，请备注研究方向。
