link0 link1 link2 link3 link4 link5 link6 link7 link8 link9 link10 link11 link12 link13 link14 link15 link16 link17 link18 link19 link20 link21 link22 link23 link24 link25 link26 link27 link28 link29 link30 link31 link32 link33 link34 link35 link36 link37 link38 link39 link40 link41 link42 link43 link44 link45 link46 link47 link48 link49 link50 link51 link52 link53 link54 link55 link56 link57 link58 link59 link60 link61 link62 link63 link64 link65 link66 link67 link68 link69 link70 link71 link72 link73 link74 link75 link76 link77 link78 link79 link80 link81 link82 link83 link84 link85 link86 link87 link88 link89 link90 link91 link92 link93 link94 link95 link96 link97 link98 link99 link100 link101 link102 link103 link104 link105 link106 link107 link108 link109 link110 link111 link112 link113 link114 link115 link116 link117 link118 link119 link120 link121 link122 link123 link124 link125 link126 link127 link128 link129 link130 link131 link132 link133 link134 link135 link136 link137 link138 link139

PersCom — Компьютерная Энциклопедия Компьютерная Энциклопедия

Шина IEEE 1394 — FireWire

Управление шиной IEEE 1394

Мастер циклов

Общая информация

Шина IEEE 1394, обеспечивая равноранговые взаимодействия между узлами, нуждается в централизованном управлении некоторыми функциями. Управляющие функции могут брать на себя разные узлы шины; в зависимости от наличия реализации тех или иных функций различают следующие варианты шины IEEE 1394:

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

Мастер циклов

Мастер циклов (Cycle Master) отвечает за регулярную передачу пакетов начала цикла. Для этого он должен быть устройством с поддержкой изохронных обменов, иметь регистры CYCLE_TIME и BUS_TIME. В информационном блоке BUS_INFO_BLOCK его памяти конфигурации должен быть установлен бит cmc (Cycle Master Capable) — признак способности к исполнению этой роли. Текущим мастером циклов является узел, у которого в регистре состояния (STATE) установлен бит cmstr (Cycle Master). Все узлы, кроме корневого, во время идентификации дерева (после сброса) должны обнулить у себя этот бит; корневой узел должен сохранять значение, которое было до сброса.

Если выбранный корневой узел не способен быть мастером циклов, а требуются изохронные передачи, то из узлов, способных быть мастером (судя по биту cmc), выбирается новый кандидат на роль корня. Для этого посылается широковещательный PHY-пакет конфигурирования с идентификатором нового кандидата и установленным битом R. Этот узел установит у себя бит RHB, а остальные его сбросят, что и обеспечит выбор данного узла новым корнем во время идентификации, вызванной посылкой этого пакета.

Мастер циклов является источником системного времени; для этого он имеет регистры CYCLE_TIME и BUS_TIME. Текущее значение регистра CYCLE_TIME передается мастером циклов в пакетах начала цикла. Сброс на шине (в любой форме) на значения этих регистров не влияет.

Регистр CYCLE_TIME (32 бита, рис. а) состоит из трех полей, соответствующих значениям трех счетчиков, соединенных каскадно:

  • cycle_offset — 12-битный счетчик по модулю 3072 (максимальное значение 3071, после него обнуляется), считающий импульсы с частотой 24,576 МГц. Период этого счетчика соответствует номинальной длительности цикла — 125 мкс;
  • cycle_count — 13-битный счетчик по модулю 8000, считающий циклы. Период этого счетчика — 1 с;
  • second_count — 7-битный счетчик, считающий секунды; период счета — 128 с.

Регистр BUS_TIME (32 бита, рис. б) содержит значение системного времени в секундах. Его младшие 7 бит (second_count_lo) отображают поле second_count предыдущего регистра. Остальные 25 бит (second_count_hi) отсчитывают 128-секундные интервалы. Период счетчика составляет 232 = 4 294 967 296 с (около 136 лет).

Диспетчер изохронных ресурсов

Диспетчер изохронных ресурсов, IRM (Isochronous Resources Manager), — узел, ведающий распределением номеров каналов и полосы шины для изохронных передач. Диспетчер требуется, когда на шине появляется хоть одно устройство, способное к изохронной передаче. Диспетчер выбирается в процессе самоидентификации узлов из числа узлов, претендующих на эту роль. Претендентами являются узлы, которые сообщают в своем пакете самоидентификации единичные значения битов L (LINK активен) и C (Contender — участник состязания). Все узлы, интересующиеся диспетчерами, слушают пакеты самоидентификации и запоминают идентификатор победителя — претендента с наибольшим номером узла. Узел-претендент «сдается», если его идентификатор меньше запомненного идентификатора победителя. Победитель (единственный «не сдавшийся» узел) становится диспетчером изохронных ресурсов. Через него можно будет найти и диспетчера шины.

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

  • поддержка изохронных обменов (как источник или приемник);
  • активность канального уровня и уровня транзакций во время процесса конфигурирования;
  • наличие в памяти конфигурации блока BUS_INFO_BLOCK, в котором установлен бит IRMC (способность исполнять роль IRM);
  • наличие регистра BUS_MANAGER_ID, поддерживающего блокированную транзакцию (условную запись);
  • наличие регистров доступных каналов и пропускной способности (CHANNELS_AVAILABLE и BANDWIDTH_AVAILABLE).

Специальные регистры диспетчера изохронных ресурсов находятся в области регистров последовательной шины начального пространства регистров узла.

При отсутствии диспетчера шины IRM отвечает за назначение мастера циклов: если текущий корень не исполняет эту роль, то IRM для этой цели выбирает иной узел (в том числе и себя). Механизм смены корня по этому поводу описан в предыдущем параграфе. При отсутствии диспетчера шины на IRM ложатся еще и минимальные обязанности по управлению питанием — отправка команды на включение LINK-уровня всем узлам. Отсутствие диспетчера шины IRM определяет по своему регистру Bus_Manager_ID (смещение 2C1h, используются только 6 младших бит): если через 625 мс после сброса его значение не отличается от 3Fh, значит, диспетчера шины нет.

После сброса устройства, нуждающиеся в изохронной передаче, запрашивают у диспетчера изохронных ресурсов выделение номера канала и полосы пропускания. Для распределения каналов служит 64-битный регистр CHANNEL_AVAILABLE (смещение 224h), представляющий собой битовую карту, в которой каждому возможному изохронному каналу ch# соответствует свой бит (ch0 — в младшем бите).

Единичное значение бита соответствует доступности (незанятости) данного канала. Начальное значение регистра — FFFF FFFFh (все каналы доступны). При запросе выделения канала бит сбрасывается, при освобождении — устанавливается.

Запрос и освобождение канала выполняются одинаково. Узел, запрашивающий выделение или освобождение канала, первым делом считывает значение регистра CHANNEL_AVAILABLE, чтобы определить текущую ситуацию, и формирует свое предложение по новому значению этого регистра. Далее, он обращается к регистру CHANNEL_AVAILABLE блокированной транзакцией compare_swap, в которой в качестве аргумента (arg_value) передает прежнее (считанное) значение, а в качестве значения (data_value) — свое новое предложение. Данная транзакция в случае совпадения текущего значения регистра с аргументом заменяет его значение на новое, то есть регистр CHANNEL_AVAILABLE принимает новое значение. При этом транзакция возвращает запрашивающему узлу значение регистра, считанное на момент начала выполнения блокированной транзакции. Если это значение совпадает с ранее считанным значением, значит, диспетчер принял новое назначение каналов — выделил узлу или освободил запрошенный канал (можно и группу каналов одновременно). Если совпадения нет, это значит, что какой-то другой узел между нашими двумя транзакциями успел изменить содержимое регистра — занять или освободить канал. В этом случае запрашивающий узел должен повторить попытку, при этом новое текущее значение регистра он уже знает.

Для распределения полосы пропускания служит регистр BW_AVAILABLE (смещение 220h), в котором младшие 13 бит (bw_remaining) содержат число единиц распределения полосы шины (bus allocation units), оставшееся доступным. Единица распределения соответствует времени передачи одного квадлета на скорости 1600 Мбит/с (20,345 нс). В 125-микросекундном цикле теоретически доступно 6144 единиц. Как минимум 25 мкс цикла резервируется под асинхронный трафик, поэтому суммарная распределяемая полоса изохронного трафика (начальное значение bw_remaining) по умолчанию составляет 4915 единиц. Сервисным запросом SB_CONTROL диспетчеру изохронных ресурсов (или диспетчеру шины) можно урезать полосу, выделяемую под изохронный обмен. Выделение полосы по времени учитывает возможность совместной работы устройств с различными скоростями — в одном цикле соседние пакеты могут передаваться на разных скоростях. Для цифрового видео, например, требуется полоса 30 Мбит/с (25 Мбит/с на видеоданные и 3–4 Мбит/с на аудиоданные, синхронизацию и заголовки пакетов). В S100 такие устройства цифрового видео запрашивают около 1800 единиц, в S200 — около 900. Запрашиваемая полоса должна учитывать не только передаваемые данные, но и накладные расходы на заголовок и на зазор арбитража. Выделение и освобождение полосы выполняется аналогично выделению и освобождению канала — с помощью чтения и блокированного обращения compare_swap к регистру BW_AVAILABLE. При сбросе шины передача трафика прекращается и все ресурсы освобождаются, так что узлы, вещавшие в изохронном режиме, должны снова запросить себе ресурсы. Для стабилизации работы шины узлы-новички, не вещавшие до сброса, задерживают свои запросы на 1 с — это позволит прежним вещателям не потерять ресурсы из-за появления новичков и не прерывать передачу.

Диспетчер шины. Управление питанием

Диспетчер шины

Диспетчер шины (Bus Manager) обеспечивает полное управление шиной. Им может стать любой узел, способный (и обязанный после избрания диспетчером) выполнять следующие функции:

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

Диспетчер шины может находиться в любом месте шины. Он выбирается из узловкандидатов на роль диспетчера изохронных ресурсов. Из этих кандидатов диспетчером шины может стать узел, способный выполнять блокированные транзакции compare_swap с регистром Bus_Manager_ID уже избранного диспетчера изохронных ресурсов. После самоидентификации каждый узел, претендующий на роль диспетчера шины, пытается с помощью транзакции compare_swap записать свой идентификатор в регистр Bus_Manager_ID. В качестве аргумента (arg_value) этой транзакции передается значение 3Fh, а в качестве значения (data_value) — идентификатор. Значение, полученное в ответ, несет информацию о назначенном диспетчере шины: 3Fh — диспетчером стал данный узел, другое значение — идентификатор узла, успевшего стать диспетчером ранее. Если из-за ошибки передачи транзакция не удалась, узел должен ее автоматически повторить. При этом он может получить в ответе свой PHY_ID — это означает, что он стал диспетчером еще в предыдущей попытке, но не получил подтверждения.

Для поиска диспетчера шины узел должен прочитать регистр Bus_Manager_ID диспетчера изохронных ресурсов. Идентификатор диспетчера изохронных ресурсов узлы запоминают в ходе самоидентификации (см. предыдущий параграф).

Управление питанием

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

Диспетчер шины во время самоидентификации собирает информацию от всех узлов шины об их отношении к питанию (из поля pwr). Он подсчитывает баланс питания (сумма запрашиваемых мощностей не должна превышать сумму подаваемых мощностей). Если баланс не сходится — питания для всех узлов недостаточно, то сервис управления питанием посылает управляющему приложению индикацию события SB_EVENT с указанием на недостаток питания. Дальнейшие действия зависят от приложения: или пользователю предлагается выбрать часть устройств, которые включать, или не включается ни одно устройство (с уведомлеуровнем сервис SB_CONTROL посылает пакет Link_On — директиву на включение питания. Если питанием управляет диспетчер изохронных ресурсов (за неимением диспетчера шины), то он лишь посылает пакеты Link_On всем узлам с неактивным LINK-уровнем, не заботясь о бюджете мощности. нием пользователя). Если питания достаточно, то всем узлам с неактивным LINKуровнем сервис SB_CONTROL посылает пакет Link_On — директиву на включение питания. Если питанием управляет диспетчер изохронных ресурсов (за неимением диспетчера шины), то он лишь посылает пакеты Link_On всем узлам с неактивным LINK-уровнем, не заботясь о бюджете мощности.

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

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

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

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

Сервисы управления шиной. Запросы и подтверждения

Сервисы управления шиной

Прикладные драйверы на каждом узле предоставляют специальный интерфейс управления шиной (Bus Management Interface), который взаимодействует с «уровнем» управления последовательной шиной (Serial Bus Management Layer). Этот «уровень» проходит по всем этажам архитектуры. Он включает:

  • контроллер узла, управляющий уровнями PHY и LINK;
  • мастер циклов;
  • диспетчер изохронных ресурсов;
  • диспетчер шины.

Взаимодействие происходит через сервисы управления последовательной шиной (Serial Bus Management Services) при помощи:

  • запросов управления шиной — SB_CONTROL.request;
  • подтверждений запросов — SB_CONTROL.confirmation, сообщающих результаты их выполнения;
  • индикаторов событий шины, происходящих неожиданно для данного узла, — SB_EVENT.indication.

Запросы и подтверждения сервисов управления

Для функций управления и определения состояния предусмотрен ряд запросов, (SB_CONTROL.request), перечисленных ниже. На все запросы уровень управления отвечает подтверждениями (SB_CONTROL.confirmation), указывающими на успех или неудачу выполнения запроса. Сервисы управления включают следующие запросы:

  • сброс шины (Bus Reset) — указание своему PHY подать сигнал сброса и реинициализироваться самому; LINK и уровень транзакций отбрасывают все ожидающие транзакции и субакции;
  • инициализация узла — LINK и уровень транзакций данного узла отбрасывают все ожидающие транзакции и субакции и становятся готовыми к работе;
  • включение LINK-уровня заданного узла. Этот запрос предоставляет только диспетчер шины и диспетчер изохронных ресурсов;
  • конфигурирование физического уровня шины, предоставляют только диспетчер шины и диспетчер изохронных ресурсов:
         -----принудительное назначение роли корня (Set Root Force) — установка бита RHB в указанном узле и сброс во всех остальных;
         -----установка зазора арбитража (Set Gap Count);
         -----посылка расширенных пакетов физического конфигурирования — пробных пакетов ping, удаленного доступа к регистрам PHY, пакета resume;
  • Опрос состояния (Present Status), по которому в подтверждениях (SB_CONTROL confirmation) сообщается следующая информация:
         -----идентификатор корневого узла (3Fh — корневой узел не является мастером циклов);
         -----идентификатор (физический адрес) данного узла (0…3Eh);
         -----состояние бита RHB, обеспечивающего победу данному узлу в состязаниях на роль корня;
         -----текущее значение зазора арбитража (gap_cnt);
         -----идентификатор диспетчера шины (3Fh — нет диспетчера);
         -----идентификатор диспетчера изохронных ресурсов (3Fh — нет диспетчера);
         -----идентификатор мастера циклов (3Fh — нет мастера);
         -----значение, которое можно вычесть из содержимого регистра BANDWIDTH_ AVAILABLE при перераспределении полосы между изохронным и асинхронным трафиком.

Последние четыре параметра доступны только у узла, являющегося диспетчером шины или диспетчером изохронных ресурсов.