link280 link281 link282 link283 link284 link285 link286 link287 link288 link289 link290 link291 link292 link293 link294 link295 link296 link297 link298 link299 link300 link301 link302 link303 link304 link305 link306 link307 link308 link309 link310 link311 link312 link313 link314 link315 link316 link317 link318 link319 link320 link321 link322 link323 link324 link325 link326 link327 link328 link329 link330 link331 link332 link333 link334 link335 link336 link337 link338 link339 link340 link341 link342 link343 link344 link345 link346 link347 link348 link349 link350 link351 link352 link353 link354 link355 link356 link357 link358 link359 link360 link361 link362 link363 link364 link365 link366 link367 link368 link369 link370 link371 link372 link373 link374 link375 link376 link377 link378 link379 link380 link381 link382 link383 link384 link385 link386 link387 link388 link389 link390 link391 link392 link393 link394 link395 link396 link397 link398 link399 link400 link401 link402 link403 link404 link405 link406 link407 link408 link409 link410 link411 link412 link413 link414 link415 link416 link417 link418 link419

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

Шина 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) вводится только после передачи последнего пакета.