CC BY
170
УДК 004.716
РЕАЛИЗАЦИЯ ПЕРЕДАЧИ ПАКЕТОВ SPACEWIRE С ПОМОЩЬЮ СЕТИ ETHERNET
© 2014 В.В. Розанов, Е.Н. Яблоков
Санкт-Петербургский государственный университет аэрокосмического приборостроения
Поступила в редакцию 02.10.2014
В статье рассматривается прототип устройства передачи SpaceWire пакетов по каналу Ethernet и реализация такого устройства. Изучаются возможные проблемы при передаче пакетов, которые необходимо учесть для обеспечения корректной и быстрой работы моста. Проводится сравнительный анализ разрабатываемого прибора с современными аналогами, и указываются достоинства и недостатки каждого из них по сравнению с представленным прототипом.
Ключевые слова: Ethernet, SpaceWire, мост, фрейм, пакет
В наше время космическая промышленность в России, Европе и Северной Америке устанавливает высокие требования для встроенных систем связи. В соответствии с [1-3] спутники и пилотируемые космические корабли требуют сети с высокими скоростями передачи данных до десятков гигабит в секунду для обработки данных, компьютерных шин и расстояний 50100 м между соседними узлами. Кроме того, необходимы приемлемая кабельная масса - приблизительно 30-60 гр/м и гальваническая развязка. Недостаток технологии SpaceWire [4] основанной на IEEE 1355-1995 [5] и ANSI/TIA/EIA-644 [6] стандартах состоит в развертывании схемы кодирования данных-строба (DS) на физическом уровне. Таким образом, максимальная скорость передачи в ссылке SpaceWire достигает 400 Мбит/с, кабель SpaceWire имеет рекомендуемую длину 10 м и включает четыре витых пары (с приемлемой массой 80 гр/м). Из-за ограничения длины кабеля SpaceWire (10 м) и необходимости соединения удаленных сегментов сети SpaceWire, которая в состоянии передать пакеты, новое решение необходимо. Основное условие - минимальная задержка и максимальная простота. Ethernet и протоколы Гигабитного Ethernet - наиболее соответствующая технология в этой проблеме.
Ethernet - это протокол, управляющий передачей данных по локальной сети. LAN Ethernet обычно использует коаксиальный кабель или специальные классы витых пар. Обычно сети Ethernet обеспечивают скорости передачи до
Розанов Валентин Владимирович, инженер. E-mail: valentin. rozanov@guap. ru.
Яблоков Евгений Николаевич, научный сотрудник. Email: evgeny.yablokov@guap.ru.
10 Мбит/с. Устройства соединены кабелем и конкурируют за доступ, используя Множественный доступ с контролем несущей и обнаружением коллизий (CSMA/CD). В настоящее время в большинстве сетей LAN широко используются Fast-Ethernet и Gigabit-Ethernet. Скорости Fast-Ethernet и Gigabit-Ethernet составляют 100 Mbits/sec и 1000 Мбит/с соответственно. Также кабели Ethernet довольно дешевые.
В ходе анализа предметной области были поставлены следующие задачи: исследовать и выявить проблемы, возникающие при передаче пакетов SpaceWire в сети Ethernet; проанализировать различные варианты подключения моста Ethernet-SpaceWire; рассмотреть существующие современные аналоги разрабатываемого устройства.
Прототип моста Ethernet-SpaceWire. На
рис. 1 представлен прототип беспроцессорного сетевого моста Ethernet-SpaceWire. На плате расположены две ПЛИС Virtex (1) и Altera (2), разъем Ethernet (4), чип gigabit-ethernet, разъемы spacewire (3), тестовые выводы и индикация (6, 7). Virtex отвечает за работу с интерфейсами SpaceWire и решает задачу формирования поля данных для передачи SpaceWire пакетов по Ethernet, а также формирует пакеты SpaceWire из получаемых по Ethernet данных. Altera в свою очередь реализует формирование и передачу фреймов Ethernet, а также необходимую инкапсуляцию передаваемых SpaceWire данных. Чип, управляющий Ethernet портом, позволяет передавать данные на скорости 10/100/1000, работать в полном дуплексе и поддерживает функции расширенного фрейма (JumboFrame) [1].
4 2 7 3
1 6
Рис. 1. Мост GigabitEthernet-SpaceWire
Существуют различные варианты включения платы в сеть передачи данных. На рис. 2 представлены три способа подключения:
Сейчас ведутся работы по созданию моста с подключением варианта один (1), который будет тестироваться в процессе разработки с использованием схемы подключения варианта два (2). Третий вариант подключения моста в данной статье не рассматривается, но является перспективой исследования, создание этого устройства будет рассматриваться в будущем.
Для анализа проблем, которые могут возникнуть при передаче пакетов SpaceWire в сети Ethernet, проведено сравнение форматов пакетов (рис. 3). Формат пакетов идентичен по наименованиям и типам полей, а именно - заголовок, поле данных, конец пакета. Однако из рис. 3 видно, что заголовок Ethernet пакета имеет фиксированную длину 14 байт, поле данных ограничено 1500 байтами и не может быть менее 64 байт, а конец пакета представляет собой 4 байта CRC [2]. В отличие от Ethernet заголовок пакета SpaceWire может иметь разную длину в зависимости от типа адресации и информации,
1. подключение моста к сети SpaceWire и ПК напрямую. В данном варианте подключения не требуется маршрутизация Ethernet фреймов, что упрощает реализацию моста, позволяя избежать необходимости реализации протоколов стека TCP/IP;
2. подключение двух удаленных друг от друга сетей SpaceWire через Ethernet, посредством разрабатываемого моста;
3. мост Ethernet-SpaceWire, обеспечивающий объединение двух сетей - сети SpaceWire, реализованной на коммутаторах SpaceWire, и сети Ethernet, построенной на коммутаторе Gigabit-Ethernet. В последнем (третьем) варианте на разрабатываемом устройстве появляется необходимость реализовывать протоколы, работающие на третьем уровне модели OSI.
передающейся в заголовке; поле данных может быть бесконечно длинным или длиной в 1 байт; конец или ошибка конца пакета [3].
Исходя из вышесказанного, можно сделать вывод о необходимости дополнительной обработки пакетов SpaceWire перед отправкой по Ethernet при длине пакета более 1500 байт. Одним из способов дополнительной обработки является разделение пакета на части и введение дополнительных служебных полей в поле данных для обозначения частей пакета и очередности сборки на принимающей стороне. При длине пакета SpaceWire от 1 до 64 байт необходимо отправлять несколько пакетов по Ethernet, так как, в противном случае, отправляется большое количество бесполезной информации, что приводит к потере быстродействия. На рис. 4 представлен график, показывающий соотношение количества полезной информации в пакете к количеству передаваемых байт в поле данных.
Рис. 2. Варианты подключения платы Ethernet-SpaceWire
Рис. 3. Сравнение пакетов Ethernet и SpaceWire
Рис. 4. Отношение полезных данных к отправленным (в %): 1 - Ethernet, 2 - SpaceWire
Из графика видно, что максимальное количество полезной информации передается уже при 30-40 байтах в поле данных пакета SpaceWire. При таком количестве байт в пакете Ethernet полезность невысока и составляет 50% от передаваемой информации. Точка перегиба на кривой 1 образуется в результате того, что минимально возможное количество байт поля данных Ethernet составляет 64 байта, и в случае отправки одного байта полезной информации недостающие 63 байта поля данных дополняются нулями. Максимальное количество полезных данных отправляется при нагрузке пакета Ethernet в 1500 байт полезных данных. Это позволяет говорить о том, что при создании моста необходимо максимально загружать пакет Ethernet,
чтобы минимизировать потери в производительности и быстродействии. Из рассмотренного выше можно выделить следующие проблемы.
1. Низкая эффективность передачи данных при отправке коротких пакетов по Ethernet.
2. Необходимость дополнительной обработки длинных пакетов SpaceWire.
3. Неэффективность передачи CCode отдельными пакетами, в виду их малой длины (см. пункт 1).
Из устройств, аналогичных разработанному, были рассмотрены продукт фирмы Aeroflex (рис. 5а) [4] и продукт фирмы Shimafuji Electric (рис. 5б) [5]. В табл. 1 представлен сравнительный анализ устройств-аналогов с разрабатываемым прототипом.
Рис. 5. Устройства Ethernet - SpaceWire
б
а
Таблица 1. Сравнение устройств Ethernet - SpaceWire
АегоПех [4] Shimafuji Electric [5] GigabitEthernet - SpaceWireBridge
программная реализация аппаратная реализация аппаратная реализация
высокие задержки при передаче пакетов внедренный TCP/IP протокол подготовка нового формата, позволяющего передавать пакет SpaceWire по Ethernet
сложность работы устройства используется для связи с ПК возможность включения режима GigabitEthernet
высокое быстродействие вследствие отсутствия избыточности
Сравнительный анализ указанных устройств по передаче SpaceWire по Ethernet показал, что они объединяют в себе функции коммутаторов, передают данные с использованием уровня TCP/IP и реализованы программно. Для объединения двух физически удаленных друг от друга сетей функционал этих устройств усложняет работу и является избыточным.
Протокол взаимодействия. Сейчас используется упрощенный вариант протокола для передачи пакетов. Предлагается ввести маленький заголовок пакета. Заголовок будет содержать информацию, содержащую длину переданного пакета, номер пакета и тип передаваемого пакета. Первый байт заголовка содержит информацию о типе пакета и, соответственно, номер пакета. Вся информация занимает 1 байт. Тип пакета кодируется первыми двумя битами. 01 - пакет заканчивается EOP 10 - пакет заканчивается EEP 00 - часть пакета (пакет не закончен, будет дальнейшая передача)
11 - пакет CCODE
Номер пакета кодируется оставшимися 6 битами. Данное поле делится на 2 части - 4 и 2 бита. Номер пакета 4-х битный будет меняться циклически от 0 до 15. Номер пакета меняется только в том случае, если в пакете содержатся данные и пакет был передан полностью. Последние 2 бита кодируют номер кусочка пакета, если пакет состоит из нескольких частей. Если фрейм Ethernet содержит только управляющий код - номер пакета не изменяется. Длина пакета будет меняться от 0 до 255. Если пакет больше 255 - в длину все равно записывается 255 - для нас существенна информация только в том случае, если пакет маленький, до 46 байт. В любом другом случае - размер пакета SpaceWire ограничен размером пакета Ethernet (рис. 6). Таким образом, если приемная сторона сможет без проблем считать данные, если их меньше 46, а также зафиксировать потерю пакета в потоке.
Ethernet заголовок Тип, номер. Длина DATA CRC
номер части
Рис. 6. Измененный фрейм Ethernet
Кроме проблемы с передачей типа пакета и длины пакета существует свободного места в буфере приема. В этом случае предполагается каждый ответный пакет с данными снабжать дополнительной информацией о кредитовании, а именно - количеством пакетов максимальной длины, которое может принять устройство.
Размер данного поля делается 1 байт. Таким образом, каждый пакет содержит дополнительную информацию о состоянии приемной стороны (число кредитов). В случае длительного отсутствия пакетов - их можно посылать по таймеру (рис. 7).
Ethernet заголовок Тип, номер. Длина Кредит DATA CRC
номер части
Рис. 7. Передача информации о состоянии приемного буфера в фрейме Ethernet
Вариант передачи пакетов SpaceWire посредством Ethernet фреймами. Невозможно передавать пакеты SpaceWire напрямую 1 в 1. Во-первых, маленькие пакеты будут передаваться очень неэффективно (если пакет меньше 46 байт передавать надо все равно 64 байта). Во-вторых, большие пакеты нельзя в принципе
передать - пакет Ethernet ограничен 1500 байтами, то есть мы наложим ограничение на сам фрейм Ethernet. В-третьих, передача управляющих кодов одним пакетом в принципе неэффективна - 1 байт будет передаваться 64 байтами в Ethernet. Соответственно напрашивается вывод -передавать несколько пакетов одним фреймом
Ethernet. Однако необходимо при этом каким-то образом сделать какую то дескрипторную часть в самом пакете, которая будет описывать тип пакетов внутри пакета Ethernet. Как говорилось выше, сам фрейм Ethernet состоит из адреса получателя, адреса отправителя и поля EtherType, в
который пишется или тип фрейма Ethernet, либо длина пакета. Для передачи дополнительной информации вводятся 4 типа дескриптора (размер 1 байт). Дескрипторы будут помещаться перед самим пакетом SpaceWire.
Таблица 2. Описание дескрипторов
Сам дескриптор Описание Комментарии
01 LLLLLL пакет (или часть пакета), которая заканчивается EOP-ом LLLLLL - длина пакета ^+1). Т.е. если в 'том поле 0 - длина пакета 1, 1 -2 и т.д., то это поле может задавать длину пакета от 1 до 64 байт
10 LLLLLL пакет (или часть пакета), которая заканчивается EEP-ом такой же пакет, который заканчивается ошибочным концом пакета
00 LLLLLL промежуточный пакет. это просто часть пакета, неизвестно чем он заканчивается, размер от 1 до 64 байт
11 XXXXXX специальный символ XXXXXX - тип специального символа
Передача небольших пакетов. Если пакеты передаются в канале небольшого размера (до 64 байт), то они пакуется напрямую в поле данных с соответствующим дескриптором. И все попадают в поле данных пакета Ethernet (рис. 8.).
Передача больших пакетов. Если пакеты больше 64 байт, они делятся на более маленькие
и передаются внутри фрейма или фреймов Ethernet (рис. 9). Большой пакет SpaceWire разбивается на несколько маленьких длиной 64 байта. И последний маленький пакет заканчивается полем TL с типом конца всего пакета.
Рис. 8. Передача несколько небольших пакетов SpaceWire в фрейме Ethernet
Рис. 9. Передача длинного пакета SpaceWire в фрейме Ethernet
Передача управляющих кодов в пакете.
Для передачи управляющих кодов используются специальные TL коды. Пакет, который передается, разбивается на 2 части (рис. 10). Таким образом, сначала помещается часть пакета с кодом TL 00 и длиной этой части пакета. Потом идет код TL 11000000, обозначающий, что идет CCode. Потом - оставшаяся часть пакета c кодом конца пакета и его длиной. Так можно передать несколько кодов CC в одном фрейме Ethernet.
Передача неполного пакета. Может возникнуть ситуация, когда необходимо резко завершить фрейм Ethernet и отправить его неполным (поле данных меньше 46 байт). Таких ситуаций может быть несколько, их мы рассмотрим
ниже. Неполный фрейм (в данном случае - из-за экстренной передачи CCode) будет заполняться специальными кодами (рис. 11). Пакет завершается, а недостающий фрейм добивается специальным кодом TL равным 11 111111.
Рис. 10. Передача CCODE SpaceWire в фрейме Ethernet
Рис. 11. Передача незаполненного фрейма Ethernet
Выводы: решена проблема создания протокола моста SpaceWire-Ethernet. Был разработан вариант простого протокола, который позволяет
быстро решить проблему передачи пакетов и управляющих кодов SpaceWire, оценена функциональность протокола. Предложен вариант расширенной реализации протокола моста SpaceWire-Ethernet. Рассмотренные варианты подключения, реализованный протокол и предлагаемый протокол требуют разных подходов к реализации работы моста, и требует дополнительного исследования. Первоначальные исследования имеющихся аналогов показали избыточность по функционалу и сложность в работе, в то время как разрабатываемый прототип моста способен обеспечить передачу данных с минимальными задержками и максимальной простотой передачи.
СПИСОК ЛИТЕРАТУРЫ:
1. MicrelInc, Gigabit Ethernet Transceiver with RGMII Support, Reversion 1.2, February, 2014
2. Стандарт Ethernet IEEE 802.3
3. Шейнин, Ю.Е. Технология SpaceWire для параллельных систем и бортовых распределенных комплексов / Ю.Е. Шейнин, Т.В. Солохина, Я.Я. Пет-ричкович // Электроника: Наука, технология, бизнес. 2007. № 1. С. 38-49.
4. AerofexGaisler, GRESB Ethernet/SpaceWire Bridge, Version 1.5.9, January 2014.
5. SHIMAFUJI Electric Inc., Document No. EN210439003-0, STAND-ALONE SpaceWire to Gigabit Ether H/W specification, Date Published July 2012.
6. Virtex-5 FPGA Select IO Resources User Guide
7. ECSS Standard ECSS-E-ST-50-12C, "SpaceWire, Links, Nodes, Routers and Networks", Issue 1, European Cooperation for Space Data Standardization, July 2008.
IMPLEMENTATION OF TRANSFERRING SPACEWIRE PACKETS VIA ETHERNET NETWORK
© 2014 V.V. Rozanov, E.N.Yablokov Saint-Petersburg State University of Aerospace Instrumentation
The article considered a prototype device of SpaceWire packet transmission via Ethernet and the implementation of such a device. Possible problems in transmission packets are studying to ensure correct and fast operation of the bridge. The article presents a comparative analysis of the developing device with modern counterparts and identifies the advantages and disadvantages of each, compared with the present prototype.
Key words: Ethernet, SpaceWire, bridge, frame, packet
Valentin Rozanov, Engineer. E-mail: valentin. rozanov@guap. ru Evgeniy Yablokov, Research Fellow. E-mail: evgeny.yablokov@guap.ru
