CC BY
67
дут отданы ресурсы процессора, может быть увеличено, а предоставляемое время, наоборот, уменьшено. Было замечено, что при отсутствии дополнительных потоков и использования стандартной функциональности обновления текстур подсистемы визуализации текстура размером 1920 на 1080 загружается в видеопамять за 5-8 мс, а также то, что задержка происходила не на этапе загрузки текстуры в видеопамять, а на этапе копирования нового видеокадра в пиксельный буфер -данный этап никак не связан с работой видеокарты и выполняется только центральным процессором. Это может означать то, что выполнение потока было приостановлено для выполнения других потоков с более высоким приоритетом. Данную проблему можно решить, если присвоить основному потоку программы (или потоку рендеринга, если поток рендеринга не является основным потоком программы), в котором происходит обновление пиксельных буферов, более высокий приоритет, чем у других потоков приложения.
В заключение можно сделать следующие выводы. Для воспроизведения видеоматериалов в подсистеме визуализации ТОС разработаны методы и алгоритмы воспроизведения видеоинформации в виртуальном трехмерном окружении; произведена оптимизация алгоритмов для достижения требуемого (не более 20 мс) времени генерации кадров в подсистеме визуализации при воспроизведении видеоинформации. Кроме того, разработана подсистема визуализации ТОС, внедрен программный модуль для декодирования видео, позволяющий обрабатывать видеофайлы на различных программно-аппаратных платформах.
Литература
1. Mamrosenko K.A. Training simulation systems for open distance learning // Proceedings Conference Open Distance Learning Towards Building Sustainable Global Learning Communities. Hanoi, Vietnam: The Gioi, 2010.
2. Гиацинтов А.М., Мамросенко К.А. Описание архитектуры подсистемы визуализации тренажерно-обучающих систем // Гагаринские чтения: тр. Междунар. молодеж. науч. конф. М.: ИЦ МАТИ, 2011. С. 85-87.
3. OpenGL 2.1 Reference Pages. URL: http://www.open-gl.org/sdk/docs/man/ (дата обращения: 18.05.2011).
4. Nicolas Schulz. Horde3D Documentation. URL: http://www.horde3d.org/docs/manual.html (дата обращения: 18.05.2011).
5. MPEG-2 video compression. URL: http://www.bbc.co.uk/ rd/pubs/papers/paper_14/paper_14.shtml (дата обращения: 18.05.2011).
6. YUV pixel formats. URL: http://www.fourcc.org/yuv.php (дата обращения: 18.05.2011).
7. NTUIT.ru: Курс: Common Intermediate ..: Лекция №11: Основы многозадачности. URL: http://www.intuit.ru/depart-ment/pl/cil/11/1.html (дата обращения: 18.05.2011).
References
1. Mamrosenko K.A., Conference Open Distance Learning Towards Building Sustainable Global Learning Communities, Hanoi, Vietnam, The Gioi, 2010.
2. Giatsintov A.M., Mamrosenko K.A., Gagarinskie chte-nija: trudy Mezhdunarodnoy molodezhnoy nauchnoy konferentsii (Readings from Gagarin: Proc. of International Yount Researchers Conference), Moscow, Informatsionniy centr MATI, 2011, pp. 85-87.
3. OpenGL 2.1 Reference Pages, available at: www.opengl. org/sdk/docs/man/ (accessed 18.05.2011).
4. Nicolas Schulz, Horde3D Documentation, available at: www.horde3d.org/docs/manual.html (accessed 18.05.2011).
5. MPEG-2 video compression, available at: www.bbc.co.uk/ rd/pubs/papers/paper_14/paper_14.shtml (accessed 18.05.2011).
6. YUV pixel formats, available at: www.fourcc.org/yuv.php (accessed 18.05.2011).
7. NTUIT.ru, Course, Common Intermediate, Lecture № 11, Multitasking Basis, available at: www.intuit.ru/department/pl/cil/ 11/1.html (accessed 18.05.2011).
УДК 519.68
СПОСОБЫ ПОВЫШЕНИЯ ЭФФЕКТИВНОСТИ ОТЛАДКИ И ТЕСТИРОВАНИЯ МНОГОПРОЦЕССОРНЫХ СИСТЕМ
Г.А. Лавринов
(НИИСИРАН, г. Москва, [email protected])
Важнейшей компонентой многопроцессорной вычислительной системы является коммуникационная сеть, или сеть обмена, с помощью которой процессоры соединяются друг с другом или с памятью. Наряду с шинами VME, PCI Express, HyperTransport и другими, для обеспечения межпроцессорного обмена бурно развивается интерфейс RapidIO. При разработке многопроцессорных систем на базе RapidIO отладка и первоначальное тестирование макетных и опытных образцов систем составляют серьезную самостоятельную проблему. Полноразмерное тестирование выполняется под операционными системами (в рассматриваемом случае - Linux и ОС РВ Багет 2.0 и 3.0), однако для успешного запуска операционных систем необходимо обеспечить достаточный уровень работоспособности и коммуникационной сети, и процессорных узлов. В распоряжении разработчика тестов есть только сама аппаратура и программа ПЗУ, автоматически получающая управление при включении питания и поступлении сигнала RESET. В данной статье предложены два способа тестирования и отладки многопроцессорных систем, реализуемых на базе интерфейса RapidIO, позволяющие обходиться минимумом дополнительной аппаратуры. А также приводятся сравнение этих способов с точки зрения эффективности применения и этапы построения тестирования на их основе. С помощью диаграмм последовательности UML представлены протокол для реализации встроенной RapidIO-консоли и протокол обмена данными с оконечными устройствами RapidIO для получения информации о результатах тести-
рования. Для этих протоколов поясняется использование конкретных типов пакетов RapidIO. Данные способы тестирования многопроцессорных систем легли в основу тестирования систем на базе процессорных микросхем 1890ВМ6Я.
Ключевые слова: RapidIO, тестирование, многопроцессорные системы, метод, консоль.
IMPROVEMENT OF DEBUGGING AND TESTING INCREASE PERFORMANCE TECHNIQUES
IN MULTIPROCESSOR SYSTEMS Lavrinov G.A. (SRISA RAS, Moscow, [email protected])
Abstract. Very important element of multiprocessor computing system is communication network used by process to provide communication with other processors or memory. Together with VME, PCI Express, HyperTransport and other buses of inter-processor communication, RapidIO interface is developed as well. Microprocessor systems based on RapidIO suffer significant difficulty and present a serious problem at debugging and beginning testing stage of trial and developmental models. Full scale testing is made with operating systems (in this case - Linux and OS PB Baget 2.0 and 3.0), however, successful start of operating systems, communication network and processor units are supposed to provide proper operating performance. Test designer has only hardware and ROM program that gets control automatically after power is on or RESET signal is received. This article provides two testing and debugging techniques of multiprocessor systems realized with RapidIO interface that can work with minimum amount of hardware. The article also provides comparison of these techniques viewing effectiveness in use and testing stage made on its basis. Using UML sequence chart, the article presents protocol that implements integrated RapidIO console and I/O RapidIO communication protocol for gathering information about testing results. It is shown how to use specific RapidIO packages. These testing techniques of multiprocessor systems became a basis for performing system test based on 1890BM6YA chips .
Keywords: RapidIO, testing, multiprocessor systems, method, console.
Сфера применения многопроцессорных систем неуклонно расширяется, охватывая все новые области в различных отраслях науки, бизнеса и производства. Усложняется и их исполнение. В силу этого необходимы новые подходы к тестированию таких систем.
Важнейшей компонентой многопроцессорной вычислительной системы является коммуникационная сеть, или сеть обмена, с помощью которой процессоры соединяются друг с другом или с памятью. Для обеспечения межпроцессорного обмена наряду с шинами VME, PCI Express, HyperTransport и другими бурно развивается интерфейс RapidIO (спецификация разработана некоммерческой организацией RapidIO Trade Association) [1]. Организация обмена настолько важна для многопроцессорной системы, что многие характеристики производительности и другие оценки выражаются отношением времени обработки ко времени обмена, соответствующим решаемым задачам. Стандарт RapidIO позволяет строить системы различных функциональных возможностей - от небольших вычислительных систем до суперЭВМ.
При разработке многопроцессорных систем на базе RapidIO отладка и первоначальное тестирование макетных и опытных образцов систем являются отдельной серьезной проблемой. Полноразмерное тестирование выполняется под операционными системами (в рассматриваемом случае - Linux и ОС РВ Багет 2.0 и 3.0), однако для их успешного запуска необходимо обеспечить достаточный уровень работоспособности и коммуникационной сети, и процессорных узлов. В распоряжении разработчика тестов имеются только сама аппаратура и программа ПЗУ (размещаемая в ПЗУ программа, автоматически получающая управление при включении питания и поступлении сигнала RESET). Такое тестирование является отдельным звеном в маршруте функционального кон-
троля [2]. Опишем два способа тестирования многопроцессорных систем на базе RapidIO, позволяющих обходиться минимумом дополнительной аппаратуры.
Первый способ опирается на возможности встроенной RapidIO-консоли программы ПЗУ. Эта консоль позволяет (после успешной инициализации коммутаторов RapidIO) подключиться к любому процессорному узлу и выйти на командный диалог с программой ПЗУ данного узла, что снижает затраты на дополнительное оборудование для тестирования и отладки функциональных узлов отдельных процессоров. Сокращается время на подготовку отдельного стенда для тестирования. Среди доступных команд есть команды загрузки данных с инструментальной машины (по zmodem^ или по протоколу TFTP через контроллер Ethernet) и передачи массивов данных из одного узла в другой. В качестве пересылаемых данных могут выступать тестовые программы и результаты их работы. На рисунке 1 показана схема подключения устройств для работы с RapidIO-консолью.
Рис. 1. Схема подключения устройств многопроцессорной системы
По спецификации интерфейса RapidIO передача сообщений осуществляется двумя операциями - DOORBELL и MESSAGE [3]. Пакет типа DOORBELL позволяет передавать сообщения размером 2 байта, пакет типа MESSAGE - размером от 8 до 4 096 байт, причем передача идет сег-ментированно, размер каждого сегмента не превышает 256 байт. Обе операции являются операциями с подтверждением.
Для реализации консоли достаточно передавать 2 байта (один для команды, другой для данных). Поэтому для построения RapidIO-консоли достаточно реализовать обмен пакетами типа DOORBELL. На рисунке 2 показана схема взаимодействия двух устройств системы - Мастера и Слэйва, где Мастером выступает устройство, инициирующее обмен по шине RapidIO. Основными командами являются команды соединения с устройством Слэйв, передача данных, разъединение и подтверждение получения команд. Испытуемым узлом выступает устройство Слэйв. С помощью RapidIO-консоли происходят запуск тестового ПО на испытуемом устройстве и вывод информации о процессе тестирования функциональных узлов данного процессорного устройства. На рисунке описана успешная работа консоли.
Второй способ делает акцент на распределенное тестирование для схемы стенда, изображенной на рисунке 1. Тестовое ПО выполняет следующие этапы.
1. Инициализация среды: определение устройств коммутационной среды Яар1^0 - как коммутаторов Яар1^0, так и оконечных устройств, количество которых доходит в малых сис-
темах до 256, a в больших до 16 К. При инициализации определяются пути к каждому устройству RapidIO многопроцессорной системы.
2. Тестирование каждого коммутатора RapidIO в отдельности для определения целостности сети обмена. Можно это выполнить и на этапе определения устройств. По мере нахождения каждого коммутатора проверяется его работоспособность.
3. Загрузка и запуск программных тестов на другие оконечные устройства RapidIO для проверки процессоров, системных контроллеров и контроллеров периферии.
4. Получение по RapidIO лог-файлов о результатах тестирования и вывод их на устройство вывода. Протокол передачи можно реализовать на служебных операциях чтения MAINTENANCE READ и записи MAINTENANCE WRITE [4].
Выбор этих операций обусловлен их наибольшей отлаженностью. Они относятся к служебным операциям контроллера RapidIO и используются для получения информации об устройствах и инициализации коммуникационной среды RapidIO. Обе операции являются операциями с подтверждением. Если в контроллере RapidIO операции MAINTENANCE READ и WRITE работать не будут, функционирование сети RapidIO невозможно. Наряду с данными служебными операциями спецификация предусматривает также служебную операцию MAINTENANCE PORT-WRITE, которая информирует процессор о проблеме в одном из коммутаторов среды RapidIO, поэтому она не рассматривается для построения протокола передачи.
Для протокола обмена данными по RapidIO, реализуемого в тестовом ПО на основе операций MAINTENANCE, в служебном адресном пространстве RapidIO необходимо определить свободный регистр, например, регистр Component Tag блока регистров логического уровня RapidIO CSR, который содержит определенное значение в качестве метки обрабатываемого устройства RapidIO и может изменяться программно. Он наиболее полезен для указания, что устройство не является оконечным в коммуникационной среде RapidIO и не может иметь ID. Кроме того, в регистре необходимо выделить область данных и область команд. На рисунке 3 приведен простейший протокол обмена. Хотя данный протокол обмена по RapidIO не согласуется с протоколом, представленным в спецификации [5], его применение облегчает работу по выявлению ошибок на RapidIO.
Мастер
Слэйв
Ввод команды соединения
Ввод символа
Вывод символа на дисплей
Вывод символа на дисплей
Ввод команды
разъединения""
DOORBELL( Соединение, пусто)
йООКБЕЩПодтверждение, пусто)
DOORBELL(Данное, символ1)
DOORBELL(Данное, символ1)
DOORBELL(Данное, символ2)
DOORBELL(Разъединение, пусто)
DOORBELL(Подтверждение, пусто)
Запуск
процесса Вывод символа S
Тест
на дисплей
Рис. 2. Диаграмма последовательности UML работы встроенной RapidIO-консоли
Мастер
Слэйв1
i i
I MAINTENANCE_WRITE(Старт1) ч |
<-
^ Данное1_1
MAINTEN¡ANCE_READ (Данное1_(М - 1))
MAINTENANCE_WRITE(СтартN)
MAINTENANCE_READ (Ожидает_передачу1)
MAINTENANCE_READ(Данное1_1) ,
^ Данное1_(М - 1)
MAINTENANCE_READ(Данное1_М) h
<-
MAINTENANCE_READ (Ожидает_передачу^
<-
MAINTENANCE_READ(ДанноеN_1)
<-
MAINTENANCE_READ (ДанноеN_(М - 1))
MAINTENANCE_READ(ДанноеN_М)
СлэйвЫ
^ ДанноеN_(М - 1)________^_____________
< Конец
, I .
Рис. 3. Диаграмма последовательности UML протокола обмена по RapidIO пакетами типа MAINTENANCE READ и MAINTENANCE WRITE
ДанноеN 1
Рассмотренные подходы к тестированию многопроцессорных систем на базе RapidЮ предъявляют минимальные требования к отлаженности среды RapidЮ. Первый способ тестирования со встроенной RapidЮ-консолью предусматривает отлаженную сеть обмена. Он полезен в случае тестирования контроллеров периферии процессорных устройств. Однако второй способ покрывает весь функционал многопроцессорной системы. Рассмотренные методы тестирования, работая
в режиме Мастер-Cлэйв, облегчают построение тестовых стендов, исключая подключение дополнительных кабелей, а иногда и инструментальных ЭВМ. Данные способы тестирования многопроцессорных систем применяются в системах на основе процессорных микросхем 1890ВМ6Я.
Литература
1. Fuller S. RapidIO. The Embedded Systems Interconnect. John Wiley & Sons, Ltd, 2005.
2. Бобков C. Г. Методика тестирования микросхем для компьютеров серии «багет» // Программные продукты и системы. 2007. № 3.
3. RapidIO Interconnect Specification. Part 2: Messsage Passing Logical Specification. Revision 2.2. RapidIO Trade Association, 2011. URL: http://www.rapidio.org/specs/current/RapidIO_ Rev_ 2.2_Specification.zip (дата обращения: 07.05.2012).
4. RapidIO Interconnect Specification. Part 1: Input/Output Logical Specification. Revision 2.2. RapidIO Trade Association, 2011. URL: http://www.rapidio.org/specs/current/RapidIO_Rev_ 2.2_Specification.zip (дата обращения: 07.05.2012).
5. RapidIO Interconnect Specification. Annex 2: Session Management Protocol Specification. Revision 2.2. RapidIO Trade Association, 2011. URL: http://www.rapidio.org/specs/current/Ra-pidIO_Rev_2.2_Specification.zip (дата обращения: 07.05.2012).
References
1. Fuller S., RapidIO. The Embedded Systems Interconnect. John Wiley & Sons, Ltd, 2005.
2. Bobkov S.G., Programmnye Produkty i Sistemy, 2007, no. 3.
3. RapidIO Interconnect Specification. Part 2: Messsage Passing Logical Specification. Revision 2.2. RapidIO Trade Association, 2C11, available at: www.rapidio.org/specs/current/Ra-pidIO_Rev_2.2_ Specification.zip (accessed 07.05.2012).
4. RapidIO Interconnect Specification. Part 1: Input/Output Logical Specification. Revision 2.2. RapidIO Trade Association, 2011, available at: www.rapidio.org/specs/current/RapidIO_Rev_ 2.2_Specification.zip (accessed 07.05.2012).
5. RapidIO Interconnect Specification. Annex 2: Session Management Protocol Specification. Revision 2.2. RapidIO Trade Association, 2011, available at: www.rapidio.org/specs/current/Ra-pidIO_Rev_2.2_Specification.zip (accessed 07.05.2012).
УДК 658.512.011.56:004.42
МЕТОДЫ СОКРАЩЕНИЯ КОЛИЧЕСТВА УЯЗВИМОСТЕЙ В СПЕЦИАЛЬНОМ ПРОГРАММНОМ ОБЕСПЕЧЕНИИ РЕАЛЬНОГО ВРЕМЕНИ
К.Г. Нархов
(НИИСИРАН, г. Москва, [email protected])
Настоящая статья посвящена вопросам автоматизации деятельности программиста, в частности, сокращению количества уязвимостей и ошибок в программном коде. Рассмотрены особенности разработки программ в среде технологических средств автоматизированной генерации специального программного обеспечения (ТСАГ СПО), а также приемы использования библиотеки, входящей в состав ТСАГ СПО для сокращений потенциальных уязвимостей в разрабатываемых программах. Приводится классификация типовых уязвимостей в программном обеспечении реального времени, анализируется каждый класс потенциальных уязвимостей с точки зрения частоты появления в программах, причин возникновения и методов их предотвращения средствами ТСАГ СПО. Некоторые потенциальные уязвимости рассмотрены с учетом особенностей конфигурации операционной системы реального времени. Для классификации уязвимостей были использованы статический анализатор и набор исходных текстов программ реального времени, разработанных в НИИСИ РАН. Общая база исходных текстов насчитывает 204 программных модуля (более 111 700 строк). Представлен пример сокращения потенциальных уязвимостей в программе генерации исходных текстов реального времени (ПГЕН РВ), которая входит в состав ТСАГ СПО. Продемонстрирован способ сокра-
