如何为SoC设计选择IP核

　　IP核可以两种形式提供给客户：软核和硬核。两种方式都可使客户获得在功能上经过验证的设计。软核也被称为可综合内核，需要由客户进行综合并在其SoC上实现。而硬核已完全实现(完成了版图设计)，可直接用于制造。(从技术上说，一种设计只有生产后才能实现。但是在此情况下，实现的意思是指安排布局并可直接投入生产)。SoC团队只需将硬核像一个单片集成电路片那样置入芯片即可。软核和硬核具有不同的问题和好处。
   　　将IP核整合到一个芯片上需要很多步骤。这个过程是否能够很容易地完成，主要取决于提供的交付成果。另外，客户不仅必须对IP核进行评估，而且还要评估IP提供商。
   　　软核与硬核的对比
   　　1. 性能
   　　由于软核没有实现，因此它天生在功能和实现方面比硬核更加灵活。另一方面，硬核开发者可能要花更多的时间来优化他们的硬核，因为它们要在很多设计中使用。因此，这使人们觉得硬核会提供更高的性能。
   　　事实上，为那些最先进工艺设计的高端、全定制硬核确实能够提供比软核更好的性能。通过使用锁存、动态逻辑、三态信号、定制存储器等，全定制设计团队能实现比完全静态综合的设计更好的结果。对于需要达到现有工艺和设计技术极限性能的SoC来说，全定制硬核能够更好地满足这些要求。
   　　然而，如果性能目标在一个软核范围内，那么硬核的优势就无关紧要了。SoC设计团队能够使用软核来满足性能要求，并利用其固有的灵活性优势。而随着工艺技术的进步，软核的最高频率限制也在提高，使它们成为更多SoC设计师的一种选择。在较低时钟频率下，硬核或许具有硅片面积方面的优势。但是情况往往并不是这样。硬核经常简单地使用ASIC的方法进行固化，使之不能提供速度上的优势。在其他情况下，全定制内核不能根据每一代工艺进行重新优化，所以削弱了频率和尺寸上的优势。
   　　2. 技术独立和可移植性
   　　软核的优势之一是技术独立的，也就是说，Verilog或VHDL不需要使用一种特定的工艺技术或标准的单元库。这意味着同一个IP核能够应用到多种设计中，或现有设计的下一代中。一些软核提供商采用使其内核技术上非独立的设计风格，但是这种方式看不到什么优势。
   
   图1：受IP核影响的开发任务。
   　　另一方面，硬核在技术上是非常特定的。事实上，如果代工厂改变其工艺参数或库，硬核可能就无法正常工作。这就产生了一个风险，因为在工艺参数改变时，IP提供商需要重新对硬核进行验证。
   　　硬核能够移植到新的工艺技术，但是重新优化全定制内核的工作既费事又昂贵。对于一些先进的微处理器内核，这可能要花两年或更长的时间。因此，硬核经常根据新的工艺进行光学调整。虽然这一方法既简单又快速，但是它减少了由设计团队针对现有工艺进行全定制优化的许多优势。
   　　不仅如此，光学调整同时带来了另一个风险，因为它只能保证新的设计满足设计规则，而不能保证准确的时序或功能，而且重新全面验证经过光学调整的IP核是非常困难的。
   　　3. 速度/面积/功率优化
   　　对于要实现的技术来说，硬核通常比可比较的软核运行速度更快。但是即使对于这单种技术来说，硬核也仅仅是针对一组目标而优化。如果目标是在合理的性能上使芯片面积更小，那么对于这种应用来说，为高度可调性能而优化的硬核可能就太大了。
   　　软核是能够被“应用优化”的。为适合特定的嵌入式SoC设计，时序、面积和功率目标可能需要进行调整。例如：如果SoC使用200MHz的时钟，那么设计运行在250MHz的软IP内核可以改为准确地运行在200MHz上。这在得到更小尺寸和更低功率的同时满足了设计约束。
   　　这种应用优化也适用于低层IO时序。软内核的IO约束可以进行调整，以准确配合内核的使用环境。如果硬内核有延迟输出信号，SoC设计师几乎无法改善时序。
   　　如果SoC的速度、面积和功率目标与硬核的目标相符，那么硬核将极具竞争力。但对于大多数设计师来说，软核在为特定的SoC优化方面更具优势。
   　　4. 可定制性
   　　软核相对硬核还具有另外一个优势：编译时间定制化。这些是实现之前的设计选项。
   　　高速缓冲存储器的内存大小就是一种常见的编译时间用户定制项目。根据特定嵌入式应用所需的高速缓冲存储器的大小，软核处理器能够精确地被配置。而硬核在这方面就不能被定制。
   　　另一种在许多软核中应用的定制项目就是指令专用，或选择性支持某种特殊指令。例如，一些SoC可能需要对外部协处理器的支持。然而，在一些不使用这些特性的系统中，多余的硬件可从软核中去掉，以节省面积和功率。
   　　软核还可以包括实现配置参数。这是一种特殊的编译时间定制，可帮助软核更好地配合SoC团队使用的设计风格。例如，微处理器内核经常通过使用门控时钟电路来实现，但这种时钟不能与某些时钟布线工具很好配合。如果处理器内核可提供一种将所有门控时钟变为相等 的多路复用器(MUX)的编译时间设置，SoC团队可使实现更为容易。
   
   　　5. 易于集成
   　　软核很可能更容易被集成到SoC设计团队使用的流程中，除非内部设计小组已经实现了硬核。其原因是SoC设计团队将在他们认可的IP核周围添加RTL模块。这些内核看上去就像另外的SoC模块，也可像它们一样地实现。
   　　另一方面，硬核看上去更像一个黑匣子RAM，特别是在它采用全定制技术实现时。这意味着硬核提供商将需要为该内核提供更多的黑匣子模型，使SoC设计师能够在其周围设计其模块。这本身就比使用软核更困难。例如，全定制硬核也许没有门级网表。这是因为该设计已经在晶体管级完成，而没有使用逻辑门。但是设计团队可能需要通过背注时序运行门级功能仿真，因为缺少门级网表，这将难以进行。
   　　附加提供物
   　　一个有竞争力的软IP核不只是一个Verilog或VHDL源文件的集合。出于同样原因，一个好的硬核也不只是一个版图数据库。今天的IP核包含一系列可交付使用的提供物，可使SoC设计团队将IP核整合到他们的设计中。这些附加提供物的目标是使IP核尽可能容易地整合到设计流程的各个环节。
   　　图1显示了采用不同IP核的SoC开发活动。这里包括了软核和硬核都必需的一些可交付使用的提供物。
   　　1. 文档创建
   　　清晰和简练的文档是大多数技术产品的先决条件。然而，需要参考IP核文档的人差异非常大，这使IP核技术文档创建面临非常大的挑战。
   　　在图1中，每一个开发活动都有不同的文档需求。例如，软件开发者需要了解硬件的可编程特性，但他们可能不关心它是怎样实现的。因此，一组好的文档可使软件开发者更容易发现他们所需的信息，而不致被大量无用的信息困扰。
   　　最后，如果SoC团队要为能复用部分IP核文档的SoC创建文档，IP提供商应该提供可编辑的源文件和引用权。
   　　2. 接口检查器
   　　SoC团队必须设计逻辑，以便与不同信号和IP核协议进行接口。为了确定其设计是否正确，IP提供商能够提供接口检查器模块，以验证所有接口信号和协议的正确运行。它可能与确认不变的静态信号一样简单，也可能像验证多周期总线协议的正确运行一样复杂。
   　　这些检查器通过自动验证给定接口处理类型是否正确运行的工作，大大简化SoC团队的工作。在一个非法处理的情况下，检查器应该报告错误，使SoC设计师能够容易地查明有缺陷的逻辑并排除故障。接口检查器必须在SoC设计环境中准确工作。它们应该能够非常容易地整合到功能仿真中，而不是以一种实际硬件的形式出现。
   　　3. 协议制表器
   　　IP提供商能够提供另一种交付成果使接口验证变得更加容易，这就是协议制表器。这是一个监测接口处理的模块，可观察到各种特殊状况。协议制表器保存所有可见的处理类型并报告没被运行的“边际”(corner case)。IP提供商必须提供一个进行接口完全验证所需的边角情况表。
   　　在开发过程中，协议制表器将帮助SoC团队决定哪些“边际”情况需要继续验证。一旦开发结束，它同时确保通知SoC团队已经执行了所有必需的“边际”情况验证。由于IP提供商对内核接口具有最佳的理解，这个“边际”情况表将比SoC团队能够想象的任何方案更加完善。
   　　4. RAM检查器
   　　如果一个IP核拥有SoC团队必须编译和整合的内部随机存储器，在处理过程中有可能引入瑕疵。排除由深度嵌入式RAM导致的故障对于SoC团队是一件非常困难的事情，因为它经常涉及通过内核模块跟踪故障的工作。RAM检查器能够大大简化排除RAM模块导致的故障的工作。(当SoC团队不得不通过一个IP核来排除故障时，这是一个非常糟的情况。他们应该能够信赖它的正确运行。)
   　　5. 快速仿真模型
   　　对于SoC设计师来说，用一个大型IP核的RTL仿真完整的SoC可能非常缓慢。如果IP提供商能够提供一个周期精确的内核快速功能模型，客户将从更快速仿真、更快速调试及更少地使用仿真授权中获益。即使是一个非周期精确的模型，对于大多数SoC设计和调试已经足够好了。只要最后运行周期精确模型，在开发过程中就可以从快速功能模型中受益。
   　　6. EDA工具支持
   　　另一个内核质量指标是EDA工具的支持情况。由于不同设计团队可能使用不同的工具，支持多种EDA工具的多种形式的可交付使用成果是目前先进内核经常能提供的。
   　　例如，一个IP核使用Verilog设计而成，但那些使用基于VHDL的EDA工具和方法的客户仍会要求VHDL。如果一个内核只针对Verilog，那么SoC团队在使用该内核时，将不得不忍受一个麻烦且容易发生错误的转换过程。
   　　此外，IP提供商应该提供比需求格式更多的东西。不同的EDA工具可能有标准格式的不同实现方法。在以上的例子中，IP提供商不能仅为Verilog客户提供Verilog RTL，它必须支持客户使用特定的Verilog仿真器。否则，该客户可能要调试与IP提供商所用的略微不同的Verilog仿真器相关的设计问题。
   
   　　这个概念实际上适用于所有交付成果。对于硬核，这个概念同样可在实现阶段应用。硬核必须以一种被SoC团队后端工具所支持的形式提供。而且IP提供商必须支持客户使用的特殊后端工具。
   　　对硬核来说，这个概念在实现阶段同样适用。硬核必须以能被SoC团队后端工具支持的形式提供，而且IP提供商必须支持使用特定的后端工具。
   　　7. EDA脚本实例
   　　为了帮助快速展开各种设计活动，IP提供商应该提供所支持EDA工具的实例脚本。这是IP提供商帮助SoC团队有效地使用IP核进行系统设计的另一种方法。该脚本可能如makefiles一样简单，可实现汇编功能仿真器。这些脚本也可能如一个全套的、针对功能回归执行的自动化设计脚本一样复杂。在任何情况下，实例脚本对于SoC设计师来说总是很有用。
   　　对于软核来说，实例综合脚本几乎是必要的。至少它们应该提供顶层约束、故障路径和多周期路径。如果可能，应该同时提供实现若干工业标准综合方法学的脚本。当然，这些实例脚本越简单，对于SoC设计师来说就越容易理解、进行修改并集成到他们的流程中。
   　　8. 功能内核验证
   　　虽然SoC设计师不会修改软IP核的RTL设计，但是他们确实会改变作为芯片设计常规部分的一些功能。这样的例子包括扫描链接插入、时钟缓存和RAM BIST集成。SoC设计团队需要验证这些改变不会对内核的正确运行产生影响。
   　　验证新设计在功能上与以前设计没有改变的一种方法是采用IP提供商提供的测试基准和测试套件，以全面验证内核是否正确运行。不幸的是，对于许多内核来说，完整的测试套件太大了，以至于不能作为IP核的一部分来提供。因此，大多数IP提供商选用完整验证套件组的子集，它同样能够验证运行。大多数情况下，对于发现那些由以上设计变化类型引起的错误来说，这个子集已经足够了。
   　　然而，形式验证工具对于保证正确运行是一个更彻底的方法。这些工具可精确地验证新设计与老设计的相同之处。支持形式验证工具可使SoC团队无需运行门级回归。
   　　9. 软件协同开发工具
   　　为新系统开发软件的标准方式是，首先生产硬件样片，然后开发运行在上面的软件。然而，在很多情况下这延长了产品上市时间，因此软件开发经常与硬件开发平行进行。
   　　软件开发比硬件开发需要快得多的系统仿真。因此IP提供商必须提供一个非常快的IP核功能模型。这为低层固件的开发提供了足够的性能。
   　　对于更高的仿真速度，有时会使用硬件逻辑仿真器，它可比纯仿真快一个数量级(虽然这仍然比实际硬件慢2至3个数量级)。这些工具非常难用，而且需要特殊的综合。对于计划进行硬件和软件协同开发的SoC设计团队来说，支持这些技术是对IP核的一个关键要求。
   　　评估IP提供商
   　　1. 是否设计成可复用？
   　　例如，一个未对IP核产品做出完全承诺的IP提供商，它的产品可能只是将以前的设计重新封包成IP核。而一家认真致力于构建高质量内核的公司从一开始就把可复用作为设计理念。
   　　首先，留意那些其源代码为全定制硬核的软核。由于这些原始设计不是针对可综合的，与针对可综合而设计的产品相比，其性能较差。在创建一个硬核时，可以基于已知实现风格进行优化。但是，对于一个软核，不应采用这种投机取巧的方法，因为它们可能导致非功能性的或非理想的实现。
   　　在寻找一个软核时，需要注意的另一个问题是寄存的接口信号。通过寄存IO，内部逻辑在时序上可独立于SoC设计团队的任何方案。而且，它易于实现时序的可预测性，并为SoC设计师提供非常好的时序约束。所有这些使得SoC设计师更加轻松。
   　　一个从一开始就针对可复用性而设计的软核常常拥有更多的配置选择，而且在执行中有更好的灵活性。它同时很可能考虑用于多种设计环境。一个没有考虑可复用的设计将在功能和实现方面缺乏灵活性。
   　　2. 完整的产品线
   　　好的IP提供商的另一个标志是拥有完整的IP核产品线。如果你选择软核，应该确认该公司提供的是考虑了未来产品改进的完整软核产品线。如果你选择硬核，应确认它可提供所有你将使用的工艺技术，他们是否计划扩展其提供的软核产品？他们如何计划将硬核移植到新一代工艺？
   　　3. 维护与支持情况
   　　产品维护和支持的质量不是IP核特有的选择因素，但是应小心那些缺乏全力支持的新兴公司。即使是成熟的公司，维护IP核所必需的基础架构一定程度上也是专门的。以下是注意事项汇总：
   　　* 这家公司是否有一个清晰地为用户提供文档的方式，以帮助解答问题；
   　　* 支持SoC队伍的费用如何(你是否存在失去支持的危险)；
   　　* 这家公司能否坦白地披露设计中的缺陷；
   　 　* 这家公司发布修复缺陷新版本的频率如何；
   
   　　* IP提供商是否发布维护版本，为IP核增加新的功能或其他成果(如提供更多EDA工具支持)；
   　　* 一旦需要技术支持，这家公司的反馈如何？
   　　* 如果技术支持反馈时间太慢，这个问题能改善吗？
   　　* 第一线的技术支持人员的素质如何？
   　　在很多情况下，技术支持的质量并不是最初决定购买IP内核的因素。但是在设计队伍非常需要帮助的时候，支持不到位可能变成一个主要问题。最佳的技术支持是项目成功的必要因素。