Реализация передачи пакетов SpaceWire с помощью сети Ethernet

10 Мбит/с. Устройства соединены кабелем и конкурируют за доступ, используя Множественный доступ с контролем несущей и обнаружением коллизий (CSMA/CD). В настоящее время в большинстве сетей LAN широко используются Fast-Ethernet и Gigabit-Ethernet. Скорости Fast-Ethernet и Gigabit-Ethernet составляют 100 Mbits/sec и 1000 Мбит/с соответственно. Также кабели Ethernet довольно дешевые.

В ходе анализа предметной области были поставлены следующие задачи: исследовать и выявить проблемы, возникающие при передаче пакетов SpaceWire в сети Ethernet; проанализировать различные варианты подключения моста Ethernet-SpaceWire; рассмотреть существующие современные аналоги разрабатываемого устройства.

Прототип моcта 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].

Рис. 1. Мост GigabitEthernet-SpaceWire

Существуют различные варианты включения платы в сеть передачи данных. На рис. 2 представлены три способа подключения:

• 1.    подключение моста к сети SpaceWire и ПК напрямую. В данном варианте подключения не требуется маршрутизация Ethernet фреймов, что упрощает реализацию моста, позволяя избежать необходимости реализации протоколов стека TCP/IP;

• 2.    подключение двух удаленных друг от друга сетей SpaceWire через Ethernet, посредством разрабатываемого моста;

• 3.    мост Ethernet-SpaceWire, обеспечивающий объединение двух сетей – сети SpaceWire, реализованной на коммутаторах SpaceWire, и сети Ethernet, построенной на коммутаторе Gigabit-Ethernet. В последнем (третьем) варианте на разрабатываемом устройстве появляется необходимость реализовывать протоколы, работающие на третьем уровне модели OSI.

  

  Рис. 2. Варианты подключения платы Ethernet-SpaceWire

  
  

Сейчас ведутся работы по созданию моста с подключением варианта один (1), который будет тестироваться в процессе разработки с использованием схемы подключения варианта два (2). Третий вариант подключения моста в данной статье не рассматривается, но является перспективой исследования, создание этого устройства будет рассматриваться в будущем.

Для анализа проблем, которые могут возникнуть при передаче пакетов SpaceWire в сети Ethernet, проведено сравнение форматов пакетов (рис. 3). Формат пакетов идентичен по наименованиям и типам полей, а именно – заголовок, поле данных, конец пакета. Однако из рис. 3 видно, что заголовок Ethernet пакета имеет фиксированную длину 14 байт, поле данных ограничено 1500 байтами и не может быть менее 64 байт, а конец пакета представляет собой 4 байта CRC [2]. В отличие от Ethernet заголовок пакета SpaceWire может иметь разную длину в зависимости от типа адресации и информации, передающейся в заголовке; поле данных может быть бесконечно длинным или длиной в 1 байт; конец или ошибка конца пакета [3].

Исходя из вышесказанного, можно сделать вывод о необходимости дополнительной обработки пакетов SpaceWire перед отправкой по Ethernet при длине пакета более 1500 байт. Одним из способов дополнительной обработки является разделение пакета на части и введение дополнительных служебных полей в поле данных для обозначения частей пакета и очередности сборки на принимающей стороне. При длине пакета SpaceWire от 1 до 64 байт необходимо отправлять несколько пакетов по Ethernet, так как, в противном случае, отправляется большое количество бесполезной информации, что приводит к потере быстродействия. На рис. 4 представлен график, показывающий соотношение количества полезной информации в пакете к количеству передаваемых байт в поле данных.

Рис. 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

Aeroflex [4]	Shimafuji Electric [5]	GigabitEthernet – SpaceWireBridge
программная реализация	аппаратная реализация	аппаратная реализация
высокие задержки при передаче пакетов	внедренный    TCP/IP протокол	подготовка нового формата, позволяющего передавать пакет SpaceWire по Ethernet
сложность работы устройства	используется для связи с ПК	возможность включения режима GigabitEthernet
		высокое быстродействие вследствие отсутствия избыточности

Сравнительный анализ указанных устройств по передаче SpaceWire по Ethernet показал, что они объединяют в себе функции коммутаторов, передают данные с использованием уровня TCP/IP и реализованы программно. Для объединения двух физически удаленных друг от друга сетей функционал этих устройств усложняет работу и является избыточным.

Протокол взаимодействия. Сейчас используется упрощенный вариант протокола для передачи пакетов. Предлагается ввести маленький заголовок пакета. Заголовок будет содержать информацию, содержащую длину переданного пакета, номер пакета и тип передаваемого пакета. Первый байт заголовка содержит информацию о типе пакета и, соответственно, номер пакета. Вся информация занимает 1 байт. Тип пакета кодируется первыми двумя битами. 01 – пакет заканчивается EOP 10 – пакет заканчивается EEP

00 – часть пакета (пакет не закончен, будет дальнейшая передача)

• 11 – пакет ССODE

Номер пакета кодируется оставшимися 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 – длина пакета (L+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. Рассмотренные варианты подключения, реализованный протокол и предлагаемый протокол требуют разных подходов к реализации работы моста, и требует дополнительного исследования. Первоначальные исследования имеющихся аналогов показали избыточность по функционалу и сложность в работе, в то время как разрабатываемый прототип моста способен обеспечить передачу данных с минимальными задержками и максимальной простотой передачи.