Статья опубликована в рамках: LXI Международной научно-практической конференции «Научное сообщество студентов XXI столетия. ТЕХНИЧЕСКИЕ НАУКИ» (Россия, г. Новосибирск, 15 января 2018 г.)
Наука: Технические науки
Секция: Моделирование
Скачать книгу(-и): Сборник статей конференции
дипломов
ЭТАПЫ ПРОЕКТИРОВАНИЯ МИКРОПРОЦЕССОРНЫХ СИСТЕМ
Процессы автоматизации технического оборудования захватили большую часть всей организации производства. Они применяются повсеместно в станках, машинах и механизмах, робототехнических комплексах. Новые технологии существенно повышают производительность труда, уменьшая влияние человеческого фактора на риски при производстве. Также повышается технический уровень и качество продукции. Микропроцессорные системы – в своё время была инновационной технологией. Но сейчас это уже обыденность, ведь приборы, которые выполнены с применением микропроцессоров, имеют более высокие показатели в работе по сравнению с приборами, выполненными на отдельных логических схемах, при экономической выгоде первых.
Стандартизация процесса разработки упрощает анализ и исследования в этой сфере. А также делает наглядным текущее состояние и возможный результат. Современные компании, занимающиеся разработкой встраиваемых микропроцессорных систем используют программируемые логические интегральные схемы (ПЛИС) и системы автоматизированного производства для быстрого и организованного проектирования. При помощи ПЛИС возможна также отладка и тестирование в режиме реального времени. Ежегодное обновление САПР позволяет всё меньше и меньше тратить время на монотонную и односложную работу, при этом, не допуская очевидные ошибки. Это позволяет абстрагироваться на более высокие уровни системы и решение тяжелых задач.
Процесс разработки встраиваемых микропроцессорных систем можно представить в виде двух маршрутов последовательных этапов проектирования. Первый маршрут — разработка аппаратной части встраиваемой микропроцессорной системы. Второй маршрут — проектирование программных средств (рис.1).
Рисунок 1. Этапы проектирования
Но не все ступени маршрута обязательны. Моделирование аппаратной части системы в процессе разработки может не проводиться. Поэтому можно исключить некоторые ступени: подготовка спецификации моделирования, генерация моделей, функционального и временного моделирование. При этом следует учитывать, что моделирование аппаратной части системы повышает эффективность процесса проектирования в целом за счет более раннего обнаружения возможных ошибок и их устранение.
Типичные этапы проектирования микропроцессорных систем включают:
- Формализация различных требований к системе. Необходимо составить внешние спецификаций, техническое задание (ТЗ) на систему, заметки образа системы разработчиком в документации, перечисляются функции системы.
- Разработка структуры и архитектуры элементов системы. Необходимо определить взаимодействие между аппаратными и программными средствами, функции периферии и программных оболочек, выбрать микропроцессорные решения, на базе которых будет реализована система, определить временные характеристики.
- Разработка и изготовление аппаратной части и программного обеспечения системы. Необходимо разработать структуру и принципиальные схемы, изготовить прототип, отладить в условиях базовых режимов работы. Разработка программного обеспечения должна состоять из алгоритмов, написания текста исходных программ, трансляции исходных программ в объектные программы, программной отладки и симуляции.
- Общая отладка и приемосдаточные испытания в рабочих условиях.
Человеческий фактор допускает неисправности и принятие неверных проектных решений. Также существуют аппаратурные дефекты в устройствах. Например, возможны следующие источники ошибок на этапах:
Этап 1. Логическая несогласованность требований, упущения, неточности алгоритма.
Этап 2. Упущения функций, упущение некоторых информационных потоков, несогласованность протокола взаимодействия аппаратуры и программ, неверное определение технических требований, неверный выбор микропроцессорных решений, неточности алгоритмов.
Этап 3. При разработке аппаратуры - упущение некоторых функций, неверная интерпретация технического задания, недоработки в схемах синхронизации, нарушение правил проектирования; при разработке программных средств - упущения некоторых функций технического задания, неточности в алгоритмах, неточности кодирования; при изготовлении прототипа - неисправности комплектующих изделий и периферии, неисправности монтажа и сборки.
Каждый из перечисленных источников ошибки может повлечь за собой большое число физических или субъективных неисправностей, которые необходимо в дальнейшем определить и устранить. Обнаружение и локализация неисправности осложняется по нескольким причинам: во-первых, из-за неисправностей может быть несколько; во-вторых, однообразие симптомов различных проблем. Так как отсутствуют модели субъективных неисправностей, указанная задача не формализована. Возможно решение при помощи экспертных систем – базы данных с уже имеющимися проблемами и их решением, исходящим из практического опыта.
Субъективные неисправности отличаются от физических тем, что после обнаружения, локализации и коррекции больше не возникают. Но субъективные неисправности могут быть внесены на этапе разработки спецификации системы, а это означает, что даже после самых тщательных испытаний системы на соответствие ее спецификациям в системе могут находиться субъективные неисправности.
Процесс проектирования - итерационный процесс, а значит при неполном устранении ошибок на одном этапе, возможно их появление на следующем. Обнаруживать неисправности необходимо как можно раньше, для этого надо контролировать корректность проекта на каждом этапе разработки. Например, неисправности, обнаруженные на конечном этапе приема-сдачи проекта, могут привести к коррекции спецификаций, а, следовательно, к началу проектирования всей системы. К таким же последствия приводят изменения технического задания (из-за недосказанности и недостатка сведений о системе).
Основными методами контроля правильности проектирования являются: верификация, моделирование и тестирование.
Верификация позволяет обнаруживать не только текущие ошибки, но и потенциальные ошибки, которые могут появиться в будущих проектах с использованием блоков. Но требует отдельного технического задания и соответствующие навыки и подходит под крупные проекты. На небольших проектах чаще используют моделирование поведения объекта и тестирование, т.к. этот вариант экономически выгоден и не требует большого количества ресурсов.
Контроль корректности достигается на каждом этапе проектирования необходимостью проведения моделирования на различных уровнях абстракций системы и проверки правильности реализованной части модели путем тестирования. Функциональная спецификация может моделироваться и проверяться в опытном порядке для выявления ожидаемого результата. Также может проводиться анализ коллективом экспертов. После утверждения функциональной спецификации начинается разработка функциональных тестов системы, предназначенных для установления правильности функционирования системы в соответствии с ее функциональной спецификацией. Наиболее эффективно разрабатывать тесты, целиком основанные на этой спецификации, поскольку это даёт возможность проверки любой реализации системы, способной выполнять функции, оговоренные в спецификации. Этот способ - аналогичен другим, где тесты строятся применительно к конкретным реализациям, но точнее проводит сопоставление ожидания и результата разработки.
После обнаружения ошибки должен быть локализован ее источник для проведения коррекции на соответствующем уровне абстрактного представления системы и в соответствующем месте. Неправильное определение источника ошибки или проведение корректировок на другом уровне абстрактного представления системы приводит к тому, что информация о системе на верхнем уровне становится ошибочной и не может быть использована для дальнейшей отладки при производстве и эксплуатации системы.
Автоматизация монотонной работы по разработке тестовых программ сокращает период конструирования и отладки за счет более раннего получения тестов (поскольку они могут быть сгенерированы сразу после формирования требований к системе) и позволяет проектировщику изменять спецификации без переписывания всех тестовых программ. На практике разработка тестов менее приоритетна по сравнению с проектом, поэтому тестовые программы появляются значительно позже его завершения.
Таким образом, учитывая нюансы проектирования микропроцессоров можно легко обойти «подводные камни» при разработке. Использование программируемых логических интегральных схем (ПЛИС) облегчает отладку еще не выпущенной партии и позволяет протестировать проект и исправить недочеты. А системы автоматизированного производства (САПР) упрощает разработку, позволяя перераспределить ресурсы более рационально.
Список литературы:
- СибГУТИ [Электронный ресурс] / Проектирование микропроцессора на ПЛИС – Режим доступа: http://ict.sibsutis.ru/sites/csc.sibsutis.ru/files/courses/mps/mp.pdf–свободный. – загл. с экрана. – яз. рус. (дата обращения 22.12.2017).
- Зотов В. Embedded Development Kit — система проектирования встраиваемых микропроцессорных систем на основе ПЛИС серий FPGA фирмы Xilinx. 2004. № 3.
дипломов
Оставить комментарий