Программные продукты и системы

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

Важнейшей компонентой многопроцессорной вычислительной системы является коммуникационная сеть, или сеть обмена, с помощью которой процессоры соединяются друг с другом или с памятью. Для обеспечения межпроцессорного обмена наряду с шинами VME, PCI Express, Hyper­Transport и другими бурно развивается интерфейс RapidIO (спецификация разработана некоммерческой организацией RapidIO Trade Association) [1]. Организация обмена настолько важна для многопроцессорной системы, что многие характеристики производительности и другие оценки выражаются отношением времени обработки ко времени обмена, соответствующим решаемым задачам. Стандарт RapidIO позволяет строить системы различных функциональных возможностей – от небольших вычислительных систем до суперЭВМ.

При разработке многопроцессорных систем на базе RapidIO отладка и первоначальное тестирование макетных и опытных образцов систем являются отдельной серьезной проблемой. Полноразмерное тестирование выполняется под операционными системами (в рассматриваемом случае – Linux и ОС РВ Багет 2.0 и 3.0), однако для их успешного запуска необходимо обеспечить достаточный уровень работоспособности и коммуникационной сети, и процессорных узлов. В распоряжении разработчика тестов имеются только сама аппаратура и программа ПЗУ (размещаемая в ПЗУ программа, автоматически получающая управление при включении питания и поступлении сигнала RESET). Такое тестирование является отдельным звеном в маршруте функционального контроля [2]. Опишем два способа тестирования многопроцессорных систем на базе RapidIO, позволяющих обходиться минимумом дополнительной аппаратуры.

Первый способ опирается на возможности встроенной RapidIO-консоли программы ПЗУ. Эта консоль позволяет (после успешной инициализации коммутаторов RapidIO) подключиться к любому процессорному узлу и выйти на командный диалог с программой ПЗУ данного узла, что снижает затраты на дополнительное оборудование для тестирования и отладки функциональных узлов отдельных процессоров. Сокращается время на подготовку отдельного стенда для тестирования. Среди доступных команд есть команды загрузки данных с инструментальной машины (по zmodem’у или по протоколу TFTP через контроллер Ethernet) и передачи массивов данных из одного узла в другой. В качестве пересылаемых данных могут выступать тестовые программы и результаты их работы. На рисунке 1 показана схема подключения устройств для работы с RapidIO-консолью.

По спецификации интерфейса RapidIO передача сообщений осуществляется двумя операциями – DOORBELL и MESSAGE [3]. Пакет типа DOORBELL позволяет передавать сообщения размером 2 байта, пакет типа MESSAGE – размером от 8 до 4 096 байт, причем передача идет сегментированно, размер каждого сегмента не превышает 256 байт. Обе операции являются операциями с подтверждением.

Для реализации консоли достаточно передавать 2 байта (один для команды, другой для данных). Поэтому для построения RapidIO-консоли достаточно реализовать обмен пакетами типа DOORBELL. На рисунке 2 показана схема взаимодействия двух устройств системы – Мастера и Слэйва, где Мастером выступает устройство, инициирующее обмен по шине RapidIO. Основными командами являются команды соединения с устройством Слэйв, передача данных, разъединение и подтверждение получения команд. Испытуемым узлом выступает устройство Слэйв. С помощью RapidIO-консоли происходят запуск тестового ПО на испытуемом устройстве и вывод информации о процессе тестирования функциональных узлов данного процессорного устройства. На рисунке описана успешная работа консоли.

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

1.     Инициализация среды: определение устройств коммутационной среды RapidIO – как коммутаторов RapidIO, так и оконечных устройств, количество которых доходит в малых системах до 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, реализуемого в тестовом ПО на основе операций MAIN­TENANCE, в служебном адресном пространстве RapidIO необходимо определить свободный регистр, например, регистр Component Tag блока регистров логического уровня RapidIO CSR, который содержит определенное значение в качестве метки обрабатываемого устройства RapidIO и может изменяться программно. Он наиболее полезен для указания, что устройство не является оконечным в коммуникационной среде RapidIO и не может иметь ID. Кроме того, в регистре необходимо выделить область данных и область команд. На рисунке 3 приведен простейший протокол обмена. Хотя данный протокол обмена по RapidIO не согласуется с протоколом, представленным в спецификации [5], его применение облегчает работу по выявлению ошибок на RapidIO.

Рассмотренные подходы к тестированию многопроцессорных систем на базе RapidIO предъявляют минимальные требования к отлаженности среды RapidIO. Первый способ тестирования со встроенной RapidIO-консолью предусматривает отлаженную сеть обмена. Он полезен в случае тестирования контроллеров периферии процессорных устройств. Однако второй способ покрывает весь функционал многопроцессорной системы. Рассмотренные методы тестирования, работая в режиме Мастер-Слэйв, облегчают построение тестовых стендов, исключая подключение дополнительных кабелей, а иногда и инструментальных ЭВМ. Данные способы тестирования многопроцессорных систем применяются в системах на основе процессорных микросхем 1890ВМ6Я.

Литература

1.     Fuller S. RapidIO. The Embedded Systems Interconnect. John Wiley & Sons, Ltd, 2005.

2.     Бобков С.Г. Методика тестирования микросхем для компьютеров серии «багет» // Программные продукты и системы. 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/Ra­pidIO_ 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).