翻译自——semiwiki，bernard murphy
我已经断断续续和chouki aktouf (ceo)和bastien gratreaux(市场营销)谈了关于defacto已有好几年了。我想知道为什么他们不会像我们一样遇到同样的问题。脚本驱动的rtl编辑，设计重组，真正的问题，这只需要很少的解决方案。最近我和chouki进行了一次热烈的讨论，现在我相信我明白了。
为了解释清楚，我需要倒退几步。首先，自动化soc装配和相关功能现在非常普遍。这个过程中有很多是非常机械的——放入ip进行顶级连接，通过脚本和一堆电子表格很容易实现自动化。如果它不是纯粹的记账，那么它可以很好地用于进一步的脚本驱动的附加功能，比如通过寄存器和内存映射定义连接io、电源管理、中断、软件接口。
ip-xact将成为所有这一切背后的统一标准，其中某些像nxp，st，三星等厂商已对它垂涎三尺，我想多个ip供应商也参与进来的情况下，与客户建立标准化的接口有什么不好呢
很多设计公司对此并不确定。他们的内部解决方案运行良好。当需要升级的时候，他们会致力于他们的下一代解决方案——几年前我曾与高通进行过类似的讨论。他们不愿意一直使用ip-xact。他们喜欢这种灵活性，如果需要的话，他们可以跳出界线。他们也有很多csv格式的遗留数据库和其他他们知道如何读取的格式，在转换到标准的过程中管理这些格式会很麻烦。
但是他们仍然喜欢ip- xact(以及其他视图)作为从供应商获得ip的一种方式。换句话说，他们想要一切。适合他们的标准，与遗留数据的向后兼容性，以及适应和创新的灵活性，而不是行业标准的速度。
对于罐装食品行业来说，这不是一个好起点，但这是一个更好的平台/基础设施产品配方。它将处理读取和写入多种格式的机制，从csv、excel、rtl到ip-xact等，并提供一个集中的对象模型，在此基础上，你可以编写脚本来读取、写入或修改你的核心内容。
谁会在乎这个几乎所有人都在做soc设计。不难看出，苹果、谷歌、三星、高通、以及存储公司正在招募具有ip-xact专业知识人才，或者在各种会议上谈论自己的工作。我确信他们中没有或很少有人会一头扎进成熟的ip-xact。我没有从事实上得到这个，我只是做了一点调查。
这就是defacto提供的东西。一个通过统一的、持久的数据结构来处理所有这些格式的读取、修改和更新机制的基础设施，让客户在对象模型的api之上构建他们的增值脚本。它们还提供了许多以实现为中心的功能。
延伸阅读——ip-xact
电子行业的厂商在设计过程中使用的工具。许多这些工具的使用独特的专有格式。而在如今的soc设计中，ip中的寄存器等设计组件的数量和复杂性不断增长，关于csrs （control and status registers）的问题在当今的soc设计中相当普遍，无法正确地控制或接收这些组件的状态可能导致严重的问题。工程师们常使用基于仿真的方法来验证csr功能，但是这种方法并不理想，因为它们不能完全穷尽所有可能。能有一个自动化验证指定寄存器的流程是ip开发人员和验证工程师的迫切需求。电子设计信息描述标准允许开发人员交流，不同的设计环境之间的信息迅速。这加快了设计流程，并导致更快的实施。
ip-xact标准的调试过程中提供类似的好处。简单的系统可以使用一个单一的接口直接访问处理器用于调试目的。工程师可以很容易地描述这样的系统调试。然而，复杂的系统可以包含多处理器和总线，甚至自己的嵌入式调试子系统。因为大多数调试器，如设计工具，使用专有格式的设计信息，正确地描述一个复杂的系统调试器可以是非常困难的。标准化描述一个系统，可以节省时间和减少调试过程中的错误，即使您使用调试器，不能直接处理系统的ip-xact的描述。
arm提供其组成部分的ip-xact的说明，以方便导入支持的ip-xact的eda工具和调试这些组件。整个电子行业更广泛采用的ip-xact标准允许arm的组成部分，更容易被集成到设计，包含从其他供应商的组件。
为了提高soc集成设计效率,构建基于ip-xact标准的cksoc（c-sky soc）设计集成平台.采用自底向上的集成策略,通过ip/子系统两层复用和软硬件资源复用,依次从ip级、soc核心系统级和soc芯片级3个层次逐步细化完善系统平台,生成3个不同的平台：rtl仿真平台、fpga原型仿真平台和门级网表逻辑综合环境,可以显著地提高soc设计集成效率。
编辑：muyan来源：eeworld

---