前言：过去的一年里，忙碌于low power design的后端实现项目，由于人力资源的有限，投入了大量的时间和精力在整个项目的迭代中。从项目schedule的规划到low power 结构的实现，从封装规格的讨论到后端IO的排布，从数据流到模块划分，从IP的电源规划到跨电源域的错误点修正，以及signoff'标准等等，每一项都是要耗费大量时间去评估去敲定。这时候对于项目的准确评估就直接影响到后期的项目进度规划，这里暴露出来的问题狠狠地给自己上了一课。各种辛酸与经验教训值得认真反思。大概从资源管理和流程进度管理两方面来总结一下个人的经验教训。

资源管理

       这里的资源分为人力资源和机器资源两部分。人力资源的确定需要参考以往团队合作模式，然后针对当前项目的规模去配置相应的人员。从PM/PL的角度来说，要保证项目的顺利进行，需要在成本有限的情况下最大化的配足工程人员，同时要考虑到“人力”的风险因素，做好plan B，这里以小规模芯片项目举例（不一定更具有普适性），假如需要两个工程师来完成实际的后端实现，那么这两个人的职能最好能有overlap的地方。当然，分工可以明确，但是职能有交叉，这样互相可以又个“照应”，技能提高解决问题的效率，又能增加一定的人力资源方面的抗风险能力。一个人忙不过来的时候，另外一位随时可以补上。这个人数也可以扩展为多名工程师。比如，负责CAD flow的同时可以兼任block owner；block owner也可以在项目中熟悉top情况，必要的时候可以帮忙分担人物。PR工程师也要熟悉PV的工作，在一定阶段由独立完成的能力。新老员工搭配，全才与专才搭配等等。

       另一方面就是机器资源，比如账号分配，EDA工具的license数量，工作服务器的磁盘空间，CPU数量等等。这里需要预估一个数量，当然，也可以在后期继续申请耕作的资源。根据人数以及任务量不断优化机器资源的配置。个人在工作的时候要定时有意识的监测机器利用率，磁盘空间等等。如下表格是后端实现所需要的常用工具：

       工具机器资源配置之后就是整个流程的runtime评估，需要在flow搭建完成之后，做初期的runtime 统计，方便制定合理的schedule，从而对整体进度的把控有一个基础的参考数据。如下是后端基本流程：

Synthesis -> DFT -> P&R -> STA -> PV/PI 

逻辑综合，插scan链，布局布线，signoff 静态时序分析，版图design rule检查，power 检查等等

其中P&R又分为 place , cts, route, postroute等等，在后端流程的每两个大步骤之间都要做等价性检查即Formality/LEC保证功能的一致性。

这里每个阶段工具的runtime做一个初步统计，大体了解跑完整的一轮流程需要多久的时间，然后制定初步的时间表。这一部分是时间表是软件客观运行的时间，很难压缩，基本确定管理一个完整流程的周期，后续考虑迭代次数。

流程进度

       考虑了基本的流程所需的运行周期之后，可以开始制定较为详细的进度表。根据计划的流片时间，结合当前的代码质量，应用场景和实现要求，开始和设计人员一起讨论具体的时间安排。充分考虑到各个环节的影响因素。

代码质量大体规划为三个阶段， trial run阶段，stable 阶段，final 阶段。

      在Trial run阶段，主要的任务就是明确spec，制定对应的技术策略，定好方案才能按部就班的继续下去，把大的风险提前提出来，避免诸多返工。宁可前期进度慢一点，也不可盲目冒进，返工的代价远比被某个问题block住要大得多。

明确PPA要求，power， performance， area，是后端实现的三大重要指标。围绕这三大指标展开来，power又可以分为低功耗设计的动态功耗和静态功耗指标，局部模块的特殊功耗要求等等。针对功耗要求，明确低功耗设计结构，制定实现策略，例如，控制VT比例，控制clock tree长度，以及EDA工具的power 优化策略同时还有电源网络规划。performance又分为关键路径，高频时钟的满足策略，根据实际要求，决定如何按照数据流规划布局，是否采用Htree等，如果是多档位电压的设计，还需要进行扫频工作，来迭代出一个合适的频率档位。Area部分呢则要考虑封装的规格，提前讨论好基本的布局规划，避免后期大改造成的返工。根据经验在可能出现瓶颈的环节预留margin，给自己一点回旋的余地。关于是实现策略的制定，大概从两个方面去着手：Design 方面和flow 方面。即设计本身的特殊性，和deisgner深入讨论设计意图，从而能够合理布局，选取有针对性的策略。然后充分利用EDA工具的通用性能，搭建环境，选择最佳里设计流程。

       在Stable阶段，主要的任务就是排除风险，解决瓶颈，在代码稳定的状态下把后端的流程走顺，该推频率推频率，该降功耗降功耗。基本上这一阶段就是解决绝大部分可能出现的问题，得到一版高质量的数据。这个阶段也是后端项目最主要和耗时最长的一个阶段。沟通就是这一阶段的主旋律。特别注意，问题不过夜，即使列入action item里，保证问题有记录有跟进。个人工作管理，团队数据交互注意写readme，方便自己，方便他人。总体项目规划的话，也可以将这一阶段再次分为几个mailstone，化整为零，阶段性总结。

Action item示例：

在公共目录写一个Readme,权限设为777，修改内容倒序写，最新的修改永远置顶看到。

##01/02, BE1 release fp1

Dir: xxx/xxx/top..fp.def.gz

##01/01, FE1 release netlist v1

Dir: xxx/xxx/top.v.gz

       在Final阶段，主要的任务就是严格按照signoff标准去收敛各项指标。这一阶段的管理工作重点在版本控制，流片时间的把控。这各阶段应该把所有的标准都已经清晰明确，工程师只需按部就班进行迭代收敛。根据TO时间倒退各个节点时间，严格把控（但是需要留有margin，做好风险评估）。什么时候出gds做premerge，排除IP风险，什么时候出网表，sdf做后仿，排除功能bug。什么时间timing clean，drc clean，IR可控，lvs pass等等，都依赖于前期的各种稳定数据的支撑。提前列出完整详细的checklist，逐步推进。

团队建设

      完成项目的过程中，“人”是一切问题的核心。技术总有规律可循，人这个因素确实复杂多变的。那么字完成项目的同时使得“人”得到了更大的发展，就显得很有必要，尤其是大型，长久的项目。老带新，在一定程度上，多岗位延展交叉，让各个阶段的成员都能在完成本职工作的基础上进行一定的能力外延，这其中所带来的价值个人觉得更重要。于公司和团队，团队和个人之间，都能得到付出劳动之后收获的更多成长。这种双赢的结局应该是大家更想得到的。

记录点滴经验，为以后能走更远的路。