浅谈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。
高效软件开发过程的三个步骤
澜起科技全新第五代津逮®CPU上市！
威尔逊恒流源电路的仿真分析
315m无线模块怎么接收程序？程序是什么？
移位寄存器的工作原理
浅谈IC验证者眼中的FS
日本研发出6G芯片 美国宣布启动6G试验！
冠状病毒影响分析 扰乱全球生产及供应链
二运放组成的锯齿波发生器
141 SMNM+系列Hand Flex同轴电缆概述
通过AI智能化技术，让金融行业迎来了极大利好
行业、政策双重驱动 思必驰提交IPO申请
利用MAXREFDES117测量心率和脉搏血氧饱和度
讨好年轻人 大众POLO Match特别版官图
人工智能在助力疫情防控中的应用情况分析
PN网络里设备名称的重要性
滤波电容器寿命短是什么原因
plc有哪两种工作状态 plc处理的是什么信号
对于农贸市场实验室检测方案的详细介绍
亚马逊自动驾驶汽获得了重大进展,成为第四家获批可以测试纯无人车的公司
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。
高效软件开发过程的三个步骤
澜起科技全新第五代津逮®CPU上市！
威尔逊恒流源电路的仿真分析
315m无线模块怎么接收程序？程序是什么？
移位寄存器的工作原理
浅谈IC验证者眼中的FS
日本研发出6G芯片 美国宣布启动6G试验！
冠状病毒影响分析 扰乱全球生产及供应链
二运放组成的锯齿波发生器
141 SMNM+系列Hand Flex同轴电缆概述
通过AI智能化技术，让金融行业迎来了极大利好
行业、政策双重驱动 思必驰提交IPO申请
利用MAXREFDES117测量心率和脉搏血氧饱和度
讨好年轻人 大众POLO Match特别版官图
人工智能在助力疫情防控中的应用情况分析
PN网络里设备名称的重要性
滤波电容器寿命短是什么原因
plc有哪两种工作状态 plc处理的是什么信号
对于农贸市场实验室检测方案的详细介绍
亚马逊自动驾驶汽获得了重大进展,成为第四家获批可以测试纯无人车的公司