link560 link561 link562 link563 link564 link565 link566 link567 link568 link569 link570 link571 link572 link573 link574 link575 link576 link577 link578 link579 link580 link581 link582 link583 link584 link585 link586 link587 link588 link589 link590 link591 link592 link593 link594 link595 link596 link597 link598 link599 link600 link601 link602 link603 link604 link605 link606 link607 link608 link609 link610 link611 link612 link613 link614 link615 link616 link617 link618 link619 link620 link621 link622 link623 link624 link625 link626 link627 link628 link629 link630 link631 link632 link633 link634 link635 link636 link637 link638 link639 link640 link641 link642 link643 link644 link645 link646 link647 link648 link649 link650 link651 link652 link653 link654 link655 link656 link657 link658 link659 link660 link661 link662 link663 link664 link665 link666 link667 link668 link669 link670 link671 link672 link673 link674 link675 link676 link677 link678 link679 link680 link681 link682 link683 link684 link685 link686 link687 link688 link689 link690 link691 link692 link693 link694 link695 link696 link697 link698 link699

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

Шина IEEE 1394 — FireWire

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

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

  • контекст приема асинхронных запросов, 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), по которому идентифицируется данный пакет.