在线咨询
eetop公众号 创芯大讲堂 创芯人才网
切换到宽版

EETOP 创芯网论坛 (原名:电子顶级开发网)

手机号码,快捷登录

手机号码,快捷登录

找回密码

  登录   注册  

快捷导航
搜帖子
楼主: yaya126

[原创] low power RTL 设计优化

[复制链接]
发表于 2017-9-12 11:59:07 | 显示全部楼层
支持楼主,持续更新
发表于 2017-9-12 13:48:53 | 显示全部楼层
持续关注!!!!!
 楼主| 发表于 2017-9-12 14:28:01 | 显示全部楼层
本帖最后由 yaya126 于 2017-9-12 14:38 编辑

Reduce Logic size:

Area大通常意味着power大,站在save power的角度,减少面积,减少逻辑单元,和降低功耗的方向是一致的。


Logic share


有些逻辑的throughput要求不高,一份逻辑分时进行N次计算,等效于N份逻辑在一定时间内计算一次。复用之后计算总量一样,但静态功耗会降低。当然需要考虑1份逻辑N次计算带来的副作用,计算latency加长是否可以接受。


Multiplier

乘法器,在这特指变量乘变量,如果是变量乘以常数,综合工具都是综合成加法器,不在考虑范围内。

同等bit数,乘法器比加法器大许多,对于每个乘法器,我们都


   1) 需要仔细review它的使用是否必须,
       2) 使用的时候位宽是不是可以降低,乘法器位宽严重影响综合面积和timing, 在计算的时候,即使是signed的数,也不要轻易添加N bit 最高位(符号位),           建议使用verilog 2001 语法, 用 $signed(A[dw-1:0])* $signed(B[dw-1:0]), 千万别写成 {{(dw){A[dw-1]}}, A[dw-1:0]}*{{(dw){B[dw-1]}}, B[dw-1:0]}, 虽然输出位宽为 2dw。
   上面提供脚本 power_check.pl –mul -d . 可以抓代码中所有的乘法器来集中review)
      3)乘法器是不是前后组合逻辑很多,造成综合工具为了meet timing而产生一个超级并行(巨大)的组合逻辑(这个在logic balance也会提到),

      4)“乘加”逻辑是不是可以转变成“加乘”逻辑, 这里乘加指的是A*mul B *mul 乘完后寄存后再加,还是(A+B*mul 后再寄存, 如果在同一拍内,即使写成A*mul+B*mul, 综合工具也会优化成(A+B*mul, 但建议在代码上体现先加后乘。
  下面是4bit与15bbit “乘加” ,“加乘”面积比较, “乘加”面积几乎大一倍

  

ADD_before_Mul or Mul_before_ADD

  
  

Area(um2)

  
  

Multiplier number

  
  

ADD_MUL =bit4*(bit15+bit15)

  
  

543

  
  

1

  
  

MUL_ADD =bit4*bit15+bit4*bit15

  
  

919

  
  

2

  
 楼主| 发表于 2017-9-12 15:17:17 | 显示全部楼层
本帖最后由 yaya126 于 2017-9-12 15:20 编辑

Reduce Logic size
Divider optimizationN/M:

乘法器通常1拍内完成,但除法器少有能1拍完成的。乘法我们可以直接在代码里面写“*”号,综合工具通常能给我们满意的结果,但除法器,极少数情况下我们直接写“/”,大部分情况我们需要单独inst 除法module.


标准除法器NM 都是变量):

基本的设计思路是移位减,如果每个cycle计算被除数1bit, N/M, 我们需要N拍,如果每个cycle 2bit则需要(N+1)/2 拍,这样的除法器面积都不大,但计算latency长。同时EDA公司也提供的design-ware除法器,速度更快,面积也更大。当然还有一种查LUT表的除法器,但我没用过,不好评价


特殊除法器

1)除数是2的幂次,如2, 4, 8,很多人会想到直接移位,对于被除数是正数来说移位绝对正确,但如果被除数是负数,除法结果收敛到0,移位结果收敛到-1

-5/64=0, -5 == 5B'1-1011, 右移后,变成5b'1-1111,= -1,两者结果不同。

判断高位是都全为1,如A[m,0]>>n, 需要确认A[m,n]的情况

             |A[n-1:0] =1'b0? A[m,n] + 1'b1 : A[m,n];

2)除数是常数,最好为 (2的幂次+/-1), 5,7,可以考虑泰勒展开,用2的幂次和来近似。

如下 用最近的2的幂去近似的除,将余数和商迭代知道其和小于除数。 Div/(2^X - K)

             step1   Div/2^X = M0 ... R0 if K*M0 + R0 >=2^X - K, to step 2, else M= M0,R=R0+K*M0

            step 2  (K*M0+R0)/2 …

如下

         100/7 =14 ...2     step 1   100/8 = 12 .. 4    if (12+4)>= 7, to step 2

                        step 2   (12+4)/8 = 2 ...0 if (2 +0 )<7  .  result = 12 +2 ...2.

3)除数是常数,是不是可以用近似的乘法来代替,比如先计算X= 1024/M, 再

X*N/1024来还原成N/M. 当然这个除法会有精度损失需要考虑。

网上还有相关文档针对特殊除法器的优化,这个需要具体应用具体分析。


正因为除法器在面积和latency上的差异非常大,特别是长latency的除法器,很容易成为计算逻辑中的瓶颈,别的逻辑都在等着它的结果才能开始后面的计算。因此在选择不同除法器时,需要考虑整个data-path的开销,减少1cycle的除法计算,是不是能缩短整个path 1 拍,可以节约多少寄存器。

data-path不关心除法latency的时候,直接选1bit移位减的除法器areapower最优,如果能结果逻辑复用效果更佳。

 楼主| 发表于 2017-9-13 00:51:53 | 显示全部楼层
Attend Mentor low power RTL design and HLS seminar
IMG_20170912_092327.jpg
上午是powerpro 的AE讲它们如何省power,如何评估power, 稍后和大家分享。
Capture.JPG
就我看来:
Automatic power reduction: RTL is very hard to understand after modification.
power estimation: to get real data, prefer PTPX with fsdb, (saif is not accurate, especially when estimate memory)
Guilded Power estimation: 基本就毛估估了。

不过这可能是我的偏见,看看今年他们有什么更新。
发表于 2017-9-13 09:56:31 | 显示全部楼层
回复 15# yaya126
楼主能不能分享一下上图右面的那几篇paper,谢谢。
 楼主| 发表于 2017-9-13 13:22:56 | 显示全部楼层
本帖最后由 yaya126 于 2017-9-13 13:27 编辑

hls_bluebook.pdf (14.29 MB, 下载次数: 531 )
mentorpaper_98423.pdf (2.42 MB, 下载次数: 335 )
mentorpaper_102112.pdf (1.35 MB, 下载次数: 304 )
mentorpaper_94085.pdf (589.09 KB, 下载次数: 316 )
今天mentor seminar分享的一些资料, 部分资料还没收到,low power RTL design, 工具虽然能帮你查漏,但save power还的有自己基本的理解,并在设计中灵活运用,如果代码写的好,它是没有水平来优化你的code的。
powerpro 虽然功能强大,3大功能,但在我看来,
1. power estimation 不如PTPX, power sign-off还是要ptpx,也许他便宜点。总之power 估计这东西,garbage in garbage out, 要想估的准,输入就的准,前期毛估估,与最终结果随便差30%
2. automatic RTL power optimizaiton: 我是不会让他来改我的code,改了看不懂,做ECO后还要买他的formal工具slec.
3. guiilded RTL power optimization: 可以看看他的手册,白皮书,学习下理念,他提到的"shift register vs circular buffer"理念 和我的“ pipe vs FIFO ”不谋而合,具体操作中,大家还是在自己的工艺下用脚本跑一下比较,看看到底在什么深度和data-width下fifo才有收益。 一般应用,我上面提供的脚本已经能解决大部分问题。

HLS: 如果是low power RTL design, 建议还是不要用,这东西就是给软件人员写硬件code用的,估计很多情况下,你一句下去都不知道底层实现的是什么。 他举例也是 nv 的 tergra 1, 当年这个不就是高功耗的代表,发热感人吗。
        如果是为了拉风投,做demo,快速出产品,可以考虑HLS, 这比写code 还是快多了。
发表于 2017-9-13 14:29:03 | 显示全部楼层
谢谢楼主!
这个帖子应该设置精华。
发表于 2017-9-13 15:22:03 | 显示全部楼层
Very professional! Keep studing.
 楼主| 发表于 2017-9-14 04:26:27 | 显示全部楼层
本帖最后由 yaya126 于 2017-9-14 04:40 编辑

Reduce logic size


Reduce pipe-line length

在写RTL前,我们应该知道最基本的计算单元(*+>= 等)的延时和面积,这个数据可以通过对基本计算单元在SDC中约束紧和松的综合得到。在tight的情况下,我们能看到综合工具把逻辑并行展开,面积非常大,也许还不能meet timingloose的情况下,逻辑串行都能满足timing要求。两者面积相差3~6倍都不稀奇。


Reduce pipe-line, 要求对基本的组合逻辑delay有基本的认识,合理的排列pipe-line,同时注意关注data-path converge点,看看data-path长短的瓶颈在哪条分支上,压缩关键分支是否能带来整个path的缩短,以及这样带来的好处。


当然预估datapath的延时和面积的影响,这个要求非常高,我自己也难做的很好,一般为了timing容易meet大家可能都会在设计是留足余量,导致path比理想状态下长不少。但我有一个想法,也许可以帮大家找到最合理的pipe-line length我准备整个脚本来帮忙实现这个功能。(仅针对算法模块,控制少,计算多

1.先直接照搬C code, 不考虑timing,把中间计算逻辑RTL写出来,最后输出用寄存器,建议写出参数化的方式,方面后续re-timing.

2.进行tight/loose两轮综合,这样我们得到组合逻辑的最大面积(最小delay)和最小面积(最大delay)。

3.通过最大delay/clock_period, 得到最小的pipe-line length。通过最小delay/clock_peroid,得到最大的pipe-line length

4.re-timing的方式,从最小pipe-line length开始,调整pipe-line重新综合,不停找面积的拐点,我期待看到的结果是,中间有个面积最小的拐点,或者直到pipe-line length 最大,面积单调递减。

5.面积最小的pipe-length就是理想的结果。

lip_image004.gif

如上图,纵轴Z是面积,X轴是频率, Y轴是PIPE length, 在不同的频率下(不同的截面),不同的pipe面积曲线是图上离散的点,我们求的就是面级最小解。


我们可以用这个结果来指导实践RTL design, 达不到最好可以采用次好,但总比没有准备直接上手要好。
如果脚本准备妥当,只是花几轮综合的时间,我觉得可行性还是有的,反正都是机器跑,不然这种设计全凭经验,没有benchmarkcheck quality.


我还想是不是还可以用HLS的综合结果来当benchmark,算法c code 去综合,看看catapuls给出来的建议是多少级,再和上叙re-timing循环综合的最优结果比,差多少,如果两者接近,证明HLS的建议可信。

您需要登录后才可以回帖 登录 | 注册

本版积分规则

关闭

站长推荐 上一条 /1 下一条

×

小黑屋| 关于我们| 联系我们| 在线咨询| 隐私声明| EETOP 创芯网
( 京ICP备:10050787号 京公网安备:11010502037710 )

GMT+8, 2024-3-29 02:25 , Processed in 0.028736 second(s), 6 queries , Gzip On, Redis On.

eetop公众号 创芯大讲堂 创芯人才网
快速回复 返回顶部 返回列表