巧用RTL原语实现MUX门级映射

对于前端设计人员，经常会需要一个MUX来对工作模式，数据路径进行明确（explicit）的声明，这个对于中后端工程师下约束也很重要。这里介绍一种巧用的RTL原语，实现MUX的方法。闲言少叙，ICerGo！

为了在最终网表里边实现确实的MUX，通常有两种方式。

RTL designer采用了手动实例化(instance)工艺的MUX来实现MUX。但是对于RTL在不同工艺下使用，却造成了一些不便。
一种使用脚本替换的方法，即在综合elaboration的数据库上进行对标工艺的硬替换（replace），这样也需要一套脚本流程。

上述方法可以实现MUX，但是灵活度不是很好，也需要额外的流程和代码量。这里看看DC的解决策略。

RTL原语

DC在做HDL分析，解析（analyze，elaboration)的时候，会对RTL里边的一些原语进行识别，譬如在verilog里边，可以这样使用：

verilog_code  //  synopsys RTL_primitive

这里的primitive是一整套RTL配置，里边有一个功能就是可以对RTL的MUX功能进行有效映射。所以，通过这个RTL 原语，就可以实现设计出MUX的诉求。

带入RTL原语的elaborate

DC的综合阶段，首先是尝试把RTL的逻辑关系影射成为功能描述库，也就是我们常说的GTECH库。但是对于下列两种情况会做较特殊的处理

使用case搭建的语句：DC 默认会处理成SELECT_OP类型
沿触发/电平触发的时序逻辑语句：DC 默认会处理成SEQGEN类型（这里暂不作展开）

对于SELECT_OP类型的逻辑转化，通常来自于类似下列的语句：

DC对于上述语句在elaborate阶段，将其转换成为了SELECT_OP，至于最终实现的器件类型，并不明确。

按照DC的规则：compile会根据实际的时序，面积等考虑，DC会决断把SELECT_OP实现为一个与或非逻辑或者是一个MUX逻辑。相对于RTL实例化一个MUX而言，这里就会带来一些不确定性。

基于此，通过对RTL进行原语级别的配置，让elaborate对case的结果进行约束。示例语法如下：

可以看到，这里的采用了infer_mux （infer：推断）的原语。这个原语可以指导DC对这里的case语句进行MUX_OP实现方式的推断，而非使用默认的SELECT_OP作替换。

通过上例可以看到，同样的代码，在使用infer_mux和不使用的情形下，DC的elaborate给出了不同的答案。

不使用infer_mux，映射为SELECT_OP_4.1_4.1_1: 四输入一输出的组合逻辑结构
使用infer_mux，映射为MUX_OP_4_2_1：四输入，二选择，一输出的MUX结构
由于DC的compile/compile_ultra命令是基于elaborate的映射结果，所以，这里距离完全实现目标就剩compile一个步骤了。

被改善compile结果

Compile完成后，通过verdi打开，可以很方便的查验到结构图：

可以看到，DC工具在infer_mux的dout[0]通路上使用了一个四输入的MUX做了实现，但是在dout[1]的通路上选择的常规的与或非逻辑作实现。
DC这样做是有它的道理的，在本案例中，穿过dout[0]和dout[1]的时序都是满足的，这个时候DC会有先使用面积小的进行实现dout[1]逻辑，但是会依赖infer_mux的指引实现dout[0]上的逻辑：

dout[0]上的MUX4面积： 98.76
dout[1]的与或非逻辑面积：70.092

所以，在原语的控制下，DC强制使用了MUX，而对于其他部分，DC其实是做了更为优化的选择，譬如这里的面积优先选择机制。

MUX树的创建

除过RTL代码保持平滑度的好处外，原语的另一个好处是可以让工具自动选择合适的MUX进行结果构建。譬如当前工艺库最大提供了四输入MUX，如果是一个较大扇入（fan-in）的MUX需求，DC工具可以友好的进行自动“拓展”，灵活构建一个MUX Tree 达到用户需要的结果
譬如下例：RTL书写了一个八输入MUX

elaborate后，DC将它正确识别成了：八输入，三控制，一输出的MUX：MUX_OP_8_3_1_1
工艺库并没有八输入这个大的MUX，这个时候如果使用手动构建会比较复杂。但是DC却可以做自动“拓展”，使用了两个MUX4外加一个MUX2，完成了这个MUX tree的构建，
compile完成后，通过查看网表可以看到，这里最终是一个MUX tree来实现这个八输入MUX，见下图：