WWW.REFERATCENTRAL.ORG.UA - Я ТУТ НАВЧАЮСЬ

... відкритий, безкоштовний архів рефератів, курсових, дипломних робіт

ГоловнаІнформатика, Компютерні науки → Мікропроцесор - Реферат

Мікропроцесор - Реферат


Реферат на тему:
Мікропроцесор
Зміст
1. Етапи проектування мікропроцесорних систем
2. Джерела помилок
3. Перевірка правильності проекту
4. Основні характеристики мікропроцесора
5. Структура типового мікропроцесора
6. Логічна структура мікропроцесора
7. Система команд
8. Режими адресації
9. Типи архітектур
10. Класифікація
Етапи проектування мікропроцесорних систем
Мікропроцесорні системи по своїй складності, вимогам і функціям можуть значно відрізнятися надійнісними параметрами, обсягом програмних засобів, бути одно процесорними й багатопроцесорними, побудованими на одному типі мікропроцесорного набору або декількох, і т.д. У зв'язку з цим процес проектування може видозмінюватися в залежності від вимог, пропонованих до систем. Наприклад, процес проектування МШС, що відрізняються одна від іншої змістом ПЗП, буде складатися з розробки програм і виготовлення ПЗП.
При проектуванні багатопроцесорних мікропроцесорних систем, що містять кілька типів мікропроцесорних наборів, необхідно вирішувати питання організації пам'яті, взаємодії з процесорами, організації обміну між пристроями системи і зовнішнім середовищем, узгодження функціонування пристроїв, що мають різну швидкість роботи, і т.д. Нижче приведена зразкова послідовність етапів, типових для створення мікропроцесорної системи:
1. Формалізація вимог до системи.
2. Розробка структури й архітектури системи.
3. Розробка й виготовлення апаратних засобів і програмного забезпечення
системи.
4. Комплексне налагодження і приємоздаточні іспиту.
Етап 1. На цьому етапі складаються зовнішні специфікації, перелічуються функції системи, формалізується технічне завдання (ТЗ) на систему, формально викладаються задуми розроблювача в офіційній документації.
Етап 2. На даному етапі визначаються функції окремих пристроїв і програмних засобів, вибираються мікропроцесорні набори, на базі яких буде реалізована система, визначаються взаємодію між апаратними і програмними засобами, тимчасові характеристики окремих пристроїв і програм.
Етап 3. Після визначення функцій, реалізованих апаратурою, і функцій, реалізованих програмами, схемотехніки і програмісти одночасно приступають до розробки і виготовлення відповідно досвідченого зразка і програмних засобів. Розробка й виготовлення апаратури складаються з розробки структурних і принципових схем, виготовлення прототипу, автономного налагодження.
Розробка програм складається з розробки алгоритмів; написання тексту вихідних програм; трансляції вихідних програм в об'єктні програми; автономного налагодження.
Етап 4. Комплексне налагодження.
На кожнім етапі проектування МШС людьми можуть бути внесені несправності і прийняті невірні проектні рішення. Крім того, в апаратурі можуть виникнути дефекти.
Джерела помилок
Розглянемо джерела помилок на перших трьох етапах проектування.
Етап 1. На цьому етапі джерелами помилок можуть бути: логічна непогодженість вимог, недогляду, неточності алгоритму.
Етап 2. На даному етапі джерелами помилок можуть бути: недогляду функцій, непогодженість протоколу взаємодії апаратури й програм, невірний вибір мікропроцесорних наборів, неточності алгоритмів, невірна інтерпретація технічних вимог, недогляд деяких інформаційних потоків.
Етап 3. На цьому етапі джерелами помилок можуть бути: при розробці апаратури - недогляду деяких функцій, невірна інтерпретація технічних вимог, недоробка в схемах синхронізації, порушення правил проектування; при виготовленні прототипу - несправності комплектуючих виробів, несправності монтажу і зборки; при розробці програмних засобів - недогляду деяких функцій технічного завдання, неточності в алгоритмах, неточності кодування.
Кожний з перерахованих джерел помилки може породити велике число суб'єктивних або фізичних несправностей, які необхідно локалізувати й усунути. Виявлення помилки і локалізація несправності є складною задачею з кількох причин: по-перше, через велике число несправностей; по-друге, через те, що різні несправності можуть виявлятися однаковим образом. Тому що відсутні моделі суб'єктивних несправностей, зазначена задача не формалізована. Маються визначені успіхи в області створення методів і засобів виявлення помилок і локалізації фізичних несправностей. Ці методи і засоби широко використовуються для перевірки працездатного стану і діагностики несправностей дискретних систем при проектуванні, виробництві й експлуатації останніх.
Суб'єктивні несправності відрізняються від фізичних тем, що після виявлення, локалізації і корекції більше не виникають. Однак, як випливає з переліку джерел помилок, суб'єктивні несправності можуть бути внесені на етапі розробки специфікації системи, а це означає, що навіть після самих ретельних іспитів системи на відповідність її зовнішнім специфікаціям у системі можуть знаходитися суб'єктивні несправності.
Процес проектування - ітераційний процес. Несправності, виявлені на етапі приємоздаточних іспитів, можуть привести до корекції специфікацій, а отже, до початку проектування всієї системи. Виявляти несправності необхідно якомога раніше, для цього треба контролювати коректність проекту на кожнім етапі розробки.
Перевірка правильності проекту
Основні методи контролю правильності проектування наступні: верифікація - формальні методи доказу коректності проекту; моделювання; тестування.
Існує багато робіт по верифікації програмного забезпечення, мікропрограм, апаратури. Однак ці роботи носять теоретичний характер. На практиці поки використовують моделювання поводження об'єкта і тестування.
Для контролю коректності проекту на кожнім етапі проектування необхідно проводити моделювання на різних рівнях абстрактного представлення системи і перевірку правильності реалізації заданої моделі шляхом тестування. На етапі формалізації вимог контроль коректності особливо необхідний, оскільки різні цілі проектування не формалізуються або не можуть бути формалізовані в принципі. Функціональна специфікація може аналізуватися колективом експертів або моделюватися і перевірятися в досвідченому порядку для виявлення, чи досягаються бажані цілі. Після твердження функціональної специфікації починається розробка функціональних тестових програм, призначених для встановлення правильності функціонування системи відповідно до її функціональної специфікації. В ідеальному випадку розробляються тести, цілком засновані на цій специфікації і перевірки, що дають можливість, будь-якої реалізації системи, що з'являється здатною виконувати функції, обговорені в специфікації. Цей спосіб - повна протилежність іншим, де тести будуються стосовно до конкретних реалізацій. Незалежна від реалізації функціональна перевірка звичайно приваблива лише в теоретичному плані, але практичного значення не має через високий ступінь спільності.
Автоматизація стомлюючої роботи зі складання тестових програм не тільки скорочуєтривалість періоду конструювання/налагодження за рахунок одержання тестових програм на етапі конструювання (оскільки вони можуть бути згенеровані відразу після формування вимог до системи), але і дозволяє проектувальникові змінювати специфікації, не піклуючись про переписування всіх тестових програм заново. Однак на практиці розробці тестів часто привласнюють більш низький пріоритет у порівнянні з
Loading...

 
 

Цікаве