Шина IEEE 1394 — FireWire

Шина IEEE 1394 — FireWire

Идентификация дерева

Изначально (по включению питания или сбросу) шина (совокупность соединенных узлов) имеет плоскую (неоформленную) структуру (рисунок а). В ходе инициализации первым делом автоматически (взаимодействием только уровней PHY) выполняется идентификация дерева (tree identification), в результате чего шина обретает форму перевернутого дерева (рисунок б). В этом дереве имеется:

  • корень (root), являющийся «верховным арбитром». Корень выбирается автоматически в зависимости от топологии шины; при необходимости стать корнем программно можно заставить любой узел;
  • листья (leaf) — конечные узлы, подключенные к шине только одним портом;
  • ветки (branch) — узлы, подключенные несколькими портами и находящиеся в иерархии между корнем и листьями.

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

  • «родительский», или p-порт (parent port), направлен в сторону корня (вверх);
  • «дочерний», или c-порт (child port), направлен в сторону листьев (вниз).

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

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

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

После идентификации дерева выполняется самоидентификация узлов (Self Identification), в результате которой все узлы шины получают уникальные адреса — физические идентификаторы (phy_ID). В процессе самоидентификации с помощью арбитража каждый узел последовательно получает право на передачу широковещательного пакета самоидентификации. В этом пакете содержится идентификатор узла, число его портов, их состояние и назначение, скоростные возможности устройства и некоторые другие параметры. Устройство назначает себе идентификатор само, исходя из числа ранее «услышанных» им пакетов самоидентификации от других устройств. Первое устройство, которому предоставили право на передачу, получает phy_ID = 0; последним самоидентифицируется корень — у него будет максимальное значение phy_ID (не превышающее 62). После посылки пакета самоидентификации узел обменивается со своим партнером-«родителем» сигналами, идентифицирующими максимальную скорость работы. Это позволяет непосредственным партнерам попарно согласовать свои скоростные возможности.

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

Обработка ошибок передачи

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

Типовая асинхронная транзакция состоит из двух субакций (запроса и ответа), каждая из которых выполняется с квитированием. Таким образом, транзакция состоит из четырех пакетов, каждый из которых при передаче может оказаться поврежденным. Рассмотрим поэтапно возможные ошибки передачи в типовой транзакции.

Пакет запроса пришел к адресованному узлу с ошибкой CRC данных:

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

Пакет запроса пришел нормально, но пакет квитирования «потерялся» (канальный уровень запросчика не дождался корректной квитанции):

  • действия узла-запросчика: канальный уровень посылает об этом уведомление своему уровню транзакций, который сообщит прикладному драйверу об отсутствии квитанции. Реакция опять же зависит от приложения, но состояние ответчика (пришел к нему запрос или нет) ему неизвестно.

Пакет ответа пришел к запросчику с ошибкой CRC данных:

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

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

Пакет ответа пришел нормально, но пакет квитированиия «потерялся». Об этом уведомляется драйвер ответчика, который обрабатывает эту ситуацию в зависимости от приложения. Дошел ли при этом ответ до запросчика — неизвестно.

Память конфигурации

Память конфигурации для узлов шины 1394 соответствует спецификации ISO/IEC 13213 со специфическими полями для последовательной шины. Эта память в шинных транзакциях допускает только чтение, поэтому она называется ROM (ReadOnly Memory). В данном случае применение термина ПЗУ (постоянное запоминающее устройство) как синонима ROM некорректно, поскольку память конфигурации узла может быть изменена его локальным ПО в процессе работы устройства. Каждое такое изменение отражается инкрементом поля gen (generation), входящим в блок параметров последовательной шины, находящийся в этой же памяти.

Память конфигурации может иметь минимальный размер 32 бита или нормальный размер 1 Кбайт. В CSR-архитектуре предусмотрена возможность расширение объема памяти конфигурации (при косвенной адресации содержимого), но в IEEE 1394 эта возможность не используется. Память конфигурации организована в виде иерархической системы каталогов (см. рисунок 1). Форматы содержимого памяти приведены на втором рисунке, где серым цветом выделены обязательные элементы.

 

Рисунок 1

 

Рисунок 2

В минимальном формате память конфигурации содержит только 24-битный идентификатор производителя vendor_id (рис. 2, а). В общем формате (рис. 2, б) память содержит следующие элементы:

  • заголовок (1 квадлет), содержащий три поля:
          -----info_length — длина информационного блока последовательной шины квадлетах (01 — признак минимального формата);
          -----crc_length — длина блока памяти (в квадлетах), защищаемого CRC (255 — весь объем памяти, 1020 байт после заголовка);
          -----rom_crc_value — значение CRC тела памяти (объявленного числа квадлетов после заголовка);
  • bus_info_block — информационный блок последовательной шины;
  • root_directory — корневой каталог, содержащий элементы описаний узла или ссылки на эти описания;
  • unit_directories — каталоги блоков;
  • root_leaves и unit_leaves — элементы-«листья», на которые ссылаются каталоги;
  • vendor_dependent_information — специфическая информация (по усмотрению разработчика).

Управление энергопотреблением

Возможность питания устройств от кабельной шины требует управления энергопотреблением узлов. В минимальном варианте, заложенном в изначальной спецификации, управление сводится к простому подсчету баланса мощности на основе классов питания узлов и включением LINK$уровня по команде от диспетчера. В IEEE 1394a управление было усовершенствовано, в частности:

  • появилась возможность приостановки и возобновления работы узлов (suspend и resume);
  • появилась возможность управлять уровнем потребления узлов и блоков;
  • расширились возможности расчета баланса мощности с учетом батарейного питания и уровней питания узлов и блоков.

Эти новые возможности потребовали введения дополнительных регистров CSR и элементов в памяти конфигурации.

В дополнении IEEE 1394b введено новое энергосберегающее состояние порта и узла — Standby, в котором PHY не обеспечивает взаимодействия своего узла с шиной.

Приостановка и возобновление (Suspend и Resume)

Приостановка (suspend) — это переход пары портов, соединенных кабельным сегментом, в состояние малого энергопотребления. В этом состоянии передача трафика по данному сегменту невозможна. Однако приостановленный порт способен определять события отключения и подключения своего партнера. Для того чтобы стала возможной передача данных по приостановленному сегменту, порты должны выполнить возобновление (resume) нормальной работы. Приостановка и запрет портов меняют конфигурацию шины — она может оказаться разбитой на активные домены, изолированные друг от друга (в плане трафика). Возобновление опятьтаки меняет конфигурацию. В связи с этим приостановка и возобновление сопровождаются сигнализацией сброса (короткого) и реинициализацией шины.

Приостановка по команде Suspend

Команда Suspend приводит к разделению шины на два фрагмента (домена): активный и приостановленный. Инициатор этой приостановки всегда остается в активном домене.

Команда Suspend принимается от удаленного узла с помощью расширенного физического пакета или от собственного LINK$уровня. В команде указывается идентификатор узла и номер его приостанавливаемого порта. В ответ на эту команду целевой узел приостановки посылает пакет подтверждения. Получив подтверждение команды приостановки, инициатор приостановки посылает сигнал TX_SUSPEND на тот порт, откуда пришло подтверждение. На остальные порты через короткий зазор узел посылает префикс данных, а за ним — короткий сигнал сброса шины. Это приводит к реконфигурированию активной части шины.

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

Узел, обнаруживающий пропадание смещения, также прекращает подачу смещения на этот порт, что завершает согласование приостановки. С этого момента в приостановленных портах остаются работать только детекторы отключения.

Приостановка по команде запрета порта

Команда запрета порта (локальная или удаленная) переводит в приостановленное состояние только указанный порт и его партнера. Таким образом, в результате шина может оказаться разбитой на два не связанных между собой активных домена.

Получив пакет с командой запрета порта (Disable Port), узел посылает во все порты, кроме запрещенного, пакет подтверждения, а за ним — короткий сигнал сброса. На запрещенный порт узел посылает сигнал TX_DISABLE_NOTIFY. Его партнер, приняв сигнал RX_DISABLE_NOTIFY, посылает на остальные порты префикс данных, а за ним — короткий сброс. Этот порт переводится в приостановленное состояние (снятием смещения, на что ответом будет снятие смещения и у запрещенного порта).

Возобновление нормальной работы

Возобновление работы порта может инициироваться несколькими способами:

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

Передача данных

Данные передаются в дифференциальном виде по обеим парам проводов. При этом по линии A передаются стробы, а по линии B — последовательные данные. Принимаются данные по линии B, а стробы — по линии A. Синхронизация данных осуществляется с помощью стробов весьма своеобразным способом. Сами данные передаются в NRZ-коде — уровень сигнала во время битового интервала соответствует значению данного передаваемого бита. Стробы при передаче формируются из тактового сигнала — меандра с периодом в два битовых интервала — и самих данных. При приеме данные и стробы поступают на логический элемент Исключающее ИЛИ (функция XOR). Немного задержанный выходной сигнал этого элемента является сигналом битовой синхронизации, по фронтам и спадам которого «защелкиваются» биты последовательных данных. Для того чтобы все биты пакета были извлечены из декодера приемника, приходится добавлять дополнительные биты (Dribble bits): 1 для S100, 3 для S200 и 7 для S400. Эти биты при передаче вводит PHY, он же их исключает при приеме, так что LINKуровень с ними дела не имеет. Значение дополнительных битов соответствует тому сигналу, в который должен завершать пакет: Data_Prefix или Data_End (см. ниже).

Передача данных начинается с префикса данных (Data Prefix) — состояния линий [0 1]. Префикс данных длится не менее 140 нс. Во время префикса данных передается и сигнал идентификации скорости (Speed Signal) — синфазное смещение уровней сигнала на паре B. Смещение вводится с помощью управляемых источников тока (в передатчике B) и измеряется компараторами (в приемнике A). Этот ток смещает среднее напряжение на линии относительно смещения TpBias. Величина тока и, соответственно, величина смещения на TPB кодируют скорость передачи пакета:

  • S100 — нет тока смещения, среднее напряжение на TPB — не ниже 1,17 В;
  • S200 — ток смещения 3,5 мА, среднее напряжение на TPB — 0,94–1,17 В;
  • S400 — ток смещения 10 мА, среднее напряжение на TPB — 0,52–0,94 В.

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

Обычным признаком окончания пакета является сигнал Data End — состояния линий [1 0] длительностью 0,25 мкс. В соединенных транзакциях пакеты разделяются префиксом данных, который будет играть роль признака конца данных для предшествующего пакета.

На рисунке ниже. приведены временные диаграммы одной субакции. Здесь изображены сигналы на парах TPA, TPB порта узла, посылающего пакет субакции и принимающего пакет подтверждения. В нижней части рисунка показаны сигналы, передаваемые портом (Tx:) и принимаемые им (Rx:). Увеличенная амплитуда дифференциального сигнала на TPA в начале передачи префикса данных обусловлена столкновением сигнала префикса, посылаемого данным портом, с сигналом предоставления права на передачу, еще не снятым узлом-партнером. На рисунке изображена нормальная форма выполнения транзакции (с передачей одиночного пакета). В случае соединенной (concatenated) формы выполнения (например, передачи одним узлом нескольких пакетов самоидентификации) пакеты разделяются лишь префиксами данных, а признак конца (Data_End) вводится только после передачи последнего пакета.

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