Шина IEEE 1394 — FireWire

Шина IEEE 1394 — FireWire

BOSS-арбитраж в чистой B-шине

Метод BOSS использует возможность полнодуплексного обмена каждой пары соединенных узлов, которая имеется только в бета-режиме. В этом режиме запросы на управление шиной посылаются по передающей линии; запросы представляют собой специальные 10-битные символы, отличимые от символов кодов данных. Узел может посылать запросы в любые свои порты, не занятые передачей данных. По логике работы повторителей многопортовых узлов оказывается, что к узлу, ведущему передачу данных, сигнальные пути от всех других узлов шины свободны. Исходя из этого узлу, ведущему передачу последнего пакета субакции, логично стать «боссом» (BOSS) — принимать решение о том, какому из узлов предоставить право следующей передачи. Роль «босса» передается между PHY узлов шины по следующим правилам:

  • данный PHY станет «боссом», если он является источником пакета. По этому признаку боссом станет узел, посылающий пакет квитирования или пакет ответа физического уровня;
  • данный PHY станет «боссом», когда он явно или неявно получает право передачи. Явное получение права — прием символа GRANT или GRANT_ISOCH в качестве признака завершения пакета или в ответ на запрос арбитража. Неявное получение права происходит, когда принимающий PHY может самостоятельно определить, что субакция завершена (шина находится в изохронном интервале или последний пакет был пакетом квитирования в асинхронном интервале);
  • корневой узел берет на себя роль «босса» после длительного отсутствия активности на шине (из-за потери пакета квитирования или иной ошибки);
  • PHY перестает быть «боссом» по приему пакета, а также когда он явно или неявно предоставляет право передачи другому узлу.

Вместо интервалов покоя, используемых в традиционном механизме арбитража для обозначения завершения фазы самоидентификации при конфигурировании, завершения изохронного интервала, завершения субакции и границы интервала справедливости, в бета-режиме используются маркеры. Маркер (token) — это специальный управляющий символ, передаваемый «боссом» в течение времени, достаточного для его обнаружения по всей шине. Маркер может передаваться, когда шина находится в покое или когда она удерживается в занятом состоянии потоком символов DATA_NULL (маркеры встраиваются в этот поток).

Как и в традиционном режиме, передача пакетов ведется в двух интервалах — изохронном и асинхронном. Изохронный интервал начинается, когда мастер циклов передает маркер CYCLE_START_EVEN/ODD и пакет начала цикла. Заканчивается изохронный интервал, когда текущий «босс» не имеет относящегося к текущей фазе изохронного запроса от своего LINK-уровня или от какого-либо активного порта, работающего в бета-режиме. В этом случае «босс» передает маркер ASYNC_EVEN или ASYNC_ODD, означающий начало асинхронного интервала. Переход шины в состояние нормальной работы после самоидентификации происходит по маркеру ASYNC_EVEN, который передается корневым узлом после передачи его пакетов самоидентификации.

Асинхронный период (время, не занятое под изохронные интервалы), делится на интервалы справедливости. Граница интервала справедливости отмечается маркером ASYNC_EVEN (начало четного интервала справедливости) или ASYNC_ODD (начало нечетного интервала справедливости), отличающимся от предыдущего асинхронного маркера. Четные и нечетные интервалы чередуются. Возможно, что маркер ASYNC_EVEN/ODD одновременно будет означать и завершение изохронного интервала, и начало нового интервала справедливости. Для повышения устойчивости шины к потере маркера корневой узел, обнаружив покой шины, непрерывно посылает маркеры ASYNC_EVEN/ODD.

Передача запросов в виде символов позволяет осуществлять их приоритезацию и конвейеризацию, введя множество типов запросов и фаз шины. Изохронные и асинхронные интервалы делятся на свои четные (even) и нечетные (odd) фазы, чередующиеся независимо друг от друга. Изохронные фазы меняются по концу каждого изохронного интервала цикла (по маркеру ASYNC_EVEN/ODD). Асинхронные фазы меняются на границе каждого интервала справедливости, в соответствии с маркером ASYNC_EVEN/ODD. После сброса изохронные и асинхронные фазы считаются четными.

Запросы арбитража могут предназначаться как для текущей фазы, так и для последующей (противоположной), что является конвейеризацией запросов. PHY бета-узла посылает «боссу» изохронные и асинхронные запросы с наивысшим приоритетом, полученные от своего LINK-уровня или от других бета-портов. Приоритетность зависит от текущего интервала шины и фазы.

Вслед за передачей последнего пакета субакции текущий «босс» передает право на передачу для запроса, наиболее приоритетного для данного интервала и фазы. Если к этому времени «босс» не принял запросов, относящихся к данной фазе, он передачей одного или более маркеров меняет интервал (с изохронного на асинхронный) и/или фазу асинхронного интервала:

  • если шина находится в изохронном интервале и нет изохронного запроса к текущей фазе, то «босс» завершает изохронный интервал маркером ASYNC_EVEN/ODD, не меняя текущей асинхронной фазы;
  • если шина находится в асинхронном интервале и нет запроса к текущей фазе, то «босс» маркером ASYNC_EVEN/ODD меняет текущую асинхронную фазу (начинается новый интервал справедливости);
  • если и для новой асинхронной фазы нет запросов, то «босс» передает управление шиной узлу, стоящему выше него по иерархии. В конце концов, управление (роль «босса») получит корневой узел. Асинхронная фаза не будет сменяться другой до тех пор, пока в текущей фазе не будет передан хотя бы один пакет.

В асинхронном интервале узел может послать запрос для текущей фазы, только если он имеет бюджет приоритета для текущего интервала справедливости. Если бюджет исчерпан, то узел может послать запрос для следующей фазы, на который право передачи будет дано в следующем интервале справедливости. Таким образом, сменой фаз осуществляется справедливый арбитраж без потерь времени на зазоры. Асинхронные фазы меняются только тогда, когда все узлы, имеющие пакеты для передачи в данной фазе, выполнят эти передачи.

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

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

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

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

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

Диспетчер шины собирает информацию о топологии и предоставляет ее по запросам чтения любым узлам сети — публикует карту топологии (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. Формат карты скоростей приведен на рисунке ниже , ее заголовок аналогичен заголовку карты топологии. Доступ к карте скоростей выполняется аналогично карте топологий, с проверкой поля длины до и после обращения.

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

Прием пакета

Прием пакета иллюстрирует рисунке. После индикации начала приема (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

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

Яндекс.Метрика