tags
type
status
date
slug
summary
category
password
icon
背景
模块关系:一个Accelerator包含一个MAC,均在同一个
.v
文件中时序关系:处理一个8*8的sint8内积需要13个cycle,其中10个cycle在调用MAC
用yosys综合的结果:
以下结果均为直接调用
make sta
的结果,时钟500MHzDESIGN ?= 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 |
标记说明:
- “*” and “{}”

“*”代表采用第39行代码,”{}”代表采用第40行代码
- cnt[3:0] and cnt[2:0]
分别表示定义cnt_int时用 reg[3:0] / reg[2:0]
问题
- 采用“* cnt[3:0]”时,功耗反而最低。理论上我们期望cnt_int的位宽增大时,pwr单调不降。
- 单独综合MAC的功耗高于整个Accelerator(包括MAC)。
试验
用商业化工具design compiler测试
下图左:MAC,
cnt_int*8+7
下图右:MAC, {cnt_int[2:0], 3’b111}

下图:MAC,
cnt_int*4’d8+4’d7

下图左:Accelerator,
cnt_int*8+7
下图右:Accelerator, {cnt_int[2:0], 3’d111}

结论
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 |
- 该工具综合后,Accelerator的功率总是高于MAC,符合预期。因而推测是yosys没有很好的优化MAC

上面是yosys的截图。MAC中用了非常多NAND门,可能是高功耗的原因
- 如果没有指定8和7的位宽,默认按照32位。因此功耗[1]>[3]
写verilog必须指定位宽!
- [3]的功耗居然比[2]小?[6]的功耗居然比[5]小?
这是因为[3]和[6]是错误的。由于cnt_int位宽为3,
cnt_int*4’d8+4’d7
或cnt_int<<<3+4’d7
最后的结果都是4位而非期望的6位【参考verilog2005-bitlength】。因此这两个表达式会导致cnt_int的前两位完全没有作用!因而功耗会更低为证明这一点,我进行了实验:


[3]和[6]的写法确实是错误的。其中[3]还存在语法错误,因为”+”的优先级高于“<<<”,应当加括号
- 作者:Tianyao Xiao
- 链接:https://www.xty27.top/article/yosys
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议,转载请注明出处。