Шина IEEE 1394 — FireWire

Контекст асинхронного приема

Подробности

Родительская категория: Шина IEEE 1394 — FireWire

Категория: «Открытый» хост-контроллер IEEE 1394 — OHCI

Контроллер асинхронного приема работает с двумя контекстами:

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

Контекстная программа асинхронного приема является списком команд, описывающих цепочку буферов, которыми контроллер заполняет принятыми асинхронными пакетами, не обрабатываемые блоком физической обработки. Эта программа является линейной. Цепочка буферов, описанная контекстной программой, для контроллера является логически непрерывной областью памяти. Границы принятых пакетов и границы буферов не связаны друг с другом (кроме начала первого пакета, совпадающего с началом первого буфера). Такой режим приема пакетов называется bufferFill mode. Извлечением пакетов из этого буфера занимается программа хоста.

В контекстах асинхронного приема используется только один тип команды — INPUT_MORE, формат ее дескриптора приведен на рис. 1. Назначение полей в дескрипторе команды приведено далее:

• cmd — код команды (0010b);
• s (status control) — управление статусом. Программа должна устанавливать этот бит, контроллер записывает состояние независимо от значения бита;
• key — ключ команды (0);
• i (interupt control) — управление прерываниями: 0 — нет прерываний, 3 — прерывание по исполнении команды (заполнении указанного в ней буфера), 1 и 2 — недопустимо. Прерывания по приему пакетов данным полем не управляются (для них есть свои биты в регистре запросов и масок прерываний контроллера);
• b (branch control) — управление переходом: 3 — дескриптор содержит указатель перехода, остальные значения недопустимы;
• reqCount — длина буфера (в байтах). Буфер должен вмещать не менее одного пакета максимальной длины (его размер определяется в bus_info_block), включая 5 квадлетов его заголовка и концевика. При этом любой пакет может пересекать не более одной границы буфера;
• dataAddress — адрес буфера данных (должен быть выровнен по границе квадлета);
• branchAddress — адрес перехода, указывающий на начало следующего блока дескрипторов;
• Z — длина следующего блока дескрипторов (допустимо Z = 0 или 1). Нулевая длина является указанием на останов контекстной программы;
• xferStatus — состояние передачи, значения младших 16 бит регистра управления контекстом на момент модификации поля resCount;
• resCount — счетчик байтов свободного места в буфере.

Программа хоста должна инициализировать контекстные программы и следить за наличием свободного места в буферах. Контроллер укладывает в буферы только корректно принятые пакеты. Пакеты, принятые с ошибками CRC заголовков и данных и с ошибками FIFO (переполнение), для программы хоста невидимы. По каждому успешному приему пакета контроллер модифицирует поля resCount и xferStatus в дескрипторах, в буферы которых попал пакет.

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

• RQPkt и RSPkt — прерывания по приему пакетов в контексты AR_Request и AR_Response соответственно;
• ARRQ и ARRS — прерывания по заполнении буферов (в контекстах AR_Request и AR_Response соответственно), для которых в дескрипторах установлено поле i = 3.

Форматы данных в буферах контекстов асинхронного приема соответствуют форматам пакетов, определенных стандартом IEEE 1394. В отличие от буферов асинхронной передачи здесь идентификаторы источника и назначения присутствуют оба и находятся на своих местах. Однако и здесь есть ряд особенностей:

• квадлеты с CRC-кодами заголовка и поля данных в буферах отсутствуют;
• вместо последнего поля CRC (заголовка или данных, смотря по формату)
  в буфер помещается концевик (packet trailer) с меткой времени и состоянием контекста (рис. 2, а):
       -----timeStamp — метка времени приема пакета (3 младших бита second_count и 13 бит cycle_count);
       -----xferStatus — состояние приема, значения младших 16 бит регистра управления контекстом на момент приема пакета;
• принятые PHY-пакеты помещаются в четыре квадлета буфера в соответствии с рис. 2, б.

Пакеты физического уровня, принятые с шины, попадают в контекст AR_Request (сюда попадают и пакеты самоидентификации, принятые не в фазе инициализации шины). Признаком PHY-пакетов являются длина в два квадлета и неверный CRC-код. Корректность пакета (соответствие прямой и инверсных копий информации) проверяется программой хоста. Прием пакетов физического уровня разрешается установкой rcvPhyPkt = 1 в регистре LinkControl.

Сброс на шине отмечается помещением в буфер контекста AR_Request (если там есть место) синтезированного пакета сброса шины. Это позволяет программе определить, какие пакеты пришли до сброса шины, а какие — после. Такая пометка необходима, поскольку после сброса могут поменяться физические идентификаторы узлов. Формат пакета приведен на рис. 2, в, назначение полей приведено далее:

• tcode — метка транзакции (Eh), указывающая на PHY-пакет;
• selfIDGeneration — номер генерации, соответствующий новому значению поля selfIDGeneration регистра selfIDCount на момент создания пакета;
• event — код события (09h), по которому идентифицируется данный пакет.

• < Назад
• Вперёд >