Hello 大家好，这篇文章想聊一下设计中一个比较常见的需求——多版本交付。如果你是一位IP设计者，经常会遇到这个问题，不同的需求方对同一IP的特性和性能有不同的要求。很明显对于不同的需求都维护一套完全不同的代码交付是不现实的，通常的做法都是同一套代码中利用好模块化，参数化来实现多个功能，性能，功耗，面积的灵活可变。因此在最开始制定方案的时候，如果知道设计今后可能会需要有多版本交付需求，就要考虑做一个灵活易变的设计，便于后续的版本扩展和切换。
1 尽可能使用可配置的模块化的通用基本逻辑单元
对于一些通用的基本逻辑，最好是将其封装起来，根据具体使用场景进行实例化和参数化。之所以将这点放在第一位，是因为着实在自己代码开发过程中发现代码中充斥着太多同样功能的，简单几行代码能描述完的逻辑。比如one hot和binary的转换，onehot选择逻辑等。这样的逻辑每次遇到的时候直接写也没什么问题，但是遇到多版本交付的时候，非常不便于修改，特别容易漏。比如某个特性在某个数据汇集处有多个4选1的逻辑，这个4选1分布在不同的.v文件中，然后在另一个版本想把它改成8选1。因为这些选择逻辑之前都是直接硬写的，每个文件都要重新去修改，无谓的重复工作量加大。此外，如果这些小功能是写在一些比较隐秘的角落（比如祖传代码），在重新开发过程中就容易漏掉，而漏掉的结果如果是性能问题，又很难被验证发现，最终可能就那么躺在一个阴暗的角落直到某天机缘巧合被挖出来发现，那时候项目可能都结束了。
2 根据可配置的功能和规格制定好相应的宏。
使用宏来做版本隔离相信大家都清楚。但在实际项目中经常会发现很多因为宏没做好而导致的乌龙事件，其根本原因主要有两个：
宏的使用没有任何规律，开关特性时容易漏
宏在代码中大量出现，难看又容易搞漏。
对于第一点，一个最常见的原因是有的工程师在使用宏隔离时，不是根据特性，功能来制定相应的宏，而是直接使用版本宏去对功能逻辑做隔离。这样版本一多，宏的名字又没有功能的特定信息，很容易会把可配置的特性搞混，特别不好。好的宏配置最好是有其特定的逻辑层级，自顶而下。最顶部是版本，下面全都是按功能区分。而功能宏也可以同样使用自顶而下的逻辑层级，大的功能宏包裹小的功能宏，而只把小的功能宏应用到具体的功能逻辑中去做隔离。比如：
对于第二点，一个可能的原因是功能宏没定义好，直接使用版本宏导致代码里到处是版本宏。还有一个可能原因是代码风格不好，或者模块划分没做好，导致同一块功能的宏分散在过多不同module中。而最常见的一个原因是需要做隔离的逻辑太多。
对于某个特性需要做隔离的逻辑太多这一点，如果只是考虑配置该特性的有无，可能可以尝试思考一下所隔离的逻辑是否真的需要隔离？这个特性的输入和输出分别是什么，有没有和其他不需要隔离的逻辑有耦合，如果没有的话，是不是直接隔离其输入或者输出就可以了，甚至是只要隔离其输入或者输出的valid信号。如果有耦合，尝试找到耦合之前最后一层隔离逻辑所独有的逻辑输入/输出，将其隔离。因为对于一些输入接死或者输出悬空的逻辑，综合工具可以智能识别并且优化掉，不需要人为写多套代码来实现隔离。比如刚才的逻辑可以写为：
如上图所示，无论功能A和B的逻辑变得多复杂，最终宏只需要控制数据选择信号，就不会出现一个宏控制一大片逻辑的现象。这两种不同的写法本质上是两套代码和一套代码的区别。后者将不同的版本功能切换做到了硬件中，通过工具的自动优化避免冗余逻辑。如果是软件配置硬件的场景，只需要把sel_a和sel_b替换成软件配置的寄存器使能信号就可以了。
3 选择不同规格配置下ppa抖动较小的设计方案
这一点可以说对多版本交付或者微架构演进来说是非常重要的。我们在设计一个功能的时候，首先都会考虑在当前背景下是否能满足指标，比较少会直接考虑到未来的微架构演进，或者需求上的变动对当前微架构可能产生的冲击。如果确定当前设计只用于当前场景，这自然没什么好考虑的，满足当前约束即可。但是如果是IP设计，很经常会需要具备不同性能配置的能力，以及用于不同时钟频率等，在设计之初就考虑到这些无疑会对后面的版本演进迭代有好处。
举个例子，最常见的性能配置选项之一就是增加某处的outstanding能力。而一般来说，增加该处的buffer数量可以实现这个需求，buffer越多，outstanding能力越大。但是增加buffer这一件事情对于整个设计产生的影响除了简单直观的因为buffer本身增加导致的寄存器面积增加以外，还可能会有一些别的影响，这里简单列举几个：
Buffer 读口时序变差，因为选择变多了，如果数据位宽大，congestion也可能变差。
如果对buffer的数据有遍历操作，遍历的逻辑也会加多
对于buffer有效个数的计算，如果采用直接统计valid个数的方式，逻辑也会增加，从而影响buffer满和buffer空的反压和有效信号的逻辑。
如果在做这块buffer逻辑之初就考虑到后面可能的微架构演进或者多版本交付配置问题，在选择这里方案的时候就要尽可能选择一些避免此类影响的方案。首先outstanding能力的增加，如果确定是通过增加buffer个数，那么：
对于1，看下buffer所存数据是否变动可能性较小，如果数据位宽变动可能性较小，可以提前评估一下不同buffer数量的增加在读口对于时序和congestion的影响和目前整体架构的可容忍度。如果buffer所读数据位宽很小，congestion风险不大，那么这里就不需要处理，如果很大，那么这里考虑是否一定要增加buffer个数，可否通过别的方式增加outstanding能力。时序方面，提前做好可能的多拍选择逻辑，或者如果评估时序风险不大，不做处理也可以。
对于2，考虑是否可以一次遍历结果多次使用，通过提前比对buffer写口数据的方式等。
对于3，考虑使用读写使能计数而非直接叠加valid信号来生成buffer_cnt
当然以上只是个人对于此类场景的一些简单思考，也不一定全对，想说明的无非是在做方案的时候需要提前考虑到未来架构的演进，这样在架构演进或者版本变更真正到来的时候能够从容应对，云淡风轻。
实际上说到底，一个设计人员的设计能力最终评价标准无非是ppa，鲁棒性，可维护性，以及返工的频率，和完工的效率。提前把问题思考清楚，方案考虑的点越多自然越好。试想一下一个新的架构或者版本任务下来，别人还在评估怎么做，有什么影响，而你发现只需要在你当前代码的基础上配几个宏就可以交差了，是不是一下子在领导心中的形象就高大起来了。
今天就到这里，欢迎大家继续关注我们后续文章。
