Синтез схеми ПЛІС для інвертора

30

МІНІСТЕРСТВО ОСВІТИ ТА НАУКИ УКРАЇНИ

ІНСТИТУТ ПІДПРИЄМНИЦТВА ТА ПЕРСПЕКТИВНИХ ТЕХНОЛОГІЙ ПРИ НАЦІОНАЛЬНОМУ УНІВЕРСИТЕТІ

“ЛЬВІВСЬКА ПОЛІТЕХНІКА”

Курсова робота

з курсу “Проектування комп'ютерних систем та мереж”

Тема: “Синтез схеми ПЛІС для інвертора.”

1. ВИХІДНІ ДАНІ НА ПРОЕКТУВАННЯ

Загальні вимоги

Скласти, імлементувати і верифікувати VHDL модель чотирибітового комп'ютера, що вбудовується до ПЛІС і містить процесор і пам'ять (пам'яті) даних і машинних кодів. Цільову ПЛІС вибирати з матриць Віртекс або Спартан фірми Ксайлінкс (www.xilinx.com). САПР розробки - САПР Ксайлінкс WebPack 8.2i з вбудованим симулятором ПЛІС проектів (www.xilinx.com).

За основу архітектури процесора рівня машинних інструкцій прийняти архітектуру процесора Gnome фірми Xess (www.xess.com) [1, стор. 253]. Результати курсового проектування верифікувати методом часового симулювання. Розробити принципову схему апаратного емулятора, що містить відповідну проекту цільову ПЛІС.

Індивідуальні вимоги

До індивідуальних вимог належать:

1)тип архітектури (принстонська/гарвардьська);

2)множина машинних інструкцій);

3)вид пам'яті (зовнішня/вбудована до ПЛІС, а коли вбудована, тоді розподілена/зблокована);

4)тип шин (однонаправлені, двонаправлені, суміш);

5)тип цільової ПЛІС;

6)функція тестової програми (додавання, віднімання, множення, ділення тощо),

7)принципова схема апаратного емулятора.

Зауваження

1.Студент погоджує проектні індивідуальні вимоги з керівником. При цьому керівник проекту має право змінювати вихідні дані на проектування.

2.Проект має статус диференційованого заліку (стобальна семестрова оцінка) і захищається на комісії (до завершення залікової сесії).

3.Розмір дистрибутиву безкоштовної САПР Xilinx WebPack 8.2i (ОС Win2000/WinXP) складає 1 ГБ, а розмір її інсталяції на жорсткому диску - 2.4 ГБ. Ще потрібна інсталяція безкоштовного пакету Adobe Reader версії від 6.0, аби використовувати такі підсистеми САПР, як допомогу, генератор ядер тощо.

4.Дистрибутивні пакети САПР і документи щодо ПЛІС фірми Ксайлінкс одержують (на флеш-диск) на кафедрі КСТ ІППТ. Для ранішних версії 4.х-6.х САПР WebPack (плюс окремий симулятор ModelSim) потрібно отримати на сайтах www.model.com або www.xilinx.com безкоштовну студентську ліцензію на симулятор.

2. ВИМОГИ ДО ПРОЕКТНОЇ ДОКУМЕНТАЦІЇ

До складу розроблюваних проектних документів належать:

1.Пояснювальна записка.

2.Прототипна плата, схема принципова (одне креслення, формат креслення вибирає студент).

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

1.Титульна сторінка.

2.Вихідні дані на проектування і їхній аналіз (1 стор.)

3.Розробка архітектури рівня машинних інструкцій (1 стор.)

4.Синтез програмної моделі комп'ютера (1 стор.)

5.Розробка тестової програми (2 стор.)

6.Розробка VHDL моделі процесора (до 4 сторінок для VHDL моделі процесора і пояснень)

7.Розробка VHDL моделі пам'яті програм (2 сторінок для VHDL модель програмної пам'яті і пояснень).

8.Розробка VHDL моделі пам'яті даних (1 сторінка для VHDL модель пам'яті даних і пояснень).

9.Розробка VHDL моделі комп'ютера (до 3 сторінок для топ-файлу проекту і пояснень щодо нього).

10.Обгрунтування вибору цільової ПЛІС (1 стор.).

11.Синтез і імплементування VHDL моделі комп'ютера (до 4 стор.).

12.Верифікація результатів проектування методом часової симуляції (до 2 стор.).

13.Розробка принципової схеми емулятора (до 2 стор.).

14.Основні результати роботи (три пункти, 1 стор.).

15.Посилання на науково-технічні літературні джерела і на пошук в Інтернеті (1 стор.).

3.МЕТОДИЧНІ ВКАЗІВКИ

Проект виконують за два етапи. На першому етапі повторюють поданий нижче стандартний варіант проекту, аби набути відповідних знань і досвіду з практики проектування. Головне на цьому етапі - уяснити зміст, стиль і деталі виконання проектних робіт. Наступним етапом до стандартного проекту вносять зміни, що відповідають індивідуальним вихідним даним. Після синтезу і імплементування модифікованого проекту розроблюють принципову схему прототипної плати (емулятора) і оформлюють пояснювальну записку. Як аналог проекту емулятора використовують прототипні плати фірми Xess (www.xess.com). Знайдений аналог перетворюють на цільовий емулятор переважно скороченням надлишкових (з погляду проектних вимог) елементів.

Далі подамо мінімальні за розміром взірці виконання окремих розділів базового варіанту проекту. Зауважимо, що пряме користування джерелом [1] не є обов'язковим через те, що подані нижче методичні вказівки основані на [1].

Програмна модель комп'ютера

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

-найбільш значна тетрада (MSN) розташована ліворуч;

-найменш значна тетрада (LSN) розташована праворуч.

Нумерація бітів в байті відбувається зправа наліво. При цьому найбільш значним є лівий, сьомий біт, а найменш значним - правий, нульовий біт (рис.1).

Комп'ютер містить наступні програмно керовані вузли:

1.Програмну пам'ять (РМ) для 128 байтових інструкцій (ROM/ПЗП); пам'ять містить комірки з адресами від 0х00 до 0хFF.

2.Пам'ять даних (DM) з довільним доступом (RAM/ПДД); пам'ять містить тетрадні комірки з адресами від 0х0 до 0хF.

3.Арифметичний і логічний пристрій (ALU/АЛП).

4.Акумулятор (АК/ACC).

5.Однобітові означні прапорці нульового результату і переносу (Zero, Carry).

Розробка архітектури рівня машинних інструкцій

Відомості про інструкції, що виконує процесор “Гном”, подані таблицями 1 і 2.

Таблиця 1 - Перелік і функції машинних інструкцій процесора “Гном”

Mнемокод

Символічний

записФункція

load #dACC <= RdЗавантажити акумулятор вмістимим комірки RAM з адресою Rd.

d є в межах [0..15].

load RdACC < = dЗавантажити до акумулятора значення d.

d є в межах [0..15].

store RdRd <= ACCЗберігти вмістиме акумулятора в RAM в комірці Rd.

d є в межах [0..15].

add #dACC<=ACC+d+c;

C <= carry outДодати значення d і прапорець C до акумулятора.

d є в межах [0..15].

add RdACC<=ACC+Rd+c

C <= carry outДодати вмістиме адреси RAM за адресою Rd и прапорець C до акумулятора. d змінюється в межах [0..15]. Сформувати вихідний перенос carry out.

xor RdACC<=ACC xor RdСума по модулю 2 вмістимого RAM за адресою Rd з акумулятором. d знаходиться в межах [0..15].

test RdACC<=ACC and Rd; C <= 1 when ACC=0 else 0;Встановити прапорець С, коли логічний добуток RAM за адресою Rd і акумулятора є нульовим. Інакше скинути прапорець С. d є адресою в межах [0..15].

clear_cC <= 0Записати в прапорець C нуль.

set_cC <= 1Записати в прапорець C одиницю.

skip_cPC <= PC + 1 + CКоли C=1, тоді перестрибнути наступну інструкцію подвійним інкрементуванням програмного лічильника замість одинарного. Коли C=0, тоді виконати наступну інструкцію.

skip_zPC <= PC + 1 + ZКоли Z=1, тоді перестрибнути наступну інструкцію подвійним інкрементуванням програмного лічильника замість одинарного. Коли Z=0, тоді виконати наступну інструкцію.

jump #aPC <= aСтрибнути на програмну адресу a, після чого виконати інструкцію, що розташована за цією адресою. a знаходиться в межах [0..127].

В тексті записки треба обгрунтувати доцільність реалізації кожної поданої машинної інструкції, пояснити до якого класу (CISC або RISC) належить ця система інструкцій, та чи можливе скорочення ціеї системи інструкцій.

Інструкція

КодуванняФаза FETCHФаза DECODEФаза EXECUTE

load Rd0100 d3d2d1d0IR <=(PC) , PC <= PC +1[IR3..IR0]<=([IR3..IR0])ACC <= [IR3..IR0]

load #d0001 d3d2d1d0IR <=(PC) , PC <= PC +1 ACC <= [IR3..IR0]

store Rd0011 d3d2d1d0IR <=(PC) , PC <= PC +1 ([IR3..IR0])<=ACC

add #d0010 d3d2d1d0IR <=(PC) , PC <= PC +1 ACC<=

ACC+[IR3..IR0]+C

add Rd0101 d3d2d1d0IR <=(PC) , PC <= PC +1[IR3..IR0]<=([IR3..IR0])ACC<=

ACC +[IR3..IR0]+C

xor Rd0110 d3d2d1d0IR <=(PC) , PC <= PC +1[IR3..IR0]<=([IR3..IR0])ACC<=

ACC xor [IR3..IR0]

test Rd0111 d3d2d1d0IR <=(PC) , PC <= PC +1[IR3..IR0]<=([IR3..IR0])ACC<=

ACC and [IR3..IR0]

cear_c00000000IR <=(PC) , PC <= PC +1 C <= 0

set_c00000001IR <=(PC) , PC <= PC +1 C <= 1

skip_c00000010IR <=(PC) , PC <= PC +1 PC <= PC + C

skip_z00000011IR <=(PC) , PC <= PC +1 PC <= PC + Z

jump #a1 a6a5a4a3a2a1a0IR <=(PC) , PC <= PC +1 PC <= [IR6..IR0]

Пояснення:

1.IR -регістр інструкції, [IR3..IR0] - бінарний код, що зберігає його молодша тетрада.

2.([IR3..IR0]) - вмістиме комірки пам'яті даних за адресою, що містить молодша тетрада регістра інструкцій.

3.Виконання будь-якої інструкції розкладено на три фази (стадії):

-FETCH : вибирання нової інструкції з пам'яті інструкцій на регістр інструкцій, обчислення адреси наступної інструкції програми за правилом “поточна адреса + 1”;

-DECODE : декодування поточної інструкції (в нас - це читання операнду з пам'яті даних до молодшої тетради регістру інструкцій);

-EXECUTE : виконання поточної інструкції за її алгоритмом, що може вимагати корекції вмістимого програмного лічильника РС.

4.d3, d2, d1, d0, a6, a5, a4, a3, a2, a1, a0 - позначки окремих бітів формату машинної інструкції.

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

Розробка тестової програми

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

1.Здійснити віртуальне часове моделювання функціонування комп'ютера, що керується тестовою програмою (засобами програмного симулятора ModelSim).

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

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

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

Таблиця 3 - Асемблерна тестова програма і її машинні коди

Адреса Машинний код Асемблер Коментар

000018Load #8

Iніціалізувати регістри числами, що додаються, а саме:

0x29 + 0x48 = 0x71.

Обнулити перенос.

Знайти суму молодших цифр і зберігти в R4.

Додати старші цифри + перенос. Зберігти суму старших цифр в R5.

000130Store R0

000214Load #4

000331Store R1

000419Load #9

000532Store R2

000612Load #2

000733Store R3

000800Clear C

000940Load R0

000a52Add R2

000b34Store R4

Страницы: 1, 2, 3