FPGA芯片全生命周期流程

        对于一颗FPGA芯片，从立项，到需求（芯片，EDA软件，IP），设计，实际的研发和测试，样片TO，回片测试，再研发，量产芯片TO，正式量产芯片的测试，客户的送样，客户反馈的支持，整个环节跨度大，生命周期长，且缺一不可。所以，非常有必要梳理一下流程。否则，很有可能踩坑和delay。

        下面，我们来仔细看一下，这些环节中有哪些关键流程，哪些节点容易出现问题，需要如何控制，降低风险。

        先声明：能力有限，这里列出只是我看到的，并不代表全流程，而且，我本身是软件开发出身，对于一些硬件设计和测试生产，市场销售，供应链的东西并不是很清楚，这里只是记录一下。

1：立项

        立项是决定是否要做一个项目，在芯片领域，一般是指是否做一颗芯片，或者是新采用一种工艺，比如：不同工艺，会有不同的实现要求，工艺切换并不是简单的配置切换，有巨大的成本。

        最终拍板的是老板（或董事会），拍板所需要的资料，需要组织跨部门提供产品立项可行性分析的内容，包括（不限于）：

1.1：市场机会、规模、竞争格局；

        项目的大背景，技术发展趋势，市场需求，行业现状。

        明确立项的目标。如：固定规格芯片，满足市场特定需求，改进现有性能，降低成本。或者是采用新工艺，保证国产替代等。目标一定是可量化的。

1.2：客户需求、竞争力控制点；

        确定目标市场，主要领域（比如：通信，汽车，工业控制，人工智能），并分析这些市场的潜力。要体现竟品的分析，同时也要突出现技术方案的创新点和挑战。

1.3：技术可行性（技术方案/软件/硬件/IP生态和可获得性）；

        很多部分的内容，实际上是合作或者购买完成，需要评估可获得性。
        初步的架构定义：架构可行性——如何支撑不同场景，如何做不同的资源配比。array尺寸，走线，内部互联。大颗粒度的特性，所需资源的定义，重要的原型验证。

1.4：资源需求（开发周期、人力资源、供应链）；

        这里重点是需要有开发计划（包括周期，人力资源），供应链是指外购的一些资源。

1.5：财务分析（成本、ROI）以及风险评估；

        需要成本预算，投资回报分析，风险评估以及应对的策略。

1.6：技术验证与测试计划：

        确定相应的验证方法（仿真，硬件测试，系统验证等），确定测试指标，内容（时序，功耗，抗干扰等），还要考虑可靠性评估和环境适应性的测试。

1.7：知识产权和专利

        如何保护技术创新的知识产权，如果使用到外部的技术或IP核，说明相关授权。

        这里要注意，大多数产品是否做一定是通过市场情况来考虑，但是，芯片是很特殊的，它存在一个国产化替代的问题，必须做为重要的考量。

        总的来说，产品是市场来驱动的。在立项阶段，并不需要对产品的详细定义，但粗粒度的描述以及技术的可行性评估一定是必要的。甚至有些关键点，需要做POC。

   立项要围绕：市场需求，预期回报，技术可行性，风险分析 四大方面来评估。

2：需求

        为什么单独把需求拿出来讲，因为从流程上讲，它一定是一个跨部门的事情，非常容易出问题。需求必须是市场，研发，生产，测试 部门对齐的一件事情。如果没有对齐，那一定会是一团糟糕，相当于后面的所有事情都没有了检查的依据。

2.1：MRD

        我们最重要的两个需求是 MRD（市场部需求），PRD（产品需求）。市场需求是面向客户的客户语言，而产品需求是为了达成客户的需求而设计出的产品中的具体的定义。产品需求会面向硬件芯片的研发，软件EDA工具的研发，重要IP和应用方案的研发，而所有测试部门的测试用例都是和产品需要对齐的。

        对于FPGA 芯片的 MRD，一定是基于系列化的定义。

        一个系列一般是代表一种架构，但同一个架构，为了满足客户不同的需求，会对一些可配置参数和IP进行调整，以形成不同档位，不同功能的产品。形成一个系列，如上图。一般称之为Family 规划。以Xilinx的 Kintex UltraScales+ 系列为例，可以看到 Ku3P 和 KU5p会有不同的参数配置。

对于EDA的软件MRD，示例 如下：

对于芯片需要的组件和IP，MRD示例如下：

2.2：PRD 

        MRD一定要在PRD中找到对应点，并且PRD能够完整支撑MRD，如果无法定义出对应的PRD，或者不认可，MRD应该是不可行的。而如何保障MRD的完整性，这是个难题，一般的做法是，如果有同类产品，可以先借鉴相似的功能定义。

2.3：PRD的拆解   

在使用PRD时，有时候会觉得不够仔细，在IPD规范中，会将它拆成三个等级。
   IR（初始）：产品包级别的需求，一般是针对原始需求的重新描述。
   SR（系统）：系统需求，会包括非功能需求，提的是经过设计之后形成的需求。
   AR（分配）：更细的分配到子模块/子系统的需求，是SR的再分解。

   这样，通过更细致的管理，可以达成对需求更细粒度的定义和管理。

2.4：需求拆解流程

        总的来说，可能需要跨部门组织大量的MRD和PRD的评审：

• 确定不同文档的不同验收标准，确保需求的分解不遗漏且配套/对齐。
  这里也包括相应的验证和测试的方法，需要与需求对齐。

• 各部门从需求源头对齐，明确交付验收标准；

2.5：需求管理

        需求要有冻结机制，并提供严格的变更管理流程。以保证不因为需求变更引入更多的风险。

        注意，需求一定要有对应的验收和测试。

3：研发

支撑产品开发，组织关键评审，信息拉通：，这里不讨论部门内部的流程，只讲一下部门间的流程拉通。

3.1：研发关键流程

• 推动部门间的计划配套落实，明确任务优先级，确保产品如期保质交付；

• 理清各部门职责边界、明确上下游的交付要求与标准；

• 建立TO流程、组织相关评审；

• 及时发布技术评审结果，调整TO时间，分析延迟原因；

 3.2：研发关键节点

        对于研发内部的管理，这里不讲解，只介绍研发之间的一些配合和交互。对于FPGA芯片，最关键的节点是：

• 硬件和软件需要共同进行架构设计。
• 硬件需要交付Primitive 给到EDA软件，及时完成相应的建模。
• 硬件需要提供组件的Validation脚本，给到生产测试部门验证。
• IP 部门需要提供相应IP给到软件部门，进行GUI封装，进行集成测试。
• 生产测试部门测试的报告需要给到硬件部门，及时修改和归避相应的问题，给出方案。

    类似有很多，研发过程中，部门之间的配合。有配合就一定会存在分岐，存在边界不清楚，存在接口和交付件不清楚的情况，那就需要定义清楚。而谁来协调这些问题，需要有专门的部门或小组来完成。存在争议，就上升解决。

4：测试

组织对产品软硬件测试的评审，推动产品验证，包括FPGA系统应用验证的评估：

4.1：测试关键流程

• 测试方案、测试结果的评审（包括样片和量产测试）；

• 推动试运行评估（ODS）（包括生产测试团队能顺利使用相关工具链）；

• 推动产品系统验证（包括量产测试）；

• 跨部门问题评审与解决；

    对于测试，不同阶段的测试，要求完全不一样。下面，以软件为例：

4.2：软件测试要点

        我们以EDA软件为例 说明一下软件产品的测试环节和方法：

        Flow测试：整体EDA流的测试，测试基础用例的稳定性，可用性。

        Device support：主要是针对提供的器件的完整测试。

        Macro-ip，Soft-ip：关注这两种IP的集成测试。

        GUI：关注操作界面的可用性测试。

        QoR：关注运行的一些关键指标的测试。包括和同行产品的对比测试

        UG：对于交付的文档的准确性和完整性，一致性进行测试。

        跨平台/兼容：对于不同操作系统的测试。

        UAT：客户应用案例的测试。

        除了软件，还有硬件数字模拟电路，Primitive组件 的测试和验证，各种IP的测试，样片和量产芯片的测试，都会有完全不同的测试输出。这里不再一一列出。

5：发布

       在正式的发布环节，一般是先在内部发布（面向市场部），然后由市场部做最后验收，获得各种报告和评估，最后完成版本的发布。发布中可能存在部分功能未达成，不匹配，并不是简单就否定，而是做风险评估，对于已知问题，如果评估合理，也可以带着问题发布。

        发布的软件可能是在网上上架提供下载，也可能是由FAE定点发送。发布时，一定要准备好客户反馈和技术支持的通道。提供完整的使用手册，用户使用一旦有问题，可以及时反馈，第一时间得到解决。

• 版本交付和发布（工具和芯片）。包括需求实现确认、跨部门交付、风险评估；

• DEMO板产品发布；

• 其他产品发布；

6：送样

        对于芯片产品，送样非常重要，它是销售的重要环节，一般是作为市场的突破口准备的，需要有额外的重视，公司需要建立送样机制。

• 新产品送样的流程确认；

• 推动各部门为客户技术支持，提供快速响应机制；

• 建立客户及时支持问题单系统；

• 召开项目总结会，整合各部门经验，完善流程改进；