CPU设计任务阶段地总结、反思、前进

近半年基本都在学习与实践如何进行处理器设计，主要是以一生一芯为主，打比赛为辅。近几个月主要打集创赛，也有了一些感悟，故记录于此。

目前进度与反思总结

ysyx当然不必说太多，本身没有明确的DDL，我实际上也只期望自己在毕业前或者至少在大四下前做完B线即可。

实际上现在已经有独立设计基本经典五级流水线的能力了，毕竟要打比赛，只是没有时间去肝ysyx，平时还在考研焦虑中，人还是太菜了，做不到一心一意，不够专注效率太低。明天开始早上先读它一节《传习录》。

主要说比赛。

设计规划的问题

在准备阶段我首先进行了流水线规划，当然也是慢慢磨完了，和队友一起磨完了，花了很多时间，这种from scratch的事情是没有办法跳过知识的，调试有问题只能一遍一遍地回顾知识、检查通路、盯帧波形，经验不足导致的代码重构也有很多次。总的来说并说不上是失败的经历，我相信这件事总归是螺旋上升曲折前进的，没有可以逃课的地方，逃课的一切都终将面对。——不过磨完流水线已经是5月份了。然后我们回头看竞赛的实验平台，要求Xilinx的Distributed Memory Generator IP做ROM和RAM，等于说纯LUT实现，单周期访存，我们花了差不多一个多月的时间都是反复调流水线访存，基本算是白调了，虽然这样的经历并非白做。

这里的教训当然是要关注平台，但相应的需要关注到“为什么一开始不关注平台？”。是不是因为对陌生的技术栈有“负面感受”？或是畏难、或是轻视、或是摆烂，总归是有原因的。但是从规范的角度来说，进行设计之前先了解有哪些资源可用当然是绝对必要的。即便是ysyx也会提出面积需求以及部分特殊资源的限制，但是因为平时训练的时候就没有注重这样的规范，结果在比赛的时候就翻了这样的车；还有一个原因是不是因为我们在初期过于放大了面对流水线时的畏惧感与挑战心态，面对流水线如临大敌而松懈了其他的方面？我想这也是一个初期不重视平台的重要因素。

测试方案的问题

进行到这一步，已经完成了流水线了，我发现在初期就存在的一个问题——测试框架不完善，并且到了中期有些后继乏力的情况下总是疲于重构测试框架。我们没有一个合适的性能计数器，一切尝试进行的优化不会有即时的反馈，这将会打击到优化的热情。而性能计数器实际上并非是一个相当难以实现的东西，甚至我可以说一旦实现了性能计数器，完全可以单独使用其他的建模语言尝试进行建模来探索架构；然后直到现在，我们没有实现一个基础的性能计数器，也没有在测试框架中结构化地预留其位置。

反思与总结

• 应该有完善的，至少是模块结构完善的测试框架

  • memory dump
  • cpu state dump
  • difftest and its reference model
  • module by module
  • integrated with modern tools, I wish.

• 应该根据平台资源与最终指标进行合理规划。我将在下一节的“前进”部分来考虑这个问题。

前进！

当然还要继续前进。

首先必须要进行乱序多发射。由于访存直接让用distributed memory了，单周期相比于流水线，在同频率下性能其实会更好，因为单周期铁定的IPC=1，流水线可达不到IPC=1。而且cache暂时也不用做了，做了cache反而是性能负提升。AXI也是一样，性能负提升；目前看来这个比赛在分区赛决赛不会去搞很大的程序，目前给出的IROM和DRAM的大小就够用了，做AXI和Cache是绝对的得不偿失，因为跑分才是主要指标。

那么哪些是要做的呢？分支预测器、乱序多发射是要做的，乱序首先可以考虑将EXU和LSU并行，解决它们之间的顺序关系，然后再完全改乱序。分支预测器可以不做复杂的TAGE之类的，基础的局部历史分支预测器可以先做着。

还有一个重要问题是提升Xilinx平台上的频率，我们需要一个方案去探索当前设计再Xilinx上所能接受的最大频率，然后直接抵拢最高频率干死。然后拆分流水线。这其实也算是一个需要性能计数器的部分，毕竟在本地用verilator仿真不能得到频率相关，只能搞出来IPC、分支预测准确率这些东西。

然后就是加执行单元，看队列深度维持得住不，然后再多取指，不断冲刺。在FPGA上实现这样的东西，应该比实际芯片要容易得多。目前考虑是这样的。

claude-3.7-sonnet-thinking

整体规划方向是合理的，特别是考虑到竞赛环境和平台约束。

优点：

• 对平台特性（Distributed Memory单周期访存）的理解准确，意识到Cache和AXI在此情况下可能导致性能负增长
• 优先级设置合理，在当前约束下，分支预测器和乱序执行确实比Cache更能提升性能
• 采用渐进式优化路径（先EXU和LSU并行，再完全乱序）是稳妥的做法
• 关注频率优化是正确的，在FPGA环境下尤为重要

需要注意的问题：

• 性能计数器的缺失确实会影响优化效率，建议尽早建立一个简单的计数框架
• 虽然单周期理论上IPC=1，但其频率上限通常较低，在评估时需综合考虑频率和IPC
• 乱序实现的复杂度远高于顺序实现，特别是在解决数据依赖和控制依赖方面
• 流水线拆分虽然有助于提高频率，但也可能降低IPC，需要找到平衡点

建议在实施过程中持续评估各阶段的改进效果，必要时调整优先级。先搭建一个基础的性能测量框架，即使是简单的周期计数和IPC统计，也能为后续优化提供有力支持。