Software & Systems

Загрузчик программного обеспечения (ПО) (системный загрузчик) является важной частью любой встроенной системы управления. Основные функции системных загрузчиков рассмотрены в [1]. Как правило, отладка системного загрузчика производится совместно с отладкой аппаратной части. В некоторых случаях (например, если аппаратная часть построена на основе новой модели центрального процессора) использование средств высокоуровневой отладки ПО в процессе разработки системного загрузчика не представляется возможным. Кроме того, при отладке кода системного загрузчика часто приходится иметь дело с дефектами аппаратуры (дефектами системного контроллера, производства платы и т.д.). Та- ким образом, задача эффективной организации процесса отладки системного загрузчика, рассматриваемая в данной статье, является акту- альной. Жизненный цикл разработки системного загрузчика

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

-     разработка кода системного загрузчика;

-     совместная верификация кода системного загрузчика и аппаратной модели;

-     предварительная отладка системного загрузчика;

-     отладка системного загрузчика на целевой аппаратной платформе.

Рассмотрим пример жизненного цикла разработки системного загрузчика. Предположим, что целевая аппаратная платформа представляет собой новую аппаратную платформу с точки зрения используемого центрального процессора (ЦП), системного контроллера и некоторых устройств ввода-вывода. Также предположим, что существует прототип кода системного загрузчика, созданный для другой аппаратной платформы, аппаратно независимые модули которого могут быть использованы.

Пример жизненного цикла разработки системного загрузчика в заданных условиях представлен на рисунке 1.

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

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

Техника совместной верификации программного обеспечения и аппаратной модели используется при разработке системных контроллеров, материнских плат и на этапе конечной интеграции системы. Основной целью этапа совместной верификации ПО и аппаратной модели служит выявление ошибок аппаратуры и ограничений, связанных с использованием аппаратуры (например, ошибок в архитектуре системного контроллера и ограничений, связанных с режимами работы системного контроллера).  Чем раньше подобные ошибки будут выявлены, тем меньше риск того, что исправление ошибок аппаратуры потребует серьезных временных и финансовых затрат. Как показывают исследования, применение техники совместной верификации ПО и аппаратуры приводит к сокращению общего времени разработки до 20 % за счет обнаружения дефектов аппаратуры и ПО на ранних этапах разработки [2].

Проблемы совместной верификации ПО и аппаратуры

Главным условием применения техники совместной верификации ПО и аппаратуры является наличие модели ЦП. Для моделирования работы ЦП, как правило, совместно используются две модели ЦП: модель ЦП на уровне исполнимых команд (instruction set simulator – ISS) и модель шины ЦП (Bus Functional Model – BFM).

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

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

Как правило, различают следующие виды транзакций на шине ЦП:

-   транзакции по выборке блоков кода и данных из внешней памяти;

-   транзакции по записи блоков данных во внешнюю память;

-   транзакции по чтению и записи отдельных машинных слов и частей машинного слова (один байт, два байта, четыре байта и т.д.) во внешнюю память;

-   управляющие и синхронизационные транзакции.

Дополнительная информация о видах транзакций на шине ЦП в многопроцессорных системах может быть получена из документации по процессору MPC7450 компании Моторола [3].

В большинстве систем верификации ПО и аппаратуры совместно используются ISS и BFM модели. Как правило, организуется пошаговое моделирование работы ЦП отдельно в рамках ISS и BFM моделей. Данный подход имеет ряд существенных недостатков. Одним из которых явля- ется низкая точность результирующей модели. Как правило, не учитываются такие важные свойства ЦП, как возможность исполнения нескольких инструкций одновременно, переупорядочивание запросов обращения к подсистеме внешней памяти, предвыборка данных из под- системы внешней памяти, динамическое предсказание условных переходов и т.д. Теоретически модель ISS может быть усложнена для учета перечисленных свойств ЦП. Однако усложнение модели ЦП ведет к существенному снижению скорости моделирования. Использование полной ISS модели процессора может привести к тому, что время, затраченное на моделирование простейшего кода (например кода инициализации внутренних регистров ЦП и подсистемы памяти), достигнет нескольких часов. Более того, создание ISS модели сложных устройств (например, системы управления кэшированием первого, второго и третьего уровней) является чрезвычайно ресурсоемкой задачей.

Существуют техники повышения производительности ISS моделей. Однако ни одна из существующих ISS моделей не обеспечивает моделирования поведения ЦП при исполнении существенных объемов кода в реальном масштабе времени. Хорошим примером применения техники повышения производительности ISS моделей служит среда разработки ПО для архитектуры IA-64 компании Intel [4].

Применение системы DeskPOD для совместной верификации ПО и аппаратуры

Наиболее удобно, если модели разрабатываемых аппаратных компонент системы (например модель системного контроллера) используются совместно с доступными компонентами системы (например с реальным экземпляром ЦП). Данный подход реализован в системе DeskPod компании Simpod Inc [5]. Тестируемая интегральная схема (ИС) помещается с систему DeskPOD, и система обеспечивает взаимодействие инструментальной машины и ИС на физическом уровне (на уровне подаваемых на ИС сигналов и на уровне принимаемых из ИС сигналов). В качестве тестируемой ИС может выступать как целевой процессор, так и прототип разрабатываемого системного контроллера. Инструментальная машина  исполняет код симулятора ИС. Несколько систем DeskPOD могут быть объединены для верификации многопроцессорных аппаратных платформ.

Пример конфигурации стенда валидации модели системного контроллера двухпроцессорной платформы представлен на рисунке 2.Инструментальная машина обеспечивает исполнение моделей аппаратных компонент системы (системного контроллера, внешних устройств), включая модель FLASH-памяти с загруженным кодом ПО. Исполнение ПО осуществляется на реальном экземпляре ЦП. Система DeskPod осуществляет интерфейс между инструментальной машиной и ЦП. Протокол сеанса моделиро- вания представляет собой протокол сеанса обме- на данными по шине системы в терминах BFM модели.

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

Процесс совместной верификации системного загрузчика, прикладного ПО и аппаратной модели

Как правило, совместную верификацию ПО и аппаратной модели начинают с верификации инициализационного кода системного загрузчика. Инициализационный код системного загрузчика обычно исполняется из энергонезависимой памяти (например из FLASH-памяти). Инициализационный код осуществляет вывод процессора на штатный режим работы, настройку подсистемы управления внешним оперативным запоминающим устройством (ОЗУ) и инициализацию устройств ввода-вывода (например, инициализацию последовательного канала связи с конечным пользователем) [1]. Возможность верификации инициализационного кода системного загрузчика на этапе разработки аппаратной части является наиболее ценной, так как позволяет обнаружить большую часть ошибок как в коде системного загрузчика, так и в моделях аппаратуры.

Процесс моделирования исполнения инициализационного кода системного загрузчика может занимать от нескольких минут до нескольких часов в зависимости от производительности инструментальной машины, сложности моделей аппаратуры и объема исполняемого кода. Анализ протоколов сеанса моделирования в терминах BFM модели также может занять часы работы. Таким образом, критерии завершения этапа верификации ПО варьируются в зависимости от доступных временных и аппаратных ресурсов (рис. 1).

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

Предварительная отладка системного загрузчика

Как правило, значительная часть кода системного загрузчика может быть отлажена при помощи так называемых демонстрационных плат. Разработчики центральных процессоров и коммуникационных контроллеров предоставляют демонстрационные платы разработчикам встроенного ПО для первичного ознакомления с целевой аппаратурой и для предварительной отладки ПО. Примером демонстрационной платы может служить система Sandpoint компании Моторола [6]. Обычно демонстрационная плата включает в свой состав ЦП, системный контроллер, подсистему внешнего ОЗУ и набор устройств ввода-вывода (последовательный порт, SPI порт, PCI порт и т.д.).

Отладка ПО может осуществляться с использованием:

-   низкоуровневого встроенного отладчика;

-   встроенного отладочного монитора и внешнего отладчика;

-   внутрисхемного эмулятора и внешнего отладчика.

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

С использованием демонстрационной платы обычно могут быть отлажены следующие функции системного загрузчика:

-   инициализация ЦП и подсистемы внешнего ОЗУ;

-   часть кода инициализации устройств ввода-вывода;

-   часть кода по организации сеанса обмена данными с пользователем;

-   часть кода по загрузке, запуску и отладке прикладного ПО.

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

Отладка системного загрузчика на целевой аппаратной платформе

Наличие этапов совместной верификации кода ПО и аппаратной модели и предварительной отладки кода ПО позволяет выявить большинство дефектов кода системного загрузчика до того, как начинается отладка системного загрузчика на целевой аппаратной платформе. Если целевая аппаратная платформа является сравнительно новой (например, если используется новая модель ЦП), наличие верифицированного кода системного загрузчика является ключевым фактором успеха на этапе совместной отладки системного загрузчика и целевой аппаратной платформы, так как существует возможность сравнения реального поведения системы с эталонным поведением системы, полученным на этапе верификации ПО. Пример схемы стенда для отладки загрузчика ПО встроенной системы управления представлен на рисунке 3.

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

Эмулятор постоянного запоминающего устройства (ПЗУ) позволяет существенно сократить время, затрачиваемое на загрузку кода системного загрузчика в целевую плату. Логический анализатор позволяет снимать протоколы обмена данными на шине ЦП и сравнивать полученные протоколы с протоколами, полученными на этапе совместной верификации ПО и аппаратной модели. В некоторых случаях бывает полезно повторить сеанс моделирования поведения системы и сравнить эталонные протоколы обмена данными на шине ЦП с экспериментальными протоколами.

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