У багатьох додатках процесор, виконання інструкцій якого відомий тимчасовим зв’язком із очікуваними вхідними стимулами, може обробляти завдання, які потребувалимуть набагато швидшого процесора, якби зв'язок був невідомим. Наприклад, у проекті, в якому я використовував PSOC для створення відео, я використовував код для виведення одного байта відеоданих на кожні 16 годин процесора. Оскільки тестування того, чи готовий пристрій SPI і розгалуження, якщо не, IIRC забирає 13 годин, а завантаження і зберігання для виведення даних займе 11, не було можливості перевірити пристрій на готовність між байтами; натомість я просто домовився, щоб процесор виконував точно 16 циклів коду для кожного байта після першого (я вважаю, що я використовував реальне індексоване навантаження, фіксований навантаження та індекс). Перше записування SPI кожного рядка відбулося до початку відео, і для кожного наступного запису існувало вікно з 16 циклом, де запис може відбуватися без перекриття або заниження буфера. Цикл розгалуження породжував вікно невизначеності 13 циклу, але передбачуване виконання 16 циклів означало, що невизначеність для всіх наступних байтів відповідатиме тому самому вікні 13 циклу (що, в свою чергу, вписується у вікно 16 циклу, коли запис може бути прийнятним трапляються).
Для старих процесорів інформація про терміни інструкцій була чіткою, доступною та однозначною. Для нових ARM-файлів інформація про терміни здається набагато невиразнішою. Я розумію, що коли код виконується з флеш-пам’яті, поведінка кешування може значно ускладнити передбачення, тому я би сподівався, що будь-який перерахований цикл код повинен виконуватися з ОЗУ. Навіть при виконанні коду з оперативної пам’яті технічні характеристики здаються трохи розпливчастими. Чи використання коду, що рахується, все ще є хорошою ідеєю? Якщо так, то які найкращі методи, щоб змусити його надійно працювати? Якою мірою можна з упевненістю припустити, що постачальник чіпів не збирається мовчки ковзати в «нову вдосконалену» мікросхему, яка голить цикл виконання певних інструкцій у певних випадках?
Якщо припустити, що наступний цикл починається на межі слова, як би визначати на основі специфікацій точно, скільки часу це займе (припустимо, Cortex-M3 з пам'яттю стану нуля очікування; нічого іншого в системі не має значення для цього прикладу).
myloop: mov r0, r0; Короткі прості інструкції, щоб дозволити попереднє встановлення більшої кількості інструкцій mov r0, r0; Короткі прості інструкції, щоб дозволити попереднє встановлення більшої кількості інструкцій mov r0, r0; Короткі прості інструкції, щоб дозволити попереднє встановлення більшої кількості інструкцій mov r0, r0; Короткі прості інструкції, щоб дозволити попереднє встановлення більшої кількості інструкцій mov r0, r0; Короткі прості інструкції, щоб дозволити попереднє встановлення більшої кількості інструкцій mov r0, r0; Короткі прості інструкції, щоб дозволити попереднє встановлення більшої кількості інструкцій додає r2, r1, # 0x12000000; 2-слівна інструкція ; Повторіть наступне, можливо, з різними операндами ; Буде тримати додавання значень, поки не відбудеться перенос itcc addcc r2, r2, # 0x12000000; 2-слівна інструкція плюс додаткове "слово" для itcc itcc addcc r2, r2, # 0x12000000; 2-слівна інструкція плюс додаткове "слово" для itcc itcc addcc r2, r2, # 0x12000000; 2-слівна інструкція плюс додаткове "слово" для itcc itcc addcc r2, r2, # 0x12000000; 2-слівна інструкція плюс додаткове "слово" для itcc ; ... тощо, з більш умовними двословними вказівками під r8, r8, # 1 bpl myloop
Під час виконання перших шести вказівок ядро встигло б отримати шість слів, з яких три буде виконано, тож може бути до трьох попередньо встановлених. Наступна інструкція - це всі три слова, тому ядро не може отримати інструкції так швидко, як вони виконуються. Я б очікував, що деякі інструкції "це" будуть мати цикл, але я не знаю, як передбачити, які з них.
Було б добре, якби ARM міг задати певні умови, за яких час виконання інструкцій "it" було б детермінованим (наприклад, якщо немає станів очікування або суперечки шини коду, а попередні дві інструкції - це 16-бітні інструкції реєстрації тощо). але я не бачив жодної такої специфікації.
Зразок застосування
Припустимо, хтось намагається спроектувати дочірню плату для Atari 2600 для створення компонентного відеовиходу при 480P. 2600 має піксельну тактову частоту 3,579 МГц та тактовий процесор 1,19 МГц (точковий такт / 3). Для компонентного відео 480P кожен рядок повинен виводитися двічі, маючи на увазі точковий вихід 7,158 МГц. Оскільки відео чіп Atari (TIA) виводить один із 128 кольорів, використовуючи 3-бітний сигнал луми плюс фазовий сигнал з роздільною здатністю приблизно 18ns, то було б важко точно визначити колір, просто подивившись на результати. Кращим підходом було б перехоплення записів до кольорових регістрів, дотримання записаних значень та подання кожного регістра в значення яскравості TIA, що відповідають номеру регістра.
Все це можна зробити за допомогою FPGA, але деякі досить швидкі ARM-пристрої можуть бути набагато дешевшими, ніж FPGA з достатньою оперативною пам’яттю, щоб обробляти необхідну буферизацію (так, я знаю, що для обсягів така річ може бути вироблена, вартість не буде ' t реальний фактор). Однак вимагати від ARM для перегляду вхідного тактового сигналу значно підвищить необхідну швидкість процесора. Передбачувані підрахунки циклу можуть зробити речі більш чистими.
Порівняно простий підхід до проектування полягав би в тому, щоб CPLD спостерігав за процесором і TIA і генерував 13-бітний сигнал RGB + синхронізації, а потім ARM DMA захоплював 16-бітні значення з одного порту і записував їх на інший з належною хронологією. Хоча було б цікавим дизайнерським завданням, щоб побачити, чи може дешевий ARM зробити все. DMA може бути корисним аспектом підходу «все в одному», якщо можна було б передбачити його вплив на кількість циклів процесора (особливо, якщо цикли DMA можуть відбуватися в циклах, коли шина пам'яті інакше простоює), але в якийсь момент процесу ARM повинен виконувати функції пошуку таблиці та перегляду шини. Зауважте, що на відміну від багатьох архітектур відео, де регістри кольорів записуються протягом проміжків інтервалу, Atari 2600 часто записує до кольорових регістрів під час відображеної частини кадру,
Можливо, найкращим підходом було б використання декількох чіпів дискретної логіки для ідентифікації кольорових записів та примушування нижчих бітів регістрів кольорів до відповідних значень, а потім використовувати два канали DMA для вибірки вхідних даних шини процесора та вихідних даних TIA, і третій канал DMA для генерації вихідних даних. Тоді процесор може вільно обробляти всі дані з обох джерел для кожної лінії сканування, виконувати необхідний переклад та зберігати їх для виведення. Єдиним аспектом обов'язків адаптера, який повинен був відбуватися в режимі "реального часу", було б перегляд даних, записаних на COLUxx, і це можна подбати про використання двох загальних логічних мікросхем.
