CC BY
48
ОТЛАДКА ЗАГРУЗЧИКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ВСТРОЕННОЙ СИСТЕМЫ УПРАВЛЕНИЯ
Я.А. Домарацкий
Motorola Global Software Group, Russia
Загрузчик программного обеспечения (ПО) (системный загрузчик) является важной частью любой встроенной системы управления. Основные функции системных загрузчиков рассмотрены в [1]. Как правило, отладка системного загрузчика производится совместно с отладкой аппаратной части. В некоторых случаях (например, если аппаратная часть построена на основе новой модели центрального процессора) использование средств высокоуровневой отладки ПО в процессе разработки системного загрузчика не представляется возможным. Кроме того, при отладке кода системного загрузчика часто приходится иметь дело с дефектами аппаратуры (дефектами системного контроллера, производства платы и т.д.). Таким образом, задача эффективной организации процесса отладки системного загрузчика, рассматриваемая в данной статье, является актуальной.
Жизненный цикл разработки системного загрузчика
В большинстве случаев разработка системного загрузчика ведется параллельно с разработкой целевой аппаратной платформы и прикладного ПО. Как правило, выделяют четыре этапа жизненного цикла разработки системного загрузчика:
- разработка кода системного загрузчика;
- совместная верификация кода системного загрузчика и аппаратной модели;
- предварительная отладка системного загрузчика;
- отладка системного загрузчика на целевой аппаратной платформе.
Рассмотрим пример жизненного цикла разработки системного загрузчика. Предположим, что целевая аппаратная платформа представляет собой новую аппаратную платформу с точки зрения используемого центрального процессора (ЦП), системного контроллера и некоторых устройств ввода-вывода. Также предположим, что существует прототип кода системного загрузчика, созданный для другой аппаратной платформы, аппаратно независимые модули которого могут быть использованы.
Пример жизненного цикла разработки системного загрузчика в заданных условиях представлен на рисунке 1.
В целях сокращения общего времени разработки ПО этапы разработки кода системного за-
грузчика и этапы верификации и отладки кода системного загрузчика могут перекрываться.
Совместная верификация системного загрузчика, прикладного ПО и аппаратной модели
Техника совместной верификации программного обеспечения и аппаратной модели используется при разработке системных контроллеров, материнских плат и на этапе конечной интеграции системы. Основной целью этапа совместной верификации ПО и аппаратной модели служит выявление ошибок аппаратуры и ограничений, связанных с использованием аппаратуры (например, ошибок в архитектуре системного контроллера и ограничений, связанных с режимами работы системного контроллера). Чем раньше подобные ошибки будут выявлены, тем меньше риск того, что исправление ошибок аппаратуры потребует серьезных временных и финансовых затрат. Как показывают исследования, применение техники совместной верификации ПО и аппаратуры приводит к сокращению общего времени разработки до 20 % за счет обнаружения дефектов аппаратуры и ПО на ранних этапах разработки [2].
Проблемы совместной верификации ПО и аппаратуры
Главным условием применения техники совместной верификации ПО и аппаратуры является наличие модели ЦП. Для моделирования работы ЦП, как правило, совместно используются две модели ЦП: модель ЦП на уровне исполнимых команд (instruction set simulator - ISS) и модель шины ЦП (Bus Functional Model - BFM).
Модель ISS включает в себя модель внутренних регистров ЦП и модель исполнения отдельных команд ЦП. Модель ISS применяется как производителями процессоров на стадии разработки аппаратуры, так и производителями компиляторов для разработки модулей генерации машинного кода.
Модель BFM представляет собой модель ЦП с точки зрения внешней среды и применяется для моделирования транзакций на внешней шине процессора, происходящих вследствие исполнения машинного кода.
Как правило, различают следующие виды транзакций на шине ЦП:
- транзакции по выборке блоков кода и данных из внешней памяти;
Разработка кода системного загрузчика
Протестированная версия готова
Разработка кода инициализации сист. контроллера
Разработка первого прототипа
Совместная верификация программоного обеспечения и аппаратной модели
Модель системного контроллера доступна
Рис. 1. Пример жизненного цикла разработки системного загрузчика
- транзакции по записи блоков данных во внешнюю память;
- транзакции по чтению и записи отдельных машинных слов и частей машинного слова (один байт, два байта, четыре байта и т.д.) во внешнюю память;
- управляющие и синхронизационные транзакции.
Дополнительная информация о видах транзакций на шине ЦП в многопроцессорных системах может быть получена из документации по процессору MPC7450 компании Моторола [3].
В большинстве систем верификации ПО и аппаратуры совместно используются ISS и BFM модели. Как правило, организуется пошаговое моделирование работы ЦП отдельно в рамках ISS и BFM моделей. Данный подход имеет ряд существенных недостатков. Одним из которых является низкая точность результирующей модели. Как правило, не учитываются такие важные свойства ЦП, как возможность исполнения нескольких инструкций одновременно, переупорядочивание запросов обращения к подсистеме внешней памяти, предвыборка данных из подсистемы внешней памяти, динамическое предсказание условных переходов и т.д. Теоретически модель ISS может быть усложнена для учета перечисленных свойств ЦП. Однако усложнение
модели ЦП ведет к существенному снижению скорости моделирования. Использование полной ISS модели процессора может привести к тому, что время, затраченное на моделирование простейшего кода (например кода инициализации внутренних регистров ЦП и подсистемы памяти), достигнет нескольких часов. Более того, создание ISS модели сложных устройств (например, системы управления кэшированием первого, второго и третьего уровней) является чрезвычайно ресурсоемкой задачей.
Существуют техники повышения производительности ISS моделей. Однако ни одна из существующих ISS моделей не обеспечивает моделирования поведения ЦП при исполнении существенных объемов кода в реальном масштабе времени. Хорошим примером применения техники повышения производительности ISS моделей служит среда разработки ПО для архитектуры IA-64 компании Intel [4].
Применение системы DeskPOD для совместной верификации ПО и аппаратуры
Наиболее удобно, если модели разрабатываемых аппаратных компонент системы (например модель системного контроллера) используются совместно с доступными компонентами системы
(например с реальным экземпляром ЦП). Данный подход реализован в системе ВвзкРвй компании 1пс [5]. Тестируемая интегральная схема (ИС) помещается с систему ВвзкРОО, и система обеспечивает взаимодействие инструментальной машины и ИС на физическом уровне (на уровне подаваемых на ИС сигналов и на уровне принимаемых из ИС сигналов). В качестве тестируемой ИС может выступать как целевой процессор, так и прототип разрабатываемого системного контроллера. Инструментальная машина исполняет код симулятора ИС. Несколько систем БвзкРОВ могут быть объединены для верификации многопроцессорных аппаратных платформ.
Пример конфигурации стенда валидации модели системного контроллера двухпроцессорной платформы представлен на рисунке 2.
Инструментальная машина обеспечивает исполнение моделей аппаратных компонент системы (системного контроллера, внешних устройств), включая модель ^ХА&Н-памяти с загруженным кодом ПО. Исполнение ПО осуществляется на реальном экземпляре ЦП. Система DeskPod осуществляет интерфейс между инструментальной машиной и ЦП. Протокол сеанса моделирования представляет собой протокол сеанса обмена данными по шине системы в терминах ББМ модели.
В зависимости от продолжительности сеанса моделирования размер протокола моделирования может достигать десятков и даже сотен мегабайт. Таким образом, удобно вести компактные протоколы исполнения ПО на отдельных процессорах и использовать данные протоколы для первичного анализа поведения ПО и аппаратуры. В сложных случаях протокол сеанса моделирования может использоваться для локализации проблемы и для обсуждения проблемы с группой разработчиков аппаратного обеспечения.
Процесс совместной верификации системного загрузчика, прикладного ПО и аппаратной модели
Как правило, совместную верификацию ПО и аппаратной модели начинают с верификации ини-циализационного кода системного загрузчика. Инициализационный код системного загрузчика обычно исполняется из энергонезависимой памяти (например из FLASH-памяти). Инициализационный код осуществляет вывод процессора на штатный режим работы, настройку подсистемы управления внешним оперативным запоминающим устройством (ОЗУ) и инициализацию устройств ввода-вывода (например, инициализацию последовательного канала связи с конечным пользователем) [1]. Возможность верификации инициали-
зационного кода системного загрузчика на этапе разработки аппаратной части является наиболее ценной, так как позволяет обнаружить большую часть ошибок как в коде системного загрузчика, так и в моделях аппаратуры.
Процесс моделирования исполнения инициа-лизационного кода системного загрузчика может занимать от нескольких минут до нескольких часов в зависимости от производительности инструментальной машины, сложности моделей аппаратуры и объема исполняемого кода. Анализ протоколов сеанса моделирования в терминах ББМ модели также может занять часы работы. Таким образом, критерии завершения этапа верификации ПО варьируются в зависимости от доступных временных и аппаратных ресурсов (рис. 1).
Использование систем совместной верификации ПО и аппаратуры на этапе разработки системы является принципиально важной возможностью, позволяющей существенно сократить затраты, связанные с исправлением дефектов ПО и аппаратуры на начальных этапах запуска системы. К
Сетевое соединение
Сетевое соединение
Инструментальная
- модель сист. контроллера
- модель ОЗУ
- модель устр. ввода-вывода
- модель FLASH памяти
Рис. 2. Пример стенда валидации двухпроцессорной системы
сожалению, системы совместной верификации ПО и аппаратуры, подобные системе DeskPOD компании Simpod Inc., достаточно дороги как в приобретении, так и в обслуживании. Однако применение систем совместной верификации ПО и аппаратуры оправдано при разработке сложных программно-аппаратных комплексов.
Предварительная отладка системного загрузчика
Как правило, значительная часть кода системного загрузчика может быть отлажена при помощи так называемых демонстрационных плат. Разработчики центральных процессоров и коммуникационных контроллеров предоставляют демонстрационные платы разработчикам встроенного ПО для первичного ознакомления с целевой аппаратурой и для предварительной отладки ПО. Примером демонстрационной платы может служить система Sandpoint компании Моторола [6]. Обычно демонстрационная плата включает в свой состав ЦП, системный контроллер, подсистему внешнего ОЗУ и набор устройств ввода-вывода (последовательный порт, SPI порт, PCI порт и т.д.).
Отладка ПО может осуществляться с использованием:
- низкоуровневого встроенного отладчика;
- встроенного отладочного монитора и внешнего отладчика;
- внутрисхемного эмулятора и внешнего отладчика.
Низкоуровневый встроенный отладчик обычно входит в комплект поставки демонстрационной платы. Отладка с использованием внутрисхемного эмулятора является наиболее удобной с точки зрения полноты получаемой информации.
С использованием демонстрационной платы обычно могут быть отлажены следующие функции системного загрузчика:
- инициализация ЦП и подсистемы внешнего ОЗУ;
- часть кода инициализации устройств ввода-вывода;
- часть кода по организации сеанса обмена данными с пользователем;
- часть кода по загрузке, запуску и отладке прикладного ПО.
Конкретный перечень функций, поддающихся отладке с использованием демонстрационной платы, зависит от того, насколько близка аппаратная архитектура и набор устройств ввода-вывода демонстрационной платы к аппаратной архитектуре и набору устройств ввода-вывода целевой аппаратной платформы.
Отладка системного загрузчика на целевой аппаратной платформе
Наличие этапов совместной верификации кода ПО и аппаратной модели и предварительной от-
ладки кода ПО позволяет выявить большинство дефектов кода системного загрузчика до того, как начинается отладка системного загрузчика на целевой аппаратной платформе. Если целевая аппаратная платформа является сравнительно новой (например, если используется новая модель ЦП), наличие верифицированного кода системного загрузчика является ключевым фактором успеха на этапе совместной отладки системного загрузчика и целевой аппаратной платформы, так как существует возможность сравнения реального поведения системы с эталонным поведением системы, полученным на этапе верификации ПО. Пример схемы стенда для отладки загрузчика ПО встроенной системы управления представлен на рисунке 3.
Рис. 3. Пример схемы стенда отладки загрузчика ПО, встроенной системы
Как правило, использование встроенных низкоуровневых отладчиков и встроенных отладочных мониторов на этапе отладки системного загрузчика не представляется возможным ввиду отсутствия свободного места в энергонезависимой памяти целевой аппаратной платформы. Дополнительным аргументом против использования встроенных низкоуровневых отладчиков и встроенных отладочных мониторов является необходимость отладки системы в режиме, приближенном к режиму промышленной эксплуатации. Таким образом, применение внутрисхемного эмулятора является предпочтительным.
Эмулятор постоянного запоминающего устройства (ПЗУ) позволяет существенно сократить время, затрачиваемое на загрузку кода системного загрузчика в целевую плату. Логический анализатор позволяет снимать протоколы обмена данными на шине ЦП и сравнивать полученные протоколы с протоколами, полученными на этапе совместной верификации ПО и аппаратной модели. В некоторых случаях бывает полезно повторить сеанс моделирования поведения системы и сравнить эталонные протоколы обмена данными на шине ЦП с экспериментальными протоколами.
В статье рассмотрены вопросы организации процесса отладки загрузчика ПО встроенной системы управления. Выделены основные этапы отладки кода и представлены основные черты каждого этапа. Приведено описание средств отладки,
применяющихся при разработке системных загрузчиков. Отдельно рассмотрена техника совместной верификации ПО и аппаратной модели. Практика разработки системного загрузчика многопроцессорной системы с общей шиной на базе процессора МРС7450 компании Моторола показывает, что оптимальным является распределение усилий по верификации, предварительной отладке и окончательной отладке ПО системного загрузчика в соотношении 30, 20 и 50 % соответственно.
Список литературы
1. Домарацкий Я. Разработка загрузчика программного обеспечения встроенной системы управления. //Программные продукты и системы. - 2003. - № 4. - С. 12-16.
2. HW/SW Coverification Backgrounder, The difference is in the model, Simpod Inc.
3. MPC7450 RISC Microprocessor Family User's Manual, MPC7450UM/D 2/2003 Rev. 3.
4. SoftSDV: A Pre-silicon Software Development Environment for the IA-64 Architecture, R. Uhlig, R. Fishtein, O. Gershon, I. Hirsh, H. Wang. Intel Technology Journal Q4, 1999.
5. Enhanced Silicon Validation, White Paper, Version 1.0, Mar 2003, Simpod Inc.
6. Sandpoint Microprocessor Evaluation System User's Manual, SPX3BUM/D.
ЭКСПЕРИМЕНТАЛЬНАЯ СИСТЕМА МОДЕЛИРОВАНИЯ «WORMHOLE» СЕТЕЙ ПЕРЕДАЧИ ДАННЫХ
Н.А. Веселое, И.В. Машечкин
В настоящей работе рассматриваются сети передачи данных, использующие технологию передачи wormhole [17]. Подобные сети находят широкое применение при построении высокопроизводительных вычислительных комплексов, сетей управления технологическими процессами в производстве, систем управления военными объектами и т.д. Основной особенностью указанного класса сетей является используемая в них технология передачи данных, которая состоит в том, что любая информация передается в виде пакетов данных, однако для передачи каждого пакета необходимо устанавливать отдельное монопольное соединение между отправителем и адресатом, после установки которого данные пакета копируются непосредственно из памяти узла-отправителя в память узла-адресата. Пакет как бы растягивается по промежуточным узлам сети, последовательно занимая каналы от отправителя к получателю так, что в любой момент времени, в любой точке присутствует только небольшая, неделимая единица данных - часть пакета, называемая в английской терминологии flit (flow-control-unit). Обязательным условием является то, что один и тот же путь не может использоваться больше чем одним пакетом, то есть если канал занят передачей, то пришедший вновь пакет блокируется и ожидает его освобождения. В случае блокировки передача пакета приостанавливается, но он не теряется и не освобождает уже занятых каналов сети. Движение пакета возобновляется после того, как соответствующий канал становится свободным. Пакет целиком хранится только в момент отправки в узле-отправителе и в момент получения в узле-адресате, поэтому далее в работе в ряде мест мы будем использовать термин «сети без промежу-
точной буферизации пакетов» для обозначения м/огшНо1е сетей.
Так как первый промышленный вариант м/отшко1е сети (сеть МуппеХ) появился сравнительно недавно (менее десяти лет назад), то существует ряд проблем, связанных с использованием данного класса сетей на практике. Одной из таких проблем является расчет и оценка эффективности работы сети. Основной характеристикой эффективности функционирования любой сети является пропускная способность, которую можно определить как нагрузку, обслуживаемую сетью за единицу времени, или величину, обратную времени приема-передачи сообщения в сети. Тогда очевидно, что в наиболее общем виде пропускная способность зависит от двух параметров:
• емкости - свойства сетевой аппаратуры, которое является физической характеристикой работы компонентов системы и представляет собой потенциальную или пиковую нагрузку, которую сеть может обработать;
• задержки пакета - времени, которое пакет проводит в сети.
Емкость для любой конкретной сети представляется фиксированной величиной, и ее увеличение является задачей, лежащей в области разработки сетевого оборудования. Задержка пакета, хотя и зависит от емкости, но определяется также и множеством абонентов сети, создаваемой ими нагрузкой, используемыми путями передачи пакетов и т.д., то есть текущим состоянием сети. Очевидно, что задержка пакета есть случайная величина, поэтому целесообразно рассматривать среднюю задержку пакета, которая для любой конкретной сети с фиксированной емкостью является обобщенной характеристикой и в конечном итоге
