Transport triggered architecture

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до навігації Перейти до пошуку
Ця стаття є сирим перекладом з іншої мови. Можливо, вона створена за допомогою машинного перекладу або перекладачем, який недостатньо володіє обома мовами. Будь ласка, допоможіть поліпшити переклад. (січень 2018)

Transport triggered architecture (TTA) — варіант архітектури мікропроцесорів, в якій програми безпосередньо керують внутрішніми з'єднаннями (шинами) між блоками процесора (наприклад, АЛП, регістровий файл). Обчислення є побічним ефектом передачі даних між блоками: запис даних на вхідний порт (triggering port) функціонального блоку приводить до початку їх обробки цим блоком. Це подібно тому, що відбувається у систолічному масиві. Завдяки модульній структурі, TTA-архітектура ідеально підходить для проектування проблемно-орієнтованих процесорів (ASIP), при цьому TTA-процесори виходять більш універсальними і дешевшими ніж апаратні прискорювачі для фіксованих функцій.

Зазвичай TTA-процесор має кілька транспортних шин і багато функціональних пристроїв (ФП), підключених до цих шин. Велика кількість ФП дозволяє досягти паралелізму на рівні команд. Паралелізм статично визначається програмістом. У цьому відношенні, а також через велику довжину машинної інструкції, TTA-архітектури подібні до Very Long Instruction Word (VLIW) архітектури. Інструкція для TTA складається з декількох слотів, по слоту на кожну шину. Кожен слот визначає, як дані будуть передаватися по даній шині. Настільки повний контроль дозволяє виробляти деякі оптимізації, неможливі для класичних архітектур. Наприклад, можливе явне пересилання даних між різними ФП без збереження проміжних даних в регістровому файлі.

Процесори з архітектурою класу TTA були доступні у продажу.[які?][джерело?]

Структура[ред. | ред. код]

Процесори з архітектурою класу TTA складаються з декількох незалежних функціональних пристроїв і реєстрових файлів, які з'єднані транспортними шинами і сокетами.

Функціональний пристрій[ред. | ред. код]

Кожний функціональний пристрій виконує одну або більше операцій. Можлива реалізація як найпростіших арифметичних операцій (цілочисельне додавання) так і складних довільних операцій, специфічних для цільової програми. Операнди передаються в ФП через порти ФП. Результат операції передається через вихідний порт ФП.

У кожному ФП може бути реалізований незалежний конвеєр команд.

Доступ до пам'яті та взаємодія з зовнішніми пристроями обробляється спеціальними ФП. ФП для доступу до пам'яті часто називають load/store unit.

Керувальний пристрій[ред. | ред. код]

Керувальний пристрій контролює процес виконання програм. У нього є доступ до пам'яті інструкцій для отримання наступних машинних команд. Також реалізує команди переходу (jump). Зазвичай керувальний пристрій конвеєризовано і виділені стадії: завантаження, декодування, виконання інструкцій.

Регістрові файли[ред. | ред. код]

Регістрові файли (РФ) містять масиви регістрів загального призначення, в яких зберігаються змінні програми. Подібно ФП, РФ мають вхідні і вихідні порти. Кількість вхідних і вихідних портів (кількість одночасно читаних РОН з масиву) може бути різним для різних РФ.

Програмування[ред. | ред. код]

У більш традиційних архітектурах процесорів, процесор зазвичай програмується шляхом визначення виконаних операцій і їх операндів. Наприклад, інструкція додавання в архітектурі RISC може виглядати наступним чином. 

add r3, r1, r2

У цьому прикладі операція додає значення загального призначення регістрів r1 і r2 і зберігає результат в регістрі r3. Виконання команди в процесорі, ймовірно, призводить до перекладу інструкції на керуючі сигнали, які управляють мережевими з'єднаннями і взаємозв'язком функціональних блоків. Мережа з'єднання використовується для передачі поточних значень регістрів r1 і r2 до функції блоку, який здатен виконувати операції додавання, які часто називають ALU, як в арифметико-логічному Unit. Нарешті, сигнал управління вибирає і запускає операцію складання в АЛП, з яких результат передається назад в регістр r3.

Програми TTA не визначають операції, але транспортування даних потребує запису і зчитування значення операндів. Сама операція ініціюється записом даних до пускового операнда операції. Таким чином, операція виконується, як побічний ефект, який ініціює передачу даних. Таким чином, виконання операції додавання в TTA вимагає трьох транспортних даних визначень, так званих ходів. Рух визначає кінцеві точки для передачі даних, що відбуваються в транспортному автобусі. Наприклад, рух можна констатувати, якщо перенесення даних з функції блоку F в порт 1, щоб зареєструвати файл R, індексний регістр 2, матиме місце в автобусі B1. У разі, якщо є кілька шин в цільовому процесорі, кожна шина можуть бути використані паралельно в тому ж такті. Операція складання може виконуватися в процесорі TTA так 

r1 -> ALU.operand1
r2 -> ALU.add.trigger
ALU.result -> r3

Другий крок — операція запису на другий операнд функції блоку називається ALU, запускає операцію складання. Це робить результат складання наявного в результаті вихідного порту після виконання «додавання».

Порти, пов'язані з АЛП можуть виступати як акумулятор, що дозволяє створювати макро-інструкції, абстрагуватися від базового активу TTA: 

lda r1    ; "load ALU": move value to ALU operand 1
add r2    ; add: move value to add trigger
sta r3    ; "store ALU": move value from ALU result

Прихований стан[ред. | ред. код]

Провідна філософія TTA полягає в складності переходу від апаратних засобів до програмного забезпечення. У зв'язку з цим, деякі додаткові небезпеки вводяться для програміста. Один з них є відкладений стан, програміст бачить операції прихованого стану функціональних блоків. Програміст повністю відповідає за терміни. Програміст повинен планувати інструкції таким чином, що результат не зчитувався дуже рано і не занадто пізно. В TTA немає функції виявлення апаратних засобів, щоб заблокувати процесор в разі, коли результат зчитується занадто рано. Розглянемо, наприклад, архітектуру, яка має операцію додати з затримкою 1, і операції MUL з затримкою 3. При спрацьовуванні операції додати, можна прочитати результат в наступній інструкції (наступного тактового циклу), але в разі мул, доводиться чекати, поки дві команди до того, як результат може бути прочитаний. Результат буде готовий до 3-й інструкцію після інструкції запуску.

Результат повинен бути прочитаний досить рано, щоб переконатися, що такий результат операції НЕ переписують ще непрочитані привести до вихідного порту.

Через велику кількість видимого контексту процесора, який він фактично включає в себе, програміст повинен зареєструвати вміст файлу, а також функціональний блок вмісту регістрів трубопроводу і / або функціонального блоку, порти введення і виведення, зберігає необхідний для зовнішньої підтримки переривань. Тому переривання зазвичай не підтримуються процесорами TTA, але їх задача делегується зовнішнім обладнанням (наприклад, процесором вводу / виводу) або їх потреба уникнути, використовуючи альтернативну синхронізацію / механізм зв'язку, таких як опитування.

Затримки операцій[ред. | ред. код]

Один з основних принципів ТТА — спростити апаратне забезпечення, ускладнивши програмне.

Переваги в порівнянні з VLIW архітектурі[ред. | ред. код]

TTAs можна розглядати як «DATAPATH» VLIW архітектур. У той час як VLIW програмується за допомогою операцій, TTA розбиває виконання операції на кілька операцій переміщення. Модель низького програмування високого рівня надає кілька переваг у порівнянні зі стандартною VLIW. Наприклад, архітектура TTA може забезпечити простіший паралелізм, ніж реєстрові файли з VLIW. Як програміст контролює терміни операндів і дані результату, складність (кількість вхідних і вихідних портів) файлу регістра (РФ) не повинні бути розширені відповідно до гіршому випадку питання / завершення сценарій кілька паралельних інструкцій.

Унікальна оптимізація програмного забезпечення дозволило транспортному програмуванню називатися програмним забезпеченням шунтування. У разі програмного забезпечення обходу, програміст обходить файл регістра зворотнього запису шляхом переміщення даних безпосередньо до портів операндів наступного функціонального блоку. Коли ця оптимізація застосовується агресивно, початковий крок, який переносить результат в файл регістрів може бути повністю усуненим, таким чином, знижуючи тиск порту регістра на файл і звільняючи регістр загального призначення для інших тимчасових змінних. Знижений тиск регістра, крім того, що спрощує необхідну складність РФ апаратних засобів, може призвести до значної економії енергії процесора, важлива перевага, особливо в мобільних вбудованих системах.

Реалізації[ред. | ред. код]

На даний час доступний мікроконтролер тільки в комерційних цілях, побудований на Transport Triggered Architecture від Dallas Semiconductor[en]. Тим не менш, це пропонує або OISC або URISC, але крім однієї гнучкою MOVE інструкції, яка може функціювати як різні віртуальні інструкції, переміщаючи значення безпосередньо до лічильника команд.

Примітки[ред. | ред. код]

  1. ↑ «MAXQ Family User's Guide»[недоступне посилання]. Розділ «1.1 Набір команд» говорить «Реєстро-базова transport-triggered architecture враховує всі інструкції, які будуть закодовані, як просто операції переміщення. Всі інструкції або зменшують або безпосередньо записують значення в адресований регістр, або в комірку пам'яті, або переміщують дані між регістрами та / або між осередками пам'яті.»
  2. ↑ Introduction to the MAXQ Architecture [Архівовано 30 вересня 2009 у Wayback Machine.] — Includes transfer map diagram
  3. ↑ TTA Codesign Environment, an open source (MIT licensed) toolset for design of application specific TTA processors. Архів оригіналу за 21 січня 2016. Процитовано 3 січня 2016.
  4. ↑ Article [Архівовано 2 липня 2010 у Wayback Machine.] about TTAs, explaining how the TTA-based Codesign Environment project uses LLVM
  5. ↑ Dr. Dobb's article with 32-bit FPGA CPU in Verilog. Архів оригіналу за 23 січня 2010. Процитовано 3 січня 2016.
  6. ↑ Web site with more details on the Dr. Dobb's CPU. Архів оригіналу за 18 лютого 2013. Процитовано 3 січня 2016.

Див. також[ред. | ред. код]

Посилання[ред. | ред. код]

Отримано з https://uk.wikipedia.org/w/index.php?title=Transport_triggered_architecture&oldid=40425787