Расчет Mips для встроенного программного обеспечения

Question

Недавно меня (и неоднократно) спрашивали клиенты о MIPS , необходимых для запуска нашего программного обеспечения. Обычно нам удавалось избавиться от этих вопросов, объяснив клиенту, что это действительно зависит от cpu / os / hw (наше программное обеспечение очень переносимо) и / или варианта использования (т. Е. Как используется наше программное обеспечение).

Но у меня есть последнее, которое не только очень упрямо, но и дает веские причины быть упрямым. :) Ему нужна оценка, потому что он не уверен, что у него достаточно мощности для запуска нашего программного обеспечения, поэтому покупка программного обеспечения до этой оценки не логична. (Мы не можем предоставить демо / оценку, поскольку для выполнения этой конкретной платформы потребуется значительный объем работы.)

А теперь вопрос: есть ли у кого-нибудь опыт с такой задачей на любом кусочке hw с любым программным обеспечением? Любой пример из реальной жизни будет очень полезным. У меня есть возможность запустить наше программное обеспечение на многих ОС и многих аппаратных средствах. Так что, если вы знаете какой-либо инструмент для такой оценки на любом оборудовании, есть шанс, что я смогу использовать его или, по крайней мере, получить представление. Ибо знаю, я только знаю, как измерить нагрузку на процессор на eCosPro OS .

Edit:

Использование probe - это действительно хорошая идея, предполагая, что я могу создать контрольную среду, в которой только мое программное обеспечение выполняет все команды, которые я могу сосчитать, - мои, и я полагаю, что у probe есть интерфейс для этого. На самом деле у меня есть несколько различных аппаратных отладчиков, и если у кого-то есть опыт, как это сделать, это будет действительно хорошо, в любом случае я собираюсь завтра прочитать какую-нибудь документацию и, надеюсь, что-нибудь найду в этом направлении.

Answer 1

Хорошо, вы понимаете, что это чревато заявлениями об отказе от ответственности - скорости процессора, скорости памяти, попадания в кэш, сбросы таблиц MMU, конфликты шины и т. Д. (Если это встроенная система для тяжелых условий работы) - все это существенно в решение ....

Сказав, что .... я бы сделал следующее. Получите операционную систему в реальном времени (оставайтесь со мной), возможно, что-то вроде FreeRTOS (бесплатно, что за сюрприз) или u / C-OS-II (не бесплатно для коммерческого использования, может быть, $ 3K). Эти ядра позволяют использовать код для подсчета циклов простоя ЦП (цикл простоя задачи).

Так что запустите все приложение (или приложение клиента) как единственную (не простую) задачу на плате, с которой вы, ребята, согласны (например, плата MPC860, плата ARM7 и т. Д.). Измерьте% CPU на плате через ОСРВ. (например, «на плате Flibber, работающей на частоте 60 МГц, наше приложение использовало 12% ЦП».)

Без них вам больше, или наоборот, это звучит как довольно разумная длина для них.

Хорошо, что после того, как вы это сделали, вы можете повторно использовать эту работу для других целей и / или плат, возможно, цифры помогут вам увеличить продажи и / или настроить / оптимизировать ваше программное обеспечение.

Удачи!

Answer 2

У вас есть симулятор или датчик отладчика, который может подсчитать количество команд? Вам даже не нужно делать это для правильной целевой платформы, достаточно грубого подсчета команд.

Если все остальное терпит неудачу, запустите его на любой платформе, к которой у вас есть доступ, масштабируйте время выполнения с частотой ваших МГц / МГц клиента. Это должно дать вам очень приблизительную оценку того, какие виды времени работы клиент будет испытывать.

Answer 3

RapiTime утверждает, что может дать вероятностную оценку времени выполнения наихудшего случая для вашей цели. Я не использовал это лично, но видел их представления ...

Если ваша цель достаточно похожа на цель вашего клиента, вы, вероятно, можете масштабировать ее, чтобы оценить WCET на их платформе. Затем они могут сравнить это с «свободным» временем, которое имеет их текущая система.

Answer 4

На двух архитектурах процессора, которые я использую (MSP430F5X и AVR32), в процессор встроен регистр счетчика аппаратных циклов. У меня обычно есть схема, где, когда процессор не занят, он переводится в состояние простоя с низким энергопотреблением с остановленным ядром процессора. Тогда есть два варианта для определения фактической загрузки процессора. Я могу либо установить точку останова в функции периодического таймера и прочитать количество выполненных циклов процессора, либо я могу управлять конкретными процессами, читая этот регистр в начале и в конце их работы. Время простоя процессора не отображается в счетчике циклов, так как процессор останавливается на это время.

Вы не указываете архитектуру своего процессора, но эта возможность может присутствовать.

Answer 5

Большинство современных дневных отладчиков дают вам возможность просматривать использованные инструкции, например; RVDS. Кроме того, вы можете использовать эмуляторы процессора, чтобы получить адекватное представление о потребляемых инструкциях без фактического выполнения на платформе (если ваш код автономен, например, кодек или криптографический модуль и не зависит от платы) - обратите внимание, что это даст вам инструкции не циклы. На циклы будут влиять данные вашей платы (например, состояния ожидания, доступ к памяти и т. Д.)

Answer 6

Вы говорите, что ваше программное обеспечение очень переносимо, поэтому я бы предложил запустить программное обеспечение на платформе, наиболее близкой по архитектуре процессора, по набору команд процессора и по типу памяти / периферийной шины. Измерьте самую длинную процедуру, которая должна выполняться в режиме реального времени, а затем определите, как долго она будет работать в их архитектуре.

Answer 7

Первое, что вам нужно сделать, это придумать какие-то критерии правильной работы. Это будет во многом зависеть от характера приложения - ваши критерии могут включать «должен выполнить код x за 3 мс» или «иметь задержку менее 100 мс». Любой критерий, который не относится к количественному измерению, будет сложным, поскольку он будет субъективным.

Поиск критериев правильной работы позволит вам найти критические части кода. Имейте в виду, что они могут быть обнаружены в угловых случаях, а не при нормальной работе.

Если эти критические части кода маленькие, то инструкции по подсчету для вашей целевой платформы будут относительно простыми. Если у вас есть симулятор, это может быть даже проще. (в зависимости от кода вам может потребоваться выполнить макет, чтобы убедиться, что он выполняется, но это, вероятно, все равно будет проще, чем подсчет инструкций, если у вас есть большой кусок кода для анализа)

Если ваш критический код большой, то вам, возможно, придется сделать что-то похожее на предложение JesperE. Если ваше приложение не нацелено на невероятно чувствительную к цене отрасль, есть вероятность, что заказчик согласится немного ослабить вычисления - поэтому его лучше переоценить, чем оценить ваши требования к процессору.

В чем я отличаюсь от предложения JesperE, так это предложения не концентрироваться на МГц, а на реальных MIPS целей. Например, скомпилируйте и выполните свой код на тестовой платформе - если у вас есть профилировщик, который может быть лучше. Затем скомпилируйте свой код для цели клиента и сделайте грубое сравнение количества инструкций в результирующем исполняемом файле. Затем вы можете включить это соотношение вместе с относительными MIPS тестового и целевого процессоров в расчет времени выполнения.

Answer 8

I / S - это «слабый» показатель для системы с операционной системой.

В мельчайших подробностях, что вам нужно сделать, это

1. определите путь к наихудшему сценарию и посчитайте, сколько циклов требуется для выполнения (это означает чтение сборки для этого ЦП и просмотр справочника по ЦП, в котором указано количество циклов).
2. Теперь выясните ваши ограничения в реальном времени.
3. Тогда вы используете # 1 для наихудших циклов. Настраивайте ЦП вверх / вниз, пока он не будет соответствовать ограничениям реального времени.
4. Добавить коэффициент помадки.