Функції інтерфейсу
Декодування адреси;
Мультиплексування інформаційного каналу (даних);
Додавання станів очікування;
Конвеєрна обробка для підвищення ефективності;
Управління конвеєром;
Endian Conversion;
Динамічне вирівнювання шини адреси;
Арбітраж для Мультімайстер;
Burst Management;
Розводка сигналів тактування;
Контролер переривань;
Розподіл скидів.
Поведінка цих функцій в певній системі Qsys залежить від схеми компонентів в системі і настройки, зроблених в графічному інтерфейсі користувача Qsys (GUI).
Декодування адреси
Виробляє сигнал chipselect. Рисунок 2.2 показує блок-схему логіки дешифрування адреси для одного майстра і двох підлеглих портів. Окрема логіка дешифрування адреси згенерована для кожного головного порту в системі.
Рис. 2.2 Блок-схема логіки дешифрування адреси для одного майстра і двох підлеглих портів.
У GUI Qsys, конфігуровані користувачем аспекти логіки дешифрування адреси контролюються в базових установках в списку активних компонентів в таблиці змісту, як показано на рисунку 2.3.
Рис. 2.3 Вигляд графічного інтерфейсу Qsys
Мультиплексування інформаційного каналу
Об'єднує сигнали readdata від безлічі підлеглих портів. На рисунку 2.4 показана блок-схема логіки мультиплексування інформаційного каналу для одного майстра і двох підлеглих портів. Qsys генерує окрему логіку мультиплексування інформаційного каналу для кожного головного порту в системі.
Мультиплексування інформаційного каналу не потрібно в напрямку запису даних. Сигнали writedata розподілені однаково всім підлеглим портам, і кожен підлеглий порт ігнорує writedata за винятком того, коли логіка дешифрування адреси вибирає той порт. У GUI Qsys, генерація логіки мультиплексування інформаційного каналу визначається з використанням панелі зв'язків на сторінці змісту системи, як показано на рисунку 2.5.
Рис. 2.4 Блок-схема логіки мультиплексування інформаційного каналу
Рис. 2.5 Панель зв'язків на сторінці змісту системи
Вставка циклів очікування
На рисунку 2.6 показана блок-схема логіки вставки стану очікування між одним майстром і одним підлеглим.
Рис. 2.6. Блок-схема логіки вставки стану очікування
System interconnect fabric може змусити головний порт чекати з кількох причин на додаток до потреб стану очікування підлеглого порту. Наприклад, арбітражна логіка в мультімастерной системі може змусити головний порт чекати, поки не буде надано доступ до підлеглого порту. SOPC Builder генерує логіку циклів очікування, грунтуючись на властивостях всіх підлеглих портів.
Конвеєрна обробка
Qsys може автоматично конвертувати system interconnect fabric, вставляючи регістри між усіма парами майстер-підлеглий зі специфічною тактовкою. Можна вручну конвеєризувати зв'язок між певними парами майстер-підлеглий, вставляючи компонент Avalon-MM Pipeline Bridge.
Автоматична конвеєризація, найбільш ймовірно, поліпшить роботу у випадку багатьох майстер-портів, які поділяють загальний підлеглий порт. Для господарів N, які отримують доступ до підлеглого порту, збільшений час очікування перебуває в межах (log2N + 1).
Конвеєрне управління або управління конвеєром
Інтерфейс Avalon-MM підтримує конвеєризацію передач читання. Конвеєризований порт Avalon-MM може виконувати операції читання послідовно, не чекаючи завершення попередніх.
Qsys генерує system interconnect fabric з конвеєрною логікою управління, щоб використовувати в своїх інтересах конвейеризацию компонентів скрізь, де можливо, грунтуючись на конвеєрних властивостях кожної пари майстер-підлеглий в системі.
Незалежно від конвеєрного часу очікування (конвеєрної латентності) цільового підлеглого порту, Qsys гарантує, що прочитані дані досягають кожного головного порту в порядку запиту. Оскільки головні і підлеглі порти часто вже не співпадають за конвеєрним часом очікування, system interconnect fabric часто містить логіку, щоб прибрати відмінності. Можливі випадки перераховані в таблиці 2.1.
Qsys генерує логіку для конвеєра, грунтуючись на властивостях майстрів і підлеглих портів. Формуючи систему в SOPC Builder, немає ніяких параметрів настроювання GUI, які безпосередньо керують конвеєрної логікою управління в system interconnect fabric.
Таблиця 2.1 Можливі випадки за конвеєрним часом очікування
Майстер порт |
Підлеглий порт |
Логіка конвеєрного управління |
немає конв. |
немає конв. |
Не додає логіки |
немає конв. |
конв. з фікс. або змінною латентністю |
System interconnect fabric змушує головний порт чекати. Ця пара майстер-підлеглий не отримує ніяких вигод конвеєрної обробки, тому що головний порт не конвеєризований і тому чекає завершення кожної операції перед початком нової. Однак, у той час як головний порт чекає, підлеглий порт може прийняти операції від іншого головного порту. |
конв. |
немає конв. |
System interconnect fabric виконує операції, як ніби ніякий порт не конвеєризований, змушуючи головний порт чекати підлеглих даних. |
конв. |
конв. з фікс. латентністю |
System interconnect fabric координує головний порт, щоб захопити дані в правильному тактовому циклі, коли дані дійсні на підпорядкованому порті. Цей випадок дозволяє цій парі досягти максимальної пропускної здатності. |
конв. |
конв. із змінною латентністю |
Це найпростіший випадок, в якому підлеглий порт стверджує сигнал, коли його дані дійсні, і головний порт захоплює дані. Цей випадок дозволяє цій парі досягти максимальної пропускної здатності. |
Управління пакетами
System interconnect fabric забезпечує логіку управління пакетами, щоб пристосувати можливості пакетів кожного порту в системі, включаючи порти, які не підтримують передачі пакетів. Логіка управління пакетами - кінцевий автомат, який транслює послідовні адреси і сигнали управління між підпорядкованою стороною і головною стороною.
Максимальна довжина пакета для кожного порту визначена відповідно до проекту і незалежна від інших портів в системі. Якщо головний порт ініціалізує пакет на 16 передач до підлеглого порту з максимальною довжиною пакету 8, логіка управління пакетами ініціалізує два пакети довжиною 8 до підлеглого порту. Якщо головний порт ініціалізує пакет 16 передач до підлеглого порту, який не підтримує пакети, логіка управління пакетами ініціалізує 16 окремих передач до підлеглого порту.
Перетин областей тактування (Clock Domain Crossing)
System interconnect fabric підтримує протокол Avalon-MM з кожним портом незалежно, і тому кожен порт Avalon-MM повинен тільки знати про його власні області тактування. Логіка CDC в system interconnect fabric забезпечує наступні вигоди, які спрощують зусилля з проектування систем:
Дозволяють складовим інтерфейсам працювати на частоті відмінній від тієї з якою працює логіка системи;
Усуває потребу проектувати апаратні засоби CDC вручну;
Кожен порт Avalon-MM працює тільки в одній області тактування, що зменшує складність компонентів;
Дозволяє головним портам отримати доступ до будь-якого підлеглого порту без обізнаності про його тактування;
Дозволяєте зосереджувати зусилля на оптимізації роботи тільки компонентів, які вимагають великої тактової частоти.
Логіка CDC складається з двох кінцевих автоматів (FSM), один в кожній області імпульсів, які використовують простий протокол процедури встановлення зв'язку, щоб розмножити сигнали управління (запит читання, запит запису) поперек кордону імпульсів. Рисунок 2.7 показує блок-схему області тактових імпульсів, що перетинає логіку між одним господарем і одним підлеглим портом.
Рис. 2.7 Блок-схема області тактових імпульсів
Розподіл сигналів скидання
System interconnect fabric генерує і розподіляє імпульси скидання в system module. Тривалість сигналу скидання - принаймні один тактовий період. System interconnect fabric стверджує скидання всієї системи в наступних випадках:
Глобальний вхід скидання до system module встановлений;
Підлеглий порт встановлює сигнал resetrequest;
FPGA переконфигурирует.
Всі повинні підтримувати цей сигнал, він асинхронний.