我们知道，IC设计是环环紧扣的。虽然流程上分前端后端，工种上分写代码的，做物理实现的（大部分公司如此划分），但是归根到底做的都是同一个产品。因此，前端设计工程师涉猎后端物理实现的知识，物理实现工程师了解前端设计具体的功能，无疑能够更好地提高整个设计流程的效率和质量。这篇文章简单罗列两个前端工程师在做RTL设计时需要考虑到的除了PPA之外的物理实现方面的点。
1 模块设计时需要考虑到上下游模块的大致物理位置。
如果做的是某个IP的子模块，需要对该IP所有子模块功能有详细了解，大致梳理清楚子模块与子模块之间数据流动，内存资源共享等关系。
那么这个必要性在哪里呢？一般而言我们都知道模块输出要做寄存打拍，这样便于模块交互信号的时序收敛。但随着工艺的不断演进，线延迟在时序路径中所占的比例越来越大，如果上下游模块的实际物理位置相隔甚远，即便两级寄存器之间只有少量组合逻辑，都会因为线长过长而插入很多buffer，在某些时候就会产生一些时序违例。当然，解决此类时序违例，基本上是EDA工具和后端工程师的事，后端工程师改变floorplan，设置工具变量提高工具效率，通过很多手段可以解决此类问题，但是在实际项目中还是经常会遇到后端工程师来向前端求助的情况，有些路径通过工具似乎不是那么好解决。比如下面这种场景：
在某个IP中，模块A与模块B和模块C都有交互，模块D是IP连接外部总线桥的模块，模块B和C都单独做了harden，模块C与片上内存有大量交互。而片上内存又和其他一些模块有交互。那么最后floorplan和placement try run出来，有可能是以下这种情况：
从上图中可以看到，模块D是连接外部总线桥的，所以肯定在PORT周围，模块B的macro与D有交互，所以在D附近。而模块C的macro由于与右上角memory有交互，放在memory边上。这样一来，没有单独harden，并且与B,C,D三个模块都有交互的模块A的那些接口交互寄存器和逻辑，很有可能会被工具打散到各个交互模块附近（因为只有这样才能缩短模块交互路径的物理距离），而相应的，模块A内部的总控逻辑到各个不同A接口寄存器的时序路径的物理距离就被工具拉长了。如果模块A内部的这些路径本身就比较紧张，这种时候很可能出现由于物理距离导致的时序为例。
这样的情况，通过改变floorplan，修改memory和port的位置，可能是可以解决的。但问题就在于，改变了floorplan来解决某些路径，很容易造成其他一些路径的违例。后端一般情况下更多的是关注一些memory交互的路径，floorplan也主要以此为主，因为memory接口的时延大。而寄存器到寄存器的路径，工具能做的事更多。如果最后真的无法解决，只能让写RTL的人想办法减少一点组合逻辑。这样一种情况，对于前端写模块A的RTL的人来说，如果一开始能意识到主控逻辑到各个交互接口逻辑的这些路径可能由于物理实现的原因造成一些预期之外的时序违例，那么在做方案的时候便能有意识地针对这部分关键路径时序做一些简化，避免最后让后端的人找上来，增加迭代时间。
对于一些涉及到大带宽数据储存计算的芯片来说后端的Congestion问题是比较头疼的。因为绕线资源有限，大数据位宽又涉及到内存访问，很容易产生拥塞。物理实现上可能无法完全解决，需要前端RTL配合梳理数据流，以及做一些额外的代码层次化来给后端做bound，从而方便后端进行人为的物理位置摆放。而前端人员写代码的时候，即便不是此类后端也难以解决的congestion问题，也是需要注意此类风险的。因为综合工具解决congestion的方式是有可能影响到PPA的（比如更长的物理走线影响时序）。
Congestion的原因有几种: hard macro之间物理空间不够，cell密度太大，多pin的cell摆放太密集，Power/Ground结构不合理等。对于前端人员来说，核心就是减少单一cell的扇入和扇出。比如使用多级2-1 mux来代替128-1 mux，复制多份相同逻辑来减少单一逻辑复用等。因为congestion的风险虽然可以提前预判，但是碍于PPA等考虑，不一定一开始就要在代码中落入相关优化，可以在代码中可能存在congestion风险的位置提前用宏另外隔离出一个专门为congestion打造的版本，以备不时之需。
今天就到这里，欢迎大家继续关注我们后续文章。
