|
||||||||||||
|
||||||||||||
|
|||||||||
МЕНЮ
|
БОЛЬШАЯ ЛЕНИНГРАДСКАЯ БИБЛИОТЕКА - РЕФЕРАТЫ - Синтез схеми ПЛІС для інвертораСинтез схеми ПЛІС для інвертора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 000c41Load R1 000d53Add R3 000e35Store R5 Loop: 000f44Load R4Показати мол. цифру. Показати старшу цифру. Показувати безперервно. 001045Load R5 00118fJump #loop Ясна річ, машинні коди тестової програми мають фіксуватися в VHDL моделі пам'яті програм. Зауважимо, що для виконуваних пар інструкцій з кодами 0х53/0x35 та 0x44/0x8F часовим симулюванням отримано і проаналізовано подані нижче часові діаграми виконання тестової програми. Розробка VHDL моделі процесора Виконаємо розробку VHDL моделі процесора на основі прототипної моделі процесора “Gnome”, що подана роботою [1] мовою ABEL. На відміну від прототипа ми задамо цільову ПЛІС Віртекс-2 з вбудованими елементами RAM і ROM. При цьому об'єднаємо CPU, RAM і ROM до єдиного комп'ютера внутрішньо кристальними шинами, одна з яких є двонаправленою. Розглянемо VHDL текст моделі. -- GNOME micro processor unit LIBRARY IEEE; USE IEEE.std_logic_1164.all; USE IEEE.std_logic_unsigned.all; -- interface ENTITY gnome IS PORT ( clk: IN STD_LOGIC;-- clock reset: IN STD_LOGIC;-- reset control input address: OUT STD_LOGIC_VECTOR (6 DOWNTO 0); -- external RAM address data: INOUT STD_LOGIC_VECTOR (7 DOWNTO 0); -- system bus web: OUT STD_LOGIC; -- external RAM active-low write-enable oeb: OUT STD_LOGIC; -- external RAM active-low output-enable sel_ram: out std_logic; carry_out : out std_logic; pc_out: OUT STD_LOGIC_VECTOR (6 DOWNTO 0); ir_out: out std_logic_vector (7 downto 0); acc_out: out std_logic_vector (3 downto 0)); END gnome; -- GNOME processor architecture behavioral description ARCHITECTURE gnome_arch OF gnome IS -- current and next GNOME state-machine state SIGNAL curr_st, next_st: STD_LOGIC_VECTOR (1 DOWNTO 0); -- possible GNOME state-machine states and their definitions CONSTANT FETCH: STD_LOGIC_VECTOR (1 DOWNTO 0) := "00"; -- fetch instruction CONSTANT DECODE: STD_LOGIC_VECTOR (1 DOWNTO 0) := "01"; -- decode CONSTANT EXECUTE: STD_LOGIC_VECTOR (1 DOWNTO 0) := "11"; -- execute -- current and next program counter value SIGNAL curr_pc, next_pc: STD_LOGIC_VECTOR (6 DOWNTO 0); -- current and next accumulator value SIGNAL curr_acc, next_acc: STD_LOGIC_VECTOR (3 DOWNTO 0); -- current and next carry flag value SIGNAL curr_carry, next_carry: STD_LOGIC; -- current and next zero flag value SIGNAL curr_zero, next_zero: STD_LOGIC; -- sum vector for holding adder output SIGNAL sum: STD_LOGIC_VECTOR (4 DOWNTO 0); SIGNAL read: STD_LOGIC; -- 1 when reading RAM SIGNAL write: STD_LOGIC; -- 1 when writing RAM SIGNAL sel_data_ram: STD_LOGIC;-- 1 when accessing R0-R15 SIGNAL jump_pc: STD_LOGIC; -- 1 when overwriting PC SIGNAL inc_pc: STD_LOGIC; -- 1 when incrementing PC SIGNAL ld_ir: STD_LOGIC; -- 1 when loading IR SIGNAL ld_ir_lsn: STD_LOGIC;-- 1 when loading LSN of IR -- ALU operation code possible ALU opcodes SIGNAL alu_op: STD_LOGIC_VECTOR (2 DOWNTO 0); --pass input to output CONSTANT PASS_OP: STD_LOGIC_VECTOR (2 DOWNTO 0):= "001"; CONSTANT ADD_OP: STD_LOGIC_VECTOR (2 DOWNTO 0):= "010"; -- add inputs CONSTANT XOR_OP: STD_LOGIC_VECTOR (2 DOWNTO 0):= "011"; -- XOR inputs CONSTANT AND_OP: STD_LOGIC_VECTOR (2 DOWNTO 0):= "100"; -- test input for 0 CONSTANT SET_CARRY_OP: STD_LOGIC_VECTOR (2 DOWNTO 0) := "101"; --set carry CONSTANT CLR_CARRY_OP: STD_LOGIC_VECTOR (2 DOWNTO 0) := "110"; --clear carry -- current and next instruction register SIGNAL curr_ir, next_ir: STD_LOGIC_VECTOR (7 DOWNTO 0); -- possible instruction opcodes CONSTANT CLEAR_C: STD_LOGIC_VECTOR (7 DOWNTO 0) := "00000000"; CONSTANT SET_C: STD_LOGIC_VECTOR (7 DOWNTO 0) := "00000001"; CONSTANT SKIP_C: STD_LOGIC_VECTOR (7 DOWNTO 0) := "00000010"; CONSTANT SKIP_Z: STD_LOGIC_VECTOR (7 DOWNTO 0) := "00000011"; CONSTANT LOAD_IMM: STD_LOGIC_VECTOR (3 DOWNTO 0) := "0001"; CONSTANT ADD_IMM: STD_LOGIC_VECTOR (3 DOWNTO 0) := "0010"; CONSTANT STORE_DIR:STD_LOGIC_VECTOR (3 DOWNTO 0) := "0011"; CONSTANT LOAD_DIR: STD_LOGIC_VECTOR (3 DOWNTO 0) := "0100"; CONSTANT ADD_DIR: STD_LOGIC_VECTOR (3 DOWNTO 0) := "0101"; CONSTANT XOR_DIR: STD_LOGIC_VECTOR (3 DOWNTO 0) := "0110"; CONSTANT TEST_DIR: STD_LOGIC_VECTOR (3 DOWNTO 0) := "0111"; CONSTANT JUMP: STD_LOGIC := '1'; BEGIN carry_out <= curr_carry; pc_out <= curr_pc; acc_out <= curr_acc; ir_out <= curr_ir; sel_ram <= sel_data_ram; -- external RAM control signals oeb <= NOT(read);-- enable RAM drivers during RAM read operations web <= NOT(write);-- RAM write line (in last half of clock) -- address either the data or program sections of the external RAM address <= "000" & curr_ir(3 DOWNTO 0) WHEN sel_data_ram='1' ELSE curr_pc; -- drive the accumulator contents into the RAM during write operations -- but disable the drivers into high-impedance state at all other times data <= "0000" & curr_acc WHEN write='1' ELSE "ZZZZZZZZ"; -- load the instruction register with a new opcode next_ir <= data WHEN ld_ir='1' ELSE -- or load only the lower 4 bits of the IR with data curr_ir(7 DOWNTO 4) & data(3 DOWNTO 0) WHEN ld_ir_lsn='1' ELSE -- or else don't change the IR curr_ir; -- load the PC with an address to jump to next_pc <= curr_ir(6 DOWNTO 0) WHEN jump_pc='1' ELSE -- or increment the PC curr_pc+1 WHEN inc_pc='1' ELSE -- or else don't change the PC curr_pc; -- this process describes the operations of the ALU PROCESS (alu_op,curr_zero,curr_carry,curr_acc,curr_ir,sum) BEGIN -- set the default values for these signals to avoid synthesis of -- implied latches sum <= "00000"; next_acc <= "0000"; next_carry <= '0'; next_zero <= '0'; CASE alu_op IS WHEN ADD_OP => -- add the accumulator with the lower 4 bits of the IR and the carry sum <= ('0' & curr_acc) + ('0' & curr_ir(3 DOWNTO 0)) + ("0000" & curr_carry); next_acc <= sum(3 DOWNTO 0);-- ACC gets lower 4 bits of the sum next_carry <= sum(4);-- carry is the most significant bit of the sum next_zero <= curr_zero;-- zero flag is not changed WHEN XOR_OP => -- XOR the accumulator with the lower 4 bits of the IR next_acc <= curr_acc XOR curr_ir(3 DOWNTO 0); next_carry <= curr_carry; -- carry flag is not changed next_zero <= curr_zero; -- zero flag is not changed WHEN PASS_OP => -- pass lower 4 bits of IR into ACC next_acc <= curr_ir(3 DOWNTO 0); next_carry <= curr_carry; -- carry flag is not changed next_zero <= curr_zero; -- zero flag is not changed WHEN AND_OP => -- test the ACC for zeroes in unmasked bit positions next_acc <= curr_acc; -- ACC is not changed next_carry <= curr_carry;-- carry is not changed -- zero flag is set if ACC has zeroes where IR has ones next_zero <= NOT( (curr_acc(3) AND curr_ir(3)) OR (curr_acc(2) AND curr_ir(2)) OR (curr_acc(1) AND curr_ir(1)) OR (curr_acc(0) AND curr_ir(0))); WHEN SET_CARRY_OP => -- set the carry bit next_acc <= curr_acc;-- ACC is not changed next_carry <= '1'; next_zero <= curr_zero;-- zero flag is not changed WHEN CLR_CARRY_OP => -- clear the carry bit next_acc <= curr_acc;-- ACC is not changed next_carry <= '0'; next_zero <= curr_zero;-- zero flag is not changed WHEN OTHERS => -- don't do anything for undefined ALU opcodes next_acc <= curr_acc; next_carry <= curr_carry; next_zero <= curr_zero; END CASE; END PROCESS; -- this process describes the transitions of the GNOME state machine -- and sets the control signals that are activated in each state PROCESS(curr_st,curr_carry,curr_zero,curr_ir) BEGIN -- set the default values for these signals to avoid synthesis -- of implied latches sel_data_ram <= '0'; read <= '0'; write <= '0'; ld_ir <= '0'; ld_ir_lsn <= '0'; inc_pc <= '0'; jump_pc <= '0'; alu_op <= "000"; CASE curr_st IS WHEN FETCH => -- fetch an instruction from external RAM sel_data_ram <= '0'; -- select the instruction RAM read <= '1'; -- read from the RAM ld_ir <= '1';-- load the instruction -- register with the opcode inc_pc <= '1'; -- increment the PC -- to the next instruction next_st <= DECODE; -- then decode the -- instruction that was just loaded WHEN DECODE => -- decode the instruction. Actually, this state is used to -- read a direct-address operand from the data section of the -- external RAM and store it in the lower 4 bits of the IR. IF curr_ir(7 DOWNTO 4)=LOAD_DIR THEN sel_data_ram <= '1'; read <= '1'; ld_ir_lsn <= '1'; END IF; IF curr_ir(7 DOWNTO 4)=ADD_DIR THEN sel_data_ram <= '1'; read <= '1'; ld_ir_lsn <= '1'; END IF; IF curr_ir(7 DOWNTO 4)=XOR_DIR THEN sel_data_ram <= '1'; read <= '1'; ld_ir_lsn <= '1'; END IF; IF curr_ir(7 DOWNTO 4)=TEST_DIR THEN sel_data_ram <= '1'; read <= '1'; ld_ir_lsn <= '1'; END IF; next_st <= EXECUTE;-- then execute the instruction WHEN EXECUTE => -- execute the instruction. IF curr_ir=CLEAR_C THEN alu_op <= CLR_CARRY_OP;-- clear the carry flag END IF; IF curr_ir=SET_C THEN alu_op <= SET_CARRY_OP;-- set the carry flag END IF; IF curr_ir=SKIP_C THEN-- skip the next instruction inc_pc <= curr_carry; -- if the carry flag is set END IF; IF curr_ir=SKIP_Z THEN-- skip the next instruction inc_pc <= curr_zero; -- if the zero flag is set END IF; IF curr_ir(7 DOWNTO 4)=LOAD_IMM THEN -- load the ACC with immediate alu_op <= PASS_OP; -- data from the lower 4 bits of IR END IF; IF curr_ir(7 DOWNTO 4)=ADD_IMM THEN -- add the lower 4 bits of the alu_op <= ADD_OP;-- IR to the ACC END IF; IF curr_ir(7)=JUMP THEN -- jump to the address stored in the jump_pc <= '1'; -- lower 7 bits of the IR END IF; IF curr_ir(7 DOWNTO 4)=STORE_DIR THEN -- write the ACC to RAM sel_data_ram <= '1'; write <= '1'; END IF; IF curr_ir(7 DOWNTO 4)=LOAD_DIR THEN -- load the ACC with the alu_op <= PASS_OP; -- data read from RAM in the previous cycle END IF; IF curr_ir(7 DOWNTO 4)=ADD_DIR THEN -- add the data read from RAM in alu_op <= ADD_OP; -- the previous cycle to the ACC END IF; IF curr_ir(7 DOWNTO 4)=XOR_DIR THEN -- XOR the data read from RAM in alu_op <= XOR_OP; -- the previous cycle to the ACC END IF; IF curr_ir(7 DOWNTO 4)=TEST_DIR THEN -- mask the ACC with the value alu_op <= AND_OP; -- read from RAM in the previous cycle and END IF; -- set the zero flag if all the bits are zero next_st <= FETCH; -- execution complete, so go fetch another instruction WHEN others => END CASE; END PROCESS; -- this process makes the next value of all these signals into the -- current value on the rising clock edge PROCESS (clk,reset) BEGIN -- asynchronously reset the state of the GNOME microcomputer IF reset='1' THEN curr_st <= FETCH;-- start by fetching instructions curr_pc <= "0000000";-- start at beginning of instruction RAM curr_ir <= "00000000"; curr_acc <= "0000";-- clear accumulator curr_carry <= '0'; -- clear carry flag curr_zero <= '0'; -- clear zero flag -- otherwise, update state on the rising clock edge ELSIF (clk'event AND clk='1') THEN curr_st <= next_st; curr_pc <= next_pc; curr_ir <= next_ir; curr_acc <= next_acc; curr_carry <= next_carry; curr_zero <= next_zero; END IF; END PROCESS; END gnome_arch; В відповідному розділі записки потрібно подати: -текст моделі з коментарями державною мовою; -побудовану на основі VHDL моделі структурну схему процесора (це можна зробити за допомогою утиліти RTL schematic Viewer, що містить САПР WebPack); -додаткові (поза коментарями) роз'яснення щодо семантики VHDL моделі; -витяги з протоколів синтезу, імплементування, програмування, діаграму часового симулювання поведінки процесора як окремого проекту. Розробка VHDL моделі пам'яті даних Модель пам'яті даних складено так, аби VHDL синтезатор за стилем написання винайшов, що її треба реалізувати на вбудованих до цільової ПЛІС елементах RAM. Це покращує реалізацію проекту. Існує варіант прямого запису в тексті моделі бібліотечних посилань на вбудовані елементи. Проте така модель набуває рис непересувної, хоча і ефективної моделі низького рівня. Це не завжди є бажаним. Подамо текст моделі пам'яті даних. library ieee; use ieee.std_logic_1164.all; use ieee.std_logic_unsigned.all; entity ram is port (clk : in std_logic; oe : in std_logic; we : in std_logic; sel_ram : in std_logic; address : in std_logic_vector(6 downto 0); data : inout std_logic_vector(7 downto 0)); end ram; architecture syn of ram is type ram_type is array (15 downto 0)of std_logic_vector (3 downto 0); signal RAM : ram_type; begin process (clk) begin if (clk'event and clk = '1') then if ((sel_ram = '1')and (oe='1')and (we='0')) then RAM(conv_integer(address(3 downto 0))) <= data (3 downto 0); end if; end if; end process; data <= "0000"& RAM(conv_integer(address(3 downto 0))) when ((sel_ram='1') and (oe='0') and (we='1')) else "ZZZZZZZZ"; end syn; В відповідному розділі пояснювальної записки потрібно подати: -текст моделі з коментарями державною мовою; -побудовану на основі VHDL моделі структурну схему пам'яті; -додаткові роз'яснення щодо семантики VHDL кодів; -витяги з протоколів синтезу, імплементування, програмування і часову діаграму симулювання пам'яті даних як окремого проекту. Розробка VHDL моделі пам'яті програм Подамо VHDL модель постійної (так нам зручно) пам'яті програм. Ця пам'ять містить машинні коди тестової програми. За допомогою цієї моделі ми вбудовуємо програму до комп'ютера. Ясно, що зміна програми вимагатиме пересинтезу і переімплементування проекту. library IEEE; use IEEE.std_logic_1164.all; use IEEE.std_logic_unsigned.all; entity rom is port ( sel_ram : in std_logic; oe : in std_logic; ADDR : in std_logic_vector (6 downto 0); DATA : inout STD_LOGIC_VECTOR (7 downto 0)); end rom; architecture XILINX of rom is subtype ROM_WORD is STD_LOGIC_VECTOR (7 downto 0); type ROM_TABLE is array (0 to 19) of ROM_WORD; constant ROM: ROM_TABLE := ROM_TABLE '( ROM_WORD '(x"18"), -- start of test program ROM_WORD '(x"30"), ROM_WORD '(x"14"), ROM_WORD '(x"31"), ROM_WORD '(x"19"), ROM_WORD '(x"32"), ROM_WORD '(x"12"), ROM_WORD '(x"33"), ROM_WORD '(x"00"), ROM_WORD '(x"40"), ROM_WORD '(x"52"), ROM_WORD '(x"34"), ROM_WORD '(x"41"), ROM_WORD '(x"53"), ROM_WORD '(x"35"), ROM_WORD '(x"44"), ROM_WORD '(x"45"), ROM_WORD '(x"8F"), -- end of test program ROM_WORD '(x"00"), ROM_WORD '(x"00")); begin DATA <= ROM(conv_integer (ADDR(5 downto 0)))when (oe='0' and sel_ram='0') else "ZZZZZZZZ"; end XILINX; В відповідному розділі пояснювальної записки потрібно подати: -текст моделі з коментарями державною мовою; -побудовану на основі VHDL моделі структурну схему пам'яті програм; -додаткові роз'яснення щодо семантики VHDL моделі; -витяги з протоколів синтезу, імплементування, програмування і діаграму часового симулювання пам'яті програм як окремого проекту. 3. СИНТЕЗ І ВЕРИФІКАЦІЯ VHDL МОДЕЛІ КОМП'ЮТЕРА Подамо структурну VHDL модель комп'ютера. Комп'ютер складено з тьох вузлів, а саме, з процесора “Гном”, пам'яті програм і пам'яті даних. Всі вузли подані відповідними VHDL компонентами. Уведеними сигналами (дротами, шинами тощо) компоненти поєднано в комп'ютер. library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_ARITH.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; -- project top file entity gnome_mcu is Port ( clk : in std_logic; Reset : in std_logic; we_view : out std_logic; carry_view : out std_logic; oe_view : out std_logic; sel_ram_view : out std_logic; pc_view : out std_logic_vector (6 downto 0); acc_view : out std_logic_vector (3 downto 0); data_view : out std_logic_vector(7 downto 0); addr_view : out std_logic_vector(6 downto 0); ir_view : out std_logic_vector(7 downto 0)); end gnome_mcu; architecture structural of gnome_mcu is component gnome port ( clk: IN STD_LOGIC;-- clock reset: IN STD_LOGIC;-- reset control input address: OUT STD_LOGIC_VECTOR (6 DOWNTO 0); -- ext memory addr data: INOUT STD_LOGIC_VECTOR (7 DOWNTO 0); -- ext memory data bus --csb: OUT STD_LOGIC;-- active-low chip-select for external RAM web: OUT STD_LOGIC;-- active-low write-enable for external RAM oeb: OUT STD_LOGIC;-- active-low output-enable for external RAM sel_ram: out std_logic; carry_out : out std_logic; pc_out: OUT STD_LOGIC_VECTOR (6 DOWNTO 0); ir_out: out std_logic_vector (7 downto 0); acc_out: out std_logic_vector (3 downto 0) ); end component; component rom port ( sel_ram : in std_logic; oe : in std_logic; ADDR : in std_logic_vector (6 downto 0); DATA : inout STD_LOGIC_VECTOR (7 downto 0)); end component; component ram port (clk : in std_logic; sel_ram : in std_logic; oe : in std_logic; we : in std_logic; address : in std_logic_vector(6 downto 0); data : inout std_logic_vector(7 downto 0)); end component; signal w_clk: std_logic; signal w_reset: STD_LOGIC; signal b_address: STD_LOGIC_VECTOR (6 DOWNTO 0); signal b_data: STD_LOGIC_VECTOR (7 DOWNTO 0); --signal w_csb: STD_LOGIC;-- active-low chip-select for external ROM/RAM signal w_web: STD_LOGIC; -- active-low write-enable for external RAM signal w_oeb: STD_LOGIC; -- active-low output-enable for external ROM/RAM signal w_sel_ram: std_logic; begin oe_view <= w_oeb; sel_ram_view <= w_sel_ram; w_clk <= clk; w_reset <= reset; data_view <= b_data; addr_view <= b_address; we_view <= w_web; U1: gnome port map ( clk => w_clk, reset => w_reset, address =>b_address, data => b_data, --csb => w_csb, web => w_web, oeb => w_oeb, sel_ram => w_sel_ram, carry_out => carry_view, pc_out => pc_view, ir_out => ir_view, acc_out => acc_view); U2: rom port map ( sel_ram => w_sel_ram, oe => w_oeb, ADDR => b_address, DATA => b_data); U3: ram port map ( clk => w_clk, sel_ram => w_sel_ram, oe => w_oeb, we => w_web, address => b_address, data => b_data); end structural; В відповідному розділі пояснювальної записки потрібно подати: -текст моделі з коментарями державною мовою; -побудовану на основі VHDL моделі структурну схему комп'ютера; -додаткові роз'яснення щодо семантики VHDL моделі; -витяги з протоколів синтезу, імплементування, програмування і діаграми часового симулювання виконання комп'ютером тестової програми. Подамо, як приклад, витяг з протоколу імплементування комп'ютера на ПЛІС Віртекс-2. Device utilization summary: Number of External IOBs 40 out of 88 45% Number of LOCed External IOBs 0 out of 40 0% Number of SLICEs 64 out of 256 25% Number of BUFGMUXs 1 out of 16 6% Number of TBUFs 32 out of 128 25% Отже, проект вимагає для реалізації 64 слайси. Це число буде меншим для коротших програм і більшим для довших. В нас можлива довжина програми в 64 інструкції. Наступний витяг з протоколу імплементування засвідчує швидкодію (на цільовій ПЛІС Віртекс-2). 6322 items analyzed, 0 timing errors detected. Minimum period is 11.235ns. Maximum delay is 14.267ns. Отже за оцінкою, комп'ютер спроможний тактуватися максимальною частотою 88 МГЦ, що на трьохциклових інструкціях забезпечувати швидкодію майже 30 MIPS. Далі подамо розташування апаратури комп'ютера в ПЛІС Віртекс-2 і копію вікна навігатора з нашим проектом. Текстом пояснювальної записки студент має роз'яснити інформацію, що містить вікно FloorPlanner. Щодо вікна навігатора проектів в пояснювальній записці теж треба подати роз'яснення. Аналізом отриманих часових діаграм потрібно підтвердити, що функціонування комп'ютера відповідає тестовій програмі. Подамо два фрагменти часової діаграми функціонування комп'ютера. Симулятор запущено на часове симулювання наступними командами: 1.Force clk 0 0, 1 50ns -repeat 100ns (тактові імпульси з частотою 10 МГц, що розпочинаються нулем). 2.Force reset 1 0. 0 70ns (форсувати скид одиницею від початку, а на 70-й нс перевести його до неактивного одиничного стану). 3.Run 6 us ( викликати симулювання перших 6-ти мікросекунд: аби встигла виконатися наша програма на частоті 10 МГц). Детальним аналізом часових діаграм (навести його письмово) підтверджують коректне функціонування переходу на кінці програми. За допомогою утиліти Xpower зі складу САПР WebPack визначаємо споживану розробкою потужність. Для визначення параметричної надійності розробки обчислюють обернену величину (середній час наробки на відмову, або MTBF) суми пронормованих лямбда-параметрів всіх складових проекту (разом із конекторами, друкованими платами і пайками). Це виконують після розробки принципової схеми емулятора. Розробка принципової схеми прототипної плати Як аналогом розробки можна скористатися відомими прототипними платами. Сайт www.xess.com надає описи і принципові схеми низки прототипних плат з різними цільовими ПЛІС. Розглянемо прототипну плату XS40. Нам мікроконтролер uC8031непотрібен. Його можна виключити зі складу емулятора. Водночас потрібно правильно призначити номери контактів нашої цільової ПЛІС наявним сигналам. Зауважимо, що емулятор XS40 містить зовнішню статичну пам'ять, яку теж можна вилучити. Отже, розробка за аналогією зводиться до спрощень і до переназв номерів контактів. Інформацію щодо цільової ПЛІС (datasheet) Віртекс-2/Cпартан-2/Спартан-2Е отримують на сайті фірми Ксайлінкс або ж від керівника проекту. 4 ІНСТАЛЯЦІЯ САПР Xilinx WebPack Спочатку інсталюють САПР Xilinx WebPack, потім - симулятор ModelSim фірми Model Technologies. Інсталювати симулятор непотрібно для WebPack 8.2i. Він містить вбудований симулятор. Після кожного кроку інсталяції комп'ютер перезапускають. Ще до інсталяції симулятора записують на диск безкоштовну студентську ліцензію. Потім зі стартового меню інстальованого симулятора викликають менеджер ліцензії симулятора, якому вказують місце розташування на диску ліцензії, а потім наказують перевірити дієспроможність ліцензії. Роботу з менеджером ліцензії завершують. Ще одне перезавантаження і система готова до використання. Використана література 1.Троценко В.В. - VHDL модель комп'ютера ; методичні вказівки до курсового проекту 21с. 2.www.xilinx.com 3.www.xess.com 4.www.model.com |
РЕКЛАМА
|
|||||||||||||||||
|
БОЛЬШАЯ ЛЕНИНГРАДСКАЯ БИБЛИОТЕКА | ||
© 2010 |