是时候该行业设计灵活,更快和更有效的方法吗?
如果你想知道如何重要的低功率是在今天的芯片设计,考虑最近的新闻博客报道争议高通Snapdragon 810 SoC -公司的第一个旗舰64位芯片,这将极有可能成为权力Android设备于2015年发布。故事打破了在12月初的810已经过热的问题。
不论真假,三星取代Snapdragon 810年当选7000 -系列,Exynos,刚刚宣布星系S6智能手机。
上面的故事可以避免吗?是的,通过使用更好的能力估计方法在SoC的设计和验证阶段。
关注动态功率估计两个关键方面:平均功耗和峰值功率消耗。不是密切相关,它们驱动芯片设计者在开发过程中几个关键的决策。通过评估的平均功耗,设计师可以决定最佳的模具尺寸,选择合适的方案,选择电池尺寸和计算电池寿命。相反,通过评估峰值功率消耗,他们可以确定芯片的可靠性,电力rails对于峰值功率负载的大小,测量性能和冷却方案进行评估。
动态功耗在很大程度上依赖于运行时的设计活动。这个活动可以由testbench触发,基于软件target-system-based或嵌入式软件的执行。
创建一个testbench彻底验证整个SoC的功能将是一个巨大的事业。幸运的是,它可以避免启动一个操作系统,和处理驱动程序、应用程序和诊断软件。
图1图功耗SoC中随着时间的推移,通过启动一个操作系统和运行一些应用程序。它清楚地表明,平均功耗徘徊在20%的最高峰值功率消耗。
图1:SoC动态功耗启动一个操作系统和运行应用程序。
直到现在,估计动态功耗的方法是一个两步的过程。首先,RTL模拟器或硬件仿真器记录的交换活动设计在数据库中。第二,能力评估工具读取数据库和计算等动态功耗。
估计平均动态功耗所有信号全局计数器积累的交换活动为整个验证会话的交换格式(赛义夫)文件。相反,作为准确估计的动态功耗峰值个人计数器记录每个信号的切换活动逐周期基础上快速信号数据库中(FSDB)文件。
重要的是要注意,采样信号的一个子集的实践在一个有限的时间窗口将导致完全不准确评估的动态功耗,必须完全避免。
但是有一个问题模拟器。,他们的执行速度大大降低设计尺寸增加。与设计尺寸达到或超过1亿门,模拟器的速度可能低于10赫兹,太慢了嵌入式软件进行处理。只有模拟器能够在合理的时间内完成具有挑战性的任务。
图2表示两个阶段在一个场景,导师图形Veloce2模拟器生成赛义夫和FSDB文件。
图2:两步动态功率估计通过导师图形Veloce2仿真平台。
当应用于大型现代SoC设计,三两步方法是受到严重的限制。首先,赛义夫文件,更因此FSDB文件,是巨大的,几乎难以管理。第二,这些文件的生成是一个漫长的过程的许多小时。第三,电力消费FSDB文件分析工具需要数天甚至数周,一个永恒的开发周期来衡量现代SoC在一个高度竞争的市场。结合,三个问题完全失败的方法。
现实的动态功率估计只能通过引导操作系统和真正的应用程序在目标环境中运行和记录每一个信号转变为每个时钟的优势。不幸的是,两步过程基于代赛义夫和FSDB文件在一个时代,SoC设计方法billion-gate能力已不再适用。
对该行业来说,是时候探索并设计一种新的灵活,更快和更有效的方法吗?我希望听到你说什么。
|
|
|
|
|
|
|
|
|
|
留下一个回复