求助Memory Compiler大块SRAM拆分策略

sunbox98

请问各位大佬，在将大块SRAM通过Memory Compiler拆分的时候，深度和宽度都拆分为同等规格的FOUNDRY SRAM CELL，还是采用不同的规格（整除之后的余数单独生成）。不知不同的策略在PR阶段有什么利弊，多谢！

kk2009

1，需要看compiler是否能支持单独分深度或者宽度。比如compiler支持宽度，但是深度不够，或者说宽度不够，但是深度可以。
2，只将深度拆分，那么所有的sram的输出外面需要加一个mux，在读写sram的时候，只有选中的sram会toggle，其他sram不会动，所以功耗会比较低一些，但是timing会变差，毕竟sram外面还有一个mux。
3，只将宽度拆分，读写sram的时候，所有的sram都会toggle，但是sram的输出不需要做逻辑，所以功耗会大一些，timing比拆分深度要好一些。

这是基本原则，具体需要分析。。。。。

sunbox98

非常感谢指导！
现在使用的是Foundry厂自带的Memory Compiler，不支持自动拆分。而设计使用的SRAM SIZE大于MC支持的Range。
比如设计中可能使用1536*108bit的SRAM，而MC支持的某种SRAM单元Range如下：
depth => "32,48...1024", width => "4,5...72"
此时深度和宽度都需要手动拆分。比如深度可以拆分为A：1024+512或者B：2*768。
A方式可以理解为异构拆分，会至少产生2种Foundry SRAM CELL，SRAM种类会变多，MUX逻辑更复杂（参与译码的地址线更多）。好处是在某些深度情况下可能利用率更高。
B方式可以理解为同构拆分，拆分之后的小SRAM规格一致，SRAM种类单一，坏处可能在某些深度下利用率会低一些。
宽度拆分也有类似的方法选择。
不知实际通常优先采用哪种拆分方法，各有什么优劣。
THANKS！！

唐三彩骆驼

我们公司一般采用同构拆分的方式，同构拆分可以保证一个logic sram对应的是同一类physical sram ，这样对后端进行floorplan时更友好一些，虽然这会浪费一些sram面积

kk2009

我们会采用异构拆分，简化设计。

sunbox98

感谢大佬们指导！

另外，请教下拆分LOGIC Memory的时候，是尽量用最大Size的Physical Memory，还是需要尝试更多的组合，如使用更小深度的Physical Memory可能时序更好。这样脚本会更复杂，生成时间也更长。

关于Aspect Ratio，高宽比过大可能会对PR不友好，如果时序可以满足，不知以下高宽比都在合理可以接受的范围么。
Height        Width        Aspect Raio
222.24        36.217        6.1
204.96        81.307        2.5
222.24        81.307        2.7
150.816        61.659        2.4
117.12        81.307        1.4

MANY THANKS！！！

Tang00

timing 满足的情况， 选面积小的