WhyCan Forum(哇酷开发者社区)

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)