SoC设计IP核选择策略

此外，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核所必需的基础架构一定程度上也是专门的。以下是