VHDL: Назви та інтерпретація архітектури

Примітка. Я використовую ISE Xilinx і маю плату FPGA для роботи (з вимикачами та світлами тощо), і я зламав разом декілька простих проектів. У той же час я читаю кілька навчальних посібників, щоб створити фундамент для того, що я роблю.

Я бачив різні сутності та їх архітектури, згадані в довідкових матеріалах, які я переглядав, але найменування часто бувають заплутаними. Часто замість "архітектури rtl з .." або "архітектурної структури ..." я побачу "архітектуру foo of ..." або навіть " арку архітектури ..."

Я усвідомлюю (запізніло), що назва архітектури настільки ж довільне, як іменування сутності, хоча існують посібники зі стилів, які пропонують більш послідовні конвенції іменування, щоб уникнути цієї проблеми. Це призводить мене до кількох питань:

• Дивлячись на сутність, як можна визначити фактичну архітектурну модель, яка використовується без натяків на назву архітектури? RTL, поведінкові, структурні ... вони здаються досить схожими на очі мого учня (якщо припустити, що приклади, які я бачив, насправді були названі правильно). Тут може бути корисним простий, але очевидний приклад (або вказівник на один).

• Якщо вказати кілька архітектур для однієї сутності (наскільки я розумію, це можливо), ви просто даєте архітекторам різні імена в одному файлі або ...?

• Чи обмежуються назви архітектури певним об'єктом (тобто чи є проблема з "просторами імен", використовуючи одне і те ж ім'я архітектури для кількох об'єктів)?

Редагувати: та ще одне:

• Здається, є різниця між RTL та поведінковою, але, як було сказано вище, я насправді не бачу цього в прикладах, які я бачив (часто я бачу лише одну архітектуру, яку визначають). Чи одна архітектура є більш поширеною, ніж інші?

Що я шукав - це всебічний, але простий багатокомпонентний проект (мало компонентів), написаний з використанням найкращих практик (належне іменування, не все забито в одному файлі тощо), але я ще його не знайшов. Я вважаю, що правильно складені зразкові проекти є дуже корисними для висвітлення основних принципів та найкращих практик. Якщо ви знаєте такий приклад проекту, я також буду вдячний за вказівку на це. (Якщо нічого іншого, можливо, колись я це зрозумію, я можу поділитися одним із своїх власних ...)

Дивлячись на сутність, як можна визначити фактичну архітектурну модель, яка використовується без натяків на назву архітектури?

Ви не можете - коли це створено оригінально або налаштовано архітектуру, можна вказати архітектуру (якщо на вибір можна вибрати більше) або буде вибрано за замовчуванням.

Якщо вказати кілька архітектур для однієї сутності (наскільки я розумію, це можливо), ви просто даєте архітекторам різні імена в одному файлі або ...?

Ви даєте їм різні імена. Це не повинно бути в одному файлі (адже VHDL піклується набагато менше, ніж ви можете подумати про те, що в тому файлі)

Чи обмежуються назви архітектури певним об'єктом (тобто чи є проблема з "просторами імен", використовуючи одне і те ж ім'я архітектури для кількох об'єктів)?

Вони "приєднані" до сутності, тому можуть бути використані повторно.

Я часто використовую a1як свою архітектуру все, що можна синтезувати як

• rtl Має на увазі нижчий рівень (для багатьох читачів), ніж я пишу.
• behavioural часто має на увазі несинтезується (для деяких читачів)
• synth використовується синтезатором для його моделі (інакше я б використав це)

a1 досі був безконфліктним і не викликає плутанини;)

Якщо у мене насправді є більше однієї архітектури, я схильний називати їх багатослівно (наприклад, hard_multipliersі lut_multipliersдля фільтра, який створює - чи ні - блоки MUL18).

Дуже часто у вас є лише одна архітектура, тому це не має значення. Гарні назви юридичних осіб набагато важливіші.

Здається, є різниця між RTL та поведінковою, але, як було сказано вище, я насправді не бачу цього в прикладах, які я бачив (часто я бачу лише одну архітектуру, яку визначають). Чи одна архітектура є більш поширеною, ніж інші?

Це історично - ви раніше не змогли синтезувати "поведінковий" код (який у один момент включав такі речі, як додавання!) - тому ви створили RTL-версію, яка інстанціювала добавники тощо. (Це я так розумію - я писав поведінковий (і все ще синтезуючий) код з мого початку VHDLing приблизно в 1999 році!)

Ось типи архітектури:

Поведінкові:

Загальні примітки:

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

Особливості Xilinx

• Як правило, основні моделі генераторів - це попередні синтези .vhd файлів

Структурна:

Загальне визначення

• Тільки інстанціює компоненти та з'єднує їх (ієрархічно).
• Повільніше імітувати, ніж поведінкове.
• Немає реального визначення поведінки сигналу на верхньому рівні.
• Тільки синтезується код.

Xilinx xpecific примітки

• Основні моделі генераторів не враховують терміни.
• Як правило, основні моделі генераторів створюють мережі після синтезу

Сказане в основному є традиційними основними двома тваринами архітектури. Дуже часто використовується "змішане" визначення, яке містить властивості обох.

RTL:

RTL, що насправді ставиться на FPGA наприкінці дня. Таким чином, це синтезований код, який визначає поведінку системи і складається з ієрархії коду:
Нижні шари будуть синтезованими поведінковими, де визначається ніткова зернистість поведінки сигналу, а верхні рівні - структурними, де компоненти поведінки пов'язані між собою, щоб створити велику "блок-схему" верхнього рівня, якщо ви хочете.

Про багато архітектури:

Архітектури можуть бути всі в одному файлі або в декількох файлах. Важливим є лише те, що об'єкт спочатку складається, а також вказана архітектура, яка буде використовуватися.

Ця книга дуже зручна і досить добре деталізує подібні речі.

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

Перш за все, проекти архітектури реального світу не можуть бути так категорично класифіковані. Навіщо обмежувати себе? Ви можете створити інстанцію інших об'єктів і з'єднати їх "структурно", але додати процес або паралельне призначення тут і там, щоб додати якусь "rtl" логіку, і, можливо, використовувати деякі "поведінкові" шаблони кодування, щоб синтезатор виявив частину деталі, які вас не цікавлять (як, наприклад, додавання без конкретного інстанції додавача з параметрами області / конвеєрного / продуктивного виконання), все в тій же архітектурі.

Що ще важливіше, ви повинні зрозуміти, що синтезується в сучасних технологіях asic / fpga, а що ні, і це незалежно від моделі архітектури.

Суб'єкт може бути реалізований декількома способами, навіть допускаючи дещо різну поведінку, тому у вас може бути кілька архітектур для одного об'єкта. Крім того, у вас може бути архітектура тільки для моделювання (як правило, не синтезується), яка може імітувати швидше, ніж "реальна" версія, яка може стати в нагоді при тестуванні великих конструкцій в цілому. Ви б дали цим іменам архітектури, які допоможуть вам запам’ятати, чим вони відрізняються від інших, а просто bhv / str / rtl зазвичай недостатньо чи точні, враховуючи гібридну природу реального дизайну.

Що стосується ваших конкретних питань, декларація архітектури прив’язана до імені сутності, тому немає проблем із простором імен з однойменними архітектурами для різних об'єктів. Просто використовуйте різні назви архітектур для одного об'єкта.

Архітектури можуть розміщуватися в різних файлах, потрібно лише переконатися, що декларація сутності скомпільована спочатку.

Ви можете вибрати, яку архітектуру використовувати для інстанціювання об'єкта або використання операторів конфігурації. Якщо цього немає, за замовчуванням «зазвичай» є остання архітектура, яку бачив компілятор для даної декларації об'єкта.