В плане описания работы шины наибольший интерес представляет узел. Узел имеет явно выраженную трехуровневую структуру средств FireWire, к которой обращаются драйверы прикладного и системного ПО (см. рисунок ниже):
Драйверы прикладного и системного ПО для организации асинхронных транзакций пользуются сервисами уровня транзакций. В плане обработки ошибок уровень транзакций предоставляет только уведомления об успехе или неудаче выполнения транзакции. В последнем случае организация повторов ложится на драйвер. Для изохронных передач (и потоковых асинхронных) драйвер пользуется сервисами канального уровня, который в данном случае обеспечивает лишь передачу пакетов, прием пакетов требуемых каналов с индикацией наличия или отсутствия ошибки в данных.
Управление шиной (Bus management) затрагивает все вышеперечисленные уровни. Шина может иметь различные степени управляемости: полностью управляемая, частично управляемая (с диспетчером изохронных ресурсов, необходимым, если есть узлы с изохронным обменом) и даже неуправляемая шина.
Узел может быть вырожденным до простого кабельного сетевого концентратора — иметь только компоненты физического уровня. Его многопортовый PHY будет выполнять функции повторителя, не нуждаясь в вышестоящих уровнях.
Интерфейс IEEE 1394 реализуется аппаратно-программными средствами устройства. Аппаратная часть FireWire обычно состоит из двух специализированных микросхем — трансивера физического уровня (PHY Transceiver) и моста связи с микропроцессорной шиной (LINK Chip). Интерфейс между ними описан стандартом IEEE 1394. Микросхема LINK выполняет все функции канального уровня и часть функций уровня транзакций; остальная часть уровня транзакций выполняется программно. Микросхема PHY выполняет сигнальное кодирование-декодирование данных, распознавание адресов, функции арбитража, а также трансляцию сигналов между своими портами. Уровень PHY достаточно автономен, все «общественнополезные» функции узла он может выполнять и при отключенных вышестоящих уровнях. Физический уровень может быть (но не обязательно) гальванически развязан с канальным уровнем. В бета-режиме (1394b) гальваническая развязка (более эффективная) возможна на уровне кабельного интерфейса. Гальваническая развязка необходима для предотвращения возникновения паразитных контуров общего провода, которые могут появиться через провода защитного заземления блоков питания.
Физический и канальный уровни могут различаться в плане поддерживаемых скоростей передачи. Если многопортовый PHY поддерживает более высокие скорости, чем LINK, то он способен транслировать высокоскоростные пакеты между своими портами. Однако скорость, на которой сам узел может общаться с остальными узлами шины, определяется самым слабым звеном в данной паре PHY-LINK. В этом случае она будет ограничиваться возможностями LINK-уровня; эти возможности могут зависеть от организации узла. Для компьютера, подключаемого к 1394, поддерживаемая скорость LINK зависит от производительности шины, которой подключен адаптер, и производительности его контролера памяти. Физический уровень для различных устройств практически одинаков, различия касаются поддерживаемых скоростей передачи, а в 1394b — и используемой среды передачи (разновидностей медных и оптических кабелей). Канальный уровень существенно зависит от прикладной части устройства — микропроцессора, на котором базируется устройство, и интерфейса подключения канального уровня.
Пакеты запросов и ответов асинхронных передач для различных транзакций имеют форматы. Пакет состоит из заголовка и необя зательно блока данных. Ниже перечислено назначение полей, используемых в заголовках пакетов различных типов:
Блок данных data_block, следующий за заголовком, и его проверочный код data_CRC присутствуют в пакетах с tcode = 1, 7, 9, A. Блок содержит целое число квадлетов; при необходимости остаток последнего квадлета заполняется нулями. Максимальный размер блока определяется скоростью передачи.
tcode | Транзакция (субакция) |
0 | Запрос записи квадлета данных (Write Request) |
1 | Запрос записи блока данных (Write Request) |
2 | Ответ записи (Write Response) |
3, C, D, F | Резерв |
4 | Запрос чтения квадлета данных (Read Request) |
5 | Запрос чтения блока данных (Read Request) |
6 | Ответ чтения квадлета данных (Read Response) |
7 | Ответ чтения блока данных (Read Response) |
8 | Начало цикла (Cycle Start) |
9 | Запрос блокированной транзакции (Lock Request) |
A | Пакет асинхронного потока (Asynchronous Streaming Packet) |
B | Ответ блокированной транзакции (Lock Response) |
E | Не стандартизован |
Допустимый размер блока данных, передаваемых в одном пакете, зависит от скорости (см. следующую таблицу).
Скорость | Максимальный размер для асинхронных передач, байт | Максимальный размер для изохронных передач, байт |
S100 | 512 | 1024 |
S200 | 1024 | 2048 |
S400 | 2048 | 4096 |
S800 | 4096 | 8192 |
S1600 | 4096 | 16384 |
S3200 | 4096 | 32768 |
rcode | Результат |
0 | resp_comlete, успешное выполнение запроса |
1-3 | резерв |
4 | resp_conflict_error, отвечающий агент обнаружил конфликт ресурсов (запрос можно повторить позже) |
5 | resp_data_error, аппаратная ошибка, данные недоступны |
6 | resp_type_error, недопустимое значение полей в пакете запроса |
7 | resp_address_error, указанные адрес недоступен |
8...Fh | резерв |
Пакет квитирования имеет длину всего 1 байт (cм. следующий рисунок), в нем содержится 4-битный код квитирования ack_code (см. следующую таблицу), достоверность которого проверяется по его двоичному дополнению ack_parity.
ack_code | Имя | Значение |
0 | Резерв | Резерв |
1 | ack_complete | Пакет успешно принят. Если это квитанция пакета запроса, то пакет ответа не предполагается |
2 | ack_pending | Пакет запроса успешно принят, пакет ответа будет послан (для пакетов ответа не используется) |
3 | Резерв | Резерв |
4 | ack_busy_x | Пакет не принят из-за занятости узла (возможен успех при повторной попытке) |
5 | ack_busy_A | Пакет не принят из-за занятости узла. Данные будут приняты при следующем повторе (фаза A), когда узел освободится |
6 | ack_busy_B | Пакет не принят из-за занятости узла. Данные будут приняты при следующем повторе (фаза В), когда узел освободится |
7-Ah | Резерв | Резерв |
Bh | ack_tardy | Пакет не принят из-за неготовности узла, находящегося в состоянии standby; попытку можно повторить через некоторое время (1394a) |
Ch | ack_conflict_error | Пакет не принят из-за конфликта ресурсов (1394a) |
Dh | ack_data_error | Пакет не принят из-за ошибки данных (CRC или несоответствие длины пакета заявленной) |
Eh | ack_type_error | Пакет не принят из-за недопустимого типа (неверные параметры, неподдерживаемый тип транзакции) |
Fh | ack_address_error | Пакет не принят из-за недоступности указанного адреса (Dest_Offset) в целевом узле(1394a) |
Успешному выполнению асинхронных транзакций может помешать ряд причин:
Уровень транзакций предоставляет драйверам надежные сервисы, уведомляющие драйвер об успехе или неуспехе транзакции. Однако средства IEEE 1394 (уровень транзакций) обеспечивают автоматические повторы только для случая занятости целевого узла.
ПОСТОВОЙ: Советую обратить внимание на бесплатный видеокурс по Windows 7. Всё по делу и ничего лишнего.
В гибридной шине, состоящей из бета-узлов и традиционных узлов с DS-сигнализацией, новый механизм арбитража обеспечивает совместимость устройств, правда, с применением зазоров. Гибридная шина состоит из B-облаков (одного или нескольких), между которыми находятся фрагменты с DS-сигнализацией. При этом корневой узел может оказаться как в B-облаке, так и в DS-фрагменте.
В каждом B-облаке имеется один старший пограничный узел (senior border PHY): это последний узел, передающий в облако пакет самоидентификации без кода скорости. Старший пограничный узел облака, содержащего корневой узел, называется прокси-корнем. Этот узел будет работать дежурным арбитром, пока другие узлы не играют роль «босса». Если корнем является традиционный узел, то прокси-корня нет. P-порт старшего пограничного узла (если он не является прокси-корнем) всегда является DS-портом.
Старший пограничный узел в каждом B-облаке наблюдает за традиционными зазорами арбитража, и только он имеет право посылать асинхронные маркеры. Обнаружив зазор асинхронных транзакций, он посылает асинхронные маркеры без смены фазы. Маркер со сменой фазы он посылает, обнаружив зазор сброса арбитража. В состоянии покоя шины он посылает маркеры текущей фазы.
В ответ на запрос от B-порта старший пограничный узел начинает процедуру арбитража, используя традиционный механизм зазоров. Если старший пограничный узел является прокси-корнем, то он предоставляет право передачи B-узлу. Если старший пограничный узел не является прокси-корнем, то он посылает запрос арбитража через свой p-порт. Выиграв традиционный арбитраж, он выполняет B-арбитраж, и начинается передача бета-трафика. Как только в B-облаке начинается бета-передача, в нем включается механизм BOSS-арбитража, и этот механизм будет работать до тех пор, пока не завершится субакция и в облаке не закончатся запросы для текущей фазы.
В период передачи трафика B-облака старший пограничный узел должен обеспечить видимость занятости шины для всех узлов остальной части шины. Пакеты, передаваемые в традиционном формате, пограничный узел транслирует нормальным образом (заменяя пакет префиксом данных, если пакет передается на недопустимо высокой скорости). Пакеты бета-формата пограничный узел транслировать из облака не может, вместо них он передает префикс данных до тех пор, пока к нему не придет пакет традиционного формата. Чтобы эта передача префикса закончилась, «босс» по окончании субакции и при отсутствии запросов текущей фазы должен послать пакет традиционного формата с нулевой длиной данных.
В конце передачи бета-трафика текущий «босс» не посылает никаких маркеров, а передает право управления вышестоящему узлу. Таким образом это право достигнет старшего пограничника, который начнет формирование интервала покоя шины.
В гибридной шине маркер CYCLE_START может быть только в облаке, в котором находится мастер цикла. Это облако называется старшим B-облаком (senior B cloud). Такового может и не быть, поскольку мастер циклов может оказаться и в традиционном фрагменте шины. Остальные B-облака называются младшими (junior B cloud). Поскольку маркеры по традиционному фрагменту распространяться не могут, воспроизведение маркеров начала цикла в младших облаках проблематично. PHY узлов младшего облака узнают о начале изохронного периода от своего LINK-уровня. Поскольку информации о номере фазы у узлов младшего облака нет, изохронная транзакция запрашивается сигналом (символом) ISOCH_CURRENT. Этот запрос достигает старшего пограничного узла, который выполняет немедленный арбитраж в традиционном фрагменте шины. Запросы ISOCH_EVEN/ODD в младшем облаке не фигурируют.
Пограничный узел принимает традиционные запросы арбитража (сигналом TX_REQUEST) и преобразует их в символ запроса LEGACY_REQUEST, посылаемый в свой p-порт. Остальные свои порты он блокирует посылкой в них символа DATA_NULL. Если арбитраж выигран, то узел получит символ GRANT или GRANT_ISOCH; если проигран — DATA_PREFIX или DATA_NULL.
Шина IEEE 1394 основана на стандарте ISO/IEC13213, известном под названием «CSR-архитектура», и наследует его основные регистры и структуры данных в памяти конфигурации. Архитектурные регистры CSR занимают первые 512 байт в начальном адресном пространстве узла. Часть регистров CSR-архитектуры в IEEE 1394 не используется, их описание здесь опущено.
Регистр состояния и управления STATE (см. рисунок ниже) доступен для чтения по двум адресам — State_Clear (000h) и State_Set (004h). Некоторые биты доступны лишь для чтения (RO), другие биты допускают программный сброс (записью единиц в биты State_Clear) и аналогичную установку (через регистр State_Set). Назначение полей регистра состояния и управления:
Регистр идентификатора узла NODE_IDS (см. следующий рисунок) содержит поля:
Регистр команды сброса Reset_Start (00Ch) служит для подачи команды сброса (операцией записи), при этом значим только бит nt (no test, бит 31), единица в котором отменяет начальное тестирование узла при сбросе.
Регистры тайм-аута расщепленных транзакций позволяют задать предельное время ожидания ответа на запрос транзакции в пределах 8 с с дискретностью 125 мкс. Начальное значение — 100 мс, по сбросу не изменяется. В младших трех битах SPLIT_TIMEOUT_HI (018h) содержится число секунд, в старших 13 битах SPLIT_TIMEOUT_LO (01Ch) содержится число 125-микросекундных интервалов.
Регистры тестирования (необязательные) служат для запуска теста (TEST_START, 028h), передачи параметров теста (ARGUMENT_HI, 020h, ARGUMENT_LO, 022h) и сообщения состояния выполнения (TEST_STATUS, 02Ch).
Регистры прерываний (необязательные) служат для управления прерываниями, вызываемыми транзакциями записи в регистр INTERRUPT_TARGET (050h). Каждый бит этого регистра соответствует одному из условий (событий) прерывания; самый старший бит соответствует прерыванию с самым высоким приоритетом. Регистр INTERRUPT_MASK позволяет селективно выбирать условия, вызывающие сигнализацию прерывания приложению (процессору) данного узла (единичное значение бита маски разрешает прерывание по данному условию). Прерывания по шине могут посылаться широковещательно (адресуясь к регистру INTERRUPT_TARGET при Dest_ID = 63) или направленно, с указанием в целевом адресе идентификатора требуемого узла.
Регистры синхронизации (Clock_Value, Clock_Tick_Period, Clock_Strobe_Arrived, Clock_Info) в IEEE 1394, как правило, не используются — их функции выполняет регистр CYCLE_TIME).
Регистры сообщений (необязательные) Message_Request, Message_Response служат для передачи и приема широковещательных сообщений, адресованных всем узлам шины или всем блокам узла.
Прикладные драйверы на каждом узле предоставляют специальный интерфейс управления шиной (Bus Management Interface), который взаимодействует с «уровнем» управления последовательной шиной (Serial Bus Management Layer). Этот «уровень» проходит по всем этажам архитектуры. Он включает:
Взаимодействие происходит через сервисы управления последовательной шиной (Serial Bus Management Services) при помощи:
Для функций управления и определения состояния предусмотрен ряд запросов, (SB_CONTROL.request), перечисленных ниже. На все запросы уровень управления отвечает подтверждениями (SB_CONTROL.confirmation), указывающими на успех или неудачу выполнения запроса. Сервисы управления включают следующие запросы:
Последние четыре параметра доступны только у узла, являющегося диспетчером шины или диспетчером изохронных ресурсов.