.. Kenneth Lee 版权所有 2023
:Authors: Kenneth Lee :Version: 0.1 :Date: 2023-03-06 :Status: Draft
设计的驱动力问题
我们从一个案例说起。有人做了一个CPU功能的设计，要集成到我的CPU标准定义中。其中 涉及到系统寄存器的访问，这些系统寄存器有些域是保留的。他定义说，这个保留域在读 的时候必须是全0。
我于是就问，为什么这些域读的时候必须是全0？他说，这其实不重要，也可以是全1，我 说，既然这个你不在乎，我们定义标准的，没有必要限制实现者的自由度，你说这个保留 域的读写行为unknown就可以了。
他就说，这样不行，这样会大大提高硬件的实现成本，因为这样验证需要假设多种情况才 能完成整个验证。
我就奇怪了，怎么我不限制你，你倒提高了成本？你完全可以实现成全0或者全1啊，只是 我标准没有要求一定是要多少而已，你定义这东西是为了什么？
他就说：但验证的人会根据你这个标准来决定怎么验。我就不信了：我这是软硬件接口的 标准，它验证的人喜欢另外弄什么别的标准，它大可以另外写去啊。我这里如果要加上对 验证的要求，我就不是现在的写法，我得穷举对验证的所有要求，这才是对验证的要求进 行设计，但我的标准从一开始就说，我这是软硬件之间的标准，保证按我这个要求设计的 硬件，软件一定可以运行。没说要定义怎么验证这个硬件啊。你最多只能说我这个是你验 证的其中一个输入，但你不能说验证有什么要求都要加到我这个定义里面来吧？
如此这般，最后他就承认了：这主要是因为其他芯片手册都有类似的规定，所以他觉得我 们也应该有。
这是本文我想重点谈的问题了。我们很多看惯别人标准的人，到自己写标准的时候，会忍 不住学别人标准表面的那些形式，而不去问“为什么”。但这个“为什么”才是最重要的，因 为你不用别人的标准，要自己写一个，那么一定是你的问题和原始的问题不一样了。那么 那些背后的原因，就肯定不一样了，如果你不关心这个“不一样”，无条件去引入别人的约 束，你会在面对自己新的约束的基础上，再背上过去你可能完全没有必要背负的约束，这 样你根本不可能创新。大部分创新的成败，不是一开始那个Idea，而是基于这个新的Idea, 你怎么把各种细节要求都重新背起来，你不过滤过去引入的条件和你现在面对的条件，等 你把更多的细节背上来的时候，你很快就会寸步难行。一个malloc算法很难吗？加上NUMA, 多线程，锁，协程，安全保护，泄漏监测，这才难啊。你一开始把人家原来基于Hash的算 法的所有约束都背上，然后想用一个基于树的数据结构完成所有这些功能？这个算法能最 终落地吗？
说回这个问题本身，我们研究旧方案的选择是有必要的，但不是学习它的样子，而是理解 它的原因，并且判断这个原因在你这里是否也存在。为什么传统的芯片手册都描述保留位 如何处理的问题？因为这些手册的保留位未来都会用的，那么他们就面对一个问题：如果 我的代码粗暴认为保留位读写什么都可以，那么未来我的硬件设计，这些保留位有了新的 含义，我的旧代码还能跑吗？
那么你有这个需求吗？有，选一个适合你这个方案的约束，尽量把这个约束和你已经引入 的约束结合，这样就没那么快让自己没路走。如果没有，那就不要无条件把这些东西引进 来。
你看，设计到最后，我也决定了要给保留域的读写建立约束，甚至说不定最后和旧方案的 选择是一样的，但这样一个设计过程，我就给我的设计选择设下了一个权重，我在遇到困 难的时候是可以移动它的。但如果我不知道这个背后的原因，这个约束就会变成铁索横江， 谁都不知道它权重几何。到你系统都是这种约束的时候，它就别在想有什么自由度了。