2008-11-17 38 views
6

我最近(反覆)向客戶詢問我們運行軟件所需的MIPS。通常我們可以通過向客戶解釋這實際上取決於cpu/os/hw(我們的軟件是高度便攜的)和/或用例(即我們的軟件是如何使用的)來擺脫這個問題。嵌入式軟件的Mips計算

但我有一個最後一個不僅非常固執,但另外提供了很好的理由固執。 :)他想要一個估計,因爲他不確定他有足夠的能力來運行我們的軟件,所以在這個估計之前購買軟件是不合邏輯的。 (我們無法提供演示/評估,因爲它需要大量工作才能在此特定平臺上運行。)

現在問題:有人在任何一個hw上都有這樣的任務經驗,任何軟件?任何現實生活中的例子都會非常有用。我可以選擇在許多操作系統和許多硬件上運行我們的軟件。因此,如果您在任何硬件上都瞭解此類估算的工具,就有機會使用它或至少可以獲得一個想法。知道我只知道如何測量eCosPro OS上的CPU負載。

編輯:

使用探頭實際上是一個好主意,假設只有在我的軟件運行的所有指令,我可以指望是我的,我可以創造一個控制環境,我想探頭有一個接口做到這一點。實際上,我有幾個不同的硬件調試器,如果有人有經驗如何做,這將是非常好的,任何方式我明天將閱讀一些文檔,並希望能找到這方面的東西。

回答

4

OK你意識到這是充滿免責聲明&警告 - CPU速度,內存速度,高速緩存命中,MMU頁表刷新,總線爭用,等...(如果它是一個重型的嵌入式系統)的所有因素明顯地進入決定......

說了這麼多, ....我會做的是這樣的。獲得一個實時操作系統(可以和我一起),也許FreeRTOS(免費,多麼驚喜)或者u/C-OS-II(不是免費的商業用途,可能是3K)。這些內核允許您測試代碼以計算空閒CPU週期(空閒任務旋轉循環)。

因此,將您的整個應用程序(或客戶的應用程序)作爲您認同的電路板上的唯一(非空閒)任務(例如,MPC860電路板,ARM7電路板等)。通過RTOS測量電路板上的%CPU。 (例如「在運行頻率爲60MHz的Flibber板上,我們的應用程序使用了12%的CPU」)。

沒有它們給你更多,反之亦然,聽起來像是一個相當合理的長度。

好的是,一旦你完成了這個任務,你可以重新使用其他目標和/或電路板的工作,也許這些數字將幫助你增加銷售和/或調整/優化你的軟件。

祝你好運!

2

您是否有仿真器或調試器探針可以給您指令計數?你甚至不需要爲了正確的目標平臺而做,只需要大致的指令計數。

如果一切都失敗了,可以在你有權訪問的任何平臺上運行它,使用-MHz/customer's-MHz的商來縮放運行時間。這應該會給你一個非常粗略的估計,即客戶會經歷什麼樣的運行時間。

+0

好主意,你知道任何* *探頭能做到嗎?我的平臺上的估計將滿足客戶。 – Ilya 2008-11-17 23:54:52

+0

我沒有太多使用不同調試器探測器的經驗,不幸的是,我只能粗略地知道你可以用它們做什麼。 – JesperE 2008-11-18 09:23:14

+0

謝謝任何​​方式,我會在這裏發佈後,我會得到一個:) – Ilya 2008-11-18 10:21:09

0

I/S是具有操作系統的系統的「弱」指標。

在基本事實,你所要做的就是

  1. 身影了最壞情況的指令路徑,並計算需要多少個時鐘週期執行(這意味着讀取組件,其CPU和審查告訴你週期數的CPU手冊)。
  2. 現在計算出您的實時約束條件。
  3. 然後你使用#1作爲最壞情況週期。向上/向下調整CPU,直到它符合實時限制條件。
  4. 添加欺騙因子。
+0

這是非常漫長的道路...... :)該軟件退出大而複雜。 – Ilya 2008-11-17 23:56:10

0

您需要做的第一件事是提出一些正確操作的標準。 這將非常依賴應用程序的性質 - 您的標準可能包括「必須在3ms內執行代碼x」或「必須具有低於100毫秒的延遲」。任何不涉及定量測量的標準都會很困難,因爲它會是主觀的。

找到正確操作的標準將允許您找到代碼的關鍵部分。請記住,這些可能發生在角落案件,而不是正常運作。

如果那些代碼的關鍵部分很小,那麼爲目標平臺計算指令將會相對順利。如果你有一個更容易的模擬器。 (取決於你可能需要做的模擬代碼,以確保它被執行,但是如果你有大量的代碼需要分析的話,這可能比計算指令更容易)

如果你的關鍵代碼很大,那麼你可能不得不做類似於JesperE的建議。除非您的應用程序針對價格敏感的行業,否則客戶可能會接受計算中的一點點鬆懈 - 因此比估算您的CPU需求更好。

與JesperE的建議不同的地方是建議不要關注MHz,而應該關注目標的實際MIPS。例如,在測試平臺上編譯和執行你的代碼 - 如果你有一個可能更好的分析器。然後編譯客戶目標的代碼,並對生成的可執行文件中指令的數量進行粗略比較。 然後,您可以將此比率以及測試和目標處理器的相對MIPS合併到執行時間的計算中。

0

你說你的軟件是高度可移植的,所以我的建議是在處理器架構,處理器指令集和內存/外設總線類型最接近的平臺上運行軟件。衡量必須實時運行的最長例程,然後估計在其體系結構上運行多長時間。

0

大多數現代調試器使您能夠查看所使用的指令,例如: RVDS。另外,你可以使用處理器模擬器來獲得一個體面的想法,而不需要在平臺上實際運行(如果你的代碼是獨立的,例如編解碼器或加密模塊,並且不依賴於電路板) - 請注意,這會給你提供說明,不循環。該週期將通過您的主板細節的影響(例如,等待狀態,內存訪問等)

0

在兩塊我使用的處理器架構(MSP430F5X和AVR32)的存在硬件循環計數寄存器內置於處理器。我通常有一種方案,當處理器不忙時,處理器內核停止進入低功耗空閒狀態。然後有兩種方法可以計算出實際的處理器負載。我可以在週期性定時器函數中設置一個斷點並讀取執行的處理器週期數,也可以通過在其操作開始和結束時讀取該寄存器來檢測特定進程。由於此時CPU暫停,處理器空閒時間不會出現在週期計數中。

不指定你的處理器架構,但這種能力可能存在。

0

RapiTime聲稱可以給的最壞情況執行時間的概率估計爲目標。我沒有用往心裏去,但看到他們的介紹...

如果你的目標是非常相似,你的客戶,你可能可以擴展它來估計自己的平臺上的WCET。然後他們可以將其與當前系統的「備用」時間進行比較。