tags
type
status
date
slug
summary
category
password
icon

背景

模块关系:一个Accelerator包含一个MAC,均在同一个.v文件中
时序关系:处理一个8*8的sint8内积需要13个cycle,其中10个cycle在调用MAC
用yosys综合的结果:
以下结果均为直接调用make sta 的结果,时钟500MHz
DESIGN ?= Accelerator 的结果如下
Accelerator
pwr
area
* cnt[3:0]
8.6e-4
2915
* cnt[2:0]
3.5e-3
2882
{} cnt[3:0]
4.3e-3
2831
{} cnt[2:0]
4.3e-3
2831
DESIGN ?= MAC 的结果如下
MAC
pwr
area
* cnt[3:0]
1.95e-3
1848
* cnt[2:0]
1.36e-2
1909
{} cnt[3:0]
1.36e-2
1909
{} cnt[2:0]
1.36e-2
1909
标记说明:
  1. “*” and “{}”
notion image
“*”代表采用第39行代码,”{}”代表采用第40行代码
  1. cnt[3:0] and cnt[2:0]
分别表示定义cnt_int时用 reg[3:0] / reg[2:0]

问题

  1. 采用“* cnt[3:0]”时,功耗反而最低。理论上我们期望cnt_int的位宽增大时,pwr单调不降。
  1. 单独综合MAC的功耗高于整个Accelerator(包括MAC)。

试验

用商业化工具design compiler测试
下图左:MAC, cnt_int*8+7 下图右:MAC, {cnt_int[2:0], 3’b111}
notion image
下图:MAC, cnt_int*4’d8+4’d7
notion image
下图左:Accelerator, cnt_int*8+7 下图右:Accelerator, {cnt_int[2:0], 3’d111}
notion image

结论

No.
discription
dynamic pwr
leakage pwr
1
MAC, cnt_int*8+7
99.9853
15.9880
2
MAC, {cnt_int[2:0], 3’b111}
99.7877
15.8999
3
MAC, cnt_int*4’d8+4’d7
94.9187
14.5535
4
Accelerator, cnt_int*8+7
214.5388
57.4933
5
Accelerator, {cnt_int[2:0], 3’d111}
214.5331
57.4972
6
Accelerator, cnt_int<<<3+4’d7
192.2715
52.6803
  1. 该工具综合后,Accelerator的功率总是高于MAC,符合预期。因而推测是yosys没有很好的优化MAC
notion image
上面是yosys的截图。MAC中用了非常多NAND门,可能是高功耗的原因
  1. 如果没有指定8和7的位宽,默认按照32位。因此功耗[1]>[3]
    1. 💡
      写verilog必须指定位宽!
  1. [3]的功耗居然比[2]小?[6]的功耗居然比[5]小?
    1. 这是因为[3]和[6]是错误的。由于cnt_int位宽为3,cnt_int*4’d8+4’d7cnt_int<<<3+4’d7 最后的结果都是4位而非期望的6位【参考verilog2005-bitlength】。因此这两个表达式会导致cnt_int的前两位完全没有作用!因而功耗会更低
      为证明这一点,我进行了实验:
notion image
notion image
[3]和[6]的写法确实是错误的。其中[3]还存在语法错误,因为”+”的优先级高于“<<<”,应当加括号
课程须知1T2R
Loading...