low power RTL 设计优化

杰克淡定

支持楼主，持续更新

y23angchen

持续关注！！！！！

yaya126

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

yaya126

Reduce Logic size
Divider optimization（N/M）:

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

标准除法器（N和M 都是变量）：

基本的设计思路是移位减，如果每个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的开销，减少1个cycle的除法计算，是不是能缩短整个path 1 拍，可以节约多少寄存器。

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

yaya126

Attend Mentor low power RTL design and HLS seminar

上午是powerpro 的AE讲它们如何省power,如何评估power, 稍后和大家分享。

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

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

haimo

回复 15# yaya126
楼主能不能分享一下上图右面的那几篇paper，谢谢。

yaya126

hls_bluebook.pdf (14.29 MB, 下载次数: 552 )

2017-9-13 13:24 上传

点击文件名下载附件
seminar4

mentorpaper_98423.pdf (2.42 MB, 下载次数: 362 )

2017-9-13 13:23 上传

点击文件名下载附件
seminar2

mentorpaper_102112.pdf (1.35 MB, 下载次数: 329 )

2017-9-13 13:23 上传

点击文件名下载附件
seminar3

mentorpaper_94085.pdf (589.09 KB, 下载次数: 341 )

2017-9-13 13:23 上传

点击文件名下载附件
seminar1

今天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 还是快多了。

interpolmoon

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

河源皮

Very professional！ Keep studing.

yaya126

Reduce logic size

Reduce pipe-line length

在写RTL前，我们应该知道最基本的计算单元（*，+，>= 等）的延时和面积，这个数据可以通过对基本计算单元在SDC中约束紧和松的综合得到。在tight的情况下，我们能看到综合工具把逻辑并行展开，面积非常大，也许还不能meet timing。在loose的情况下，逻辑串行都能满足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就是理想的结果。

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

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

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