【平头哥开源CPU——玄铁C910】开源项目DC综合准备流程（SRAM处理）

项目库配置和前仿真可以参考我的上一个文章：http://t.csdnimg.cn/NDLAz

后端

要后端仿真首先就得找到对应的工艺库，没有库的仿真是仿真不成的。我们选择tsmc65nm工艺库做这个芯片的仿真库。

SRAM处理

在进行后仿真之前，注意到这个设计中用到了大量的sram，还有很多sram颇为巨大。如果我们不对这些sram做相关处理而直接使用dc综合的话，那么默认情况下dc就会生成大量的寄存器来构成这样的sram。这一方面会导致生成速度极为缓慢，另一方面会导致面积和功耗过大的问题。

因此对于这种问题的解决方法就是使用Memeory Complier（MC）来生成对应大小的sram，然后再把生成好的sram替换掉原本设计中的sram.

以下是整个设计中的所有sram：
端口类型_addrwidth x datawidth

不能直接生成的sram	可以直接生成的sram
spsram_16384x128.v 2048x128x8（256KB）	spsram_1024x128.v
spsram_256x196.v 256x98x2	spsram_1024x144.v
spsram_32768x128.v 2048x128x16（512KB）	spsram_1024x32.v
spsram_4096x128.v 2048x128x2（64KB）	spsram_1024x59.v
spsram_4096x144.v 2048x144x2	spsram_1024x64.v
spsram_4096x32.v 2048x32x2	spsram_1024x92.v
spsram_4096x84.v 2048x84x2	spsram_128x104.v
spsram_512x7.v 512x8	spsram_128x144.v
spsram_64x108.v 128x108	spsram_128x16.v
spsram_65536x128.v 2048x128x32（1MB）	spsram_2048x128.v
spsram_8192x128.v 2048x128x4（128KB）	spsram_2048x144.v
spsram_8192x32.v 2048x32x4	spsram_2048x32.v
	spsram_2048x32_split.v
	spsram_2048x59.v
	spsram_2048x88.v
	spsram_256x100.v
	spsram_256x144.v
	spsram_256x23.v
	spsram_256x52.v
	spsram_256x54.v
	spsram_256x59.v
	spsram_256x7.v 256x8
	spsram_256x84.v
	spsram_512x144.v
	spsram_512x22.v
	spsram_512x44.v
	spsram_512x52.v
	spsram_512x54.v
	spsram_512x59.v
	spsram_512x96.v

生成SRAM

这里选择使用MC来生成相关的SRAM，MC的使用方法见我的另一篇文章：

调用SRAM .v进行仿真

内存扩展

由于C910里面的cache有些比较大，我使用的MC软件（也许是使用的工艺库的问题）无法完全编译出所有大小的SRAM，所以有些SRAM需要我们自行做处理。
具体替换sram的方法，在c910的用户手册里有提供示例，大家可以参考相关内容自行修改：

这里只总结一些关于替换SRAM的经验：

• 替换一个sram之前，你需要看以下内容：
  • 哪些模块调用了该sram？
  • sram组合了哪些其他sram？
  • sram原本内部的控制逻辑？
  • 替换前后sram的区别？
    • 接口是否对应？
      • 不对应的接口如何处理？（生成本地zero信号，不能悬空）
    • 数据位宽是否一致？(A D BWEN Q)

路径替换

然后我们替换sram 这里建议是直接修改.fl文件的spsram路径：

/home/lizhaofeng/PRJ/Workbench/extended_sram

原来的.fl文件 copy一份备份

将所有名称有ct_f_spsram*的文件路径都删除掉，然后改成我们新路径下的ct_f_spsram*的路径。
注意，这里我们要保留几个例化了ct_f_spsram的ct_spsram文件

在前期生成好SRAM的.v文件后，需要修改原来的设计中例化的模块为刚刚生成好的例化模块。

我们使用脚本语言先生成我们修改过的SRAM的路径

find /home/lizhaofeng/PRJ/Workbench/extended_sram -type f -name "*.v" > v_files.txt

然后把这些路径粘贴到.fl文件中。

（注意，这里不能使用*符号代替所有.v文件，因为会无法识别）

CASE测试

先跑个hello_world看一下基础功能：

make runcase CASE=hello_world SIM=vcs

报了个小错，按照提示修改一下：

最后成功跑通：

再跑一些内存相关测试case：
和内存相关的case如下，这些case实测修改sram之前都可跑通，不会出现卡住的问题。

make runcase CASE=ISA_AMO SIM=vcs (pass)
make runcase CASE=cache_op SIM=vcs (pass)
make runcase CASE=debug_memory SIM=vcs (pass)
make runcase CASE=MMU SIM=vcs (unpass)
make runcase CASE=ISA_BARRIER SIM=vcs (pass)
make runcase CASE=sleep SIM=vcs (pass)

再跑完其他case，看有哪些不能通过（实测不进行sram修改的情况下都能跑通）：

make runcase CASE=smoke_bus SIM=vcs (unpass)
make runcase CASE=debug_gpr SIM=vcs (pass)
make runcase CASE=ISA_THEAD SIM=vcs (pass)
make runcase CASE=hello_world SIM=vcs (pass)
make runcase CASE=csr SIM=vcs (pass)
make runcase CASE=plic_int SIM=vcs (pass)

以下case默认情况下就无法跑通：

make runcase CASE=coremark SIM=vcs (error ee_ptr_type)
make runcase CASE=ISA_FP SIM=vcs (build error)
make runcase CASE=ISA_IMAC SIM=vcs (finished with error)

有部分case跑不通，但是不太影响DC的后续流程。