返回列表 发帖

[原创] low power RTL 设计优化

支持楼主,持续更新

TOP

持续关注!!!!!

TOP

本帖最后由 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

  

TOP

本帖最后由 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最优,如果能结果逻辑复用效果更佳。

TOP

Attend Mentor low power RTL design and HLS seminar
IMG_20170912_092327.jpg
2017-9-13 00:44

上午是powerpro 的AE讲它们如何省power,如何评估power, 稍后和大家分享。
Capture.JPG
2017-9-13 00:43

就我看来:
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: 基本就毛估估了。

不过这可能是我的偏见,看看今年他们有什么更新。

TOP

回复 15# yaya126
楼主能不能分享一下上图右面的那几篇paper,谢谢。
海阔天空,漠大无边

TOP

本帖最后由 yaya126 于 2017-9-13 13:27 编辑

hls_bluebook.pdf (14.29 MB)
mentorpaper_98423.pdf (2.42 MB)
mentorpaper_102112.pdf (1.35 MB)
mentorpaper_94085.pdf (589.09 KB)
今天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 还是快多了。

TOP

谢谢楼主!
这个帖子应该设置精华。

TOP

Very professional! Keep studing.

TOP

本帖最后由 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
2017-9-14 04:37

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


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


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

TOP

返回列表

站长推荐 关闭


音频系统、USB TYPE-C、智能手机、移动电源、SSD 参考设计汇总(免信元)

太多参考设计,原理图了,都是精品!(免信元下载)


查看