Лекція № 4 бозові конструкції моделей на мові vhdl
Сигнали є окремим класом в мові, що відрізняються від класів змінних і констант. Сигнали є абстракцією, яка представляє в моделі vhdl стан провідників в структурі цифрового пристрою і задається парою значень: момент модельного часу / значення сигналу, в даний момент часу. Послідовність значень сигналу в привязці до моментів модельного часу на протязі деякого проміжка часу формує часову діаграму сигнала (waveform).
Зміна сигналу, яка відбувається в певний момент модельного часу, називається подією (event). При виконанні операторів присвоювання значенню сигналу, системою моделювання формується спеціальна структура даних, пара: значення сигналу / момент модельного часу, коли сигнал прйме дане значення. Така пара опису мови vhdl називається транзакцією (transaction).
Ще одним поняттям, пов'язаним з сигналами, яке часто використовується в описі vhdl, є драйвери (driver) - джерело сигналу. Одне джерело сигналу і в реальному цифровому пристрої і в програмі vhdl формує один сигнал. Але сигнали можуть існувати паралельно з іншимим сигналами в модельному часі. Джерело сигналу може визначати не тільки одне значення сигналу у певний момент модельного часу, але й цілу послідовність значень сигналу в різні момент модельного часу, формувати планову часову діаграму сигналу (projected output waveform). Часто в описі vhdl саме цей список тразакцій , пов'язаний з одним джерелом сигналу, називається терміном драйвер.
Оскільки кожне джерело сигналу в реальній схемі формує свій сигнал паралельно в часі з ішимим джерелами, то в моделі пристрою на vhdl джерела сигналів працюють паралельно в модельному часі. Коли декілька джерел сигналів приєднані в схемі до однієї точки, то результуючий сигнал в цій точці буде сформований всіма джерелами.
2. Структура опису об'єкта моделювання
Опис об'єктів моделювання складається з декларативної частни і опису архітектури.
В декларативній частині описуються зв'язки об'єкта із зовнішнім світом, входи і виходи об'єкта, що фактично задає специфікацію інтерфейса об'єкта.
В описі архітектури визначаються функції об'єкта, здійснення ним формування вихідних сигналів на основі вхідних і внутрішнього стану об'єкта. 2.1. Декларативна частина
Повний формат деклараративної частини опису об'єкта моделювання має наступний синтаксис:
Entity entity_mame is [generic (generic_interface_list);] [port (port_interface_list);] [begin {concurrent_assertion_statement | passive_concurrent_procedure_call_statement | passive_process_statement}] {entity_declaration_item} end [entity] [entity_name];
Ім'я об'єкта entity_mame повинно бути унікальним.
Секція generic призначена для опису констант, які визначають параметри об'єкта моделювання, що змінюються.ця секція не є обов'язковую.
В термінах мови vhdl входи і виходи проектованої схеми називаються портами. Це спеціальні програмні об'єкти, які є сигналами (а не змінними). Після ключового слова port в круглих дужках розташований список описів сигналів - port_interface_list. Він має наступний синтаксис:
{identifier, {...}:[] subtype indication[:=expression]}, {...}
Опис кожного сигналу складається з ім'я identifier виду сигналу і типу сигналу subtype_indication.
Вид игналу mode може приймати значення: in вхідний сигнал
Out вихідний сигнал
Inout сигнал, що може бути як вхідним так і вихідним.
Всі типи subtype_indication, які вказуються в описі портів, повинні бути вже відомими.
В декларації об'єктів не передбачено опис типів, тому всі типи, які не встроєні у vhdl повинні бути описані або вище по тексту в цьому ж файлі, або винесені в окремий пакет чи бібліотеку.
В секції port сигналам можуть присвоюватися значення по замовчуванні. Ідентифікатори декількох сигналів, які мають подальший однаковий опис, можуть переаховуватись через кому в одному описі.
Після ключового слова begin вказуються секції паралельно виконувальних дій, які можуть використовуватись для перевірки правильності функціонування об'єкта і для документування процесу функціонування.
Останньою задається секція внутрішніх декларацій {entity_declaration_item} об'єкту. В цій секції може міститися декларація констант, змінних, сигналів і типів, які є внутрішніми для даного об'єкту моделювання - доступні тільки в середині цього об'єкту.
Завершується опис об'єкту ключовим словом end у відповідному форматі end [entity] [entity_name];
Приклад 1.
Entity adder is
Port (a, b, c: in word;
Sum: out word end entity adder;
В цьому прикладі описано об'єкт з ім'ям adder, який має три вхідних сигнали a, b, c типу word і один вихідний сигнал такого ж типу.
Приклад 2. Entity adder1 is port (a: in integer;
B:in integer:=1; -- значення по замовчуванню c: in integer; sum: out word end entity adderl;
В прикладі 2 описаний об'єкт з ім'ям adder1, який має три вхідних сигнали a, b, c типу integer і один вихідний сигнал типу word. Сигналу b по замовчуанні присвоєно значення рівне 1.
2.2. Опис архітектури об'єкта.
В мові vhdl під описом архітектури мається на увазі опис функціонування об'єкта, що описується. Це можна зробити наступними способами.
1. Описати поведінку об'єкта, перетворення інформації і його внутріш ніх станів, формування вихідних сигналів при відповідному поступленні вхідних, задати алгоритмічний опис поведінки обякта, що специфікується. Такий опис називається поведінковим описом і при цьому внутрішня структура не специфікується.
2. Описати структуру об'єкта, як сукупності інших об'єктів, вказуючи їх перелік і звязки між ними. Такий опис називається структурним описом архітектури обєкта. Поведіка об'єкта, перетворення інформації і формування вихідних сигналів при поступленні відповідних вхідних, визначається складом і звєязками об'єктів, що формують дану структуру. Самі складові об'єкти описуються окремо із застосуванням структурного чи поведінкового опису. Таким чином на певно рівні вложень доходимо до визначених компонентів або до алгоритічного - поведінкового способу опису складових об'єктів.
3. Змішаний структурно-поведінковим спосіб опису, який є комбінацією попередніх двох видів.
Приклад 3
Architecture identifier of entity_name is {block_declarative_item}
Begin
{concurrent_statements}
End [architecture] [identifier]
Специфікатор entity_name дозволяє пов'язати декларативну і архітектурну частини опису об'єкта моделювання. Після ключового слова architecture вказується унікальний ідентифікатор identifier даної архітектури.
Після ключового слова йде блок паралельних операторів, які задають в алгоритмічному вигляді функціонування опмсуваної архітектуриоб'єкта. Завершується опис архітектури ключовим словом end , після якого може вказуватися слово architecture і її ідентифікатор identifier.
Об'єкт моделювання може мати декілька різних описів архітектур, але одночасно в моделі може використовуватися тілки одна з них. Вибір конкретного виду архітектурного опису здійснюється з використанням конфігурованої специфікації.
Приклад 4.
Architecture abstract of adder is
Begin
Add_a_b_c:process(a,b,c) is
Begin
Sum<=a+b+c;
End process add_a_b_c
End architecture abstract
Бібліотеки організовано як окремі файли, в яких можуть бути розміщені різні варанти опису архітектури об'єктів. Бібліотеки дозволяють використовувати в різних проектах повторне використання вже розроблених об'єктів.
При описі архітектури, яка включає об'єкти, розміщені в бібліотеках, то безпосередньо перед описом архітектури необхідно вказати імена цих бібіліотек, з наступним синтаксисом:
Library library_name {, ...} Тут library_name - ідентифікатор, ім'я бібліотеки
Приклад 5
Library widget_cells, wasp_lib; architecture cell of filter is begin
Clk_pad: entity wasp_lib.in_pad -- використовується об'єкт in_pad з
-- бібліотеки wasp_lib
Port map...
Accum:entity widget_cells.reg32 port map...
End architecture cell;
Для того щоб в тексті модуля кожен раз не вказувати ім'я бібіліотеки, в якій міститься опис об'єкту, що часто використовуєтся, використовується
Умовне посилання з таким синтаксисом:
Use library_name.(identifier|all)
Де identifier - ім'я об'єкту з бібіліотеки library_name.
Тоді попередній приклад можна записати в наступному вигляді.
Приклад 6.
Library widget_cells, wasp_lib; use widget_cells.reg32; architecture cell of filter is begin
Clk_pad: entity wasp_lib.in_pad -- використовується об'єкт
-- in_pad з бібліотеки wasp_lib
Port map...
Accum:entity reg32 -- використовується об'єкт
-- reg32 з бібліотеки widget_cells
Port map...
End architecture cell;
Якщо в описі вказано ключове слово , то всі об'єкти з вказаної бібіліотеки можуть бути використані в тілі опису об'єкта, яке використовує цю бібліотеку без вказування імені бібліотеки (всі об'єкти бібліотеки стають безпосередньо видимими).
Пакети дозволяє згрупувати деякі описи в єдину сукупність - пакет, який в подальшому може багатократно використовуватись в проектах. Механізм пакетів дозволяє об'єднання опису типів, констант, процедур, функцій, компонентів. Опис пакету складається з декларативної частини і тіла пакету.
Декларативна частина має синтаксис:
Package name is
{package_declarative_item}
End [package] [name];
Опис тіла пакету має наступний синтаксис:
Package body name is
{package_bodt_declarative_item}
End [package body] [name];
Звернення до об'єкту, розміщеному в пакеті, має синтаксис:
Library_name.packet_name.object_name, де library_name - ім'я процедури, packet_name - ім'я пакету, object_name - ім'я об'єкту.
Для констант в декларативній частині пакету може використовуватись
Скорочений запис:
Constant name:type_name;
Константі, описаній таким чином, в тілі пакету необхідно присвоїти значення.
Наприклад, якщо в декларативній частині пакету є опис:
Constant max_size:positive; то в тілі пакету необхідно виконати повний опис:
Constant max_size:positive:=4 0;
Опис тіла пакету може містити опис додаткових типів, підтипів, констант і підпрограм. Всі описи, здійснені в декларативній частині пакету, автоматично видимі в його тілі.
Опис сигналів в тілі пакету включатися не можуть. Для того щоб кожен раз при використанні об'єктів, розміщених в пакетах, не вказувати їх повне 'я використовуються умовні посилання (як і для бібіліотек).
Use library_name.packet_name.(identifier |character_literal| operator_symbol|all);