ISSN 0236-235X (P)
ISSN 2311-2735 (E)

Journal influence

Higher Attestation Commission (VAK) - К1 quartile
Russian Science Citation Index (RSCI)

Bookmark

Next issue

2
Publication date:
16 June 2024

Improvement of debugging and testing increase performance techniques in multiprocessor systems

The article was published in issue no. № 3, 2012 [ pp. 86-89 ]
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 .
Аннотация:Важнейшей компонентой многопроцессорной вычислительной системы является коммуникационная сеть, или сеть обмена, с помощью которой процессоры соединяются друг с другом или с памятью. Наряду с шинами VME, PCI Express, HyperTransport и другими, для обеспечения межпроцессорного обмена бурно развивается интерфейс RapidIO. При разработке многопроцессорных систем на базе RapidIO отладка и первоначальное тестирование макетных и опытных образцов систем составляют серьезную самостоятельную проблему. Полноразмерное тестирование выполняется под операционными системами (в рассматриваемом случае – Linux и ОС РВ Багет 2.0 и 3.0), однако для успешного запуска операционных систем необходимо обеспечить достаточный уровень работоспособности и ком-муникационной сети, и процессорных узлов. В распоряжении разработчика тестов есть только сама аппаратура и программа ПЗУ, автоматически получающая управление при включении питания и поступлении сигнала RESET. В данной статье предложены два способа тестирования и отладки многопроцессорных систем, реализуемых на базе интерфейса RapidIO, позволяющие обходиться минимумом дополнительной аппаратуры. А также приводятся срав-нение этих способов с точки зрения эффективности применения и этапы построения тестирования на их основе. С помощью диаграмм последовательности UML представлены протокол для реализации встроенной RapidIO-консоли и протокол обмена данными с оконечными устройствами RapidIO для получения информации о результатах тести-рования. Для этих протоколов поясняется использование конкретных типов пакетов RapidIO. Данные способы тес-тирования многопроцессорных систем легли в основу тестирования систем на базе процессорных микросхем 1890ВМ6Я.
Authors: Lavrinov G.A. (lavrinov@cs.niisi.ras.ru) - SRISA RAS, Moscow, Russia
Keywords: console, the method, multiprocessor systems, testing, RapidIO
Page views: 10955
Print version
Full issue in PDF (7.64Mb)
Download the cover in PDF (1.33Мб)

Font size:       Font:

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

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

Подпись:  
Рис. 1. Схема подключения устройств 
многопроцессорной системы
При разработке многопроцессорных систем на базе 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].

Подпись:  
Рис. 2. Диаграмма последовательности UML работы 
встроенной RapidIO-консоли
Выбор этих операций обусловлен их наибольшей отлаженностью. Они относятся к служебным операциям контроллера 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.

Подпись:  
Рис. 3. Диаграмма последовательности 
UML протокола обмена по RapidIO пакетами 
типа MAINTENANCE READ и MAINTENANCE WRITE
Рассмотренные подходы к тестированию многопроцессорных систем на базе 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).


Permanent link:
http://swsys.ru/index.php?page=article&id=3220&lang=&lang=&like=1&lang=en
Print version
Full issue in PDF (7.64Mb)
Download the cover in PDF (1.33Мб)
The article was published in issue no. № 3, 2012 [ pp. 86-89 ]

Perhaps, you might be interested in the following articles of similar topics: