巧妙的mux“移动”

1
从两块128x1024的SRAM中选择一个1024 bit的数据进行ECC校验，输出一个1bit的ECC错误指示信号。

从上图中可以看到，这个data_sel信号需要驱动一个1024 bit的2选1多路复用器，因为驱动能力不足，或者说fanout太大，工具需要插入几级buffer来增加驱动能力。这时候如果data_sel的生成逻辑comb logic本身路径较长，加上后面的大位宽的ECC校验逻辑，这条路径很容易时序违例。

这里简单提一下为什么驱动一个大数据位宽的多路复用器会需要插入几级buffer。

我们知道当输出负载大，也就是C_load大的时候，需要更强的驱动能力来驱动，否则路径单级时延会很大。这个时候如果插入一个大驱动能力的buffer，或者分几级buffer tree来分别驱动不同fanout对于路径时延减小的帮助大于他们自身带来的时延，工具就会进行此操作。

而一个大数据位宽的多路复用器，实际上是由一大堆小位宽的多路复用器组成（工艺库里大多数的mux单元或者AOI单元最大位宽不过4或者8）。这个时候可以简单想象一下如果是1024bit的数据或者甚至是128bit的数据，需要的小mux单元数量都会十分庞大。假设每个4bit位宽的小mux cell的输入电容是1，那么128bit就是32，1024bit就是256。很明显需要大驱动能力的buffer（本身时延很大），或者多个小的buffer组成buffer tree来分组驱动fanout。

那么如何从设计角度优化这条时序路径呢？

2
尝试将该mux向后移动到该通路数据位宽小的节点上：

从上图中可以看到，因为ECC校验输出的结果是1bit的错误指示，并且我们最终只是想得到一个1 bit的指示，而不是1024bit的数据，我们将数据mux移动到数据通路上的1 bit位置，通过将数据的选择改成了结果的选择，成功地避开了大数据位宽的选择，并且保证了功能的一致性。当然代价是需要多做一份ECC校验逻辑。在时序优先的高频设计中，这是可以接受的。

从这个例子中可以看到，数据通路上的选择逻辑，其实是可以任意”移动”的。可能一开始在写功能代码的时候在哪个地方需要做数据选择是根据最初的算法逻辑决定的。但是在时序收敛阶段，如果发现一些地方需要做时序优化，则可以考虑移动这些通路上的mux，看看是否有优化的机会。

当然在这个例子中，如果第二个方案和第一个方案反过来，则是一个优化面积的典型例子。通过mux上移来节省了1个ECC校验逻辑的面积。根据实际项目的需求，可以灵活调整。还是那句话，需要因地制宜地选择需要的设计。