为了应付日益增长的复杂性，必须提高抽象的水平。但当摩尔定律将SoC(系统单芯片)的复杂性加速到逃逸速度时，哪里能找到一种作为RTL(寄存器传输级)补充的新抽象方法？很多观察家注意到，面向硬件的文本式RTL可替代逻辑图，从而推断认为某种系统级描述语言(如SystemC)将提供下一个好的抽象。不过这种情况并不会出现。

　　Atrenta公司主席、总裁兼首席执行官Ajoy Bose认为：“可重用IP(智能产权)才是新的抽象等级。”如果看看SoC设计团体正在做的工作，就会发现，创建SoC的过程就是对以前所用IP的寻找、特性确定和装配过程。无论是哪种设计创建工具(SystemC、Verilog亦或逻辑图)，都只是扮演一个填充空白的角色，如专利功能以及IC的缔结组织结构。但正如大量EDA公司、代工厂和大多数SoC设计者所想象的那样，今天的设计流已经缓慢地认识到了这个现实。看一下自己的工具，你就会知道每个SoC都开始于一组功能需求，以及一张白纸。实际上，要考虑的是一个SoC设计中真正做什么，以及从这些观察数据中可以抽象出什么结论。

　　新的抽象

　　Synopsys公司主席兼首席执行官Aart de Geus喜欢乐高玩具，他还喜欢用它们作为硅IP的比拟。他指出，将IP装配起来创建一片SoC，就像把乐高积木块装成玩具一样。IP块是其中的RTL抽象，就好像乐高积木块要比用塑料或木头，去手工制作出一艘船或一只恐龙来得简单。这种模拟可以一直做下去，直到开始无效。

    乐高积木(尤其是高价主题包中的精密积木块)也可以体现出以IP为中心的设计流应该是什么样子。最开始是需求，这与传统设计流没有两样。但以IP为中心的设计流很快就会与传统方式分道扬镳。在传统流程中，要将需求划分为更小的模块，仔细地定义接口，直到这些模块足够小，使RTL设计师能用Verilog编写它们。而以IP为中心的流程则几乎相反：你要选择适用的IP块，将它们与需求匹配，就像装配乐高积木一样。你要尝试尽可能用较少的块，留下的空间尽量少。然后用新代码填充这些空白。

　　设计流程再继续下去，两种方案仍然是各行其道。传统流程经过了功能验证，综合，分析，时钟、电源和测试的精细插入，后端设计以及收敛，这些过程都在不断去除抽象，创建更多的实现细节，直到需求变成为多层的多边形。在每个新的级别上，流程都要停下来，验证该设计是否仍然满足需求。

　　而以IP为中心的流程再次走了几乎相反的道路。它的要点是将IP装配为一个满足需求的系统，而尽可能少地寻求有关IP细节的新信息。Bose称：“在装配过程中不要陷入调试IP的误区。”

　　这种情景对很多团队都很理想，富有吸引力。de Geus说：“例如在中国，设计方法研究的就是如何快速地从定义走到IP列表，再到装配。”

　　但现实情况通常并不是这样。Open-Silicon公司工程副总裁Taher Madraswala说：“至少今天有些功能有很好的定义，理论上你本可以在整个流程中把它们看作黑箱子，但也仅仅是理论上而已。实际上，最终还要在综合与门级优化时打开黑箱子。”为解决这些问题，必须遍历一个理想的设计流，找到希望与现实之间的差距。你必须考虑IP选择、装配、实现和收敛。

　　IP选择

　　从需求到一个IP BOM(物料清单)的过程是变化的，而且很不幸要手工完成。如何从A到B取决于系统的性质、IP的可用性、设计团队在重用方面的经验、芯片差异化的营销计划，以及企业策略等等。这个过程不能依赖的一件事是自动化，Synopsys公司的de Geus指出，理论上说，自动化应不存在障碍。

　　他发现，在RTL时，Design Compiler能从Verilog源中有效地找出该公司DesignWave的相对复杂块。不过，对于较大的IP块，自动化就不稳定了。他说：“用IP时，块都不太通用，要加入更多的人工选择。”

　　有些情况下，手工IP选择的轻松程度可以接近于自动化工具。例如，很多较小的SoC仍然采用一种简单的、类似于微控制器的架构：一个CPU核心、一个本地缓存，还有一系列外设接口。所有需要的块一般都能从第三方IP库中获得，再补足AMBA(先进微控制器总线架构)接口的管脚，就可以插接到一起了。对于其它情况，IP的选择并不能从需求明显看出。例如，假设一个智能手机SoC有多种授权与加密的要求。你是获取一个大且昂贵的第三方加密引擎许可证，还是选择一个较小的加密数据路径协处理器？另外，你是用MathWorks的MatLab开发自己的块并做综合，还是采用一个较快的(或第二个)CPU核心，并用软件处理需求？

　　功能的选择并不是过程的结束。功能类似的模块之间可能有很多方面的差异，包括性能、面积、功耗、接口要求、可配置性、对时钟与电源控制的条件、验证覆盖范围以及使用史.