1. 为什么和什么（Why and What）
在芯片的设计过程中，尤其是复杂的SoC芯片迭代设计中，经常需要根据产品定位增加或删减部分功能，如果把这些模块做好后打包放置于某处供其他项目调用，既可以节省开发成本、缩短开发周期，又可以充分验证电路，保证可靠性。
有哪些IP适合这么做呢？BG、DCDC、LDO、ADC、DAC、PLL、XO、SerDes、Aux、TempSensor、ProcessSensor等等。它们的特点就是随处都需要，但对性能的要求不是很高；Layout的Size不会很大，走线不会很复杂，方便随处摆放。
2. 怎么做（How）
想法是好的，关键在于怎么去落实。对于这件事，我的看法是可以分为这么几步进行：准备、开发、发布、维护和更新。
2.1 准备——原始需求收集、分析和整理
在项目开始前，先根据公司产品策略收集可能会用到这个模块的场景，并针对相应的场景提出需求。把需求收集起来后取其并集，如果有无法实现或者代价太大的需求，则另立项目或者再商讨修改需求。最后，应该可以得到一份可以实现的、能覆盖所有目标应用场景的、并且有一定远见的设计需求。
接下来需要把这份设计需求转换为Spec文档，请参与讨论的人会签。会签通过就意味着大家对这个IP的设计目标是认可的。
2.2 开发——从需求到实物，从目标到结果
我个人比较喜欢面向Spec设计，因为Spec文档是客观的、可量化的、经过会签认可的东西，它意味着如果我的设计是满足Spec的，那么我的设计就应该是满足应用需求的。如果实际应用中出现了问题，追责起来也可以避免扯皮。
一旦确定了Spec，那么设计就专心致志的为满足它而努力就行了。Review和测试时重点检查Compliance table就好了。
2.3 发布——文档、文档、文档，重要的东西说3遍
很多人都讨厌写文档，就如同很多人喜欢思考schematic但不喜欢思考layout。诚然schematic是layout和文档的起点，但是最终制造出来的东西其实是与layout直接相关，调用或后期维护这个模块的人通常直接面对的是文档。
还有一点就是调用这个模块的人有时候（通常）不见得很了解这个模块，更不用说在某些公司在共享IP时还会加密或混淆网表——这时候文档就是使用者手里唯一的稻草。
发布时要附带哪些文档呢？
- Spec：说明IP的应用场景和基本参数；
- Release Note：发布说明，记录开发人员的信息、所用软件版本信息、DRC/LVS rule的版本、所调用的Stdcell版本、更新内容等；
- Design Report：说明内部结构（框图）、原理、接口、使用方法、仿真验证结果等；
- User Guide：比Design Report简单，侧重于接口和使用方法；
- Review Report
- Test Report
- ECO Report
- Defect Report：已知缺陷报告；
- …
以上的文档当然不是都必须提供，但多多益善吧。
除了文档，IP需要发布的主体应该包括SPICE netlist和GDS（包括DRC、ERC waived mask等）。
2.4 维护——完美之路漫漫其修远兮
就像你永远想不到挂机的队友是遭遇了什么事一样，很多事都不是可以预期的。对于IP来说，有可能有人又提了新的需求进来，也有可能需要减一层metal或禁止使用ulvt的管子，甚至只是因为一层厚金属要改为薄金属，这都需要有人来检查相应的database，并给出结论。
还有，比如在实际应用中发现了缺陷，或者DRC rule update后出现了violation，也需要有人来打补丁。总而言之，维护包括纠错、完善和预防。
如果不需要调整则皆大欢喜，如果需要调整则要走一遍开发流程，新发布一版，并通知所有涉及到的产品的负责人。
2.5 更新——追求是进步的动力
一个电路不能用一辈子，一个架构也不能从古用到今。人总得有点追求，无论是想发Paper还是想提高KPI，我们总会想到更新。
更新和维护的区别，在我看来，更新是主动的，而维护是被迫的。维护通常需要告知受影响的人，但更新（换代）则主要看用户是不是想为了某些特性来冒险尝鲜了。
3 谁（Who）
在整个流程中，需要这么几个参与者：
- 资深设计工程师：负责收集、分析、整理需求，对他的要求是可以快速的评估出实现难度，能指出不合理的需求，并可以将需求转换为Spec文档，并参与电路设计review；
- 电路设计工程师：负责根据Spec文档设计出合适的电路，并撰写相关报告；
- 测试工程师：负责测试IP，并撰写测试报告（有时候由电路设计工程师兼任）；
- IP维护工程师：负责解答、应对IP使用者的疑问和需求，并跟踪IP在应用过程中出现的异常；
- IP发布系统：显然如果没有一套IT系统负责发布、跟踪IP，很多工作开展的难度是不可想象的。
后语： 写这篇文章的原因是看到公司在推类似的东西，但在执行面遇到了一些问题，就梳理了一下自己的想法。因为在老东家那边做的东西主要是射频，很少会直接搬之前的项目复用，但把玩过内部的IP store。现在碰到这个问题，大致一想还挺有意思。 总的来说，这还是一个系统性的问题，必须要参与者健全、流程清晰可控才行。 路漫漫其修远兮，吾将上下而求索。
