а значит группировать их экранное изображение в порядке, необходимом пользователю.
В-пятых, предложенный подход может быть расширен для нескольких FPGA-модулей, использование которых возможно в составе ячейки. Для этого каскад ПЛИС объединяется посредством интерфейса SPI, мастером на котором выступает микроконтроллер. Каждой ПЛИС присваивается индивидуальный идентификационный номер, позволяющий ее идентифицировать со стороны микроконтроллера пульта. После идентификации работа с ЛА, встроенным в выбранную ПЛИС, производится так же, как и при одиночном варианте применения.
Расплата же за указанные выше преимущества, на наш взгляд, незначительна - разработчику необходимо резервировать порядка 20 контактов корпуса ПЛИС и определенное пространство кристалла для реализации встроенной части ЛА. Очевидно, объем занимаемой ЛА части кристалла пропорционален сложности как самого анализатора, так и применяемых в каналах функций расширенной обработки сигналов. Так, коэффициент использования кристалла ПЛИС в случае макета ЛА с учетом реализации в нем мегафункции PCI-устройства не превышает 15 % от общего числа его ресурсов. Для большей же эффективности проект следует реализовывать с применением ПЛИС таких семейств, как APEX, Cyclone, Stratix и др., поддерживающих на аппаратном уровне вышеупомянутую SignalTap-технологию и обладающих достаточным объемом встроенной памяти.
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Пьявченко А. О. Об одном из подходов к построению устройств функционального контроля и диагностики бортовых микропроцессорных систем // Известия ТРТУ -Таганрог. 2005. №1 (45). С.157-164.
2. Микропроцессоры: системы программирования и отладки / В.А.Мясников,
М.Б.Игнатьев, А.А.Кочкин, Ю.Е.Шейнин; Под ред. В.А.Мясникова, М.Б.Игнатьева. - М.: Энергоатомиздат, 1985. - 272 с.
3. Шумский И.А. Современный инструмент разработчика цифровых устройств- логические анализаторы Textronics серии TLA5000 // Контрольно-измерительные системы. 2004. №4. С.17-19 ; №>5. С.33-35.
4. Каршенбойм И. Микропроцессор своими руками -2. Битовый процессор // Компоненты и технологии. 2003. №8. С.48-53.
5. Altéra Documentation Library. June 2003/2004.
6. MegaCore Function User Guide. February 2003.: 101 Innovation Drive San Jose, CA 95134
7. PCI Local Bus Specification. Revision 2.2 //PCI Special Interest Group 2575 N.E. Kathryn #17 Hilsboro, Oregon 97124.
8. AN224 High-Speed Board Layout Guidelines // Altera Documentation Library.
9. AN106 Designing with 2.5-V Devices // Altera Documentation Library.
В.Е. Золотовский, Д.В. Золотовский СТРУКТУРА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ СИСТЕМ СТРУКТУРНОГО МОДЕЛИРОВАНИЯ
Задача симуляции физических объектов методами структурного моделирования требует разработки алгоритмов и специального программного обеспече -ния, реализующих их. Ниже описывается программная система моделирования. Структура программного обеспечения приведена на рис.1. Система содержит:
- три входных интерфейса: входной, визуальный и программный интерфейсы (блоки 1, 2, 3);
- блок формирования библиотеки объектов (блок 4);
- модуль автоматического построения полной модели системы (блоки 5,
6);
- модуль автоматического связывания объектов в соответствии со струк-турной схемой (блок 7);
- модуль автоматического формирования программной системы моделирования, включающий в себя подпрограмму распределения объектов по процессорам при параллельной реализации программы моделирования.
Входные интерфейсы системы моделирования
Рассмотрим (рис.1). Как уже было сказано, входной интерфейс обеспечивает ввод решаемой задачи в систему. Традиционно основным средством описания исследуемой системы объектов является командный язык среды моделирования. Этот язык обладает высокой гибкостью и значительно облегчает описание больших однородных схем. Однако в системах структурного моделирования целесообразнее использовать визуальный интерфейс графического ввода схемы. Данный способ позволяет скрыть сложность синтаксических конструкций командного языка, более нагляден и удобен, чем операторный способ описания систем. При вводе в систему моделирования больших сложных схем необходимо использовать принцип группировки моделей - иерархического представления схемы. Эти задачи успешно решаются при помощи визуального интерфейса.
Рис. 1. Входной интерфейс системы моделирования
При этом композиция схемы осуществляется из базового множества элементов системы моделирования (библиотеки элементов). Именно наличие библиотеки предопределённых элементов позволяет значительно сократить время описания больших схем.
Процесс постановки задачи состоит из следующих этапов:
1) определение исходной моделируемой системы в виде набора элементов и определения их взаимодействия друг с другом;
2) поиск модели, соответствующей каждому элементу исходной системы в библиотеке моделей. Если модель отсутствует, то вызывается процедура создания новой модели;
3) формирование структуры решаемой задачи посредством вызова и добавления в схему необходимых моделей из библиотеки, а также установки коммутаций между моделями.
Таким образом, входной интерфейс представляет собой редактор схемы компонент, позволяющий набирать схему из библиотечных элементов и определять связи и параметры элементов. Также во входной интерфейс включается редактор библиотеки, позволяющий определять новые компоненты. В соответствии с принципами структурного моделирования, на первом этапе создания моделирующего стенда необходимо иметь набор базовых библиотек, содержащих в себе описания математических моделей типовых объектов. При этом каждый раздел библиотеки ориентирован на одну из проблемных областей: электричество, механику, гидравлику и т.д.
В представлена на рис. 2.
Рис. 2. Графический вид иерархической структуры библиотеки
Каждый раздел библиотеки объектов строится по единой схеме и включает в себя следующие поля:
1. Имя библиотеки. Поле содержит уникальное имя данной библиотеки и является единственным.
2. Имя объекта. Поле содержит общее наименование объекта, описываемого в данной библиотеке.
3. Тип объекта. Поле описывает конкретную разновидность описываемого объекта или его упрощенный вариант.
4. Входные переменные. Описывается набор входных переменных объекта.
5. Выходные переменные. Описывается набор выходных переменных объекта.
6. Функции состояния объекта. Поле содержит имена функций, описывающих внутренние состояния объекта.
7. Функции управления объектом. Поле содержит имена функций управления объектом, которые являются внешними по отношению к нему.
8. Микропрограммы функций. В данном поле содержатся микропрограммы функций, описанные на низкоуровневом языке процессора моделирующей системы (данный раздел заполняется, если система работает с аппаратными программами).
Редактор библиотеки объектов
Рассмотрим реализацию редактора библиотеки структурных моделей. Одной из трудностей моделирования сложных систем является трудоемкость составления описания данной системы на языке моделирования, поскольку число элементов, составляющих систему, очень велико. Данная проблема решается определением базисного множества элементов, из которых состоит моделируемая система. Это определяет область применимости системы и позволяет значительно облегчить процесс создания моделируемых схем. Поэтому создание библиотеки элементов, разработка её формата и создание соответствующего редактора является очень важной задачей. Библиотека элементов находится на верхнем уровне структуры системы моделирования (см. предыдущий параграф). Для редактирования содержимого библиотеки и создания новых элементов был разработан специальный компонент системы, который называется “Library Navigator" (). Его внешний вид представлен на рис. 3. Данная форма отображается при выборе соответствующей опции сервисного меню «Library Navigator».
Element Condition
<|>| » I -»Ml
/1 element name |,Area Library sise Type | Active Breaker
Image
Рис. 3. Внешний вид редактора библиотеки
Кнопки на toolbar позволяют выбрать необходимый элемент для редактирования, а также вставить, сохранить или удалить элемент из библиотеки
Реализация формы редактора находится в модуле LibNavigator. Данная форма вызывается как при редактировании содержимого библиотеки, так и при редактировании математической модели. Функциями данной формы является предоставление интерфейса для редактирования содержимого библиотеки.
В.Б. Резников ОСОБЕННОСТИ ОРГАНИЗАЦИИ СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ ХРАНЕНИЯ МНОГОУРОВНЕВЫХ СТРУКТУРНЫХ МОДЕЛЕЙ
Интерфейс программирования системы моделирования прежде всего предназначен для удобного и быстрого описания сложных технических объектов. Решение этой задачи невозможно без поддержки повторно используемых моделей. Наиболее полно основы данного подхода изложены в [1]. Суть применения подобных моделей сводится к добавлению к системе моделирования средств сохранения и последующего использования моделей. В этом случае программирование сложных объектов производится путем их ассемблирования из элементарных объектов, которые хранятся в репозитарии - разделяемом инструментальными средствами системы хранилище артефактов проектирования [2]. Традиционно такие репозитарии организуются в виде локальных баз данных, в которые сохраняются элементарные модели, отсортированные по категориям. В этом случае хранилища образуют базис конструирования сложных моделей. Анализ таких традиционных схем организации баз моделей с точки зрения удовлетворения требований к современным системам моделирования, показал необходимость разработки специализированного средства - репозитария.
В основу данного средства были положены организационные схемы, расширяющие традиционные подходы к организации хранилищ моделей [1, 3, 4]. Особенностями данных схем являются: сохранение в базу данных композиционных (сложных) моделей в виде иерархических структур элементарных моделей и разбиение описания исходных моделей на несколько уровней абстракций, каждый из которых имеет свой вариант реализации. Данные свойства были расширены в сторону поддержки HLA-подхода, а именно использования распределенных баз данных и сохранения в репозитарии всех уровней структурных моделей.
Достоинства предлагаемого подхода - возможность модификации отдельных элементарных моделей без перестраивания сложных моделей, совместная разработка сложной системы территориально распределенной группой исследователей. И необходимо особо отметить, что сохранение в репозитарии всех уровней структурной модели позволяет, в отличие от традиционных баз моделей, накапливать, использовать повторно и разделять между исследователями данные проектирования в целом, что включает в себя не только поведенческие модели, но и их схемы взаимодействия (описываемые на функциональном уровне), алгоритмы расчета схем (алгоритмический уровень), а также дизайн виртуальных устройств (представляемых на описательном уровне). Всё это позволяет эффективно реализовать исследование сложных технических объектов группой исследователей или исследовательских учреждений, специализирующихся в различных областях науки, путем комбинирования их знаний. В результате возникает не только возможность одновременной корректировки всех разнородных моделей компонент сложного объекта, выполняемой специалистами соответствующих областей, но и повы-