|
По скорости ядра STR912, восемь операторов на ассемблере за 1.6мкс?!! |
|
|
|
Jun 13 2007, 15:47
|
Знающий
   
Группа: Свой
Сообщений: 995
Регистрация: 3-06-05
Пользователь №: 5 713

|
Есть main(), фактически из одного бесконечного цикла для проверки производительности ядра STR912FW44. Среда - IAR4.40:
u8 TMP0 = 0;
while(1) { if (Tick == 0) { GPIO_WriteBit(GPIO0, GPIO_Pin_0, Bit_RESET); Tick = 1; } else { GPIO_WriteBit(GPIO0, GPIO_Pin_0, Bit_SET); Tick = 0; } }
Время выполнения 1,6мкс. Ядро тактируется 96MHz через PLL. Память flash конфигурируется с двумя тактами ожиданмия и тактируется 48MHz
//FMI Waite States FMI_Config(FMI_READ_WAIT_STATE_2, FMI_WRITE_WAIT_STATE_0, FMI_PWD_ENABLE,\ FMI_LVD_ENABLE, FMI_FREQ_HIGH);
В симуляторе при выключенной оптимизации по скорости все действия занимают 8-мь ассемблерных команд. С учетом медленного доступа к внутренней flash (не более 24MHz) на выполнение должно уйти не более 320ns. Измеренное значение почти в пять раз больше. Где может теряеться вычислительный ресурс?
|
|
|
|
|
Jun 14 2007, 08:05
|
Знающий
   
Группа: Свой
Сообщений: 995
Регистрация: 3-06-05
Пользователь №: 5 713

|
Цитата(etoja @ Jun 14 2007, 06:59)  Биты ввода-вывода не могут переключаться с большой частотой. На них и теряется быстродействие. Все задействованные блоки GPIO тактируются частотой 1/2 master-clock (RCLKDIV = 1): SCU_PCLKDivisorConfig(SCU_PCLK_Div2); SCU_APBPeriphClockConfig(__GPIOx, ENABLE); GPIO_DeInit(GPIOx);
|
|
|
|
|
Jun 14 2007, 09:53
|
Знающий
   
Группа: Validating
Сообщений: 838
Регистрация: 31-01-05
Пользователь №: 2 317

|
Цитата(HardJoker @ Jun 14 2007, 12:05)  Все задействованные блоки GPIO тактируются частотой 1/2 master-clock (RCLKDIV = 1):
SCU_PCLKDivisorConfig(SCU_PCLK_Div2);
SCU_APBPeriphClockConfig(__GPIOx, ENABLE); GPIO_DeInit(GPIOx); Это ничего не значит !, тактироваться может чем угодно, а дергает всеравно медленно ! Если хотите измерять производительность с помощью ног, делается это так, пишется функция которая выполняет скажем 100 милионов нопов, перед входом устанавливете ногу после выхода опускаете, после чего врямя делите на 100 милионов и получите более мене точный результат, чем больше цикл, тем меньше сказывается тормознутость ног на измерение и следовательно более точный результат имеете.
|
|
|
|
|
Jun 14 2007, 10:36
|
Знающий
   
Группа: Validating
Сообщений: 838
Регистрация: 31-01-05
Пользователь №: 2 317

|
Так зачем тогда такой умный код ? Почему бы не так ? Код while(1) { GPIO_WriteBit(GPIO0, GPIO_Pin_0, Bit_RESET); GPIO_WriteBit(GPIO0, GPIO_Pin_0, Bit_SET); } Так более точно можно определить скорость "дрыганья" ногами
|
|
|
|
|
Jun 14 2007, 10:55
|
Знающий
   
Группа: Свой
Сообщений: 995
Регистрация: 3-06-05
Пользователь №: 5 713

|
Цитата(MALLOY2 @ Jun 14 2007, 13:53)  Это ничего не значит !, тактироваться может чем угодно, а дергает всеравно медленно ! Если хотите измерять производительность с помощью ног, делается это так, пишется функция которая выполняет скажем 100 милионов нопов, перед входом устанавливете ногу после выхода опускаете, после чего врямя делите на 100 милионов и получите более мене точный результат, чем больше цикл, тем меньше сказывается тормознутость ног на измерение и следовательно более точный результат имеете. Увы, интересует именно выполнение короткой процедуры. Штатная программа состоит из набора простых действий, которые должны выополняться за минимальный временной интервал. Иногда по прерыванию требуется обработать разовую команду также за минимальное время. Интегральные оценки производительности не подходят. Возможно, выход в выполнении всех критичных процедур из внутренней SRAM. Цитата(MALLOY2 @ Jun 14 2007, 14:36)  Так зачем тогда такой умный код ? Почему бы не так ? Код while(1) { GPIO_WriteBit(GPIO0, GPIO_Pin_0, Bit_RESET); GPIO_WriteBit(GPIO0, GPIO_Pin_0, Bit_SET); } Так более точно можно определить скорость "дрыганья" ногами  Умный код позволяет анализировать установленное состояние пина в любом месте алгоритма. Процедура используется в штатной программе, поэтому интересует именно ее скорость выполнения.
|
|
|
|
|
Jun 14 2007, 11:02
|
Знающий
   
Группа: Validating
Сообщений: 838
Регистрация: 31-01-05
Пользователь №: 2 317

|
Цитата Увы, интересует именно выполнение короткой процедуры. Штатная программа состоит из набора простых действий, которые должны выополняться за минимальный временной интервал. Иногда по прерыванию требуется обработать разовую команду также за минимальное время. Интегральные оценки производительности не подходят. Возможно, выход в выполнении всех критичных процедур из внутренней SRAM. Это тут причем ? какая разница короткая или длиная, мленькаыя или большая. Я посоветовал как измерить скорость выполния 1 команды NOP, тоесть после этого теста можзно сказать что 1 команда ноп выполняется за некоторое время. Другое доло когда вы в своих коротких функциях испрользуете ножки, в этом случае ядро будет останавливаться и ждать выполения команды, да и на конвеерных ядрах много переходов не есть хорошо, особенно в этом ядре у которого кеш переходов очень мальнький, а в FW версии в отличии от FAW еще и глючный!. Такчто оптимизируйте свою программу и делайте выводы. Еще в ковеерных ядрах выполнениефункции может колебаться на длинну конвеера. P.S. у STR время выполнения из ОЗУ и из FLASH практически одинаковое.
|
|
|
|
|
Jun 14 2007, 11:39
|
Знающий
   
Группа: Свой
Сообщений: 995
Регистрация: 3-06-05
Пользователь №: 5 713

|
Цитата(MALLOY2 @ Jun 14 2007, 15:02)  Это тут причем ? какая разница короткая или длиная, мленькаыя или большая. Я посоветовал как измерить скорость выполния 1 команды NOP, тоесть после этого теста можзно сказать что 1 команда ноп выполняется за некоторое время. Другое доло когда вы в своих коротких функциях испрользуете ножки, в этом случае ядро будет останавливаться и ждать выполения команды, да и на конвеерных ядрах много переходов не есть хорошо, особенно в этом ядре у которого кеш переходов очень мальнький, а в FW версии в отличии от FAW еще и глючный!. Такчто оптимизируйте свою программу и делайте выводы. Еще в ковеерных ядрах выполнениефункции может колебаться на длинну конвеера.
P.S. у STR время выполнения из ОЗУ и из FLASH практически одинаковое. Большое спасибо за ценный совет. Подозрения на конвейер были и раньше. Как я понимаю, отключить конвейер нельзя, хотя очень бы хотелось. Как раз из-за необходимости загружать его каждый раз в том числе при переходах.
|
|
|
|
|
Jun 14 2007, 16:28
|

Ally
     
Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050

|
Ну сперва убедитесь, что у вас выставлены все настройки как указано ниже: Core clock (MCLK) 96 MHz RCLK 96 MHz Flash Memory Interface Clock 96 MHz AHB clock (HCLK) 96 MHz APB clock (PCLK) 96 MHz External memory clock (BCLK) 96 MHz Branch cache enabled DTCM has 0 wait state AHB has 0 wait state AHB Lock transfer disabled FLASH read with 2 wait states FLASH Bus clock speed >66 MHz ARM966ES buffered writes disabled ARM966ES instruction prefetch buffer enabled Потом учтите, что из FLASH чуть ли не в два раза медленее выполняется чем из RAM. Правда это не к NOP-у относится, а интегральный показатель. У STR91xFAW он улучшен. Как быстро генеряться импульсы на пинах можно почитать тут: http://aly.projektas.lt/Projects/STR91_Start/STR91.htm#2Конвеер в STR91x - это не аттрибут ядра, а прокладка между ядром и FLASH, при работе из RAM он никакого влияния не имеет. И конвеер, кстати, можно отключить, хотя не советую. Также STR91x можно разогнать до 130 МГц. Во время тестирования на этой частоте сбоев обнаружить не удалось, даже АЦП работал с прежней точностью.
|
|
|
|
|
Jun 14 2007, 18:20
|
Знающий
   
Группа: Свой
Сообщений: 995
Регистрация: 3-06-05
Пользователь №: 5 713

|
Цитата(AlexandrY @ Jun 14 2007, 20:28)  Ну сперва убедитесь, что у вас выставлены все настройки как указано ниже: Core clock (MCLK) 96 MHz RCLK 96 MHz Flash Memory Interface Clock 96 MHz AHB clock (HCLK) 96 MHz APB clock (PCLK) 96 MHz External memory clock (BCLK) 96 MHz Branch cache enabled DTCM has 0 wait state AHB has 0 wait state AHB Lock transfer disabled FLASH read with 2 wait states FLASH Bus clock speed >66 MHz ARM966ES buffered writes disabled ARM966ES instruction prefetch buffer enabled Потом учтите, что из FLASH чуть ли не в два раза медленее выполняется чем из RAM. Правда это не к NOP-у относится, а интегральный показатель. У STR91xFAW он улучшен. Как быстро генеряться импульсы на пинах можно почитать тут: http://aly.projektas.lt/Projects/STR91_Start/STR91.htm#2Конвеер в STR91x - это не аттрибут ядра, а прокладка между ядром и FLASH, при работе из RAM он никакого влияния не имеет. И конвеер, кстати, можно отключить, хотя не советую. Также STR91x можно разогнать до 130 МГц. Во время тестирования на этой частоте сбоев обнаружить не удалось, даже АЦП работал с прежней точностью. Практически такие настройки в SCU у меня и стоят. Исключение в делителе на двойку PCLK. Ресурс http://aly.projektas.lt уже смотрел. На него есть ссылка в нескольких темах форума. Выложенный там пример проекта с STR912 у меня тоже есть. Если не трудно, пожалуйста, приведите собственный вариант настроек и инициализации STR91x.
|
|
|
|
|
Jun 15 2007, 05:15
|

Местный
  
Группа: Свой
Сообщений: 482
Регистрация: 5-07-05
Из: Санкт-Петербург
Пользователь №: 6 528

|
Цитата(MALLOY2 @ Jun 14 2007, 16:11)  Разве такое возможно ? невстречал ниодного ядра с переменным конвеером  , скорее всего это не возможно, да я и смыла невижу. Да, возможно, например в AVR32 можно играть длинной (глубиной) конвейера.
--------------------
Для связи email: info собака qbit.su
|
|
|
|
|
Jun 18 2007, 08:15
|
Знающий
   
Группа: Validating
Сообщений: 838
Регистрация: 31-01-05
Пользователь №: 2 317

|
Цитата Конвейер в STR91x - это не атрибут ядра, а прокладка между ядром и FLASH, при работе из RAM он никакого влияния не имеет. И конвейер, кстати, можно отключить, хотя не советую. Конвейер это неотъемлемая часть ядра, точнее это и есть ядро. в ARM966E-S он 5ти ступенчатый и состоит из следующих фаз - Fetch,Decode,Execute,Memory Writeback. Он неможет не изменятся не выключатся. Вы наверное путаете конвейер с так называемым "Pre-Fetch Que and Branch Cache" это ускоритель памяти и это разные вещи. Код Также STR91x можно разогнать до 130 МГц. Во время тестирования на этой частоте сбоев обнаружить не удалось, даже АЦП работал с прежней точностью. Этого я вам не советую делать, будут большие проблемы с серией  , исключения составляют те устройства которые сделаны для дома для семьи  . По поводу выполнения из ОЗУ, ARM9 и ARM7 построены по разной архитектуре и имеет разный конвейер ARM7 имеет 3х ступенчатый, ARM9 5ти, но это не самое главное. Самое главное то что ARM9 Имеет разные шины для данных и кода, это позволяет при записи данных выбирать следующую команду не останавливая при этом конвейер (есть конечно некоторые исключения ), по этому стоит задуматься откуда выполнять код. Да из флеша код выполняется медленней но при этом при записи/чтении конвейер не ждет выполнения операции что бы выбрать следующую, и следовательно конвейер работает без остановки. Если бы память в STR , была 2х портовая тогда это бы не влияло на производительность. По это выводы такие если функция имеет мало обращений к памяти данных она будет быстрее из ОЗУ работать, если она имеет много обращений скажем это КИХ фильтр, то тут уже не будет преимущества, и может даже еще медленней будет. Цитата Да, возможно, например в AVR32 можно играть длинной (глубиной) конвейера. Не могли бы вы конкретнее сказать где об этом написано, что то я не нашел только что листая мануал. P.S. конвейер "сборочная линия" - цепочка параллельно работающих исполнительных устройств центрального процессора, на которой обработка команд разбивается на ряд небольших шагов, стадий или ступеней, выполняемых за один такт. Конвейер организован таким образом, что выходные данные одного устройства поступают на вход другого. Число стадий называется длинной конвейера. Использование конвейера позволяет начать исполнение следующей машинной команды в одном блоке до завершения предыдущей, т.е. с перекрытием по времени. Какова длина конвейера, столько команд одновременно он и может обрабатывать. В современных процессорах конвейеры имеют длину до 20 стадий ( Pentium 4). Однако параллельная обработка команд возможна не всегда, так как в программе часто встречаются команды условных переходов и ситуации, когда для исполнения команды требуется результат предшествующей команды. В таких случаях, чтобы предотвратить перезагрузку конвейера ( pipeline break ) применяются более сложные процессы: упреждающая обработка (предсказание переходов) или изменение порядка исполнения команд
|
|
|
|
|
Jun 18 2007, 19:20
|
Участник

Группа: Новичок
Сообщений: 29
Регистрация: 3-11-04
Пользователь №: 1 027

|
Ну и мои 5 коп, сравнивал Гертцеля из флеша и ОЗУ на этом кристалле, особой разницы не заметил. Правда код линейный был. Так что в два раза медленеее из ОЗУ - это не так. Может процентов на 10-20 на таком коде, но не больше.
|
|
|
|
|
Jun 18 2007, 19:41
|

Ally
     
Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050

|
По моему из контекта обсуждения достаточно ясно, что речь шла о конвеере команд считанных из FLASH, а не о ядерном. Конвеер самого ARM-а мало кому интересен, ибо как правильно заметили он не регулируем. Но вы упустили нюанс, что за ядром стоит реализация шины памяти в исполнении ST о которой вы ничего не знаете, и соответственно ничего теоретически предположить о ее быстродействии не можете. Не забывайте также об имеющемся арбитре шин TСM и AHB. Даже шина TCM как не покажется странным не обеспечивает доступ к памяти за такт. Так что верить можно только натурным испытаниям. Цитата(MALLOY2 @ Jun 18 2007, 11:45)  Конвейер это неотъемлемая часть ядра, точнее это и есть ядро. в ARM966E-S он 5ти ступенчатый и состоит из следующих фаз - Fetch,Decode,Execute,Memory Writeback. Он неможет не изменятся не выключатся. Вы наверное путаете конвейер с так называемым "Pre-Fetch Que and Branch Cache" это ускоритель памяти и это разные вещи.
|
|
|
|
|
Jun 19 2007, 07:21
|
Знающий
   
Группа: Свой
Сообщений: 995
Регистрация: 3-06-05
Пользователь №: 5 713

|
Цитата(AlexandrY @ Jun 18 2007, 23:41)  По моему из контекта обсуждения достаточно ясно, что речь шла о конвеере команд считанных из FLASH, а не о ядерном. Конвеер самого ARM-а мало кому интересен, ибо как правильно заметили он не регулируем. Но вы упустили нюанс, что за ядром стоит реализация шины памяти в исполнении ST о которой вы ничего не знаете, и соответственно ничего теоретически предположить о ее быстродействии не можете. Не забывайте также об имеющемся арбитре шин TСM и AHB. Даже шина TCM как не покажется странным не обеспечивает доступ к памяти за такт. Так что верить можно только натурным испытаниям. Не хочется плодить новую тему, поэтому спрошу снова здесь. Я пользуюсь библиотеками от IAR-WB 4.40 для STR912. Дополнять, а тем более переписывать их нет никакой возможности. Появилась жизненная необходимость назначить несколько (внутренних - 1, внешних - 3) прерываний вложенными. Как это сделать в рамках того инструментария, который имеется в IDE? Прежде всего имеется ввиду библиотека 91x_it.c с болванками под обработчики прерывания. Примеров на STR91x по вложенным прерываниям я пока не нашел.
|
|
|
|
|
Jun 19 2007, 08:57
|
Знающий
   
Группа: Validating
Сообщений: 838
Регистрация: 31-01-05
Пользователь №: 2 317

|
Цитата Конвеер самого ARM-а мало кому интересен После чего возникают вопросы Цитата восемь операторов на ассемблере за 1.6мкс?!! , ядро самое важно, так как неправельно написанный код может снизить производительность в 5 раз ! если програмиимть на асме, и 2-3 раза если на высоком уровне (как ни как но компилятор всеравно пытается под конвеер подстроится). А если приэтом еще неучитывать особенностей шин и их арбитров так вобще тормоз будет. Так что я вашим натурным испытания никогда не поверю Цитата Даже шина TCM как не покажется странным не обеспечивает доступ к памяти за такт. В мануале все хорошо расписано как работают шины. Вопрос в следующем что вы подрозумеваете под словом ТАКТ ?
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|