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

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

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

  1. RTL designer采用了手动实例化(instance)工艺的MUX来实现MUX。但是对于RTL在不同工艺下使用,却造成了一些不便。
  2. 一种使用脚本替换的方法,即在综合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,见下图:
在这里插入图片描述
可以看到,DC先是放了两个平行的四输入的MUX进行选择,然后进入到一个两输入的MUX做最后的决断。

作为比对,这里的dout[4],并未采用infer_mux 作实现,可以看到DC使用了常规的与或非结构进行了实现
在这里插入图片描述
使用RTL原语的方法,对于设计人员的工作量大为减少,并且可以不依赖工艺库,DC工具甚至可以自动构建MUX tree,达到了事半功倍的效果。

【敲黑板划重点】

在这里插入图片描述
RTL原语是DC对于RTL的一个特殊指令,通过这套系统可以对elaborate进行显性(explicity )的干预,设计人员可以灵活使用,将设计理念完整的传递到中后端。

参考资料

Synopsys Design Compiler® User Guide

  • 24
    点赞
  • 24
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值