Самоидентификация узлов

Подробности

Родительская категория: Шина IEEE 1394 — FireWire

Категория: Конфигурирование шины и узлов IEEE 1394

На этапе самоидентификации узлы назначают себе уникальные идентификаторы, согласуют скоростные возможности и (не обязательно) выбирают диспетчера изохронных ресурсов. Самоидентификация выполняется под управлением корневого узла, организующего последовательное предоставление прав на самоидентификацию всем узлам сети. Получив это право, узел посылает пакет (или серию пакетов) самоидентификации, которые распространяются по всей шине. Закончив посылку пакетов, узел обменивается со своим родителем информацией о доступной скорости. В результате этого обмена пара соединенных портов становится сконфигурированной. Сконфигурированный порт — это активный порт, для которого установлен его тип (c-порт или p-порт) и согласована скорость.

Промежуточные узлы-ветки и корневой узел организуют передачу права самоидентификации всем узлам по порядку. Порядок, в котором узлы выполняют самоидентификацию, определяется нумерацией портов в промежуточных узлах (ветках и корне). Первым будет самоидентифицироваться конечный узел (лист), который подключен к порту корня с наименьшим номером и путь к которому лежит в узлах-ветках через порты с наименьшими номерами. Этот узел получит PHY_ID=0. Последним идентифицируется корень — он получает наибольший идентификатор.

На следующем рисунке приведены два варианта назначения идентификаторов, соответствующие деревьям, взятым из первого рисунка (а и в).

Право на самоидентификацию получает узел, которому по p-порту приходит сигнал Self_ID_Grant, а все его c-порты (если таковые есть) уже сконфигурированы. В ответ на предназначенный ему Self_ID_Grant узел отвечает передачей (вверх) префикса данных. Когда в ответ на это узел увидит снятие сигнала Self_ID_Grant, он посылает пакет(ы) самоидентификации. Пакет самоидентификации всегда передается на скорости S100. Пакет содержит информацию, описывающую физические свойства узла:

• идентификатор (PHY_ID), который узел назначает себе сам равным числу услышанных им пакетов самоидентификации (пакетов-0). Самый первый идентифицирующийся узел возьмет PHY_ID=0, корень получает наибольший идентификатор;
• число портов и их состояние: неактивен, c-порт или p-порт. Эту информацию узел получает на предшествующем этапе — при конфигурировании дерева;
• зазор арбитража, взятый по умолчанию (при смене топологии) или сохраненный с прошлого сеанса работы (до сброса);
• доступная скорость работы (определяется свойствами узла, заложенными разработчиком);
• отношение к питанию от шины, определяется аналогично;
• состояние LINK-уровня (бит L, определяется по факту включения);
• претензии на роль диспетчера (бит C), определяемые с участием прикладного ПО.

При числе портов более трех узел посылает серию пакетов самоидентификации. Пакеты самоидентификации слышат все узлы, по ним они могут строить карту топологии и карту скоростей. Прослушивая пакеты самоидентификации, узлы определяют диспетчера изохронных ресурсов — им станет узел с максимальным номером PHY_ID, у которого в пакете самоидентификации установлены биты C и L. Завершив передачу пакетов самоидентификации, узел посылает в p-порт сигнал Ident_Done. На это родительский узел отвечает префиксом данных и помечает свой соответствующий c-порт как сконфигурированный. При подаче сигнала Ident_Done узел с помощью смещения уровней сообщает доступную ему скорость работы; его родитель при передаче префикса данных аналогичным образом сообщает свою. Таким образом, на завершающем этапе самоидентификации узла его p-порт и соединенный с ним c-порт родительского узла согласуют и устанавливают максимально возможную скорость обмена друг с другом.

Промежуточный узел-ветка, получивший сверху сигнал Self_ID_Grant, транслирует его на свой несконфигурированный c-порт с наименьшим номером; на остальные порты он посылает префикс данных. Получив префикс данных с c-порта, промежуточный узел прекращает подачу сигнала Self_ID_Grant (вниз) и транслирует префикс данных вверх. Далее, если после прохождения пакета самоидентификации на c-порт приходит сигнал Ident_Done, узел ответит ему префиксом данных с указанием своей скорости и пометит данный порт как сконфигурированный. Когда промежуточный узел, у которого все c-порты сконфигурированы, снова получит сигнал Self_ID_Grant, он сам отправит пакет(ы) самоидентификации (во все активные порты), а затем и сигнал Ident_Done.

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

Карты топологии и скоростей

Подробности

Родительская категория: Шина IEEE 1394 — FireWire

Категория: Управление шиной IEEE 1394

Знание топологии шины дает информацию о возможностях ее оптимизации, которая может быть выполнена путем:

• сокращения максимального количества кабельных сегментов между самыми удаленными узлами. Это позволяет снижать задержки распространения сигналов, увеличивая эффективность использования шины (задержки являются бесполезной тратой времени);
• перегруппировки узлов с учетом поддерживаемых ими скоростей передачи, что позволяет более эффективно пользоваться высокоскоростными передачами.

Диспетчер шины собирает информацию о топологии и предоставляет ее по запросам чтения любым узлам сети — публикует карту топологии (Topology_Map). В этой карте после заголовка размещаются копии всех пакетов самоидентификации, посланных узлами во время самоидентификации. Диспетчер шины отвечает за контроль целостности карты — число p-портов (родительских) должно совпадать с числом c-портов (дочерних). Если целостность нарушена, диспетчер обнуляет поле длины карты и посылает управляющему приложению уведомление SB_EVENT.

По карте топологии диспетчер шины способен определить максимальное число хопов (кабельных сегментов) между узлами сети. Это позволяет определить минимальный зазор арбитража (subaction gap), не конфликтующий с пакетами квитирования, и сообщить его всем узлам сети. Минимальный зазор вычисляется через задержку распространения сигнала в кабельных сегментах и повторителях. Зазор арбитража должен быть больше, чем время оборота по шине: до истечения времени зазора арбитража передающий узел должен успеть получить квитанцию на пакет, посланный самому дальнему узлу. Вместо вычисления задержки диспетчер шины может измерить время оборота, посылая выбранному узлу пробный пакет Ping и измеряя время до прихода ответа — пакета самоидентификации (или серии этих пакетов). Измерение реальных задержек позволяет использовать кабели длиннее 4,5 м (если у них малое затухание) и узлы-повторители, вносящие задержку более 144 нс. Задание зазора осуществляется широковещательно пакетом конфигурирования с установленным битом T.

Карта топологии располагается с адреса 1000h в начальном пространстве узла-диспетчера шины, ее формат приведен на первом рисунке . В карте имеются следующие поля:

• length — длина карты (в байтах). Нулевая длина — признак некорректности карты. Длина проверяется до и после чтения информационных элементов. Несовпадение этих длин означает, что считанные элементы недостоверны (нужно повторить чтение карты, поскольку она только что изменилась);
• CRC — контрольный код;
• generation_number — номер генерации карты (увеличивается с каждой ее модификацией);
• node_count — число узлов сети;
• self_id_count — число пакетов самоидентификации в карте (может быть больше числа узлов, поскольку некоторые узлы могут посылать и по несколько пакетов самоидентификации;
• self_id_packet[i] — собственно пакеты самоидентификации.

По карте топологии диспетчер шины строит карту скоростей (Speed_Map), которая позволяет определить максимальную скорость, возможную при обмене между любой парой узлов. Логически карта представляет собой двухмерную матрицу, в которой каждой паре узлов с идентификаторами m и n соответствует байт кода скорости (speed_code). Младшие 3 бита этого байта соответствует коду скорости в формате поля xspd пакета самоидентификации. Фактически карта — это последовательность байтов speed_code[i], где I = 64×m + n. Формат карты скоростей приведен на рисунке ниже , ее заголовок аналогичен заголовку карты топологии. Доступ к карте скоростей выполняется аналогично карте топологий, с проверкой поля длины до и после обращения.

Прием и передача пакета

Подробности

Родительская категория: Шина IEEE 1394 — FireWire

Категория: Взаимодействие с физическим уровнем шины IEEE 1394

Прием пакета

Прием пакета иллюстрирует рисунке. После индикации начала приема (Data_On) принимается байт скорости SPD, определяющий также и формат (см. таблицу ниже). Далее принимаются байты данных — пакет, передаваемый по шине.

 

Во время индикации начала приема по шине данных передается байт ST, сообщающий состояние шины:

• ST[0] — Bus Reset, сброс шины;
• ST[1] — Arbitration Reset Gap Odd, признак зазора сброса арбитража и начала нового нечетного интервала справедливости;
• ST[2] — Arbitration Reset Gap Even, признак зазора сброса арбитража и начала нового четного интервала справедливости;
• ST[3] — Cycle Start Odd, признак начала нечетного цикла;
• ST[4] — Cycle Start Even, признак начала четного цикла;
• ST[5] — Subaction Gap, признак зазора арбитража. После сброса означает завершение сброса и инициализации шины.

Таблица. Кодирование скорости и формата принимаемого пакета

SPD[0:7]	Скорость, формат
0000 0000	S100 Legacy
0000 0001	S100 Beta
0000 0100	S200 Legacy
0000 0101	S200 Beta
0000 1000	S400 Legacy
0000 1001	S400 Beta
0000 1101	S800 Beta
1111 1111	DATA_ON, признак начала приема
Остальные значения	Резерв

 

Передача пакета

В ответ на запрос передачи пакета PHY, сигнализируя состояние Grant (Ctl[0:1] = 11), посылает LINK-уровню байт GT, в котором сообщает формат, скорость и тип разрешенной передачи. После этого он отдает управление интерфейсом LINK-уровню, указав состояние Grant (Ctl[0:1] = 11), а затем и прекращая управлять линиями Ctl[0:1] и D[0:7]. Теперь LINK устанавливает состояние Hold (Ctl[0:1] = 11), обозначая занятость интерфейса и шины, и начинает передавать пакет данных (состояние Transmit, Ctl[0:1] = 01). После передачи пакета LINK сигнализирует состояние MORE_INFO (Ctl[0:1] = 11), в котором по шине данных передается байт дополнительной информации AI[0:7]. В этом байте может присутствовать встроенный последующий запрос шины с указанием его формата, типа и скорости. После этого LINK указывает состояние Idle (Ctl[0:1] = 00), затем перестает управлять линиями Ctl[0:1] и D[0:7] и отдает управление PHY.

Получив право передачи пакета, LINK может послать только пакет, полностью удовлетворяющий свойствам, описанным байтом GT. Этот байт декодируется следующим образом:

• бит GT[0] задает тип формата: 0 — произвольный, 1 — B-формат;
• биты GT[1:3] задают тип гранта (пакета, разрешенного к передаче): 010 — изохронный, 101 — асинхронный, 110 — пакет начала цикла, 111 — немедленный (пакет квитирования), остальные значения зарезервированы;
• биты GT[5:6] задают скорость: 00 — S100, 01 — S200, 10 — S400, 11 — S800.

Байт дополнительной информации AI[0:7]содержит следующие поля:

• AI[0] — признак формата последующего запроса: 0 — произвольный, 1 — B-формат;
• AI[1:3] — тип встроенного запроса: 000 — нет запроса, 001 — PH_ISOCH_REQ_ODD, 010 — PH_ISOCH_REQ_EVEN, 011 — PH_CURRENT, 100 — PH_NEXT_EVEN, 101 — PH_NEXT_ODD, 110 — PH_CYC_START_REQ, 111 — резерв;
• AI[4] — признак последнего пакета в субакции;
• AI[5:6] — скорость для встроенного запроса: 00 — S100, 01 — S200, 10 — S400, 11 — S800;
• AI[7] — резерв.

Контроллеры DMA

Подробности

Родительская категория: Шина IEEE 1394 — FireWire

Категория: «Открытый» хост-контроллер IEEE 1394 — OHCI

Контроллеры DMA OHC по способу управления разделяются на два типа:

• контроллеры, работающие по программам контекстов. Программа контекста DMA — это связанный список дескрипторов, описывающих команды и связанные с ними буферы данных. Программу контекста, расположенную в системной памяти хоста, формирует программа (драйвер), исполняемая процессором хоста. По контекстным программам работают контроллеры асинхронной передачи и приема, обслуживающие пакеты запросов и ответов, генерируемые и отрабатываемые программой хоста. По контекстным программам работают и контроллеры изохронного приема и передачи. Управление каждым контекстом (фактически — каналом DMA) производится с помощью своего блока регистров;
• Контроллеры, обслуживающие аппаратно обрабатываемые внешние запросы к узлу. Эти контроллеры управляются регистрами; никаких контекстных программ для них не создается. К данному типу относятся следующие контроллеры:
       -----контроллеры блока физических запросов на внешние обращения к памяти хоста и автономым регистрам OHC;
       -----контроллер записи пакетов самоидентификации.

Контроллер асинхронной передачи (Asynchronous Transmit), AT DMA, имеет по одному контексту для передачи запросов (AT Request) и ответов (AT Responce). Для каждого отправленного пакета контроллер ожидает пакет квитирования; в случае получения квитанции ack_busy (занято) контроллер организует программно заданное число попыток повтора. Контроллер может реализовать однофазный или двухфазный протокол повторов. Если контроллер реализует изменение порядка исполнения, то он в случае занятости узла-получателя может продвигаться дальше по контекстной программе, возвращаясь к повтору данного пакета позже. Контроллер AT DMA отвечает и за ответы на запросы к физической памяти, обнаруженные принимающим контроллером DMA.

Прием асинхронных пакетов выполняют блок физических запросов и контроллер асинхронного приема.

Блок физических запросов, Physical Request Unit, включается в работу, когда приходит пакет запроса одного из трех типов:

• запрос к системной памяти хоста, доступной для узлов шины (лежащий в диапазоне нижних адресов);
• запрос блокированной транзакции (compare_swap), адресованный к одному из автономных регистров (для диспетчера изохронных ресурсов);
• запрос по адресу памяти конфигурации.

Остальные асинхронные пакеты обслуживает контроллер асинхронного приема (Asynchronous Receive), AR DMA, который имеет по одному контексту для приема запросов (AR Request) и ответов (AR Responce). Этот же контроллер обслуживаети запросы блокированных транзакций, адресованных не к регистрам изохронных ресурсов, помещая их в контекст AR Request.

Контроллер DMA изохронной передачи (Isochronous Transmit), IT DMA, поддерживает от 4 до 32 контекстов, каждый из которых обеспечивает передачу одного канала.

Контроллер DMA изохронного приема (Isochronous Receive) поддерживает от 4 до 32 контекстов, каждый из которых обеспечивает прием одного канала. Один из контекстов можно запрограммировать на прием множества каналов.

Специальный контроллер, Self_ID DMA, принимает пакеты самоидентификации и укладывает их последовательно в один выделенный буфер. После каждого обнаруженного сброса контроллер начинает укладку пакетов с начала буфера, затирая предыдущие пакеты.