您尚未登录。

楼主 # 2021-11-01 09:22:00

echo
会员
注册时间: 2020-04-16
已发帖子: 283
积分: 291.5

CH573F的dhrystone运行速度测试

CH573F这颗RISC-V的MCU很有意思,内部FLASH很大,CodeFlash就有448kB,但是SRAM相对较少,只有18kB。

官网介绍标的主频为20M,但是实际SDK里面,可以通过PLL提高主频到60M,关于性能,手册介绍得比较少,只在介绍FLASH的时候提了一句:20MHz系统主频下基本零等待。

根绝多年经验,判断内部使用的是大容量的SPI FLASH,代码通过cache来访问,性能比SRAM中零等待运行慢一些,但是比无cache的方案(比如GD32F1x0系列)速度有质的差异。

使用dhrystone进行了一些测试,结果完全支持以上结论,性能主要决定于主频和程序运行的位置,结果如下:

SRAM
  • 60M   13.3ms     2.76x

  • 20M   25.2ms     1.55x

  • 8M     73.5ms     1.94x

FLASH
  • 60M 36.7ms      36.2%

  • 20M 39.0ms      64.6%

  • 8M 142.4ms      51.6%

几个结论:
  • 代码在SRAM中运行时,随着主频提高,性能也在提高,在FLASH中运行时,超过20M性能提升就非常有限了。

  • SRAM中运行时,8M主频时73.5ms,和其它RISC-V(比如GD32VF103,54.39ms)比稍慢一些,比Cortex-M3的45.92ms速度再慢一些。

  • 代码在FLASH中运行时,性能只有SRAM中运行的一半左右,大量对速度要求不高的代码,比如业务逻辑,完全可以在FLASH中运行,性能是可以接受的。

  • 代码在FLASH中运行时,超过20M以后性能提升很小了,手册中提到的“20MHz系统主频下基本零等待”应该就是这个意思,这个性能大约就是一个8M的Cortex-M4(38.4ms)的水平。

  • 少数需要很高运行速度的代码可以放到SRAM中运行,不受SPI FLASH性能限制,高主频时提升还是非常明显的。

整体上感觉这个设计还是挺好的,在FLASH容量和性能之间取得了一个折衷,是个不错的解决方案。

WCH的设计经常有些类似的惊喜,比如CH552那个200次的iFLASH工艺,可以有效降低成本,200次的FLASH寿命可以满足绝大多数低端产品的需求了。

最近编辑记录 echo (2021-11-01 09:22:43)

离线

#1 2021-11-01 09:33:04

VAN-D
会员
注册时间: 2020-02-22
已发帖子: 8
积分: 1

Re: CH573F的dhrystone运行速度测试

该评论内容与本帖子无关,鼓励各位坑友积极发言讨论与帖子有关的内容!

离线

  • 不通过:其他

#2 2021-11-01 09:47:50

iamseer
会员
注册时间: 2020-06-06
已发帖子: 64
积分: 41.5

Re: CH573F的dhrystone运行速度测试

我记得测试的时候CH573F跑flash大概不到10条指令就要插等待,速度确实影响很大,也不可控。
另外SRAM虽然无等待,但是比较坑的是有对齐问题,如果有指令被压缩,后面的指令也可能会插1时钟的等待。

离线

#3 2021-11-01 17:28:03

david
会员
注册时间: 2018-03-05
已发帖子: 312
积分: 257.5

Re: CH573F的dhrystone运行速度测试

这货现在不到4元 还带蓝牙和usb 虽然有坑 但是可用性还是不错

离线

页脚

工信部备案:粤ICP备20025096号 Powered by FluxBB

感谢为中文互联网持续输出优质内容的各位老铁们。 QQ: 516333132, 微信(wechat): whycan_cn (哇酷网/挖坑网/填坑网) service@whycan.cn