香山处理器敏捷开发总结性论文概述（MICRO-2022已接收）
近日，关于 “香山” 开源高性能 RISC-V 处理器与处理器芯片敏捷开发方法的学术论文被第 55 届 IEEE/ACM 国际微架构研讨会（MICRO 2022）接收。此次 MICRO 录用论文《Towards Developing High Performance RISC-V Processors Using Agile Methodology》介绍了团队围绕 “香山” 开源高性能 RISC-V 处理器开展的芯片敏捷开发研究工作。
近年来，开源硬件与硬件敏捷开发方法受到了学术界与工业界越来越多的关注，但其仍未在工业界得到广泛应用。究其原因，一方面，敏捷开发方法尚未在工业级高性能的开源处理器项目上得到应用，另一方面，如何完成复杂处理器项目的敏捷验证仍然是一个难题。本论文从处理器芯片的功能验证、仿真调试、性能评估等角度介绍了芯片敏捷开发平台 “MinJie” ，其中创新性地提出了基于规则的敏捷验证方法、基于系统快照的敏捷仿真调试方法等。
基于参考模型的协同仿真与在线错误检查是硬件验证的通用方法，由于设计规范与实现之间存在的差异性，现有传统方法通常需要基于特定的设计需求完成参考模型的搭建。在敏捷开发背景下，硬件设计快速迭代，在验证者角度看到的设计行为具有不确定性，多种实现均是合法的，这造成了参考模型的开发与维护难题。论文创新性地提出了基于规则（Diff-Rule）完成对设计行为非确定性的刻画，有效降低参考模型与验证框架的开发与维护成本，提高硬件验证效率。论文进一步发现并明确了 RISC-V 处理器与典型多层 Cache 结构中的非确定性行为来源，实现了针对通用 RISC-V 处理器的协同仿真验证框架 DiffTest，已成功地应用于香山、一生一芯等项目的开发过程中。
软件 RTL 仿真是硬件验证与调试的常用手段，出错时的错误现场复现则是调试时最耗时的一步。论文提出了一种轻量级仿真快照技术 LightSSS，利用操作系统提供的 fork 接口完成对仿真进程的定期快照，并在仿真出错时恢复上一个快照进行调试。实验评估结果显示，LightSSS 相比当前业界最优的仿真快照方案 LiveSim 有显著优势，成功地将仿真快照开销从 10% ~ 20% 降低至 0.01%，大幅度地提高了硬件开发时的调试效率。
除此之外，MinJie 还提供了（1）支持 Chisel 敏捷设计的信息抓取工具，如信息探针Probe、微结构调试数据库 ArchDB、日志调试工具 Waveform Terminator；（2）面向 RISC-V 处理器的基于程序片段采样的敏捷性能评估工具，支持在 24 小时内完成处理器的 SPEC CPU2006 评分估计，实测误差在 5% ~ 10% 范围内。
MinJie 平台仍在持续地完善中，更多的敏捷开发工具将会在未来工作中展示，后续“香山”团队还计划发布一本关于 MinJie 的使用手册。
国际微架构研讨会（International Symposium on Microarchitecture，MICRO）是计算机体系结构领域最顶级的国际会议之一，由 IEEE（Institute of Electricaland Electronics Engineers，电气和电子工程师协会）和 ACM（Association for Computing Machinery，国际计算机学会）共同举办，自 1968 年起每年举行一次。MICRO 会议汇聚了微架构、编译器、芯片和系统相关领域的研究人员，就传统微架构主题和新兴研究领域进行技术交流，包括处理器与存储体系结构、多核系统架构、处理器微结构、云计算、物联网、互联网络、硬件加速器、量子计算、近内存计算、近似计算、架构建模与仿真、系统评估与测量方法等。2022 年的 MICRO 会议将于 2022 年 10 月 1 日至 5 日在美国伊利诺伊州芝加哥举办，会议共收到 369 篇投稿，录用 83 篇论文，接收率为 22.5%。
包云岗评论：这其实并不是一篇介绍香山本身架构的文章，而是一篇介绍香山开发背后的敏捷设计方法的学术论文。正如前段时间我在朋友圈中提到（图 1），我们在开发香山的同时，同步实现了一套不同于工业界传统的芯片敏捷设计新方法、新流程和新平台。在投稿的论文中，我们暂且命名为 “MinJie” （图 2 ）。
图 1在朋友圈对 MBIST 技术文章的评论
图 2MinJie 平台
香山项目是从 2020 年 6 月开始建开源代码仓。但随着香山项目的演进，我们越来越深刻地认识到，原来这套集成了新方法和新工具的 “MinJie” 平台才是香山开源项目最有价值的东西，这是冰山水下面的部分（图 4 ）；而香山芯片架构其实是这套流程副产品，是冰山水上面的部分。正是因为有了 MinJie，我们才能快速迭代优化，不断演进新版本。
图 3香山芯片与敏捷开发基础设施
这篇 MICRO 论文还有三个意义：
① 这篇文章介绍了我们在开发香山过程中时遇到的一系列问题以及如何解决，这表明香山作为一个开源芯片项目，它本身就蕴含了很多国际前沿问题。某种程度上，香山自身成为了一个国际学术前沿阵地，大家可以围绕香山挖掘更多学术前沿问题。
同时工业界又有不少企业在对香山进行产品化改造和架构探索（图 4 ），因此香山可以成为连接学术界与工业界的桥梁，让学术界的创新成果更快地应用到产业界中（图 5 ）。我们也很期待未来能有越来越多的学者围绕香山开展研究。
图 4香山 V2 与 V3 项目企业合作情况
图 5香山的 “产学研” 协作模式
② 香山项目是对芯片领域如何通过开源模式实现联合开发的一个很好的实践。这篇 MICRO 论文共有 33 位作者，除了中科院计算所，还有来自深圳鹏城实验室、北京大学、南京大学、深圳大学等科研院校的老师、学生和工程师，还有来自微核芯的企业专家——如果不是开源模式，几乎不可能形成这种联合开发团队。这种模式也得到越来越多的认可，如今有更多的企业参与到这个联合开发团队中，开展香山的后续迭代优化（图 4 ）。
③ 过去几年我们一直推崇“科研重工业模式”（CCCF 卷首语 | 伯克利科研模式的启发）。但很多人认为这类科研模式需要大量工程投入，创新性不足。过去几年，我们通过香山项目的实践，反而更深刻地体会到“科研重工业模式”的价值——看似工程量很大的项目，其实蕴含着很多的创新机会；解决香山本身的问题，就是在做很多创新性工作了。这也让我们对在国内开展“科研重工业模式”更加充满信心。
最后，再次感谢大家对香山的关注和支持！
完 敏捷开发，瀑布模型
1.瀑布模型
1.1 瀑布模型介绍
1970年温斯顿·罗伊斯（Winston Royce）提出了著名的“瀑布模型”，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。
1.2 瀑布模型核心思想
瀑布模型核心思想是按工序将问题化简，将功能的实现与设计分开，便于分工协作，即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
1.3 瀑布模型有以下优点
(1)为项目提供了按阶段划分的检查点。
(2)当前一阶段完成后，您只需要去关注后续阶段。
(3)可在迭代模型中应用瀑布模型。
增量迭代应用于瀑布模型。迭代1解决最大的问题。每次迭代产生一个可运行的版本,同时增加更多的功能。每次迭代必须经过质量和集成测试。
1.4 瀑布模型有以下缺点
(1)在项目各个阶段之间极少有反馈。
(2)只有在项目生命周期的后期才能看到结果。
(3)通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
(4)瀑布模型的突出缺点是不适应用户需求的变化。
2.迭代模型
2.1 什么是迭代模型
在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：需求、分析设计、实施和测试工作流程。实质上，它类似小型的瀑布式项目。RUP认为，所有的阶段都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。
2.2 迭代模型的使用条件
(1)在项目开发早期需求可能有所变化。
(2)分析设计人员对应用领域很熟悉。
(3)高风险项目。
(4)用户可不同程度地参与整个项目的开发过程。
(5)使用面向对象的语言或统一建模语言（Unified Modeling Language，UML）。
(6)使用CASE（Computer Aided Software Engineering，计算机辅助软件工程）工具，如Rose（Rose是非常受欢迎的物件软体开发工具。）。
(7)具有高素质的项目管理者和软件研发团队。
2.3 迭代模型的优点
与传统的瀑布模型相比较，迭代过程具有以下优点：
(1)降低了在一个增量上的开支风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。
(2)降低了产品无法按照既定进度进入市场的风险。通过在开发早期就确定风险，可以尽早来解决而不至于在开发后期匆匆忙忙。
(3)加快了整个开发工作的进度。因为开发人员清楚问题的焦点所在，他们的工作会更有效率。
(4)由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。因此，迭代过程这种模式使适应需求的变化会更容易些。
3.敏捷开发模型
3.1 什么是敏捷开发
是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本。能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。敏捷建模（Agile Modeling，AM）的价值观包括了XP的四个价值观：沟通、简单、反馈、勇气，此外，还扩展了第五个价值观：谦逊。
3.2 敏捷开发特点
(1)人和交互 重于过程和工具。
(2)可以工作的软件 重于求全而完备的文档。
(3)客户协作重于合同谈判。
(4)随时应对变化重于循规蹈矩。
项目的敏捷开发,敏捷开发小组主要的工作方式可以归纳为：作为一个整体工作； 按短迭代周期工作； 每次迭代交付一些成果:关注业务优先级； 检查与调整。
最重要的因素恐怕是项目的规模。规模增长，面对面的沟通就愈加困难，
因此敏捷方法更适用于较小的队伍，40、30、20、10人或者更少。
4.螺旋模型
螺旋模型是一种演化软件开发过程模型，它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控。螺旋模型最大的特点在于引入了其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减小损失。同时，在每个迭代阶段构建原型是螺旋模型用以减小风险的途径。螺旋模型更适合大型的昂贵的系统级的软件应用。
1988年，巴利·玻姆(Barry Boehm)正式发表了软件系统开发的“螺旋模型”，它将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。
螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动：
四种象限
（1）制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；
（2）风险分析：分析评估所选方案，考虑如何识别和消除风险；
（3）实施工程：实施软件开发和验证；
（4）客户评估：评价开发工作，提出修正建议，制定下一步计划。
螺旋模型由风险驱动，强调可选方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。
5.快速原型模型
快速原型模型需要迅速建造一个可以运行的软件原型 ，以便理解和澄清问题，使开发人员与用户达成共识，最终在确定的客户需求基础上开发客户满意的软件产品。 快速原型模型允许在需求分析阶段对软件的需求进行初步而非完全的分析和定义，快速设计开发出软件系统的原型，该原型向用户展示待开发软件的全部或部分功能和性能；用户对该原型进行测试评定，给出具体改进意见以丰富细化软件需求；开发人员据此对软件进行修改完善，直至用户满意认可之后，进行软件的完整实现及测试、维护。
原型是指模拟某种产品的原始模型，在其他产业中经常使用。软件开发中的原型是软件的一个早期可运行的版本，它反映了最终系统的重要特性。
快速原型模型又称原型模型，它是增量模型的另一种形式；它是在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系统的开发工作。快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。
快速分析
在分析人员与用户密切配合下，迅速确定系统的基本需求，根据原型所要体现的特征描述基本需求以满足开发原型的需要。
构造原型
在快速分析的基础上，根据基本需求说明尽快实现一个可行的系统。这里要求具有强有力的软件工具的支持，并忽略最终系统在某些细节上的要求，如安全性、坚固性、例外处理等等，主要考虑原型系统能够充分反映所要评价的特性，而暂时删除一切次要内容。
运行原型
这是发现问题、消除误解、开发者与用户充分协调的一个步骤。
评价原型
在运行的基础上，考核评价原型的特性，分析运行效果是否满足用户的愿望，纠正过去交互中的误解与分析中的错误，增添新的要求，并满足因环境变化或用户的新想法引起的系统要求变动，提出全面的修改意见。
修改
根据评价原型的活动结果进行修改。若原型未满足需求说明的要求，说明对需求说明存在不一致的理解或实现方案不够合理，则根据明确的要求迅速修改原型。
6.几种模型间的对比
传统的瀑布式开发，也就是从需求到设计，从设计到编码，从编码到测试，从测试到提交大概这样的流程，要求每一个开发阶段都要做到最好。
特别是前期阶段，设计的越完美，提交后的成本损失就越少。
迭代式开发，不要求每一个阶段的任务做的都是最完美的，而是明明知道还有很多不足的地方，却偏偏不去完善它，而是把主要功能先搭建起来为目的，以最短的时间，
最少的损失先完成一个“不完美的成果物”直至提交。然后再通过客户或用户的反馈信息，在这个“不完美的成果物”上逐步进行完善。
螺旋开发，很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。
敏捷开发，相比迭代式开发两者都强调在较短的开发周期提交软件，但是，敏捷开发的周期可能更短，并且更加强调队伍中的高度协作。
敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性。
适应性的方法集中在快速适应现实的变化。当项目的需求起了变化，团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化。
孔明 发表于 2022-7-22 16:03
1.瀑布模型
1.1 瀑布模型介绍
1970年温斯顿·罗伊斯（Winston Royce）提出了著名的“瀑布模型”，直到8 ...
这是软件开发模型 {:12_360:}
页:
[1]