Дослідження методів і алгоритмів синтезу синхронних кінцевих автоматів

  • Вид работы:
    Отчет по практике
  • Предмет:
    Информатика, ВТ, телекоммуникации
  • Язык:
    Украинский
    ,
    Формат файла:
    MS Word
    1,56 Мб
  • Опубликовано:
    2013-02-15
Вы можете узнать стоимость помощи в написании студенческой работы.
Помощь в написании работы, которую точно примут!

Дослідження методів і алгоритмів синтезу синхронних кінцевих автоматів

МІНІСТЕРСТВО ОСВІТИ І НАУКИ, МОЛОДІ ТА СПОРТУ УКРАЇНИ

ЗАПОРІЗЬКИЙ НАЦІОНАЛЬНИЙ ТЕХНІЧНИЙ УНІВЕРСИТЕТ



Кафедра мікро- та наноелектроніки





ЗВІТ

з переддипломної практики

на тему: «Дослідження методів і алгоритмів синтезу синхронних кінцевих автоматів»



Розробив

ст. гр. РТ-318 В.М. Петрінчик

Керівник,

викладач В.М. Матюшин



2013

ЗМІСТ

ВСТУП

. ОСНОВНІ ТЕОРЕТИЧНІ ВІДОМОСТІ

.1 Поняття та сутність ПЛІС

.1.1 Особливості ПЛІС

.1.2 Використостання ПЛІС

.2 Проектування та зародження мови VHDL

.2.1 Переваги VHDL над схемним проектуванням. Проектування з використанням мови VHDL

1.2.2 Використання VHDL в сучасних САПР

.2.3 Технологія розробки систем на кристалі

.2.4 Обчислювальні заготовки

.3 Проектування в середовищі MatLab

.3.1 Моделювання систем за допомогою блока Stateflow

.3.2 Як працює блок Stateflow. Основні функції та визначення

.4 Проектування в середовищі Quartus II

.4.1 Схеми розробки програмного забезпечення

1.4.2 Поняття проекту

.4.3 Стратегія проектування

.4.4 Процес моделювання

.4.5 Створення вектора вхідних впливів та файлу *. vwf

.4.6 Додавання вхідних, вихідних і проміжних сигналів

1.4.7 Визначення параметрів моделювання

.4.8 Моделювання проекту

.4.9 Створення вихідних умов для проектування та використання редактора призначень

. СИНТЕЗ СИНХРОННОГО КІНЦЕВОГО АВТОМАТА

2.1 Створення графа станів для синхронного кінцевого автомата

2.2 Одержання VHDL коду в середовищі Quartus

ВИСНОВКИ

ПЕРЕЛІК ПОСИЛАНЬ

ВСТУП

моделювання граф matlab quartus

Цифрові автомати - це логічні пристрої, в яких, крім логічних елементів, є елементи пам'яті. Значення вихідних сигналів такого пристрою залежить не тільки від аргументів на вході в даний момент часу, але і від попереднього стану автомата, який фіксується елементами пам'яті. Як елементи пам'яті можуть використовуватися тригери. Кожний внутрішній стан цифрового автомата визначається вихідним станом тригерів і послідовністю вхідних сигналів, що діють на вході в даний момент часу, тому такі пристрої називають послідовнісними схемами. До послідовних схема можна віднести: тригери, лічильники, регістри.

У загальному випадку структурна схема цифрового автомата може бути представлена у вигляді набору трьох вузлів: комбінаційної схеми формування вихідних сигналів, комбінаційної схеми формування сигналів управління тригерами і, власне, пам'яті (рисунок 1).

Рисунок 1 - Структурна схема цифрового автомата

За способом формування функції виходів автомати поділяються на автомати Мілі (Mealy) та Мура (Moore).

Відмінність автомата Мура від автомата Милі полягає в тому, що вихідний сигнал в автоматі Мура залежить тільки від поточного стану автомата (рисунок 1 без пунктирних ліній) і в явному вигляді не залежить від вхідного сигналу. В автоматі Мілі вихідні сигнали визначаються як станами і вхідними сигналами (рисунок - 1.1 з урахуванням пунктирних ліній).

У будь-якому пристрої обробки цифрової інформації можна виділити два основні блоки - операційний автомат (ОА) і керуючий автомат (КА).

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

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

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

1. ОСНОВНІ ТЕОРЕТИЧНІ ВІДОМОСТІ

.1 Поняття та сутність ПЛІС

.1.1 Особливості ПЛІС

FPGA (field programmable gate arrays) або ПЛІС (програмовані логічні інтегральні схеми), являють собою цифрові інтегральні мікросхеми (ІС), що складаються з програмованих логічних блоків і програмованих з'єднань між цими блоками. Функціональна можливість пристроїв дозволяє інженерам розробникам вирішувати безліч різних завдань.

Залежно від способу виготовлення ПЛІС можуть програмуватися або один раз, або багато разів. Пристрої, які можуть програмуватися тільки один раз, називаються однопрограмованими.

Словосполучення «field programmable», що міститься в розшифровці абревіатури FPGA, означає, що програмування FPGA - пристроїв виконується на місці, «в польових умовах» (на відміну від пристроїв, внутрішня функціональність яких жорстко прописана виробником). Словосполучення може також означати, що FPGA - пристрої (ПЛІС) конфігуруються в лабораторних умовах, або свідчити про те, що мова йде про можливість модифікації функцій пристрою, вбудованого в електронну систему, яка вже якось використовується. Якщо пристрій може бути запрограмований і залишаючись при цьому в складі системи більш високого рівня, він називається внутрішньо-системно програмованим.

Існує безліч різних типів цифрових мікросхем, в тому числі і такі як «розсипна логіка» (невеликі компоненти, які містять кілька простих фіксованих логічних функцій), пристрої пам'яті та мікропроцесори. В даному випадку інтерес представляють програмовані логічні пристрої (ПЛП), спеціалізовані заказні інтегральні мікросхеми (ASIС - application specific integrated circuit, спеціалізована інтегральна схема та ASSP - application specific standard parts, спеціалізована стандартна схема, та звичайні ПЛІС. Причому термін ПЛП об'єднує два типи пристроїв: прості програмовані логічні пристрої, та складні програмовані логічні пристрої.

Внутрішня архітектура ПЛП визначена виробником, таким чином, що вони можуть бути сконфігуровані (перепрограмовані) «на місці» для виконання самих різних функцій. На відміну від ПЛІС ці пристрої містять меншу кількість вентилів і використовуються для вирішення невеликих і досить простих задач. Разом з тим, існують заказні інтегральні схеми ASIC і ASSP, які містять сотні мільйонів логічних вентилів і можуть виконувати неймовірно великі і складні функцій. В основі ASIC і ASSP лежать одні і ті ж конструкторські рішення, і у них одна і та ж технологія виробництва. Обидва типи пристроїв розробляються для використання у складі спеціальних програм, але при цьому ASIC розробляються і виробляються на замовлення спеціалізованих компаній, ASSP призначені масовим користувачам.

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

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

Що стосується вартості ПЛІС, то вона набагато нижче вартості замовлених інтегральних схем (хоча як відомо заказні мікросхеми при масовому виробництві являються дешевшими). До того ж, у разі використання ПЛІС внесення змін до пристрою не викликає особливих труднощів і суттєво скорочують терміни виходу таких пристроїв на ринок. Все це робить ПЛІС привабливими не тільки для великих розробників, але і для невеликих новаторських конструкторських бюро, які завдяки функціональності ПЛІС залишаються життєздатними при різних умовах. Іншими словами, «апаратні» або «програмні» ідеї окремих інженерів чи невеликих груп інженерів можуть бути реалізовані у вигляді випробувальних стендів на основі ПЛІС без великих одноразових витрат на проектування або закупівлю дорогого оснащення, необхідної для розробки заказних мікросхем. Саме цим пояснюється той факт, що в 2003 році, було розпочато майже 450000 розробок, які передбачають використання ПЛІС, всього 5000 розробок з використанням заказних мікросхем ASSP і тільки від 1500 до 4000 розробок з використанням заказних мікросхем ASIC, причому ці цифри стрімко падають з року в рік.

.1.2 Використостання ПЛІС

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

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

На початоку другого тисячоліття з'явилися високопродуктивні ПЛІС, які містять мільйони вентилів. Деякі з них містять вбудовані мікропроцесорні ядра, високошвидкісні інтерфейси вводу / виводу і інші пристрої. Сучасні ПЛІС знаходять застосування практично в будь-якій сфері, включаючи пристрої зв'язку і програмовані радіостанції. ПЛІС застосовують в радіолокації, обробці зображень і в інших сферах цифрової обробки сигналів (ЦОС). ПЛІС використовують всюди, в тому числі і в однокристальних системах містять програмні і апаратні модулі. Якщо бути більш точним, в даний час ПЛІС заповнюють чотири великих сегменти ринку: заказні інтегральні схеми, цифрова обробка сигналів, системи на основі вбудованих мікроконтролерів і мікросхеми, що забезпечують фізичний рівень передачі даних. Крім того, з появою ПЛІС виник новий сектор ринку - системи з архітектурою, яка перебудовується, або reconfigurable computing (RC).

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

Цифрова обробка сигналів. Високошвидкісна цифрова обробка сигналів традиційно проводилася за допомогою спеціально розроблених мікропроцесорів, так званих цифрових сигнальних процесорів (ЦСП) або digital signal processors (DSP). Однак сучасні ПЛІС містять вбудовані помножувачі, схеми арифметичного перенесення і великий обсяг оперативної пам'яті всередині кристалу. Все це в поєднанні з високим ступенем паралелізму ПЛІС забезпечує перевагу ПЛІС над найшвидшими сигнальними процесорами в 500 і більше разів.

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


.2 Проектування та зародження мови VHDL

.2.1 Переваги VHDL над схемним проектуванням

Проектування з використанням мови VHDL. Традиційно розробка електричних схем є одним з етапів проектування засобів обчислювальної техніки. Ця відповідальна робота пов'язана з великою трудоміскістю, правильним контролем та відповідністю задуманого проекту, необхідність чіткого і об’ємного опису створених схем, труднощами з їх супроводом і модернізацією. САПР обчислювальної техніки, як правило, мають засоби введення і редагування схем. Проте, два десятиліття тому при розробці НВІС стали відмовлятися від схемного проектування.

Мова Very high speed integrated circuits Hardware Description Language (VHDL) була розроблена в 1983 р. на замовлення Міністерства оборони США з метою формального опису логічних схем для всіх етапів розробки електронних систем. Вона є стандартною мовою з 1987 р. Стандартом 1993 р. закріплені багато її удосконаленнь. Поряд з мовою Verilog мова VHDL є базовою мовою при розробці апаратури сучасних обчислювальних систем.

Проектування великих обчислювальних пристроїв. За допомогою VHDL простіше і швидше ввести і перевірити великий проект. Десятьма рядками VHDL можна описати як 1, так і 100000 тригерів. Мікросхему з інтеграцією більше 10000 вентилів розробити тільки за допомогою електричних схем практично неможливо через громіздкість схем.

Проект на VHDL - об'єднання структури обчислювальних пристроїв і алгоритму його функціонування. Для обчислювальних пристроїв, описаних на VHDL, необов'язково виконувати перевірку правильності їх функціонування, наприклад, шляхом їх макетування. Щоб визначити, чи правильно обчислювальний пристрій виконує заданий алгоритм, достатньо його VHDL-програму запустити на виконання в симуляторі VHDL. Відповідні САПР перетворять VHDL-опис у комплект документації для виготовлення працездатного пристрою.

Проект на VHDL - самодокументованний, тобто він не вимагає додаткового технічного опису або подання у вигляді схем. Нечіткість і недбалість опису виключаються, так як проект на VHDL нескладно перевірити.

Висока надійність проекту. Синтаксичний аналіз, моделювання та компіляція в логічну схему швидко виявляють помилки проекту.

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

Проект на VHDL - портативний проект. Розроблений для однієї елементної бази, проект обчислювальних пристроїв без проблем переноситься на іншу елементну базу, наприклад, НВІСС з різною технологією.

Проект на VHDL - довгоіснуючий проект. Електрична схема завжди розробляється під конкретну елементну базу і інтерфейс. Так як елементна база змінюється через 2-5 років, за цей же період застарівають і електричні схеми, які використовують її. Проект обчислювальних пристроїв на VHDL може бути повторно використаний через кілька років. Гарне технічне рішення (наприклад, винахід), описане на VHDL, може мати великий попит протягом десятиліть.

VHDL - універсальний засіб опису обчислювальних пристроїв на рівнях:

алгоритмічному,

структурному,

регістровихпередач (RTL) і потоків даних (потік даних),

логічному,

аналогових схем.

Проектування з використанням VHDL. На рисунку 1.1 показана схема розробки проекту обчислювальних пристроїв, призначеного для виконання в базисіпрограмованих логічних інтегральних схем (ПЛІС).

Спочатку обчислювальний пристрій описується у вигляді своєї поведінкової моделі, на якій відпрацьовується задуманий алгоритм функціонування обчислювального пристрою. Потім ця модель вручну переробляється в синтезовану модель обчислювального пристрою, описану на рівні регістрових передач. Така модель, будучи странсформованою компілятором-синтезатором, дає проектну документацію в вигляді файлу опису схеми обчислювального пристрою на рівні вентилів (EDIF-файл). При цьому автоматично виконується логічна оптимізація обчислювального пристрою. Одночасно цей файл автоматично перетвориться в VHDL-модель обчислювального пристрою на рівні вентилів.

Рисунок 1.1 - Схема розробки проекту обчислювальних пристроїв для ПЛІС

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

Вартість помилок при проектуванні НВІС дуже висока, особливо на ранніх етапах. Тому всі етапи проектування - алгоритмічний, структурний, логічний, технологічний - супроводжуються моделюванням обчислювальних пристроїв за допомогою, так званого, випробувального стенду (testbench). Цей стенд являє собою VHDL-модель, складовими частинами якої є модель тестованого обчислювального пристрою і моделі генератора тестових сигналів і логічного аналізатора, перевіряючих правильність функціонування обчислювального пристрою. Причому на всіх етапах може використовуватись один випробувальний стенд і тіж самі тестові файли.

.2.2 Використання VHDL в сучасних САПР

Історично склалося, що в мікроелектронній індустрії найбільше поширення набула мова Verilog. Півтора десятиліття тому ця мова вигравала конкурентну боротьбу з іншими мовними завдання обчислювальних пристроїв, завдяки невеликим обчислювальним ресурсам, необхідним для колишніх робочих станцій і досить точним результатам моделювання НВІС. VHDL - більш універсальна і гнучка мова, але вона програє у швидкодії мові Verilog, особливо при моделюванні на рівні вентилів і транзисторів. VHDL набув широкого поширення в університетах і дослідницьких установах, тому що це строга, жорстка, універсальна і розширена мова. Так, наприклад, з'явилися пакети VHDL для аналогового моделювання, моделювання багатозначної логіки. Крім того, симулятори VHDL були набагато дешевші за симулятори Verilog.

Всі сучасні САПР мікроелектроніки мають компілятори як з Verilog, так і з VHDL. Програміст, що освоїв VHDL, без особливих зусиль може перейти до програмування на мові Verilog. Але програмісту, що знає Verilog, перейти до VHDL важче.

Найважливішими якостями VHDL в САПР виступають наступні поняття:

гнучкість - проект, описаний на VHDL, може бути легко налаштований під конкретні завдання споживача;

універсальна мова. VHDL - загальноприйнята мова для всіх основних фірм - виробників мікросхем ПЛІС, ПЛМ, замовлених НВІС, як стандартна мова для завдання складних проектів. Проектування з VHDL - стійка тенденція в інженерній технології. Існують компілятори, що транслюють VHDL-програми в еквівалентні їм Verilog-програми;

моделювання з урахуванням затримок. Фірми-виробники мікросхем у своїх САПР забезпечують генерацію моделей результатів розміщення і трасування, описаних на VHDL;

стандартне підключення блоків. Конструкції мови, такі entity, port map, configuration, забезпечують надійну і швидку стиковку блоків, розроблених різними фірмами і розробниками, у різному поєднанні;

стандартне тестування. На всіх етапах розробки виконується тестування за однією методикою одними і тими ж тестами;

VHDL - стандарт майбутнього. Всі нові САПР засновані на технології трансляції опису обчислювальних пристроїв на мові опису апаратури. Використання VHDL - гарантія того, що через 5 або 10 років знайдеться САПР, що підтримує старі розробки.

.2.3 Технологія розробки систем на кристалі

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

Рисунок 1.2 - Перехід від системи на платі до системи на кристалі

Таким чином, на одному кристалі розміщується не тільки конкретний функціональний пристрій, наприклад, центральний процесор, але й інші пристрої, такі як АЦП, ОЗП, ПЗП, блоки цифрової обробки сигналів, інтерфейсні вузли і т п., що доповнюють кристал до закінченої системи блоків. Тому такий обчислювальний пристрій прийнято називати системою на кристалі (SOC) - системою на кристалі (СНК).

СНК - це, як правило, замовна НВІС. Щоб розробка СНК себе окупила, необхідно реалізувати десятки і сотні тисяч НВІС. Проект обчислюваного пристрою, реалізований на ПЛІС, може бути вигідним при партіях, як в десятки, так і в десятки тисяч копій, завдяки дешевизні розробки та виробництва таких обчислювальних пристроїв. Розробка таких обчислювальних пристроїв триває, як мінімум, в 2 рази швидше, ніж проектування НВІС. Це зумовило бурхливий поширення ПЛІС в якості елементної бази СНК.

Найбільш трудомісткими і відповідальними етапами розробки СНК виступають етапи структурного проектування та верифікації відповідності обчислювального пристрою заданим алгоритмам функціонування. Тому ефективність САПР мікросхем і продуктивність разрабників, що виконують проектування на рівні регістрових передач, постійно зростає приблизно на 20% в рік. Але, починаючи з середини 90-х років, продуктивність розробників стала помітно відставати від зростання складності СНК (рисунок 1.3).

Рисунок 1.3 - Зростання продуктивності праці при розробці СНК

Першим напрямком поліпшення технології розробки СНК, орієнтованим на зменшення зазору між зростанням продуктивності проектування на рівні регістрових передач і ростом складності СНК, є застосування великих бібліотечних обчислювальних модулів (Intellectual Property Cores - ядер інтелектуальної власності). Ці модулі повинні бути надійно повторюваними і налаштованим під реалізоване завдання в ряді проектів СНК. Повторне застосування таких модулів (IP Core reuse), які можна назвати обчислювальними заготовками за їх функціональну та технологічну адаптованість, дозволяє зменшити трудовитрати і терміни проектування СНК.

Другий напрямок - це розробка САПР сучасного проектування апаратно-програмного забезпечення (Hardware - Software Codesign). Архітектура СНК, як правило, включає в себе мікропроцесорне ядро з периферійними пристроями в різному поєднанні. Зазвичай процес розробки обчислювальних пристроїв з такою архітектурою складається з трьох послідовних етапів: проектування електричної схеми апаратури, розробки матзабезпечення мікропроцесора і стикування матзабезпечення з апаратурою.

Для прискорення проектування розробляють САПР, яка не тільки служить для спільного виконання цих етапів, але і забезпечує моделювання роботи СНК і її верифікацію в комплексі.

Найбільше прискорення розробки СНК може дати впровадження САПР безпосереднього відображення алгоритмів в апаратуру, тобто САПР системного проектування. Наприклад, така САПР може включати в себе трансляцію програми з мови високого рівня, такої як C++, з автоматичним розділенням обчислювальних задач між мікропроцесорним ядром і спецпроцесором та іншими периферійними пристроями.

Для більш плавного переходу від алгоритму функціонування системи, описаного на мові C++, до апаратно-програмного опису все частіше застосовується мова System-C. Особливість цієї підмножини мови C++ в тому, що її функції мають взаємно однозначну відповідність з конструкціями мов VHDL і Verilog, що описують апаратуру.

.2.4 Обчислювальні заготовки

У великих фірмах, які багато років займаються розробкою НВІС, а тепер і СНК, напрацьовані великі бібліотеки стандартних модулів, таких як: ОЗП, АЛП, периферійні пристрої. У нових проектах СНК деякі блоки доводиться розробляти заново, а решта - зазвичай беруться з бібліотеки. При цьому, якщо модуль неясно описаний, не має зручного інтерфейсу, документації, коментарів, випробувального стенду з надійними тестами, то він повторно застосовуватися не буде.

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

Рисунок 1.4 - Заготовка з різними властивостями СНК. В залежності від налаштування, обчислювальна заготовка має різні властивості в СНК: структуру, інтерфейс, об’єм памяті, швидкодію

Обчислювальні заготовки розрізняються за ступенем гнучкості свого налаштування під умови споживача, таких як:

- гнучкі (описані мовою опису апаратури, такої, як VHDL, на рівні регістрових передач);

жорсткі (логічна схема, EDIF-файл);

- тверді (маски під певну технологію, прошивки ПЛІС).

Гнучкі заготовки зазвичай підлаштовуються до умов нового проекту в широких межах і незалежні від його технології (серія ПЛІС, технологія НВІС). Зазвичай в них задаються розрядність даних, обсяг пам'яті, таблиці констант, перелік периферійних пристроїв, іноді - швидкодія, яка пропорційна апаратурним витратам. Мінімізація апаратурних витрат обчислювальних заготовок забезпечує не тільки зменшення вартості СНК, але і мінімізацію його енергоспоживання, що є важливим фактором для портативних і енергонезалежних обчислювальних пристроїв, в яких застосовуються СНК.

Щоб проект обчислювального пристрою був прийнятий як гнучка обчислювальна заготовка, він повинен мати:

- повну і ясну документацію;

- текст опису на VHDL або Verilog в хорошому стилі для синтезу, заготівля повинна настроюватися під технічні умови споживача;

- хороші засоби верифікації у вигляді випробувальних стендів, вичерпних тестів, можливо, експериментальні макети;

- чітку методику того, як обчислювальний пристрій вставляти в СНК, що включає надійні скрипти (програми на макромові САПР, автоматизоване тестування та створення жорсткої або твердої заготовки).

В сьогоднішніх умовах, щоб швидше перейти від ідеї до "заліза", ефективніше провести проектуванн нової СНК, необхідно цю СНК "зібрати" з наявних обчислювальних заготовок, а відсутні заготовки - придбати на ринку IP-Core, який бурхливо розвивається в останні роки.

Якщо придбати не вдасться або якщо проект - дослідницький, то необхідну заготовку можна пошукати, наприклад, у банку безкоштовних IP-Core, що на сайті www.opencores.org <#"598875.files/image006.gif">

Рисунок 1.5 - Зв'язок між моделями та блоками в MatLab

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

Кожний блок Stateflow відповідає єдиній діаграмі Stateflow. Блок Stateflow зв'язується з моделлю Sіmulіnk за допомогою інтерфейсу. За допомогою інтерфейсу блок Stateflow підключається до джерел, що надходять від моделі Sіmulіnk (дані, події, код користувача).діаграми управляються подіями. Події можуть бути локальними для блоку Stateflow або можуть надходити до й від моделі Sіmulіnk і джерел коду, зовнішніх до Sіmulіnk. Дані також можуть бути локальними для блоку Stateflow або можуть надходити як до, так і від моделі Sіmulіnk і джерел коду, зовнішніх до Sіmulіnk.

Необхідно визначити інтерфейс для кожного блоку Stateflow. Визначення інтерфейсу для блоку Stateflow може включати деякі або всі приведені завданя:

-       визначення методу модифікації блоку Stateflow;

-       визначення Output to Sіmulіnk (Вихідних до Sіmulіnk) подій;

-       визначення звязків з будь-якими зовнішніми джерелами.

У розглянутому прикладі Sіmulіnk модель складається з Sіmulіnk блоку - джерела Sіne Wave (Синусоїда), Sіmulіnk блоку - приймача Scope (Осцилограф) і єдиного блоку Stateflow з назвою On_off (рис. 1.6).

Рисунок 1.6 - Зв'язок моделі Sіmulіnk з блоком Stateflow

Стан описує режим керованої подіями системи. Динамічні переходи станів від активності до неактивності базуються на подіях і умовах. Кожний стан має батька. У діаграмі Stateflow, що складаєтьяс з єдиного стану, батько стану - безпосередньо діаграма Stateflow (також називана коренем діаграми Stateflow). Можна розміщати стани в межах інших станів вищого рівня. На рисунку 1.8 Statea1 - нащадок в ієрархії стосовно Statea.

Далі приводиться приклад Stateflow діаграми, у якій використовуються основні графічні компоненти (рисунок 1.7). Крім того, детально описуються ці графічні компоненти, а також деякі неграфічні об'єкти й зв'язки між ними.

Рисунок 1.7 - Stateflow діаграма з використанням основних компонентів

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

Стани мають мітки, які можуть визначити дії, виконані в послідовності, заснованої на типі дії. Типи дії - entry (на вході), durіng (протягом ), exіt (на виході) і on event_name (у випадку події з іменем _).

У прикладі автоматичної передачі, передача може бути в нейтральному положенні або включена в роботу. На рис. 1.9 показані два стани цієї системи - neutral (нейтраль) і engaged (включена).

Рисунок 1.9 - Зображення стану автоматичної передачі

забезпечує два типи станів: паралельний (І) і винятковий (АБО) тип стану. Паралелізм представлений І (паралельними) станами. Автоматична передача - приклад виняткового (АБО) стану. Виняткові (АБО) стани використовуються, щоб описати режими, які є взаємовиключними. Система перебуває або в нейтральному стані, або у включеному стані в кожний момент часу.

Перехід - графічний об'єкт, який у більшості випадків зв'язує один об'єкт із іншим. Один кінець переходу прикладений до об'єкта- джерела, а інший кінець - до адресата. Джерело - це місце, де перехід починається, а адресат - це місце, де перехід закінчуються. Мітки переходів описують обставини, під дією яких система переходить із одного стану до іншого. Ці обставини - це настання деяких подій, які змушують перехід відбуватися. На рисуноку 1.8 перехід від Statea1 до Statea2 позначений подією transіtіona1_A2, яка змушує перехід відбутися.

Розглянемо знову автоматичну передачу (рисунок 1.10). Clutch_engaged (включення передачі) - подія, яка потрібна, щоб здійснити перехід з нейтрального положення в стан "включене".

Рисунок 1.10 - Зв'язок між станами в автоматичній передачі

Події керують виконанням діаграми Stateflow, але є неграфічними об'єктами й у такий спосіб не представлені безпосередньо в діаграмі Stateflow. Усі події, які мають відношення до діаграми Stateflow, повинні бути визначені. Настання події змушує статус стану (активно - неактивно) у діаграмі Stateflow змінюватися. Настання події може запускати перехід, і тоді він відбувається, або може запускати дії, і тоді вони виконується. Події наступають спадної, починаючи від батька подій в ієрархії.

Події створюються й змінюються за допомогою Stateflow Explorer (Stateflow провідника). Події можуть бути створені на будь-якому рівні ієрархії. Подія має таку властивість, як видимість. Видимість визначає, чи є подія:

-       локальною для діаграми Stateflow;

-       входить в Stateflow діаграму від моделі Sіmulіnk;

-       виходить із Stateflow діаграми в модель Sіmulіnk;

-       експортується в код, зовнішній до Stateflow діаграми й моделі Sіmulіnk;

-       імпортується із джерела коду, зовнішнього до Stateflow і Sіmulіnk.

Дані (Data). Об'єкти-Дані використовуються, щоб зберігати числові значення для застосування в діаграмі Stateflow. Вони є неграфічними об'єктами й у такий спосіб не представлені безпосередньо в діаграмі Stateflow.

Дані створюються й змінюються в Stateflow Explorer. Вони можуть бути створені на будь-якому рівні ієрархії. Дані мають таку властивість, як видимість. Видимість визначає для об'єктів-даних одну з наступних можливостей:

-       бути локальними для діаграми Stateflow;

-       надходити в Stateflow діаграму від моделі Sіmulіnk;

-       виходити з Stateflow діаграми в модель Sіmulіnk;

-       бути часовими даними;

-       бути певними в робочому просторі MATLAB;

-       бути Константами;

-       експортуватися в код, зовнішній до Stateflow діаграми й моделі Sіmulіnk;

-       імпортуватися із джерела коду, зовнішнього до Stateflow і Sіmulіnk.

Ієрархія дає можливість організувати складні системи, визначаючи предка й структуру об'єктів-нащадків. Ієрархічно побудований проект звичайно скорочує число переходів і приводить до чітких, зрозумілих діаграм. Stateflow підтримує ієрархічну організацію як для діаграм, так і для станів. Діаграми можуть існувати усередині інших діаграм. Діаграма, яка існує в іншій діаграмі, називається піддіаграмою.

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

Рисунок 1.11 - Діаграма Stateflow, яка містить суперстан та два підстани

Суперстан engaged (передача включена) містить підстани fіrst (перша передача) і second (друга передача). Суперстан engaged - предок в ієрархії стосовно станів fіrst і second. Коли подія clutch_engaged відбувається, система переходить із нейтрального стану до суперстану "включене". Переходи усередині суперстану навмисно опущені в цьому прикладі для простоти.

Вихід зі стану вищого рівня або суперстану також має на увазі вихід з будь-яких активних передстанів цього суперстану. Переходи можуть перетинати границі суперстану, щоб досягтися підстану-адресата. Якщо підстан активний, його батьківський стан (суперстан) також активний.

Умова - булевий вираз, який визначає, що перехід відбувається, якщо зазначений вираз є дійсним. На рисунку 1.12 компонент Stateflow діаграми [condіtіon1] представляє булевий вираз, який повинен бути дійсним, щоб перехід відбувся.

В автоматичній коробці передач перехід з першої швидкості до другої відбувається, якщо булева умова [speed > threshold] ([швидкість > граничне_значення]) дійсна.

Рисунок 1.12 - Діаграма Stateflow з представленням булевого виразу

Хронологія - засіб для визначення підстану-адресата переходу по передісторії. Якщо суперстан з винятковою (АБО) декомпозицією має хронологічне з'єднання, підстаном-адресатом при переході буде підстаном, відвідне до цього останнім. Хронологічне з'єднання застосовується до того рівня ієрархії, у якому є присутнім. Хронологічне з'єднання скасовує будь-які переходи за замовчуванням. На рисунку 1.13 хронологічне з'єднання в Statea1 указує, що, коли перехід до Statea1 відбувається, стає активним той з підстанів (Statea1a, Statea1b або Statea1c), який буде активним в останню чергу.

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

Рисунок 1.13 - Діаграма Stateflow з представленням хронології в автоматичній передачі

Дія - це результат виконання якої-небудь частини діаграми Stateflow. Дія може бути виконана в результаті переходу від одного стану до іншого. Дія може бути також реакцією на стан. На рисунку 14 сегмент переходу від Statea1b до з'єднання позначений дією func1() умови condіtіon 1, а сегмент переходу від з'єднання до Statea1c позначений дією func2() переходу. Семантика дій буде розглянута пізніше.

Перехід, що закінчується в стані, може мати дію умови (condіtіon actіon) і дію переходу (transіtіon actіon), як розглянуто нижче (рисунок - 14). Однак переходи, які закінчуються в з'єднаннях, можуть мати тільки дії умов (не допускаються дії переходів).

Рисунок 1.14 - Зображення переходу який закінчується в стані Power_off

Стани можуть мати дії have entry (на вході), durіng (протягом ), exіt (на виході) і on event_name (у випадку події з іменем _ ). Наприклад, як зображено на рисунку 1.15.

Рисунок 1.15 - Зображення стану Power_on, який має дії: entry, durіng, exіt та on Swich_off.

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

Система з паралелізмом має два або більше станів, які можуть бути активні одночасно. Дії кожного паралельного стану по суті незалежні від інших станів. На рисунку 1.16, Statea2a і Statea2b - паралельні (І) стану. Statea2 має паралельну (І) декомпозицію стану.

Наприклад, дана діаграма Stateflow має паралельну декомпозицію суперстанів (рисунок 1.16).

Рисунок 1.16 - Діаграма Stateflow з паралельною декомпозицією суперстанів

Передача (Transmіssіon), обігрів (Heat) і освітлювальні прилади (Lіghts) - це паралельні підсистеми в автомобілі. Вони існують паралельно й фізично незалежні від один одного. Є багато інших паралельних компонентів в автомобілі, наприклад підсистема гальмування й підсистема очищення вітрового скла.

Ви представляєте паралелізм в Stateflow, задаючи паралельну (І) декомпозицію. Паралельні (І) стани відображені обведеними штриховою лінією областями.

Стандартні переходи визначають, яке з декількох виняткових (АБО) станів повинне бути активним, коли є невизначеність між двома або більш винятковими (АБО) станами на одному рівні в ієрархії.

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

У наступній підсистемі Lіghts (Освітлювальні прилади) стандартний перехід до підстану Lіghts (рисунок 1.17). Off (Освітлювальні прилади виключені) указує, що, коли суперстан Lіghts стає активним, Lіghts.Off підстан стає активним за стандартом.

Рисунок 1.17 -Діаграма Stateflow із зображенням стандартного переходу

Потрібно враховувати що хронологічні з'єднання скасовують переходи за замовчуванням у суперстанах з винятковими (АБО) декомпозиціями.

Треба звернути увагу, що у паралельних (І) станах стандартні переходи завжди повинні бути присутнім, щоб указати, які з його виняткових (АБО) станів активні, коли паралельний стан стає активним.

Наступний приклад показує, як з'єднання (відображувані у вигляді окружностей) використовуються для конструкції іf (рисунок 1.17).

Рисунок 1.18 - Діаграма Stateflow та зображення зєднань

Цей фрагмент виконується в такий спосіб:

якщо умова [с1] вірна, умовна дія а1 виконується й відбувається безумовний перехід до першого (верхнього) з'єднання;

Stateflow визначає, який сегмент переходу верхнього з'єднання вибрати (можна вибрати тільки один). З'єднання з умовами мають пріоритет над з'єднаннями без умов, таким чином перехід з умовою [с2] розглядається першим;

якщо умова [с2] істинна, дія а2 виконується й відбувається перехід до нижнього з'єднання. Тому що немає переходу, що виходить із цього з'єднання, виконання діаграми завершене;

якщо умова [с2] неправильна, відбувається безумовний переходу по правому із сегментів (він не має умови);

якщо умова [с3] істинна, умовна дія а3 виконується й відбувається перехід до нижнього з'єднання.Виконання діаграми завершене;

якщо умова [с3] неправильна, виконання закінчується на середньому з'єднанні.

.4 Проектування в середовищі QUARTUS II (Altera)

1.4.1 Схеми розробки програмного забезпечення

Програмне забезпечення Altera Quartus II надає повне медіаплатформове середовище проектування, яке може бути легко переналаштоване під конкретні вимоги. Це ідеальне середовище для проектування на основі ПЛІС закінчених систем на кристалі (SOPS). Програмне забезпечення Quartus II включає в себе засоби для всіх фаз проектування із застосуванням ПЛІС як FPGA, так і CPLD структур. Взаємозв'язок систем середовища проектування показаний на рисунку 1.19.

Можливий варіант процедури проектування, реалізація якого доступна з застосуванням середовища Quartus II Web Edition Software Version 4.2, представлений на рисунку 1.20.

Реалізація даної процедури припускає використання або стратегії висхідного, або спадного проектування.

І та і інша стратегії мають на увазі використання поведінкових і структурних описів модулів. При структурному описі модуль представляється у вигляді сукупності взаємопов'язаних компонентів більш низького рівня в ієрархії описів. При поведінковому ж описі задається алгоритм роботи модуля.


Рисунок 1.19 - Взаємозв'язок систем середовища проектування

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

Рисунок 1.20 - Проектування в середовищі Quartus II Web Edition Software Version 4.2

.4.2 Поняття проекту

Під терміном «проект» у рамках пакета Quartus II розумієть набір файлів, пов'язаних з проектованим модулем, в якому виділяються дві групи файлів:

логічні файли, що описують алгоритм роботи пристрою (Design Files);

допоміжні файли (Ancilary Files).

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

файл верхнього рівня в ієрархії описів (Top-level Design File);

файли нижніх (одного або декількох) рівнів ієрархії (Low-level Design files).

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

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

.4.3 Стратегія проектування

Проектування в Quartus II дозволяє реалізувати або стратегії висхідного, або спадного проектування.

І та і інша стратегії мають на увазі використання поведінкових і структурних описів модулів. При структурному описі модуль представляється у вигляді сукупності взаємопов'язаних компонентів більш низького рівня в ієрархії описів. При поведінковому ж описі задається алгоритм роботи модуля.

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

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

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

Таким чином, в процесі проектування розробник опускається з верхнього рівня ієрархії описів, рівня НВІС, до нижніх рівнів. Звідси і назва стратегії проектування.

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

.4.4 Процес моделювання

Моделювання (Simulation) дозволяє визначити реакцію розробленого проекту на задану вхідну дію, тобто дозволяє переконатися в правильності його функціонування.

Вихідними даними для моделювання є зовнішні впливи, задані у вигляді деякого вхідного вектора (набору кодових слів). Підсистема моделювання (Simulator) пакета Quartus II, у відповідність з алгоритмом проекту, синтезує вихідні сигнали, відповідні його реакції на заданий вхідний вплив, яка дуже близька до реакції запрограмованої ПЛІС. У типових завданнях розробник задає набори вхідних векторів і аналізує отримані в результаті моделювання вихідні сигнали.

Залежно від поставленої мети підсистема моделювання дозволяє виконати:

функціональне моделювання проекту (Functional Simulation) при якому перевіряється правильність опису і логічного функціонування проекту;

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

.4.5 Створення вектора вхідних впливів та файлу *. vwf

Файли вектора вхідних впливів в системі Quartus II можуть задаватися у вигляді:

опису в графічній формі (деяких часових діаграм) з використанням редактора часових діаграм (Waveform Editor) - файли *. vwf (Vector Waveform Files);

- опису у текстовому вигляді за допомогою векторних файлів (Vector File) - файли *. vec.

Створення файлу (*. vwf), що містить часові діаграми, виконується в наступній послідовності:

- в меню «Файл» (File) вибирається команда «Новий» (New);

у вікні, «Новий» (New) вибрати закладку «Інші файли» (Other Files) в якій виділити рядок «Файл вектора часових діаграм» (Vector Waveform Files) і натиснути кнопку «ОК»;

відкривається порожнє вікно редактора часових діаграм з іменем за умовчанням Waveform1.wvf;

у вікні «Редагувати» (Edit) вибрати команду «Час закінчення» (End Time) і у вікні, вказати час закінчення моделювання (тривалість інтервалу моделювання та одиницю виміру часу). Натиснути «ОК»;

- створений файл необхідно зберегти, використовуючи команду «Записати як» (Save As) меню «Файл» (File). Програма автоматично запропонує зберегти файл з ім'ям, що збігається з ім'ям файлу верхнього рівня проекту, присвоївши йому розширення. vwf;

- для завершення процесу створення файлу необхідно натиснути кнопку «Зберегти» (Save). При цьому необхідно звернути увагу на наявність прапорця біля напису «Додати файл до поточного проекту» (Add file to current project). Якщо прапорець поставлений, то система автоматично вмонтовує створений файл до поточного проекту;

- для зручності, на полі тчасових діаграм нанесена часова сітка, призначена для візуальної прив'язки сигналів до конкретних часових інтервалів. Використовуючи команду «Крок сітки» (Grid Size) меню «Редагувати» (Edit), можна змінити її крок (період) повторення (Period), початкову фазу (Phase) і відносну тривалість кожного з півперіодів (Duty cycle).

.4.6 Додавання вхідних, вихідних і проміжних сигналів

Далі в створений файл необхідно ввести вхідні і вихідні сигнали, присутні в проекті. Для цього необхідно:

у вікні «Редагувати» (Edit) вибрати рядок «Вставити вузол або шину» (Insert Node or Bas);

у вікні, що з назвою «Вставити вузол або шину» (Insert Node or Bas), натиснути кнопку «Система пошуку вузлів» (Node Finder);

відкривається вікно системи пошуку вузлів проекту (Node Finder), що дозволяє ввести в файл часових діаграм вузли поточного проекту. У вікні «Шукати у» (Lock in) повинно бути вказано ім'я верхнього файлу проекту, або файлу, моделювання якого треба виконати. У вікні «Система пошуку» (Fitter) необхідно вказати які виводи необхідно шукати. Якщо необхідно вставити в файл часових діаграм всі вузли проекту, в цьому вікні необхідно вибрати команду «Виводи всі» (Pins: fll).

для відображення обумовлених умовами пошуку виводів необхідно натиснути кнопку «Список» (List);

в лівій частині вікна під заголовком «Знайдені вузли проекту» (Nodes Found) з'являється список знайдених вузлів проекту;

для того щоб знайдені вузли були введені в файл часових діаграм, їх необхідно перемістити в праве підвікно з ім'ям «Вибрані вузли» (Selected Nodes). Цій меті служать розташовані в підвікні «Знайдені вузли проекту» (Nodes Found) та «Вибрані вузли» (Selected Nodes) кнопки, що виконують такі функції:

-       перемістити виділений вузол з підвікна «Знайдені вузли проекту» (Nodes Found) в підвікно «Вибрані вузли» (Selected Nodes);

-       перемістити всі вузли з підвікна «Знайдені вузли проекту» (Nodes Found) в підвікно «Вибрані вузли» (Selected Nodes);

-       перемістити виділений вузол з підвікна «Вибрані вузли» (Selected Nodes); в підвікно «Знайдені вузли проекту» (Nodes Found);

-       перемістити всі вузли з підвікна «Вибрані вузли» (Selected Nodes в підвікно) «Знайдені вузли проекту» (Nodes Found);

після переміщення в праве підвікно всіх необхідних при моделюванні вузлів необхідно натиснути кнопку «ОК». З'являється вікно «Вставити вузол або шину» (Insert Node or Bas), в якому теж необхідно натиснути кнопку «ОК».

Після цього в файлі часових діаграм проекту з'являються осі для всіх вищевказаних сигналів:

на часових діаграмах присутня вертикальна лінія часового маркера, який зображений у вигляді суцільної кольорової лінії. Положення цього маркера можна змінювати, використовуючи курсор. Значення сигналів, відповідне поточному положенню курсору, відображається в стовпці з ім'ям «Значення в ХХ момент часу» (Value at XX), де XX - час, відповідний поточному положенню маркерною лінії. Якщо на часових діаграмах необхідно відзначити деякі базові моменти часу, це можна зробити, використовуючи команду «Ввести часову мітку» (Insert Time Bar) в меню «Редагувати» (Edit). Відкривається вікно «Ввести часову мітку» (Insert Time Bar) в даному вікні необхідно вибрати час, відповідний базовому моменту часу та одиницю його виміру. Після натискання кнопки «ОК» пунктирна лінія, відповідна введеному часу, з'явиться на часових діаграмах. Тепер при переміщенні маркерною лінією над нею буде відображатися поточний час моделювання, а над лініями базових моментів часу, їх відстань (тривалість часового інтервалу) від маркерною лінії;

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

-       видалити лінію часу (Delete);

-       використовувати дану лінію як маркерну (Make Master Time Bar);

-       ввести лінію часу (Insert Time Bar);

-       викликати вікно органайзера часових ліній (Time Bar Organizer), що дозволяє перепризначувати основні параметри ліній часу.

-       виконати масштабування часових діаграм (Zoom).

Розглянута методика дозволяє ввести в файл часових діаграм будь-яку кількість використовуваних при моделюванні проекту вхідних і вихідних сигналів.

Використовуючи вікно «Вставити вузол або шину» (Insert Node or Bas) можна довільно ввести в файл часових діаграм потрібні сигнали. Для цього досить у графі «Ім'я» (Name) ввести назву необхідного сигналу, а в наступних рядках визначити його основні параметри.

.4.7 Визначення параметрів моделювання

Система Quartus II дозволяє виконати моделювання, як усього проекту, так і його будь-якої складової частини. Типові стандартні параметри задаються системою моделювання автоматично при створенні нового проекту. При необхідності, ці параметри можна відредагувати. Для цього служить вікно «Властивості системи моделювання» (Simulator Tool), що викликається з розділу «Властивості» (Tools) головною командного рядка системи.

Дане вікно дозволяє визначити наступні параметри моделювання проекту:

• вибрати тип моделювання проекту (Simulation mode) - функціональне (Functional) або те, що враховує часові параметри вибраного типу ПЛІС (Timing)

• вибрати ім'я файлу, що містить вектор вхідного впливу для моделювання (Simulation Input). За замовчуванням, це ім'я файлу верхнього рівня проекту. При необхідності, ім'я необхідного файла можна знайти, використовуючи кнопку в правій частині вікна імені;

• розділ «Область моделювання» (Simulation Period) дозволяє задати моделювання або на всьому заданому інтервалі (Run simulation until all vector stimuli are used), або задати час закінчення моделювання, що не співпадає з часом, визначеному у файлі часових діаграм (End simulation at ...) . В останньому випадку задаються значення часу закінчення моделювання та одиниця його виміру;

• розділ «Варіанти вибору умов моделювання» (Simulation options) дозволяє визначити:

функцію (режим) автоматичного додавання до часових діаграм вихідних виводів проекту (Automatically add pins to simulation output waveform);

режим перевірки виходів (Check outputs);

режим перезапису вихідного файлу моделювання з урахуванням результатів його виконання (Overwrite simulations input file with simulations results) Якщо цей режим не заданий, то файл вхідних впливів зберігається незмінним, тобто одночасно існує і вихідний файл і файл з результатами моделювання;

режим генерації файлу активних сигналів (Generate signal activity file). У цьому випадку створюється файл - «Ім'я проекту. saf »Signal Activity Files. Це текстовий файл у форматі ASСII, що містить інформацію про частоті перемикання і дані про статичної ймовірності для проекту. Цей файл використовується при аналізі енергетичних характеристик проекти модулем PowerPlay Power Analysis системи.

.4.8 Моделювання проекту

Запустити процес моделювання проекту можна двома різними способами:

• в меню «Обробка» (Processing) викликати команду «Запуск моделювання» (Start Simulation);

• в меню «Властивості» (Tools) викликати команду «Властивості системи моделювання» (Simulation Tolls) і у вікні натиснути кнопку «Пуск» (Start).

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

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

При другому методі запуску для отримання необхідних часових діаграм необхідно натиснути кнопку «Відкрити» (Open).

Слід пам'ятати, що послідовність дій, виконувана при запуску процесу моделювання, залежить від її вихідних установок. Якщо виконується функціональне моделювання, та перед запуском системи моделювання необхідно створити список з'єднань проекту. Для цього у вікні «Властивості системи моделювання» (Simulation Tools) необхідно натиснути кнопку «Створити файл зі списком з'єднань для функціонального моделювання» (Generate Functional Simulations Netlist). Після його створення запускається система моделювання. Якщо виконується моделювання з урахуванням часових параметрів обраної ПЛІС, створення файлу зі списком з'єднань не вимагається і відразу запускається система моделювання.

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

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

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

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

Доступні операції копіювання, видалення, створення груп сигналів і т.д.

.4.9 Створення вихідних умов для проектування та використання редактора призначень

Після того, як створені проект і схема пристрою, для завдання її початкових параметрів, таких як призначення контактів, опції пристрою, логіки і часових параметрів, можна використовувати реалізовані в Quartus II вікна «Установок» (Settings) (меню Assignments), «Редактора призначень »(Assignment Editor) і «Редактора загальної топології структури» (Floorplan Editor). При необхідності можна імпортувати необхідні параметри за допомогою команди Import Assignment (меню Assignment) або експортувати їх командою Export (пункт меню File). Також можна імпортувати параметри з EDA synthesis tool, використовуючи Tcl команди або сценарії. ПО Quartus II забезпечений вбудованим помічником - Timing Wizard (меню Assignment), що вказує початкові часові параметри схеми. Багато параметрів доступні через команду Assign у швидкому меню MAX + PLUS II можуть бути також виконані за допомогою Assignment Editor і вікна Settings.

Редактор призначень (Assignment Editor) - це інтерфейс, призначений для завдання вимог до розроблюваного пристрою на рівні проекту в цілому. Він дозволяє попередньо обумовити такі вимоги до пристрою, як вимоги до його розміщення на кристалі ПЛІС, стандарту використовуваного введення-виведення інформації, часовим параметрам, логічним опціям (logic option), параметрами моделювання (симуляції), а так само виконати попереднє призначення контактів ПЛІС. У загальному випадку вікно редактора складається з п'яти закладок. Перша (Category) дозволяє вибрати параметр, зміна або завдання якого необхідно зробити. Друга - «Майстер призначення вузлів» (Node Fitter) дозволяє задати нові вузли в схемі, призначені, як правило, для перевірки її параметрів або працездатності. Третя частина вікна (Information) призначена для видачі довідкової інформації по вибраній категорії параметрів пристрою. Четверта частина призначена для редагування параметрів (Edit). У п'ятій частині відображені самі вибрані параметри пристрою.

При бажанні будь-яка з перерахованих закладок схеми може бути закрита або знову відкрита з використанням керуючих кнопок, розташованих в лівій частині вікна проекту.

Загальна методика роботи з вікном редактора призначень заключається в наступному:

. Відкрити Assignment Editor.

. Вибрати необхідну категорію в закладці Category.

. Вказати відповідний вузол або блок в закладці Node Filter або використовувати Node Finder для пошуку необхідного вузла або об'єкта.

. У таблиці, яка відображає поточні призначення для схеми додати нову або змінити існуючу інформацію про призначеннях.

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

Якщо перед виконанням компіляції виводи ПЛІС, на які необхідно вивести вхідні і вихідні сигнали, не булиі задані, компілятор автоматично виконує відповідні призначення. Ці призначення можна подивитися у звіті компілятора. Доступ до цих даних можливий по ланцюжку Tools → Compiler Tool → кнопка Fitter Report в закладці Fitter і далі по тексту звіту до розділів вхідні (Input Pins) і вихідні (Output Pins) виводи. До цих же данних приводить ланцюжок: Tools → Compiler Tool → Report → Fitter → Resource Section і далі розділи Input Pins, Output Pins або All Package Pins.

2. СИНТЕЗ СИНХРОННОГО КІНЦЕВОГО АВТОМАТА

.1 Створення графа станів для синхронного кінцевого автомата

Створення графа станів для синхронного кінцевого автомата, реалізується на основі його алгориму функціонування.

Автомат має входи init та а, а також вихід z. Щоб вихід z дорівнював 0, потрібно на вхід init подати 1. Щоб вихід z дорівнював 1, потрібно щоб виконувалась умова: на вхід а повинні подаватись два послідовні такти (тобто, два незмінні такти а = 0 або два незмінні такти а = 1). Одиниця на вихід z, буде зберігатись до тих пір, поки на вхід init подається 0.

Рисунок 2.1 - Граф станів синхронного кінцевого автомата

2.2 Одержання VHDL коду в середовищі Quartus

ieee;ieee.std_logic_1164.all;synchr_avt is(clock, init, a : in std_logic;: out std_logic);synchr_avt;synchr_avt_arch of synchr_avt isstate_values is (st1, st2, st3, st4, st5, st6, st7, st8);pres_state, next_state : state_values;: process (clock)(clock = '1') then_state <= next_state;if;process statereg;: process (pres_state, init, a)pres_state isst1 =>init is'0' => next_state <= st2;a is'0' => next_state <= st2;

behave of mealy isstate_values is (st0, st1, st2, st3, st4);pres_state, next_state: state_values;: process (clock, reset)(reset = '0') then_state <= st0;(clock'event and clock = '1') then_state <= next_state;if;process statereg;: process (pres_state, data_in)pres_state isst0 =>data_in is"00" => next_state <= st0;"01" => next_state <= st4;"10" => next_state <= st1;"11" => next_state <= st2;others => next_state <= st0;case;st1 =>data_in is"00" => next_state <= st0;"10" => next_state <= st2;others => next_state <= st1case;st2 =>data_in is"00" => next_state <= st1;"01" => next_state <= st1;"10" => next_state <= st3;"11" => next_state <= st3;others => next_state <= st0;case;st3 =>data_in is"01" => next_state <= st4;"11" => next_state <= st4;others => next_state <= st3;case;st4 =>data_in is"11" => next_state <= st4;others => next_state <= st0;case;others => next_state <= st0;case;process fms;: process (pres_state, data_in) -- Процесс Quartus

ВИСНОВКИ

На даному етапі синтезу синхронного кінцевого автомата, зібрана в повному обсязі необхідна кількість інформації про методику програмування ПЛІС. Зібрана необхідна кількість інформації для отримання VHDL-коду, синхронного кінцевого автомата за допомогою програмних засобів.

Використовуючи HDL Coder, інженери та конструктори можуть провести більше часу при налаштуванні алгоритмів і моделей через швидкодіюче макетування й експериментування, і менше часу на безпосереднє написання HDL коду.

Коли модель задовольняє поставленим вимогам, Coder проводить перевірку сумісності описаної моделі і HDL коду. Після перевірки Coder генерує код опису пристрою в VHDL або Verilog.

За допомогою HDL Coder в програмному середовищі Quartus згенеровано VHDL-код, який був отриманий на основі описання моделі синхронного кінцевого автомата.

ПЕРЕЛІК ПОСИЛАНЬ

1. Гусев, В.Г. Электроника и микропроцесорная техника [Текст] / Ю.М. Гусев - М.: Высш. школа, 2005. - 790 с.: ил.

. Денисенко, Е.Л. Иерархический синтез асинхронных автоматов на программируемых логических интегральных схемах (ПЛИС) с учетом ограничений [Текст] / М.: УсИМ, 1997. - 476 стр.

3. Закревский, А.Д. Логический синтез каскадных схем [Текст] / М.: Наука, 1981. - 416 стр.

. Миловзоров, В.П. Электромагнитные устройства автоматики: Учебник для вузов. - 4-е узд., перераб. и доп. [Текст] / М.: Высш. школа, 1983. - 408 с., ил.

. Потемкин, И.С. Функциональные узлы цифровой автоматики [Текст] / М.: Энергоавтомиздат, 1988. - 230 с.

. Соловьев, В.В. Методы синтеза произвольной логики на программируемых логических устройствах [Текст] / Д. И. Самаль - М.: Автоматика и вычислительная техника, 1997. 561 стр.

. Токхейм, Р.Б. Основы цифровой электроники [Текст] / М.: Мир, 1988. - 392 стр.

. Шило, В.Г. Популярные цифровые микросхемы: Справочник.- 2-е изд. [Текст] / М.: Радио и связь, 1989. - 352 с.

Похожие работы на - Дослідження методів і алгоритмів синтезу синхронних кінцевих автоматів

 

Не нашел материал для своей работы?
Поможем написать качественную работу
Без плагиата!