中端设计在IC开发中的价值和思考

IC设计中通常基于设计时间线/业务线分为前端设计和后端实现，这个也是大家通常所能理解和接受的。类似下图

可以看到这里的FE/BE有一个明显的桥接地带，就是逻辑综合（synthesis），所以在实际的公司业务部门分部上，会有下列三种情形存在：

• 将综合部分会划归为前端
• 将综合划归为后端
• 将综合单独出来，变为中端（ME：middle-end）

这里的三种方式笔者都有接触，相对于不同业务各有优缺点，但是从芯片的整体规模日益增大的趋势下，第三种的情形未来应该会越来越多

方式	适用情形	优势	不足
综合划给前端	后端专注于版图，并且前端对综合的支持确实可以到位	减轻后端工作量。SDC/UPF的迭代更快速高效	BE接入SDC/UPF过少，一些真实的问题可能会传播下去；前端人员工作量变得比较大，不利于推进功能收敛
综合划给后端	前端出具RTL，SDC和UPF，后端来s跑 综合。后端有一点前端基础，中间地带共同承担工作和风险	后端完成综合，很多问题可以尽早暴露；前端可以更专注代码，SDC/UPF只需基本了解	模糊地带，容易扯皮，每一版本的RTL更新，后端人员可以完全不了解，但是出了问题就需要去仔细排查，返工的次数会明显增加
综合划给中端	前后端都很忙，没精力/业务基础去做。前后端相互的独立性也比较强，交流不多的情形，使用这种方式比较合适	中端人员负责综合相关的一切，包括SDC/UPF/synthesis_release甚至后面的timing signoff等，业务专注度高，项目也可以从第三极的维度去瞻前顾后，只要中端转的流畅，前后端都会产出更好	公司需要额外的费用去搭建ME团队；ME团队的业务本质更像平台部门（类BE），当前的市场繁荣度还是稍逊于FE/BE

这个话题放到前几年，可能还不是很敏感，从2020年开始，国内的初创公司多了很多，大部分都是BEless的模式。从保护自身核心利益触发，RTL代码是不便于公开的，所以采用网表交付就成为最优解，上述基本流程变成了

公司的中端部门基本就是公司的对外数据交付部门了，所有的数据出口都是这里，后端外包团队的结果会直接去到FAB进行TO。这里的中端组的权责就是：给外包团队提供数据和业务支撑，确保最终流片。

这种模式主要是服务于初创公司第一版的业务模式，快并且时间可控，费用自然会高。当然，简单的用一把资金能解决的问题一定只是部分解决。这种模式里的伤与痛，也只有真正经历过的同学可以体会的到吧。这个流程也是一种中间产物，从业务收敛上讲，最后还是会回归本文的开票所述的三种模式之一。

从结构图上看，中端犹如项目的腰（类核心力量），承上而启下，这个部位的带宽一定要足，确保前后端无缝衔接，犹如连接两个马达之间的传动轴，一定是需要细心呵护和用心经营的。

随着芯片规模和复杂的不断地增大，前两种模式通过类似一种刷前端/后端机时的方式已经很难在高速的发展中继续跟进了，专业的人做专业的事，独立的中端部门可以很好的解决下面的问题场景

• SDC质量：不是不好，是不够好

  • 时钟有，但是不全
  • gen-clock都有，但是和master的关系不清楚
  • clock的定义点不太合适
  • CGU的写法对于后端实现的友好性
  • DFT对SDC的影响考量
  • clock 结构优化
  • 使用MCP替换UPF
  • IO约束的合理性
  • 时钟树的重聚和细节（launch vs capture）
  • 等等

• UPF的各种小issue

  • load_upf可以，但是check_mv有error

  • isolation/LS插入的质量细节商榷

  • power-domain/power-state的合并和优化

  • 对层次化设计的支持

  • 全芯片rail的logic和physical的布局

  • 等等

以上种种，看起来都什么大问题，但是对于大芯片而言，哪个细节出问题都是回导致大问题。芯片设计是一个很难收敛的硬设计，要保证系统的稳定性（stability），就必须降低/剪除系统的冗余性（Redundancy）/多义性（ambiguity）。这个特点对于静态的时序分析和低功耗分析的挑战尤甚，如果还是对此不太理解的话，可以想象一下RTL在跑linting的时候的信息量，就可以感知到静态分析的威力了。

类似的，对于综合（DC/Genus），静态时序分析（PT/Tempus），低功耗分析（vclp/LEC_low-power）的各种信息分类：info，warning和error（严格上讲，error是需要全部消灭的），也是需要中端团队查验的，

中端的任务是平抑前后端的差异，最终的服务对象还是后端团队，这里有一些简单的案例可以分享给大家，可能一点点的工作，就可以让后端的实施变得平滑通过是提高项目静态质量。

• 时钟的定义点必须是leaf cell的output pin：有时候为了方便，前端会把时钟的点位定义点放到CGU的一个hierarchy的输出pin，这样很容易下约束，但是会面临port punch的挑战，最惨代价就是在BE侧，导致这个时钟丢失。

  综合view

APR cts view

这个情形，clock_out依然是一个clock point，但是由于APR 工具的push port，这个点依然是有clock 属性，但是却没法真实的驱动后面的逻辑了，也就相当于把这个clock弄丢了。

• 时钟的定义点需要尊重原著：有时候，clock是从外部的PAD进来的，但是由于PAD都是双向口，那么进来的那一只一定是固定的pin，可能会有同学用这个点定义clock， 譬如这里的C pin
  

  这个从原理上讲，没有问题，但是却没有精确反应实际情形，有实际的风险，真实且正确的定义是这样的：
  

  这样做是有它的道理的，不仅仅是点位的问题，一起看一下下图

可以看到，从PAD进到C的timing arc在rise和falling的线性度不是非常一致，这里在核算min-pulse width之类问题的时候，结果会比之前定义到C点上要悲观很多；如果定义到C点，回导致sign-off乐观，往往芯片最怕乐观，这种木桶效应的伤害，都是每个经历者的终身遗憾啊！所以这里的clock的定义点需要修正到PAD上。

常言道：精品必出于细品，只有好好品味把玩自己的数据库，才能做出真正的精品项目，只要比对手强一丢丢，那么你的出货可能就不止这么一丢丢了。各位同学，关注中端就从今天开始吧。