軟件應用程序開發人員–還有那些坐在自家客廳沙發上使用筆記本電腦的開發人員–他們該如何估算其應用程序運行在目標設備時的功耗?這是目前的一個大問題(很顯然是一件讓iPhone和黑莓用戶覺得很痛苦的事情)，并且未來這個問題只會越來越難解決。軟件工程師們可能會認為這不是他們的事。他們只管編寫代碼，然后把問題推給硬件工程師，而事實上硬件工程師解決問題的能力也是有限的。

　　可以肯定的是，隨著越來越高等級的抽象模型的使用-這樣工程師可以仿真某些應用程序或函數，硬件/軟件協同設計環境最終將成為'新的領域'。當然，需要用到新工具來考慮到這些因素。但總的來說，這些工具可能仍需要幾年時間才能被用到工程師的工作平臺，更別說(被用到)那些在家干活的開發人員的軟件開發工具包。

　　在理想的情況下，如果可以創建高層模型，將其突破對硬件的RTL描述至事務級，那么就可以捕獲硬件信息并傳送給軟件應用，不管其是否包含功耗、軟件領域或類似的信息。然后，工程師們可以清楚軟件的影響，并相應地修改硬件，Apache Design Solutions公司RTL業務部門高級副總兼總經理Vic Kulkarni表示。 “但現在情況反過來了：因為硬件工程師使用的硬件五花八門，然后軟件開發人員并不是真的了解這個硬件能做些什么。”

　　Cadence Design Systems公司解決方案市場營銷總監Pete Hardee指出，現在的智能手機是匯聚性設備，智能手機的計算能力與近期的獨立器件不相上下。 “現在的智能手機的處理能力可以媲美四、五年前的主流個人電腦或筆記本電腦”;智能手機所具備有的視頻功能，機頂盒也是在早兩年前才有;高清視頻和3~500萬像素的攝像頭。與此同時，正是由于硬件技術在過去取得了巨大飛躍(仍明顯遵從摩爾定律)，并且軟件生產力的飛躍實際上已經超越了摩爾定律，這才使得手機能具備上述強大功能。沒有取得進步的是古老的電池技術。因此，我們現在還是用鋰離子電池。設計師竭盡所能地利用電池的能量，但我們基本的期望仍是手機至少能支撐一個完整的工作日，能挨到回家后再給手機充電?！?/p>

　　當然，這要取決于你用手機做些什么，但底線是這一切都由軟件控制。 “當分析功率時，它不僅僅是關于硬件的特征。你還需要運行一系列系統模式，這些系統模式用于抽象地表征工作量最大的情況-此時會要用到所有應用程序，以及工作量較少的情況-此時很閑(不需使用多個應用程序)，并且還要在這些系統模式之間做切換，這樣我才能知道什么時候可以對設備的某些部件斷電，什么時候不能這么做”，Hardee表示。

　　現今許多芯片公司要面臨的挑戰是需要仿真30個不同的系統模式。此外，他們還要煞費苦心地測量所有這些模式、芯片的各個部件的帶寬，并且要非常清楚電源管理系統究意是如何處理：那些可以放緩、那些需要加速，從而使其可以斷電更長時間。所有這些不同的模式都需要測量。 “估算運行真實軟件的真實系統工作的功率成了一個大問題，并且只有極少極少的解決方案可以做到這一點，”他表示。目前普遍的看法是傾向于用虛擬平臺來做(功率)測量，但Hardee認為虛擬平臺太過于抽象而不能夠測量功率的影響。 “一旦你真的需要知道在硬件中實現的電源模式，那么你就需要運行在一定的精度，而這將會減慢虛擬平臺。”公平地說，Cadence公司的方案也的確包含有虛擬平臺直達其事務級仿真器，并且將ARM公司的快速處理器模型和其它各種型號的處理器整合在一起，但該公司側重于其基于硬件的仿真系統-用于電源敏感類仿真。

　　Mentor Graphics公司ESL市場開發經理Shabtay Matalon認為，工程師已經熟悉了抽象的概念，他們從抽象gates(門級)-RTL開始，目前有用SystemC(一種系統級建模語言)和事務級建模對更高級RTL功能進行抽像。 “人們現在意識到，通過創建一個模型，雖然這個模型沒有包含全部信息但包含了取得時序概念所需要的足夠信息，但這樣你也可以將時序抽象。但人們可能不知道的是，我們可以創建一個可供軟件工程師使用的模型，這個模型包含將電源抽像一直到ESL或TLM”。該模型將功率與流經這些事務級模型的流量聯系起來。這些模型在被創建后可以被縫合在一起，Matalon表示。這些模型可以是外圍設備模型、處理器模型或設備模型，并且可以縫合在一起生成一個可以運行應用軟件的平臺。

　　Synopsys公司低功耗解決方案組的技術市場總監Cary Chin認為，虛擬平臺是通往高級層的解決方法。 “有很多非常好的方法通過一個虛擬平臺來鉤住軟件堆棧。但我仍然認為，從虛擬平臺向下通過高級RTL的連接仍然有一點不連貫，因為有很多要素需要發生以便將這些環境連接在一起?！北M管，這里需要回答的大問題是：我們有多希望讓軟件開發人員來直接控制硬件，Cary Chin表示。這基本上直接反對信息隱藏(模塊之間通過其API通信，一個模塊不需要知道另外一個模塊的內部情況)的觀點。

　　“在軟件開發環境下，我們試圖隱藏事物，因為有些事物我們實事上無法在高級別Vs.低級別的情況下做出更好的決定。當你從軟件領域跨越到硬件領域時，這些概念也會隨之而來，因此，非常難以判斷。你希望能編寫一款可在各個開發環境之間轉移的軟件或類似的東西，但如果你將其與某個特定的硬件平臺緊密聯系在一起，那么事情就會變得非常困難。

　　教育軟件開發人員

　　“有了這一切，仍然有可能寫不出好軟件，因為數據使用的效率非常低—例如，也許有些(情況下)會不必要地持續刷新液晶屏，” Hardee表示。 “人們如何獲得反饋，真正歸結于那些由手機制造商或網絡運營商(Sprint有一個應用程序開發網絡)提供的應用開發工具包。使用Android的手機有一個開發系統?？梢跃瓦@些開發工具包中的不良的優化、不好的內存用法等等向用戶提供反饋?！?/p>

　　該解決方案的一部分可能是一個產業鏈或合作型方案。“從硬件方面來看，[EDA供應商]與蘋果或谷歌這類公司在某些方面展開合作以真正地將他們的開發工具包向下擴展的想法可能實際上和努力搭建一樣有意義，因為那些人手上有很多資源并且他們能就在中間層會合幫不少忙”，Chin進一步補充道。

　　但這仍不能解決其中的一個大問題，那就是存在于軟件和硬件之間的巨大鴻溝。 “硬件領域和軟件領域之間的鴻溝比前端設計和后端設計之間的鴻溝更大。硬件設計和軟件設計目前并沒有真正地銜接好，并且最終會有在某種意義上人們可以想到的不同等級的抽象，如果你從軟件開發的角度來看。有高級編程語言C / C + +，有低級編程語言匯編代碼”，Apache Design Solutions公司產品工程和應用高級主管Will Ruby指出。至少有些(問題)在短期內可以使用模型來處理，但有些也需要用到智能編譯器這樣的新技術?！皡R編實際上更接近硬件，但人們通常不會用匯編語言來寫程序，除非他們是在處理嵌入式編程。硬件的概念需要轉移到C/C + +或Java類的開發環境。模式就是在那出現的。我們需要模型來表征硬件行為，但我想我們同樣還需要像一個類似智能編譯器的東西，這樣就能利用其中這些硬件勾子的某些優勢，并且了解當你在為某個手機應用程序編程的時候，會需要在針對性能或功耗編譯之間做取舍。硬件工程師們一直在考慮這個問題，但對軟件工程師們而言這不是一件容易的事。因此，編譯器可能需要涉及這個方向。編譯器需要對解件敏感，并且需要了解硬件正在做什么”，他總結道。