Модельно ориентированное проектирование

Применение концепции модельно-ориентированного проектирования в разработке ПЛИС



В данной статье рассматривается модельно-ориентированное проектирование (МОП). На примере достаточно простых и типичных задач, которые встают каждый день у разработчиков ПЛИС будет показано, как можно упростить те или иные этапы разработки. Рассмотрим задачу проектирования интерфейса UART от этапа построения базовой модели в симуляторе и до тестирования работоспособности в ПЛИС.

В данной статье используется:

− Nios Development Board (Cyclone II, EP2C35F672C6)

− Преобразователь USB-to-UART

− САПР Altera Quartus II

− Matlab Simulink (+HDL-coder)

Рис. 1. Nios Development Board

Концепция модельно-ориентированного проектирования.

Любая современная разработка — результат деятельности многих специалистов из разных областей: схемотехники, конструктора, программисты и тестировщики.

Зачастую возникает ситуация, когда инженеры говорят «на разных языках», т. е. используют внутреннюю терминологию, которая может быть понятна одним специалистам, но не понятна специалистам другой области. В связи с этим возникает недопонимание и, как следствие, задержки при разработке.

Существует 2 очевидных решения подобных проблем:

  1. Выучить «все языки»: заставить математиков изучать схемотехнику, а программистов топологию. Очевидно, что подобное решение нерационально и затратно.
  2. Сформировать единую междисциплинарную систему представления проектов и решений, которая была бы понятна всем. Иными словами, сформировать модель, которая была бы интуитивно понятна всем.

Заставить инженеров общаться на одном «стандартном» языке — это и есть концепция МОП.

Перечислим основные достоинства МОП:

− Позволяет нескольким инженерным командам эффективнее взаимодействовать друг с другом.

− Помогает избежать ошибки на ранних стадиях разработки.

− Позволяет обосновать дополнения и изменения системы заказчику.

− Является важным компонентом для валидации и верификации производительности системы.

В дальнейшем система МОП рассматривается на примере графической среды имитационного моделирования Simulink.

Задача: Разработать блок приёма данных UART_RX с последовательного канала.

Будем использовать следующий формат посылки:

По умолчанию шина находится в состоянии логической 1.

Двоичное представление числа 14510=(1001 0001)2

Младшие разряды идут первыми, меняем последовательность битов

(1001 0001=1000 1001) и добавляем старт и стоп бит: 0_1000 1001_1.

Итоговый вид посылки представлен на рисунке

Рис. 2. Посылка на экране осциллографа

Построим модель в среде Simulink (рисунок 4) и поясним ключевые её моменты и принцип работы:

InTX-вход в модуль с последовательного канала.

Spad (детектор фронта) — получает на вход данные InTX и выдает на выход 1 каждый раз, когда происходит перепад из 1 в 0 (необходимо для того, чтобы вычислить start-бит).

StateRX — машина состояний (рисунок 3), которая работает следующим образом:

− На входе в блок поступает сигнал Spad.

− Пока сигнал spad равен 0, автомат находится в состоянии ожидания (IDLE).

− Как только сигнал spad становится равным 1 — происходит переход из состояния ожидания в состояние работы (WORK).

− Стартует счетчик i=0, увеличивающий свое значение с каждым тактом. Как только i=7, происходит переход в состояние IDLE. Это происходит по причине того, что были переданы все данные (от 0 бита и до 7). После этого автомат считает, что пришел стоп-бит, а затем и ожидание старта следующих данных. При этом выходному сигналу receive присваивается значение 1, а внутренний счетчик i обнуляется.

Receive — внутренний сигнал конца посылки, по которому необходимо защелкнуть выходные данные из сдвигового регистра

Data Type Conversion — преобразует тип данных.

Ready — функция конкатенации сдвигового регистра.

Extract Bits — функция извлечения битов.

OutRX — выходное значение приёмника.

Рис. 3. Машина состояний

Рис. 4. Модель UART_RX в Simulink

Проведем моделирование схемы в Simulink и посмотрим результат работы блока:

Рис. 5. Результат моделирования в Simulink

Значение сформировалось при выставлении сигнала ready. Видим, что это 145, т. е. наша исходная посылка.

Итак, имеется готовая модель, которую можно просмотреть, отладить, протестировать и даже модернизировать. Модель интуитивно понятна всем инженерам, которые вовлечены в работу над задачей. Здесь нет в явном виде вещей из программирования или принципиальных электрических схем. Простота и гибкость — залог успеха в МОП.

Теперь используем эту модель и произведем генерацию аппаратного кода при помощи внутреннего пакета Matlab (HDL-coder).

Важно помнить, что HDL кодер не воспринимает такие типы данных, как char, double и т. д. Поэтому, если встретит подобные типы данных в модели, то известит нас об этом, выдав ошибку кодера.

Стоит сразу позаботиться и преобразовать типы данных в uint или Boolean.

После генерации кода, если все прошло успешно-вам выдадут сообщение о том, что код сгенерирован и в папке с размещением проекта вы получите файлы с синтезируемым аппаратным кодом. В нашем случае, имеем дело с Verilog-описанием.

Если же есть какие-то ошибки-выйдет предупреждение с указанием модулей и блоков внутри него, которые нужно заменить или исправить.

Фрагмент кода, сгенерированного HDL-кодером.

Произведем встраивание полученного кода в проект Altera Quartus(рисунок 6).

Опустим процесс создания проекта, т. к. в зависимости от модели ПЛИС различаются настройки.

В нашем случае на рисунке изображен готовый BDF-файл, который является файлом верхнего уровня для Quartus-проекта.

UART_TX-спроектированный наш модуль. Можно заметить, что помимо оговоренных ранее InTX добавились ряд выходов, которые объявил кодер по умолчанию, а именно:

Clk — вход тактирования модуля.

Reset — сигнал сброса (в нашем случае заведен на GND)

Enb — разрешение работы модуля (в нашем случае заведен на VCC)

Количество выходных пинов же не изменилось.

Universal prescaller — готовый модуль, который делит входную частоту по 2 параметрам:

In_Prescaller — Частота работы кварца (в нашем случае 50МГц) на него приходит входной сигнал clk_in

Speed — скорость работы UART в нашем случае (115200 бод)

Clk — выход сигнала. От него тактируется вся остальная схема.

DFFE — триггер, защелкивающий данные OutRX по управляющему сигналу recv.

Модули Crtch+hex_decoder+набор pinout — система выдачи информации на 7-сегментный дисплей.

Рис. 6. Модель UART_RX в Quartus

Вся модель в целом работает следующим образом:

  1. С терминала через преобразователь USB to UART (Input pin proto2_io38) приходит последовательный код.
  2. Последовательный код заходит в модуль Uart_RX.
  3. Модуль забирает данные.
  4. Uart_RX передает данные в систему ввода/вывода, которая выводит данные на дисплей.

Скомпилируем проект.

Загружаем скомпилированный файл в ПЛИС. И проверяем работоспособность.

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

Рис. 7. Внешний вид терминала

Рис. 8. Таблица ASCII-кодов

Работает она следующий образом:

В самой таблице находится число(буква) — которая является посылкой (в нашем случае 5).

Смотрим по таблице соответствия по столбцу (0..7),а затем по строкам (0..F).

В нашем случае, число 58=35ASCII

Значит, если мы отправим посылку 5, то на выход приемника придет число 35.

Проверяем:

Рис. 9. Результат работы UART_RX

По рисунку видно, что значение, отправленное с терминала, соответствует тому, что выдал на выход UART_RX.

Принципы МОП существенно отличаются от традиционной методологии проектирования.

Вместо создания сложных программных кодов разработчики могут применять МОП для улучшения характеристик модели, используя стандартные функциональные блоки. Построенные таким образом модели вместе с использованием инструментов для моделирования могут быстро привести к созданию прототипа системы управления, тестированию и верификации программного обеспечения.

В некоторых случаях аппаратно-программное моделирование может быть использовано в качестве инструмента проектирования для более быстрого и эффективного тестирования динамических воздействий на систему, в отличие от традиционного метода проектирования.

Мы убедились, что МОП может является не только удобным средством абстракции для инженеров из разных областей, а еще и мощным средством для разработки и, самое главное, реализации запланированных задач.

Модельно-ориентированное проектирование

Эта статья опирается на источники, аффилированные с предметом статьи или иной заинтересованной стороной. Это может вызвать сомнения в нейтральности и проверяемости представленной информации. Такие источники также не показывают значимость предмета статьи. Статью можно улучшить, использовав независимые вторичные источники вместо аффилированных. (1 февраля 2014)

Модельно-ориентированное проектирование (МОП) — это математический и визуальный метод решения задач, связанных с проектированием систем управления, обработки сигналов и связи. МОП часто используется при управлении движением в промышленном оборудовании, аэрокосмической и автомобильной промышленности. МОП является методологией, применяемой при разработке встроенного программного обеспечения.

МОП определяет общую структуру взаимодействия в процессе проектирования, эффективно реализуя V-образный цикл разработки.

В модельно-ориентированном проектировании систем управления разработка происходит в 4 этапа:

  • построение модели объекта управления
  • анализ и построение регулятора
  • моделирование объекта и системы управления
  • как результат — реализация системы управления на объекте.

Принципы МОП существенно отличаются от традиционной методологии проектирования. Вместо создания сложных программных кодов разработчики могут применять МОП для улучшения характеристик модели, используя стандартные функциональные блоки с непрерывным и дискретным временем. Построенные таким образом модели вместе с использованием инструментов для моделирования могут быстро привести к созданию прототипа системы управления, тестированию и верификации программного обеспечения. В некоторых случаях аппаратно-программное моделирование может быть использовано в качестве инструмента проектирования для более быстрого и эффективного тестирования динамических воздействий на систему, в отличие от традиционного метода проектирования.

Некоторые из наиболее заметных преимуществ МОП в сравнении с традиционным подходом:

  • МОП предоставляет общую среду разработки, что способствует взаимодействию группы разработчиков в процессе анализа данных и проверки системы
  • Инженеры могут найти и исправить ошибки на ранних стадиях проектирования системы, когда время и финансовые последствия изменения системы сводятся к минимуму
  • МОП способствует повторному использованию модели для улучшения системы и создания производных систем с расширенными возможностями.

Основные этапы МОП

  1. Построение модели объекта. Построение модели может быть эмпирическим и теоретическим. При эмпирическом построении модели используются такие методы, как идентификация системы. При идентификации системы собираются и обрабатываются исходные данные, полученные от реальной системы, и некоторый алгоритм используется для определения математической модели объекта. Перед построением системы управления модель может быть использована для анализа и построения различных симуляторов. При теоретическом моделировании строятся блок-схемы модели, которые реализуют известные дифференциально-алгебраические уравнения, описывающие динамику объекта. К этому типу относится физическое моделирование, где модель создается с помощью соединяющихся блоков, представляющих собой физические элементы, из которых фактически состоит модель. Данный подход реализован, например, в продукте Simscape в составе среды MATLAB, или в российском решении — SimInTech.
  2. Анализ и построение системы управления. Математическая модель, сконструированная на шаге 1, используется для определения динамических характеристик модели объекта. На основе этих характеристик строится система управления.
  3. Офлайн-моделирование и моделирование в реальном времени. Время отклика динамической системы на входные данные, изменяющиеся во времени, исследуется с помощью симуляции модели в виде простой линейной стационарной системы или нелинейной системы. Симуляция позволяет немедленно найти характеристики модели, требования, накладываемые на неё, и ошибки построения до начала проектирования. Моделирование в реальном времени может быть осуществлено с помощью автоматической генерации кода системы управления, построенной на шаге 2. Этот регулятор может быть запущен на специальном компьютере, управляющем работой объекта в реальном времени. Если прототип объекта отсутствует или тестирование на прототипе опасно или дорого, код прототипа может автоматически генерироваться из модели объекта и запускаться на специальном компьютере, работающем в реальном времени и соединенном c целевым процессором с меняющимся кодом управления. Таким образом система управления может быть протестирована в реальном времени на модели объекта.
  4. Реализация регулятора. В идеале это делается с помощью автоматической генерации кода из системы управления, полученной на шаге 2. Маловероятно, что система управления будет работать в реальной системе так же хорошо, как это было при моделировании, поэтому итерационный процесс отладки осуществляется на основе анализа результатов на фактическом объекте и обновления модели регулятора. Инструменты МОП позволяют выполнить все эти итерационные шаги в единой визуальной среде.

История

С расцветом электротехники связано появление инновационных и передовых систем управления. Еще в 1920-е годы объединились две инженерных области: теория управления и системы управления, чтобы сделать возможным создание единых крупномасштабных систем. Поначалу системы управления широко использовались в промышленной среде. Крупные предприятия начали использовать контроллеры для регулирования непрерывных переменных, таких как температура, давление и скорость потока. Электрические реле, встроенные в многозвенные схемы, были одними из первых дискретных устройств управления для автоматизации всего процесса производства.

Системы управления набрали обороты, прежде всего в автомобильной и аэрокосмической отраслях. В 1950-х и 1960-х годах выход в космос вызвал интерес ко встраиваемым системам управления. Инженеры построили такие системы управления, как блоки управления двигателем и авиационный тренажер, которые могут быть частью конечного продукта. К концу XX века встраиваемые системы управления использовались повсеместно, так как даже предметы домашнего обихода, такие как стиральные машины и кондиционеры, содержали сложные и передовые алгоритмы управления, позволяющие им стать гораздо более «умными».

В 1969 году был внедрён первый компьтеризированный контроллер. Ранние программируемые логические контроллеры (ПЛК) имитировали операции уже имеющихся дискретных технологий управления, которые использовали устаревшие ступенчатые реле. Появление компьютерных технологий принесло радикальные изменения на рынок непрерывных и дискретных регуляторов. Общедоступный настольный компьютер с соответствующим аппаратным и программным обеспечением может работать со всем процессом, выполнять сложные, хорошо себя зарекомендовавшие ПИД-алгоритмы или работать в качестве распределенной системы управления (РСУ).

Трудности

Инструменты моделирования используются уже давно, но традиционных текстовых методов недостаточно для современных систем управления, имеющих сложный характер. Из-за ограниченности графических инструментов инженеры-конструкторы ранее в основном полагались на текстовое программирование и математические модели, однако отладка текстовых программ — весьма трудоёмкий процесс, требующий множества проб и ошибок, прежде чем будет создан окончательный полностью рабочий модуль. Кроме того, математические модели подвергаются существенным изменениям, проходя через различные этапы проектирования.

Эти проблемы решаются с помощью графических инструментов моделирования, уже используемых во всех областях проектирования. Такие инструменты образуют единую среду графического моделирования, уменьшают сложность построения модели, разбивая её на отдельные блоки, каждый из которых проектируется самостоятельно. Таким образом, конструкторы могут достигать высокого уровня точности, просто заменяя один блок на другой. Графические модели также являются лучшим способом документирования идей инженеров. Это помогает инженерам осмыслить всю систему и упрощает процесс переноса модели от одной стадии к другой во время проектирования. Симулятор EASY5 компании Boeing стал одним из первых инструментов моделирования, снабжённых графическим пользовательским интерфейсом.

При разработке встроенных систем управления конструкторы столкнулись с двумя проблемами — сокращением циклов разработки и ростом сложности проекта. Стратегия «разделяй и властвуй» для развития таких сложных систем означает координацию людей, имеющих опыт в широком спектре дисциплин. Традиционный текстовый подход к проектированию встроенных систем управления недостаточно эффективен, чтобы справляться с продвинутыми сложными системами.