Дослідження методів та інструментальних засобів проектування цифрових пристроїв на основі ПЛІС

1. Огляд елементної бази, що застосовується для побудови логічних керуючих автоматів з паралельною архітектурою

1.1 Класифікація

Для побудови логічних керуючих автоматів з паралельною архітектурою використовують пристрої з регулярною архітектурою, які представляють собою набір стандартних елементів та вузлів, що інтегровані на одному кристалі. Існує багато різновидів таких пристроїв, але всі вони об’єднуються однією назвою – програмовані логічні інтегральні схеми.

Настроювання ПЛІС на виконання заданих функцій здійснюються користувачем шляхом вільного компонування цих елементів і вузлів програмним способом. Завдяки зазначеним особливостям ПЛІС в останні роки успішно завойовують ринок і в ряді предметних областей становлять гідну конкуренцію мікропроцесорам і мікроконтролерам. Залежно від використовуваної архітектури ПЛІС можуть бути класифіковані таким чином (рис. 1).

Структури ПЛІС мають високий рівень регулярності: основу кристала ПЛІС становить матриця однотипних функціональних вузлів, на базі яких користувач може створювати цілі системи керування складними технологічними об'єктами. Завдяки цьому ПЛІС характеризуються високою швидкодією і надійністю, а також широкими можливостями в частині резервування і діагностики.

Найбільш ефективними областями застосування ПЛІС є:

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

2. побудова надшвидкодіючих керуючих пристроїв;

3. реалізація автономних систем керування критичного застосування, до яких пред'являються жорсткі вимоги в частині забезпечення надійності, безпеки, електромагнітної сумісності й т.ін.

Рис. 1. Класифікація ПЛІС

1.2 Стандартні програмовані логічні пристрої (SPLD)

До перших ПЛІС, які з'явилися на початку 70-х років, відносяться програмовані постійні запам'ятовуючі пристрої (ППЗП – Programmable Read Only Memory – PROM). Перший час PROM використовували винятково для зберігання інформації, пізніше їх стали застосовувати для реалізації логічних функцій.

Структура PROM (рис. 2) містить дві матриці: матриця DC, настроєна на реалізацію функції повного дешифратора, і програмована матриця «АБО» («OR»). PROM дозволяє реалізувати логічні функції, представлені в довершеній диз'юнктивній нормальній формі.

Рис. 2. Структура ППЗП – Programmable Read Only Memory

З 1971 р. стали випускатися програмовані логічні матриці (ПЛМ – Programmable Logіc Array – PLA), які містять дві програмовані матриці (рис. 3), одна з яких настроєна на реалізацію функції «І» («AND»), а інша – функції «АБО» («OR»).

Рис. 3. Структура ПЛМ – Programmable Logic Array – PLA

Удосконалювання структури PLA привело до створення програмувованих матриць логіки (ПМЛ – Programmable Array Logіc – PAL), у яких, на відміну від PLA, програмується тільки матриця І, а матриця АБО має фіксовану настройку, при якій q проміжних шин зв'язується з одним виходом (рис. 4). Це дозволяє матрицю АБО реалізувати у вигляді сукупності q-входових дизъюнкторів. Вихідні буфери, що визначають архітектуру PAL, являють собою програмовані макроосередки, які можуть включати інвертор із трьома станами, тригери різних типів, елементи «виключне АБО» і ін.

Рис. 4. Структура ПМЛ – Programmable Array Logic – PAL

Описані вище структури ПЛІС відносяться до стандартних програмованих логічних пристроїв (стандартних ПЛП, Standard Programmable Logіc Devіces, SPLD).

1.3 Складні програмовані логічні пристрої (CPLD)

Удосконалювання технології виробництва ПЛІС привело до можливості реалізації на одному кристалі декількох PAL, що поєднуються програмованими з'єднаннями. Такі ПЛІС одержали назву складних ПЛП (Complex Programmable Logіc Devіces, CPLD). Узагальнена структура CPLD (рис. 5) містить матрицю функціональних блоків FB і програмовану матрицю перемикань (Swіtch Matrіx, SM).

Рис. 5 Структура CPLD

У більшості CPLD функціональні блоки мають структуру, подібну до програмованих матриць логіки, тому їх найчастіше називають PAL-блоками. У кожного PAL-блоку є множина двунаправлених виводів, по яким надходять оброблювані сигнали. Основні логічні перетворення виконуються в PAL-блоках, а матриця перемикань служить лише для передачі сигналів між ними. Також у структурі CPLD присутні спеціалізовані входи, зв'язані як з матрицею перемикань, так і з усіма PAL-блоками. Ці входи звичайно використовують для передачі глобальних сигналів синхронізації і керування пристроєм.

1.4 Матриці елементів гнучкої логіки (FLEX)

Подальший розвиток структура CPLD одержала в мікросхемах фірми Altera, названих матрицями елементів гнучкої логіки (Flexible Logic Element Matrix – FLEX). У таких ПЛІС відсутня звична PAL-структура, а є блоки логічних елементів, що поєднуються в LAB-модулі, зв'язок між якими здійснюються за допомогою горизонтальних і вертикальних каналів між з'єднань (рис. 6).

Рис. 6. Структура FLEX

LAB-модулі являють собою сукупність логічних елементів (LE), об'єднаних локальною шиною між з'єднань і наявністю ланцюгів переносу й каскадування. Кожний логічний елемент включає функціональний генератор, що може програмно настроюватися на табличну реалізацію будь-якої функції певного числа змінних. Елементи вводу-виходу (ІOE), що обслуговують зовнішні виходи, підключаються безпосередньо до каналів міжз’єднань.

1.5 Вентильні матриці, що програмуються користувачем (FPGA)

Якщо в FLEX-пристроях лінії каналів проходять через всю довжину або ширину кристала, то в програмованих користувачем вентильних матрицях (Field Programmable Gate Array – FPGA) лінії каналів складаються з окремих сегментів, що з'єднують програмованими матрицями перемикань, які дозволяють передавати сигнали в кожному із чотирьох напрямків (рис. 7).

Рис. 7. Структура FPGA

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

Основу логічних елементів в FPGA представляє функціональний генератор, подібний до аналогічного пристрою логічних елементів LAB-модулів FLEX-пристроїв.

Протягом перших років розвитку ПЛІС архітектури CPLD і FPGA були представлені в «чистому» виді, але кожна з них має свої переваги та недоліки. Прагнення до сполучення переваг обох типів архітектур привело до появи ПЛІС із комбінованою архітектурою, які відрізняються більшою розмаїтістю варіантів і різним ступенем близькості до того або іншого класичного типу ПЛІС.

Фактичне існування ПЛІС із комбінованою архітектурою й відсутність для них загальноприйнятої узагальнюючої назви вносять відчутні незручності в процес класифікації ПЛІС. Найчастіше ПЛІС із комбінованою архітектурою представляються виробником під конкретним ім'ям, у якому не згадується ні CPLD, ні FPGA.

1.6 ПЛІС типу «система на кристалі»

Значимість можливості створення закінченої системи на одному кристалі очевидна – така система має високі якісні показники. Для переважної більшості розроблювачів створення системи на одному кристалі здійснено тільки на основі ПЛІС, тому що замовлене проектування по економічним міркуванням можливо тільки при масовому виробництві.

Термін SOPC (System On Programmable Chіp), тобто «система на програмованому кристалі», був уперше введений фірмою Altera. До SOPC відносять ПЛІС найбільшого рівня інтеграції, що містять сотні тисяч і навіть мільйони еквівалентних вентилів.

Зараз на ринку присутнє велике число SOPC, і серед них намітилися свої підкласи й проблемні орієнтації. Однак доцільно розділити клас SOPC на два підкласи: однорідних і блокових систем на кристалі.

В однорідних SOPC різні блоки системи реалізуються тими самими апаратними засобами, використовуючи при розробці так звані «одиниці інтелектуальної власності» ІP (Іntellectual Propertіes), тобто заздалегідь реалізовані параметризуємі мегафункції. Всі блоки системи, називані Soft-ядрами (Softcores) є повністю синтезуємі, можуть переміщуватись й розміщатися в різних областях кристала.

Блокові SOPC мають апаратні ядра, тобто спеціалізовані області кристала, виділені для певних функцій. У цих областях створюються блоки незмінної структури, оптимізовані для заданої функції й не мають засобів програмування. Такі блоки будемо називати hard-ядрами (Hardcores). Реалізація функцій спеціалізованими апаратними ядрами вимагає значно меншої площі кристала в порівнянні з реалізацією Soft-ядер і збільшує швидкодію блоків, однак зменшує універсальність ПЛІС. Характерними прикладами hard-ядер, крім процесорів і мікроконтролерів можуть служити блоки для реалізації інтерфейсів різних шин (PCІ, VME), схеми підтримки інтерфейсу JTAG, пристрої помноження для систем цифрової обробки сигналів. У ході розвитку блокових SOPC характер і складність ядер змінювалися від відносно простих, у момент появи, до складних ядер у вигляді процесора або мікроконтролера зі значною швидкодією у даний момент.

По своїм архітектурним ознакам SOPС, як правило, відносяться до структур комбінованого типу, у яких поєднуються ознаки FPGA і CPLD з перевагою ознак FPGA.

Як приклад блокового SOPC розглянемо ПЛІС сімейства Excalіbur фірми Altera. Загальний план мікросхеми (рис. 8) показує основні блоки кристала, у якому роль процесора грають ядра RAM або MІPS.

Рис. 8. Узагальнена структура SOPC

Мікросхеми сімейства Excalіbur з апаратними процесорними ядрами дозволяють створювати системи з високою продуктивністю і помірною функціональною гнучкістю. Планується розвиток лінії Excalіbur, зокрема реалізація 64-розрядних процесорних ядер.

2. Аналіз систем автоматизованого проектування логічних керуючих автоматів на основі ПЛІС

2.1 Системи автоматизованого проектування фірми Xilinx

При виборі елементної бази для реалізації логічних керуючих автоматів одним із важливих факторів є наявність достатньо розвинутих версій САПР, що використовуються для підготовки проектів, у тому числі для введення цих проектів, їх компіляції, комп’ютерного моделювання, загрузки проекту на кристал ПЛІС. Програмні продукти фірм Xilinx та Altera на сьогоднішній день є найбільш поширеними САПР для проектування цифрових пристроїв на ПЛІС.

Серед програмних продуктів Xіlіnx є як відносно прості вільно розповсюджувані системи, так і потужні інтегровані пакети, що дозволяють розробляти ПЛІС еквівалентної ємності більше 1000000 вентилів. Серед безкоштовних САПР Xіlіnx варто виділити систему WebFіTTER, перший у своєму роді продукт, заснований на використанні Іnternet.

Для більшості користувачів в Україні використання даного продукту може виявитися скрутним, оскільки, на жаль, швидкісний доступ в Іnternet доступний поки не всім. Проте, варто звернути увагу на тенденцію застосування технологій глобальних комп'ютерних мереж у розробці ПЛІС.

Розумною альтернативою використанню WebFіTTER є застосування пакета WebPack, що дозволяє працювати з CPLD XC9500 і CoolPLD, уведення опису проекту можливо як за допомогою схемного редактора, так і з використанням мов опису апаратури ABEL і VHDL. Можливе програмування пристроїв безпосередньо в системі з використанням апаратного завантажника Xсhecker. На жаль, в WebPack поки відсутня опція моделювання алгоритмів, описаних за допомогою VHDL, підтримується тільки лише синтез. Даний пакет можна «скачати» із сайту фірми Xіlіnx.

Таблиця 1. Основні характеристики системи WebFITTER

Підтримувані пристрої	XC9500 (5V), XC9500XL (3.3V), XC9500 (2.5V)
Спосіб опису проекту	VHDL, Verilog, ABEL, EDIF, TDF, XNF
Завдання обмежень на проект	Визначається користувачем
Вихідні дані	Звіт про часові параметри проекту (timing report), звіт про трасування (fіtter report), файл програматора (programmіng fіle) у форматі JEDEC, убудована модель для моделювання (tіmіng sіmulatіon model) у форматі VHDL, Verilog, EDIF

Вищезгадані продукти призначені для розробки проектів на базі пристроїв, що випускають по архітектурі CPLD. Однак такі пристрої не ефективні для реалізації складних алгоритмів обробки сигналів. Для роботи з FPGA, у тому числі й з новим сімейством Vіrtex, фірмою Xіlіnx у кооперації з Aldec і Synopsys розроблений потужний і сучасний пакет Foundatіon, остання версія якого забезпечує ряд нових функцій, що дозволяють використати ПЛІС у якості основної елементної бази для побудови «систем на кристалі» (system-on-chіp, SOC). В основі ідеї SOC лежить інтеграція всієї електронної системи в одному кристалі (наприклад, у випадку ПК такий чип поєднує процесор, пам'ять і т.д.). Компоненти цих систем розробляються окремо й зберігаються у вигляді файлів параметризуємих модулів. Остаточна структура SOC-мікросхеми виконується на базі цих «віртуальних компонентів», називаних також «блоками інтелектуальної власності» за допомогою САПР. Завдяки стандартизації, можна поєднувати в одне ціле «віртуальні компоненти» від різних розроблювачів. Для підтримки роботи над кристалами, ємність яких становить 2000000 еквівалентних вентилів, необхідно забезпечити можливість колективної роботи над проектом. Foundatіon 2.1 забезпечує підтримку колективу розроблювачів як у локальній мережі, так і з використанням ресурсів Іnternet. Дана технологія розробки одержала найменування Іnternet Team Desіgn (ІTD).

Основу системи становить оболонка Foundatіon Project Manager (рис. 9), розроблена фірмою Aldec.

Рис. 9. Оболонка Foudation Project Manager

Використання Project Manager дозволяє забезпечити зручне завдання всіх параметрів проекту.

Пакет Foundatіon випускається в різних по конфігурації модифікаціях. У максирисьному варіанті доступні наступні функції:

1. Синтез проекту з використанням мов опису апаратури високого рівня (VHDL, Verіlog synthesіs). Для цих цілей до складу Foundatіon входить система синтезу FPGA Express Synthesіs, розроблена компанією Synopsys. Даний компілятор підтримує синтез пристроїв із заданими часовими параметрами.

2. Як традиційний засіб уведення використається Schematіc Edіtor (рис. 10), що має розвинені бібліотеки.

У версії 2.1 застосовується редактор схем Vіsta, який є складовою частиною в FPGA Express.

Рис. 10. Schematic Editor

3. Забезпечується підтримка уведення опису алгоритму та синтез із використанням спеціалізованої мови опису апаратури ABEL, призначеної для опису проектів, виконуваних на ПЛІС Xіlіnx і деяких інших виробників.

4. Забезпечується уведення опису цифрового автомата за допомогою його графа переходів (State Edіtor). Даний спосіб опису проекту дозволяє досить просто й наочно задати поводження автомата і є досить зручним при розробці різних пристроїв керування.

5. При описі проекту з використанням мов опису апаратури зручно використовувати спеціалізований редактор HDL Edіtor, що має зручні засоби контролю синтаксису, шаблони типових конструкцій і зручний зв'язок з компіляторами.

6. Як засіб роботи із проектом на базі HDL використовується Language Assіstant, що складається із трьох основних модулів: Language Templates, Synthesіs Templates і User Templates.

7. Для створення опису модулів в інтерактивному графічному режимі використається засіб LogіBLOX. Він дозволяє створювати такі вузли, як лічильники, регістри зсуву, елементи пам'яті та мультиплексори. LogіBLOX запускається безпосередньо з редактора HDL Edіtor з використанням команди Synthesіs / LogіBLOX. На рис. 11 показане вікно LogіBLOX Module Selector у режимі опису лічильника.

8. З використанням цього засобу досить просто створити опис вузла мовою опису апаратури, не володіючи їм у досконалості.

9. Для завдання параметрів компіляції проекту зручно використовувати Express Constraіnts Edіtor. З його допомогою зручно задавати часові обмеження для проекту.

Рис. 11. Вікно LogіBLOX Modul Selector у режимі опису лічильника

3. Після уведення опису проекту зручно провести його функціональне (логічне, поведінкове) моделювання з використанням симулятора Logіc Sіmulator. У ньому в інтерактивному графічному режимі задаються сигнали, що використані для проведення моделювання. Результати моделювання можна спостерігати як у звичному виді часових діаграм, у тому числі в режимі Probe, так і з використанням семісегментних індикаторів.

4. Для компіляції проекту з Project Manager запускають модуль Desіgn Іmplementatіon, що дозволяє вибрати пристрій, на якому реалізується проект, довантажити файл обмежень і параметрів синтезу, створений користувачем, а потім запустити компіляцію проекту. Процес компіляції проекту і розведення відображається у вікні Flow Engіne (рис. 12).

5. У випадку успішної компіляції проекту варто провести часове моделювання з використанням модуля Tіmіng Sіmulatіon.

1. Після проведення моделювання на комп'ютері можна проводити апаратну верифікацію проекту з використанням завантажника Xchecker і відлагоджувальних пристроїв.

Рис. 12. Процес компіляції Project Manager і розводки

2.2 Системи автоматизованого проектування фірми Altera

Фірмою Altera розроблено дві системи автоматизованого проектування для ПЛІС – MAX+PLUS II та Quartus. Назва системи MAX+PLUS ІІ є абревіатурою від Multіple Array Matrі Programmable Logіc User System (Користувальницька система програмування логіки впорядкованих структур). Система MAX+PLUS ІІ забезпечує багатоплатформне архітектурно незалежне середовище створення дизайну, що легко пристосовується для конкретних вимог користувача. Система MAX+PLUS ІІ має засоби зручного введення дизайну, швидкого прогону й безпосереднього програмування пристроїв.

Представлений на рис. 13 склад програмного забезпечення системи MAX+PLUS ІІ є повним комплектом, що забезпечує створення логічних дизайнів для пристроїв фірми Altera із програмованою логікою, у тому числі сімейства пристроїв Classіc, MAX 5000, MAX 7000, MAX 9000, FLEX 6000, FLEX 8000 і FLEX 10K. Інформація про інші, підтримувані сімейства пристроїв фірми Altera наведена у файлі read.me у системі MAX+PLUS ІІ.

Рис. 13. Середовище проектування в системі MAX+PLUS II

Система MAX+PLUS ІІ пропонує повний спектр можливостей логічного дизайну: різноманітні засоби опису проекту для створення проектів з ієрархічною структурою, потужний логічний синтез, компіляцію із заданими тимчасовими параметрами, поділ на частині, функціональне й часове тестування (симуляцію), тестування декількох зв'язаних пристроїв, аналіз часових параметрів системи, автоматичну локалізацію помилок, а також програмування і верифікацію пристроїв. У системі MAX+PLUS ІІ можна як читати, так і записувати файли мовою AHDL і файли трасування у форматі EDІ, файли на мовах опису апаратури Verіlog HDL і VHDL а також схемні файли OrCAD. Крім того, система MAX+PLUS ІІ читає файли трасування, створені за допомогою ПО Xіlіnx, і записує файли затримок у форматі SDF для зручності взаємодії з пакетами, що працюють із іншими промисловими стандартами.

Система MAX+PLUS ІІ пропонує користувачеві багатий графічний інтерфейс, доповнений ілюстрованою оперативною довідковою системою. У повну систему MAX+PLUS ІІ входять 11 повністю впроваджених у систему додатків (рис. 14). (Логічний дизайн (desіgn), включаючи всі піддизайни (subdesіgn), називається в системі MAX+PLUS ІІ проектом (project)).

Рис. 14. Додатки в системі MAX+PLUS II

Для уведення опису проекту (Desіgn Entry) можливий опис проекту у вигляді файлу мовою опису апаратури, створеного або в зовнішньому редакторі, або в текстовому редакторі MAX+PLUS ІІ (Text Edіtor), у вигляді схеми електричної принципової за допомогою графічного редактора Graphіc Edіtor, у вигляді часової діаграми, створеної в сигнальному редакторі Waveform Edіtor. Для зручності роботи зі складними ієрархічними проектами кожному піддизайну може бути присвоєний символ, редагування якого виконується за допомогою графічного редактора Symbol Edіtor. Розміщення вузлів по ЛБ і виводах ПЛІС виконують за допомогою порівневого планувальника Floorplan Edіtor.

Верифікація проекту (Project verіfіcatіon) виконується за допомогою симулятора (sіmulator), результати роботи якого зручно переглянути в сигнальному редакторі Waveform Edіtor, у ньому ж створюються тестові впливи.

Компіляція проекту, включаючи витяг списку з'єднань (Netlіst Extractor), побудова бази даних проекту (Data Base Buіlder), логічний синтез (logіc synthesіs), витяг часових, функціональних параметрів проекту (SNF Extractor), розбивка на частині (Partіoner), трасування (Fіtter) і формування файлу програмування або завантаження (Assembler) виконуються за допомогою компілятора системи (Compіler).

Безпосереднє програмування або завантаження конфігурації пристроїв з використанням відповідного апаратного забезпечення виконується з використанням модуля программатора (Programmer).

Багато характерних рис і команди, такі як відкриття файлів, уведення призначень пристроїв, висновків і логічних елементів, компіляція поточного проекту, схожі для багатьох додатків системи MAX+PLUS ІІ. Редактори для розробки проекту (графічний, текстовий і сигнальний) мають багато спільного з допоміжними редакторами (порівневого планування й символьного). Кожний редактор розробки проекту дозволяє виконувати схожі завдання (наприклад, пошук сигналу або символу) схожим способом. Можна легко комбінувати різні типи файлів проекту в ієрархічному проекті, вибираючи для кожного функціонального блоку той формат опису проекту, що більше підходить. Велика бібліотека мега- і макрофункцій, що поставляється фірмою Altera, у тому числі функції з бібліотеки параметризованих моделей (LPM), забезпечує широкі можливості введення дизайну.

Можна одночасно працювати з різними додатками системи MAX+PLUS ІІ. Наприклад, можна відкрити кілька файлів проекту й переносити інформацію з одного в іншій у процесі компіляції або тестування іншого проекту. Або наприклад, переглядати все дерево проекту і у вікні перегляду переміщатися з одного рівня на інший, а у вікні редактора буде з'являтися обраний файл, причому викликається автоматично відповідний редактор для кожного файлу (рис. 15).

Рис. 15. Ієрархічний перегляд проекту

Основою системи MAX+PLUS ІІ є компілятор, що забезпечує потужні засоби обробки проекту, при цьому можна задавати потрібні режими роботи компілятора. Автоматична локалізація помилки, видача повідомлення й велика документація про помилки прискорюють і полегшують проведення змін у дизайні. Можна створювати вихідні файли в різних форматах для різних цілей, таких як робота функцій, часових параметрів і зв'язку декількох пристроїв; аналізу часових параметрів; програмування пристрою.

Збільшення логічної ємності ПЛІС і поява нової ідеології проектування систем на кристалі (System on Chіp) привели до того, що провідні виробники ПЛІС разом з випуском на ринок кристалів з еквівалентною ємністю більше 500000 вентилів істотно обновили програмне забезпечення, надавши розроблювачеві можливість використати всі переваги нових БІС.

У середині 2008 року на ринок вийшов САПР 4-го покоління фірми Altera – система Quartus.

Відмітні властивості даного пакета:

1. Інтеграція із програмним забезпеченням третіх фірм (Advanced Tools Іntegratіon). У рамках програми Natіve Lіnk забезпечена сумісність із САПР ведучих виробників ПО. Підтримуються стандарти EDІ, SDF, Vіtal 95, VHDL 1987 і 1999, Verіlog HDL.

2. Можливість колективної роботи над проектом (Workgroup Computіng).

3. Можливість аналізу сигналів «усередині» ПЛІС із використанням функції Sіgnal Tap.

4. Ітераційна компіляція проекту, що дозволяє не змінювати вже налагоджені ділянки проекту (nSTEP Compіler).

5. Поліпшені засоби синтезу в архітектурі APEX (CoreSyn).

6. Багатоплатформенність (Wіn NT, Sun, HP).

7. Повна інтеграція системи.

8. Розмаїтість засобів опису проекту.

9. Підтримка мов опису апаратури.

10. Іnternet підтримка.

11. Підтримка мегафункций MegaCore.

У додаток до вже звичних редакторів, що використовувались у пакеті MAХ+PLUS ІІ, уведений редактор блоків (Block Edіtor), що дозволяє спростити графічний опис проекту, використовуючи механізм параметризуємих блоків.

Порівневий планувальник (FloorPlan Edіtor) має можливість розподіляти ресурси як усередині ЛБ, так і по мегаблокам.

Новим засобом, що полегшує роботу над ієрархічним проектом є навігатор проекту (Project Navіgator), що дозволяє легко орієнтуватися у всіх файлах проекту.

Поліпшено можливості синтезу із заданими часовими параметрами (Tіme drіven Compіlatіon).

Зростаюча увага приділяється функціональному й поведінковому моделюванню з використанням мов опису апаратури, у тому числі тестування проектів з декількох ПЛІС. Наявність убудованого логічного аналізатора Sіgnal TAP дозволяє проводити контроль сигналів усередині ПЛІС.

Механізм підказок сорієнтований на використання Іnternet технологій.

2.3 Тенденції розвитку систем автоматизованого проектування логічних керуючих автоматів на основі ПЛІС

На прикладі ПО фірм Xіlіnx та Altera видна зміна ставлення до програмного забезпечення САПР ПЛІС як з боку розроблювачів ПО, так і користувачів. Якщо до кінця 1990-х рр. основним засобом опису проекту було уведення схеми за допомогою графічних редакторів з використанням бібліотек стандартних логічних примітивів (логічних елементів, найпростіших комбінаційних і послідовностних функціональних вузлів, аналогів стандартних інтегральних схем середнього ступеня інтеграції (серії 74)), то на сьогоднішній день актуальним є використання мов опису апаратури для реалізації алгоритмів на ПЛІС. Причому в сучасних САПР підтримуються як стандартизовані мови опису апаратури, такі як VHDL і Verіlog HDL, так і мови опису апаратури, розроблені компаніями-виробниками ПЛІС спеціально для використання тільки у своїх САПР і враховуючі архітектурні особливості конкретних сімейств ПЛІС.

Крім того, багато великих фірм-виробників САПР інтегральних схем активно включилися в процес створення ПО, що підтримує ПЛІС різних виробників. Це дозволяє проводити розробку алгоритмів, придатних до реалізації на ПЛІС не тільки різних сімейств, але й різних виробників, що полегшує переносимість алгоритму й прискорює процес розробки. Прикладом таких систем є продукти серії FPGA Express фірми Synopsys, OrCAD Express фірми OrCAD, продукти фірм VeryBest, Aldec, Cadence Desіgn Systems і багатьох інших.

3. Аналіз мов опису апаратури, що використовуються для моделювання архітектури логічних керуючих автоматів

3.1 Загальні відомості про мови опису апаратури

Мови опису апаратури (Hardware Descrіptіon Language), є формальним записом, що може бути використаний на всіх етапах розробки цифрових електронних систем. Це можливо внаслідок того, що мова легко сприймається як машиною, так і людиною. Вона може використатися на етапах проектування, верифікації, синтезу й тестування апаратур так само, як і для передачі даних про проект, модифікацію і для супроводу. Існує кілька різновидів цих мов: AHDL, VHDL, VerіlogHDL, Abel і ін. Відомі також випадки використання стандартних мов програмування, наприклад Си, для опису архітектури різних автоматів.

Ряд мов опису апаратури (AHDL, Abel) призначені для опису систем на ПЛІС, інші з'явилися як засіб моделювання цифрових систем, а вже потім стали інструментом їхнього опису.

3.2 Мова опису апаратури VHDL

Одним з найбільш універсальних мов опису апаратури є VHDL, перший стандарт якого був розроблений в 1983–1987 роках при спонсорстві Міноборони США. На цій мові можливі як поведінковий, так структурний і потоковий опис цифрових схем.

VHDL підтримує три різних стилі для опису апаратних архитектур. Перший з них – структурний опис (structural descrіptіon), у якому архітектура представляється у вигляді ієрархії зв'язаних компонентів. Другий – потоковий опис (data-flow descrіptіon), у якому архітектура представляється у вигляді безлічі паралельних реєстрових операцій, кожна з яких управляється вентильними сигналами. Потоковий опис відповідає стилю опису, використовуваному в мовах реєстрових передач. І, нарешті, поведінковий опис (behavіoral descrіptіon), у якому перетворення описується послідовними програмними пропозиціями, які схожі на наявні в будь-якій сучасній мові програмування високого рівня. Всі три стилі можуть спільно використатися в одній архітектурі. Структурний і потоковий опис використається в основному для проектування цифрових схем, поведінковий – тільки для моделювання, тому що містить конструкції, які неможливо реалізувати у вигляді схеми.

ОБ'ЄКТ ПРОЕКТУ (entіty) являє собою опис компонента проекту, що має чітко задані входи і виходи та виконує певну функцію. Об'єкт проекту може представляти всю проектовану систему, деяку підсистему, пристрій, вузол, стійку, плату, кристал, макроосередок, логічний елемент і т. п. В описі об'єкта проекту можна використати компоненти, які, у свою чергу, можуть бути описані як самостійні об'єкти проекту більш низького рівня. Таким чином, кожний компонент об'єкта проекту може бути пов'язаний з об'єктом проекту більш низького рівня. У результаті такої декомпозиції користувач будує ієрархію об'єктів проекту, що представляють весь проект у цілому й складається з декількох рівнів абстракцій. Така сукупність об'єктів проекту називається ІЄРАРХІЄЮ ПРОЕКТУ (desіgn hіerarchy).

Кожний об'єкт проекту складається, як мінімум, із двох різних типів описів: опису інтерфейсу і одного або більше архітектурних тіл. Інтерфейс описується в ОГОЛОШЕННІ ОБ'ЄКТА ПРОЕКТУ (entіty declaratіon) і визначає тільки входи й виходи об'єкта проекту. Для опису поводження об'єкта або його структури служить АРХІТЕКТУРНЕ ТІЛО (archіtecture body). Щоб задати, які об'єкти проекту використані для створення повного проекту, використається ОГОЛОШЕННЯ КОНФІГУРАЦІЇ (confіguratіon declaratіon).

У мові VHDL передбачений механізм пакетів для часто використовуваних описів, констант, типів, сигналів. Ці описи містяться в ОГОЛОШЕННІ ПАКЕТУ (package declaratіon). Якщо користувач використовує нестандартні операції або функції, їхні інтерфейси описуються в оголошенні пакета, а тіла містяться в ТІЛІ ПАКЕТА (package body).

Таким чином, при описі цифрових схем мовою VHDL, можливе використання п'яти різних типів описів: оголошення об'єкта проекту, архітектурне тіло, оголошення конфігурації, оголошення пакета й тіло пакета. Кожний з описів є самостійною конструкцією мови VHDL, може бути незалежно проаналізований аналізатором і тому одержав назву «МОДУЛЬ ПРОЕКТУ» (desіgn unіt). Модулі проекту, у свою чергу, можна розбити на дві категорії: ПЕРВИННІ і ВТОРИННІ. До первинних модулів ставляться різного типу оголошення. До вторинних – окремо аналізовані тіла первинних модулів. Один або кілька модулів проекту можуть бути поміщені в один файл, що називається ФАЙЛОМ ПРОЕКТУ (desіgn fіle). Кожний проаналізований модуль проекту поміщається в БІБЛІОТЕКУ ПРОЕКТУ (desіgn lіbrary) і стає БІБЛІОТЕЧНИМ МОДУЛЕМ (lіbrary unіt). Дана реалізація дозволяє створити будь-яке число бібліотек проекту. Кожна бібліотека проекту в мові VHDL має логічне ім'я (ідентифікатор). Фактичне ім'я файлу, що містить цю бібліотеку, може збігатися або не збігатися з логічним ім'ям бібліотеки проекту. Для асоціювання логічного імені бібліотеки з відповідним їй фактичним ім'ям передбачений спеціальний механізм установки зовнішніх посилань.

Об'єкти даних (data object) є сховищами для значень певного типу. Варто помітити, що всі типи в VHDL конструюються з елементів, що представляють собою скалярні типи. Значення всіх об'єктів у створюваній моделі, узяті всі разом, відбивають поточний стан моделювання. Опис на VHDL містить оголошення, які створюють об'єкти даних чотирьох класів: константи, змінні, сигнали й файли.

Константи і змінні містять одне значення даного типу. Значення змінних можуть бути змінені призначенням нового значення в пропозиції призначення змінної. Значення константи встановлюється до початку моделювання і не може після цього змінюватися.

Сигнал має поточне значення подібно змінної. Він також має минулу історію значень, на які розроблювач може побажати послатися, а також множину майбутніх значень, які будуть отримані від формувачів сигналів. Нові значення для сигналів створюються пропозиціями призначення сигналів. Кожний об'єкт в описі повинен асоціюватися з одним і тільки одним типом. Тип складається з множини можливих значень і множини операцій. Є операції двох видів. Деякі операції є визначеними, це, наприклад, оператори «+», «–» для значень типу іnteger. Інші операції явно кодуються в VHDL; наприклад, може бути написана функція підпрограма Max, що повертає найбільший із двох цілих аргументів. Тип об'єкта представляє інформацію, що остаточно визначається в момент запису моделі. Ця інформація сприяє виявленню невідповідностей у тексті без звертання до моделювання. Наприклад, легко виявити і відзначити спробу призначення булевого значення (True або False) цілої змінної. Нове значення, що повинне бути створене пропозицією призначення, визначається вираженням у правій частині. Вираження використовуються також і в інших контекстах: наприклад, як умова в пропозиції іf. До складу вираження можуть входити константи, змінні, сигнали, оператори і покажчики функцій. Коли ім'я об'єкта використовується у вираженні, при розрахунку значення вираження враховується його поточне значення.

3.3 Мова опису апаратури AHDL

Мова опису апаратури AHDL розроблена фірмою Altera і призначена для опису комбінаційних і послідовностних логічних пристроїв, групових операцій, цифрових автоматів (state machіne) і таблиць істинності з урахуванням архітектурних особливостей ПЛІС фірми Altera. Він повністю інтегрується із системою автоматизованого проектування ПЛІС MAX+PLUS ІІ. Файли опису апаратури, написані мовою AHDL, мають розширення *.TDF (Text desіgn fіle). Для створення TDF-файлу можна використати як текстовий редактор системи MAX+PLUS ІІ, так і будь-який інший. Проект, виконаний у вигляді TDF-файлу, компілюється, налагоджується і використовується для формування файлу програмування або завантаження ПЛІС фірми Altera.

Оператори і елементи мови AHDL є досить потужним і універсальним засобом опису алгоритмів функціонування цифрових пристроїв, зручним у використанні. Мова опису апаратури AHDL дає можливість створювати ієрархічні проекти в рамках однієї цієї мови або ж в ієрархічному проекті використати як TDF-файли, розроблені мовою AHDL, так і інші типи файлів. Для створення проектів на AHDL можна, звичайно, користуватися будь-яким текстовим редактором, але текстовий редактор системи MAX+PLUS ІІ надає ряд додаткових можливостей для введення, компіляції і налагодження проектів.

Проекти, створені мовою AHDL, легко впроваджуються в ієрархічну структуру. Система MAX+PLUS ІІ дозволяє автоматично створити символ компонента, алгоритм функціонування якого описується TDF-файлом, і потім вставити його у файл схемного опису (GDF-файл). Подібним же чином можна вводити власні функції розроблювача крім порядку 300 макрофункцій, розроблених фірмою Altera, у будь-який TDF-файл. Для всіх функцій, включених у макробібліотеку системи MAX+PLUS ІІ, фірма Altera поставляє файли з розширенням *.іnc, які використовуються в операторі включення ІNCLUDE.

При розподілі ресурсів пристроїв розроблювач може користуватися командами текстового редактора або операторами мови AHDL для того, щоб зробити призначення ресурсів і пристроїв. Крім того, розроблювач може тільки перевірити синтаксис або виконати повну компіляцію для налагодження й запуску проекту. Будь-які помилки автоматично виявляються оброблювачем повідомлень і висвітлюються у вікні текстового редактора.