采用SystemC ESL设计的九个理由

支持SystemC的电子系统级（ESL）设计和验证环境旨在设计，分析，优化和验证片上系统（SoC）平台模型。这样的环境构成了已建立的RTL实现流程的前端。

现在，您为什么要关心？

根据Gartner DataQuest的说法，SystemC设计和验证环境被用作设计流程前端用于约2003年的约100个SoC设计。其中许多设计是世界领先的SoC设计公司的旗舰产品。

根据最近发布的材料，德州仪器使用SystemC ESL设计方法设计和开发其OMAP处理器和调制解调器平台，STMicroelectronics使用它来设计其Nomadik应用处理器。此外，诺基亚和高通等领先的系统设计公司正在建立面向SystemC的设计流程。

但为什么所有这些领先的公司都采用SystemC方法？是什么促使公司使用SystemC ESL设计增强其现有的设计方法？换句话说，您如何决定是否需要SystemC ESL设计方法？

当您遇到以下任何问题时，应考虑使用SystemC ESL设计：

1。当您的SoC部署采用多个嵌入式微处理器和DSP来实现融合功能时，例如通信和/或多媒体？复杂的体系结构，功能和协议的设计陷入了大量耗时的RTL细节。

SystemC ESL设计方法可以将架构设计时间从几个月缩短到几周。如何？

优化SoC架构需要探索和分析多个候选硬件/软件分区方案和硬件架构，每个方案都有不同的性能和经济权衡。在这个阶段，SoC架构师关注的是开发和优化系统行为和架构。

但RTL的引脚精确连接和纳秒精确的时序细节模糊了系统范围的视图，并大大减慢了设计速度。使用这种低生产率的方法，设计师偶尔会选择“无论什么工作”，而不是设计“什么效果最好”？并冒险推出一项缺乏竞争力的产品。国际商业战略（IBS）对领先的SoC公司进行的一项调查预测，SoC架构开发工作将很快超过物理设计工作，因此这种生产力问题有望变得更加糟糕。

SystemC ESL设计速度复杂硬件/软件分区和硬件架构开发通过执行比RTL更高的抽象级别，仅使用与系统设计相关的那些设计属性。这是“设计意图”被最有意义地捕获的水平？为SoC架构师提供直接和清晰的系统行为视图的水平。

SoC架构采用SystemC IP模块设计，通过应用程序接口（API）连接到与实现无关的高级总线模型。使用事务级建模（TLM），该体系结构在功能方面进行设计和验证，其特征在于高级块输入和输出事件以及块间数据传输。

系统IP组件和总线可以比RTL更容易修改或更换，模拟速度提高1000多倍。因此，设计人员可以快速优化设计，以实现“最佳效果”。

最终优化架构的TLM模型构成了一个“可执行规范”，可驱动整个后续RTL实现。

2。当完整的系统，功能验证消耗了更大的设计时间和预算？你仍然对第一次通过成功没有信心。

设计师报告说，SystemC ESL设计可以减少验证时间，使整体设计和验证工作减少50％ ，并确保第一次是正确的。事实上，当设计团队首次使用SystemC ESL设计来设计和开发SoC时，这是投资回报率中的最大因素。 SystemC ESL设计如何提供这一价值？

RTL验证始于设计人员对系统级行为的全面解释，包括大量的块内威廉希尔官方网站 状态和纳秒精确的转换，以及相关的比特精确的总线行为。然后，需要定义执行这些行为的大量详细场景，并为这些场景创建众多刺激/预期响应，然后进行模拟，通常以实际芯片速度的百万分之一执行。

这就是为什么随着SoC复杂性的增加，验证会消耗不断增加的设计时间。然后将验证的RTL设计转移到合成。但是如果全面的解释不够全面呢？

SystemC ESL设计自动化SoC架构的开发，并根据高级块输入和输出事件以及块间数据传输来验证行为，交易级别。这种系统级行为的直接视图消除了手动RTL到系统行为的解释，这种解释太容易不够全面，并且显着减少了所需场景的数量和测试它们所需的刺激/响应。

消除如此多的任务大大简化了验证工作和时间。此外，周期精确的TLM仿真执行速度比RTL快1000倍。

最终的系统级功能测试平台构成了“黄金”验证套件，可确保RTL设计符合规范。此外，SystemC与RTL的协同仿真功能使验证团队能够将SoC的TLM模型用作测试平台，以便在RTL块可用时对其进行验证。

3.当市场生存需要你以类似消费者的速度旋转原始SoC设计的多个衍生物？并且你迫切希望提高设计效率。

设计师报告说，SystemC ESL设计可以将衍生物的旋转时间减少多达75％。实际上，衍生设计是SystemC ESL设计的生产力对ROI影响最大的地方。如何？

衍生设计旨在维护SoC平台的基本架构和行为，同时增强或添加所选功能。传统方法是围绕第一个SoC选择的处理器建立基线RTL平台，然后通过“混合和匹配”适当的RTL IP来设计衍生产品，以实现所需的新功能。

问题在于“混合搭配”意味着RTL IP模型从未实现的“即插即用”程度，因为它们过于复杂。通常，衍生设计几乎与“干净”设计一样困难。

同样，SystemC ESL设计解决了这个问题。 IP模型实际上可以在SoC平台的SystemC TLM中“混合和匹配”。使用SoC设计的其余部分快速模拟新的SystemC IP，并且经过验证的衍生SoC的TLM模型可以用作测试平台，其中可以共同验证新IP的RTL视图。

4.当SoC性能和/或低功耗可以决定你的市场地位？并且调整RTL设计无法提供所需的改进。

SystemC ESL设计可以提供更高的性能，并且比RTL优化所实现的功耗节省10倍至20倍。怎么样？

SoC性能主要由硬件/软件分区，处理器，总线和存储器的速度以及它们的通信协议决定。这些系统组件和属性无法在RTL中进行调整。 SystemC ESL设计使设计人员能够设计出最佳的硬件/软件分区，硬件架构和协议，从而最大限度地提高SoC性能。

处理器，存储器和相关总线活动消耗高达80％的SoC功率，以及因此，硬件/软件分区以及软件算法和数据存储的效率受到很大影响。同样，这些系统组件和属性无法在RTL中进行调整，因此RTL调整最多可以在剩余的20％中进行渐进式改进。

功耗优化内存包括最小化内存访问次数和定制给定应用程序的内存架构。将高使用率的内存访问集群到一个单独的优化缓存中可以简化内存事务，从而降低功耗（并且通常可以提高SoC性能），因此缓存内存架构对功耗至关重要。

SystemC ESL设计直接和即时查看内存访问以及与之相关的活动，可以实现缓存命中率与缓存大小之间的直接关联，以及用于确定最佳内存大小的软件甘特图。从函数调用与内存访问频率的相关性中识别算法优化候选。

5.当您的系统客户需要早期SoC模型以使他们能够完成他们的设计并赢得设计时??他们不能等到RTL设计完成。

在无线通信中经常出现这种情况，这也是全球最大的寓言半导体公司之一Qualcomm的原因之一已经在SystemC上实现了标准化。

系统设计人员在芯片可用性之前通常需要SoC模型来验证整个系统设计的进展情况，并赢得客户的早期批准。此阶段的验证使系统设计人员能够在完成原型硬件之前检测并纠正系统不合格或彻底的故障，从而消除昂贵且耗时的硬件重制。

以及“迟到”，RTL模型并不是特别适合这个目的，因为它的实际芯片速度的百万分之一的验证速度减慢了系统模拟的速度。并且系统设计人员不一定知道如何调试RTL。

SystemL TLM模型在RTL实现之前几个月就可用，它封装了系统感兴趣的所有系统级行为和属性。设计师，执行速度比RTL快1000倍。因此，它不仅满足系统设计人员对早期SoC模型的需求，而且还在系统设计者最熟悉的抽象层次上执行。

6.当您仅开始软件开发时原型可用？产品发布的软件和软件完成。

在嵌入式软件中实现了超过50％的SoC功能，这正成为SoC设计的起搏项目。 IBS调查预测嵌入式软件开发工作将很快超过SoC硬件设计工作，因此问题变得更加严重。软件开发人员必须在RTL设计完成之前开始有效工作。

使用外设“存根”的先前软件开发方法不再能够充分代表现代的多处理器，多总线架构。如果没有早期的SystemC TLM原型，该软件的开发完全独立于硬件团队设计，从而产生了显着的集成风险。在设计过程的尾端进行集成使得上市时间变得非常难以预测。

使用FPGA原型来实现早期的软件和系统硬件集成只能适度地改善计划，因为这样的原型仍然来得太晚。在这个阶段，RTL设计发生了变化？甚至是次要的？整合所遇到的问题需要非常耗时。

同样，SystemC TLM原型可以在几个月前开始有效的软件开发。可以将与硬件相关的软件（例如RTOS）移植到模型中，而无需连接各个引脚。应用软件 ？？这与硬件无关？可以使用TLM作为数据流模型开发和移植。

7.当使用RTL原型协同验证软件太慢时，您无法验证是否有足够的信心确保没有错误。

Qualcomm举了一个这个问题的例子。维特比解码器在20ms内执行一个数据包，但需要6个小时来模拟C/RTL级别。 Qualcomm估计必须模拟1,000个数据包以达到合理的置信水平，但认为必要的6000小时的模拟时间是不切实际的。

SystemC ESL设计可以与硬件相关的软件共同验证硬件架构比RTL快1000倍以上，具有周期精度。维特比解码器可在不到6小时内验证，而不是6,000小时。通过使用定时和协议无关的仿真，可以更快地共同验证与硬件无关的软件，例如应用软件。

8.当您的团队想要建立或已经维护时这是一个本土化的系统级设计环境，它将重要的工程资源和预算从创收设计中转移出来。

构建和维护自行开发的ESL设计环境既昂贵又不提供战略分化。自行开发的ESL设计环境与本土逻辑综合或布局布线工具一样具有经济意义？

此外，许多历史悠久的ESL设计环境利用C或C ++方言，与SystemC不同，它们不具备描述真实所需的时间，位精度和并发性概念。 RTL设计人员和嵌入式软件开发人员所需的世界行为和性能。更糟糕的是，没有标准的C/C ++建模方法，导致缺乏可用的模型，难以共享和重新使用那些可用的模型。

这两个问题的解决方案是部署商用的SystemC ESL设计环境。提供商确保该工具和您始终处于SoC设计自动化的前沿。

9.当您在日程安排上失眠，第一次成功，设计和掩盖成本超过跑？你想知道如何继续与其他领先的SoC公司竞争。

解决方案很简单。采用与领先的SoC设计人员已经使用的相同的SystemC ESL方法。

电子系统级设计和验证方法的采用正在加速。 ESL设计工具的需求受复杂多处理器设计的挑战驱动，其中一半以上的功能在嵌入式软件中实现，而SystemC则使ESL设计得以快速采用。

今年将远远超过使用ESL设计方法的100个SoC设计。这种方法最终超越了它的采用鸿沟，因为SoC设计遇到了自己的鸿沟？系统级设计生产力鸿沟。

Mark Creamer是CoWare公司的副总裁。