Шина IEEE 1394 поддерживает два типа передач данных:
Направленные асинхронные передачи являются основой для выполнения асинхронных транзакций — логически завершенных обменов между парами узлов. Протокол шины позволяет узлам с помощью асинхронных транзакций обращаться к памяти (регистрам) друг друга в режиме прямого доступа (DMA). При этом они не нуждаются в памяти и процессорных ресурсах «третьих лиц».
Изохронные передачи представляют собой потоки пакетов данных. Эти передачи ведутся широковещательно и адресуются через номер канала, передаваемый в каждом пакете. На шине может быть организовано до 64 изохронных каналов, передачи всех каналов «слышат» все устройства шины, но из всех пакетов принимают только данные интересующих их каналов. По шине могут передаваться и асинхронные потоки, для которых, в отличие от изохронных, не предоставляется гарантированная полоса пропускания.
Асинхронные транзакции на шине IEEE 1394 реализуют подмножество операций
протокола запросов-ответов, соответствующего стандарту архитектуры регистров управления и состояния CSR (Control and Status Register) для микропроцессорных шин. Асинхронные передачи обеспечивают три типа транзакций:
В каждой асинхронной транзакции участвуют два устройства: запросчик (requester) и ответчик (responder). Протокол запросов-ответов для этих типов транзакций иллюстрирует рисунок. Каждая асинхронная транзакция состоит из двух субакций (subaction) — шагов исполнения:
Реализация данного протокола в последовательной шине, где весьма вероятны ошибки при передаче информации, потребовала введения квитирования (и механизма повторов) для каждой субакции. Каждая субакция состоит из основного пакета (запроса или ответа) и пакета-квитанции. В общем случае для того, чтобы начать передачу пакета, узел должен получить на это право — выиграть арбитраж. Передача пакетов квитирования выполняется без арбитража — адресованный узел должен послать квитанцию через короткий интервал (ack_gap) после получения пакета.
Асинхронные транзакции могут выполняться в разных формах, различающихся числом субакций, необходимостью квитирования и способом получения права передачи (количеством операций арбитража). Эти формы иллюстрирует рисунок. На рисунке показаны операции арбитража (arb), короткие зазоры подтверждений (ack gap), длинные зазоры субакций (subaction gap), признаки начала (Data Prefix) и конца (Data End) пакетов.
Расщепленные транзакции используются при обращении к медленным устройствам (рис. а). Здесь между запросом и ответом могут вклиниваться другие транзакции на шине, так что перед ответом требуется арбитраж и зазор. В этой форме могут выполняться запись (Split Write), чтение (Normal Split Read) и блокированные транзакции (Normal Split Lock);
Соединенные расщепленные транзакции используются при обращении к быстрый устройствам (рис. б). Здесь пакет ответа передается сразу за пакетом квитирования (отделяясь только префиксом данных), так что дополнительный арбитраж (и зазор) не требуется. В этой форме могут выполняться запись (Concatenated Split Write), чтение (Concatenated Read) и блокированные транзакции (Concatenated Lock);
Объединенные транзакции используются в тех случаях, когда не требуется содержательного ответа (рис. в). В этой форме возможна только запись (Unified Write) — самый быстрый вариант, предназначенный для тех операций, которые заведомо проходят успешно (или успех не волнует запросчика).
Транзакции записи начинаются с пакета запроса, в котором передается полный адрес назначения, идентификатор источника, которому нужно будет послать ответ, и сами данные записи. Пакет ответа записи несет код результата выполнения.
Транзакции чтения в пакете запроса несут полный адрес назначения, длину запрашиваемого блока и идентификатор источника. Запрашиваемая длина определяется кодом типа транзакции (чтение квадлета или блока), а для чтения блока — полем длины. Пакет ответа чтения несет код результата выполнения и собственно данные чтения.
Блокированные транзакции чтения-модификации-записи в пакете запроса кроме адреса назначения несут значения аргумента и данных транзакции. Эти значения могут быть как 32, так и 64-битными (одинаковой длины), аргумент может и отсутствовать. Расширенный код транзакции задает тип выполняемой операции (таблица) и, соответственно, наличие или отсутствие аргумента. Поле длины определяет разрядность аргумента и данных и может принимать значение 4 (только 4-байтные данные), 8 (аргумент и данные по 4 байта или только данные размером 8 байт) или 16 (аргумент и данные по 8 байт). Пакет ответа по формату аналогичен ответу на чтение блока, где в поле данных возвращаются старые данные (считанные перед модификацией). Длина блока данных ответа может составлять 4 или 8 байт.
Расширенный код транзакции | Имя | Назначение |
0000h | Резерв | Резерв |
0001h | mask_swap | Биты целевой ячейки, которым соответствуют единичные значения в arg_value, заменяются на биты из data_value |
0002h | compare_swap | Содержимое целевой ячейки заменяется на data_value, если ее прежнее значение совпадает с arg_value |
0003h | fetch_add | Содержимое целевой ячейки складывается с data_value; числа рассматриваются как целые, целевой адрес указывает на самый старший байт числа (big endian) |
0004h | litle_add | То же, но целевой адрес указывает на самый младший байт числа (litle endian) |
0005h | bounded_add | Если содержимое целевой ячейки не равно arg_value, то она заменяется на сумму прежнего и data_value; иначе целевая ячейка не изменяется |
0006h | wrap_add | Если содержимое целевой ячейки не равно arg_value, то она заменяется на сумму прежнего и data_value; иначе она заменяется на data_value |
0007h | vendor | Назначение определяется разработчиком |
0008-FFFFh | Резерв | Резерв |
Пакеты запросов и ответов асинхронных передач для различных транзакций имеют форматы. Пакет состоит из заголовка и необя зательно блока данных. Ниже перечислено назначение полей, используемых в заголовках пакетов различных типов:
Блок данных 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. Всё по делу и ничего лишнего.