软件应用程序开发人员–还有那些坐在自家客厅沙发上使用笔记本电脑的开发人员–他们该如何估算其应用程序运行在目标设备时的功耗?这是目前的一个大问题(很显然是一件让iPhone和黑莓用户觉得很痛苦的事情),并且未来这个问题只会越来越难解决。软件工程师们可能会认为这不是他们的事。他们只管编写代码,然后把问题推给硬件工程师,而事实上硬件工程师解决问题的能力也是有限的。可以肯定的是,随着越来越高等级的抽象模型的使用
软件应用程序开发人员–还有那些坐在自家客厅沙发上使用笔记本电脑的开发人员–他们该如何估算其应用程序运行在目标设备时的功耗?这是目前的一个大问题(很显然是一件让iPhone和黑莓用户觉得很痛苦的事情),并且未来这个问题只会越来越难解决。
软件工程师们可能会认为这不是他们的事。他们只管编写代码,然后把问题推给硬件工程师,而事实上硬件工程师解决问题的能力也是有限的。
可以肯定的是,随着越来越高等级的抽象模型的使用-这样工程师可以仿真某些应用程序或函数,硬件/软件协同设计环境最终将成为'新的领域'。当然,需要用到新工具来考虑到这些因素。但总的来说,这些工具可能仍需要几年时间才能被用到工程师的工作平台,更别说(被用到)那些在家干活的开发人员的软件开发工具包。
在理想的情况下,如果可以创建高层模型,将其突破对硬件的RTL描述至事务级,那么就可以捕获硬件信息并传送给软件应用,不管其是否包含功耗、软件领域或类似的信息。然后,工程师们可以清楚软件的影响,并相应地修改硬件,Apache Design Solutions公司RTL业务部门高级副总兼总经理Vic Kulkarni表示。 “但现在情况反过来了:因为硬件工程师使用的硬件五花八门,然后软件开发人员并不是真的了解这个硬件能做些什么。”
CadenceDesign Systems公司解决方案市场营销总监Pete Hardee指出,现在的智能手机是汇聚性设备,智能手机的计算能力与近期的独立器件不相上下。 “现在的智能手机的处理能力可以媲美四、五年前的主流个人电脑或笔记本电脑”;智能手机所具备有的视频功能,机顶盒也是在早两年前才有;高清视频和 3~500万像素的摄像头。与此同时,正是由于硬件技术在过去取得了巨大飞跃(仍明显遵从摩尔定律),并且软件生产力的飞跃实际上已经超越了摩尔定律,这才使得手机能具备上述强大功能。没有取得进步的是古老的电池技术。因此,我们现在还是用锂离子电池。设计师竭尽所能地利用电池的能量,但我们基本的期望仍是手机至少能支撑一个完整的工作日,能挨到回家后再给手机充电。”
当然,这要取决于你用手机做些什么,但底线是这一切都由软件控制。 “当分析功率时,它不仅仅是关于硬件的特征。你还需要运行一系列系统模式,这些系统模式用于抽象地表征工作量最大的情况-此时会要用到所有应用程序,以及工作量较少的情况-此时很闲(不需使用多个应用程序),并且还要在这些系统模式之间做切换,这样我才能知道什么时候可以对设备的某些部件断电,什么时候不能这么做”,Hardee表示。
现今许多芯片公司要面临的挑战是需要仿真30个不同的系统模式。此外,他们还要煞费苦心地测量所有这些模式、芯片的各个部件的带宽,并且要非常清楚电源管理系统究意是如何处理:那些可以放缓、那些需要加速,从而使其可以断电更长时间。所有这些不同的模式都需要测量。 “估算运行真实软件的真实系统工作的功率成了一个大问题,并且只有极少极少的解决方案可以做到这一点,”他表示。
目前普遍的看法是倾向于用虚拟平台来做(功率)测量,但Hardee认为虚拟平台太过于抽象而不能够测量功率的影响。 “一旦你真的需要知道在硬件中实现的电源模式,那么你就需要运行在一定的精度,而这将会减慢虚拟平台。”
公平地说,Cadence公司的方案也的确包含有虚拟平台直达其事务级仿真器,并且将ARM公司的快速处理器模型和其它各种型号的处理器整合在一起,但该公司侧重于其基于硬件的仿真系统-用于电源敏感类仿真。
Mentor Graphics公司ESL市场开发经理Shabtay Matalon认为,工程师已经熟悉了抽象的概念,他们从抽象gates(门级)-RTL开始,目前有用SystemC(一种系统级建模语言)和事务级建模对更高级RTL功能进行抽像。 “人们现在意识到,通过创建一个模型,虽然这个模型没有包含全部信息但包含了取得时序概念所需要的足够信息,但这样你也可以将时序抽象。但人们可能不知道的是,我们可以创建一个可供软件工程师使用的模型,这个模型包含将电源抽像一直到ESL或TLM”。
该模型将功率与流经这些事务级模型的流量联系起来。这些模型在被创建后可以被缝合在一起,Matalon表示。这些模型可以是外围设备模型、处理器模型或设备模型,并且可以缝合在一起生成一个可以运行应用软件的平台。
Synopsys公司低功耗解决方案组的技术市场总监Cary Chin认为,虚拟平台是通往高级层的解决方法。 “有很多非常好的方法通过一个虚拟平台来钩住软件堆栈。但我仍然认为,从虚拟平台向下通过高级RTL的连接仍然有一点不连贯,因为有很多要素需要发生以便将这些环境连接在一起。”
.尽管,这里需要回答的大问题是:我们有多希望让软件开发人员来直接控制硬件,Cary Chin表示。这基本上直接反对信息隐藏(模块之间通过其API通信,一个模块不需要知道另外一个模块的内部情况)的观点。
“在软件开发环境下,我们试图隐藏事物,因为有些事物我们实事上无法在高级别Vs.低级别的情况下做出更好的决定。当你从软件领域跨越到硬件领域时,这些概念也会随之而来,因此,非常难以判断。你希望能编写一款可在各个开发环境之间转移的软件或类似的东西,但如果你将其与某个特定的硬件平台紧密联系在一起,那么事情就会变得非常困难。
教育软件开发人员
“有了这一切,仍然有可能写不出好软件,因为数据使用的效率非常低—例如,也许有些(情况下)会不必要地持续刷新液晶屏,” Hardee表示。 “人们如何获得反馈,真正归结于那些由手机制造商或网络运营商(Sprint有一个应用程序开发网络)提供的应用开发工具包。使用Android的手机有一个开发系统。可以就这些开发工具包中的不良的优化、不好的内存用法等等向用户提供反馈。”
该解决方案的一部分可能是一个产业链或合作型方案。“从硬件方面来看,[EDA供应商]与苹果或谷歌这类公司在某些方面展开合作以真正地将他们的开发工具包向下扩展的想法可能实际上和努力搭建一样有意义,因为那些人手上有很多资源并且他们能就在中间层会合帮不少忙”,Chin进一步补充道。
但这仍不能解决其中的一个大问题,那就是存在于软件和硬件之间的巨大鸿沟。 “硬件领域和软件领域之间的鸿沟比前端设计和后端设计之间的鸿沟更大。硬件设计和软件设计目前并没有真正地衔接好,并且最终会有在某种意义上人们可以想到的不同等级的抽象,如果你从软件开发的角度来看。有高级编程语言C / C + +,有低级编程语言汇编代码”,Apache Design Solutions公司产品工程和应用高级主管Will Ruby指出。
至少有些(问题)在短期内可以使用模型来处理,但有些也需要用到智能编译器这样的新技术。
“汇编实际上更接近硬件,但人们通常不会用汇编语言来写程序,除非他们是在处理嵌入式编程。硬件的概念需要转移到C/C + +或Java类的开发环境。模式就是在那出现的。我们需要模型来表征硬件行为,但我想我们同样还需要像一个类似智能编译器的东西,这样就能利用其中这些硬件勾子的某些优势,并且了解当你在为某个手机应用程序编程的时候,会需要在针对性能或功耗编译之间做取舍。硬件工程师们一直在考虑这个问题,但对软件工程师们而言这不是一件容易的事。因此,编译器可能需要涉及这个方向。编译器需要对解件敏感,并且需要了解硬件正在做什么”,他总结道。