Пакеты PHY

Подробности

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

Категория: Взаимодействие с физическим уровнем шины IEEE 1394

Физический уровень сам является источником и конечным получателем специальных пакетов, используемых для ряда целей:

• самоидентификации узлов шины;
• физического конфигурирования узлов;
• удаленного управления узлами;
• тестирования портов на образование петель в топологии (1394b).

Пакеты PHY-уровня по формату отличаются от пакетов транзакций и потоков: PHY-пакеты имеют длину 64 бита, первые 32 несут информацию, а в следующих 32 битах содержится инверсное значение информационных бит. Такой способ контроля позволяет отличить PHY-пакет от изохронного пакета с нулевой длиной данных: CRC-контроль для пакета PHY позволит сформировать сигнал об ошибке, что в совокупностью с длиной в 64 бита и является признаком PHY-пакета. Несоответствие контрольных бит информационным заставляет получателя игнорировать пришедший пакет. Адресация PHY-пакетов тоже иная — здесь используется только 5-битный идентификатор узла (PHY-пакеты за пределы шины не выходят). Назначение PHY-пакета определяется по первым двум битам.

Форматы пакетов самоидентификации приведены на рисунке 1. В 1394–1995 допускалось до четырех пакетов (0, 1, 2 и 3), что позволяло описывать свойства до 27 портов одного узла. В 1394a сократили число портов до 16, в результате остались только пакеты 0, 1 и 2. Назначение полей пакетов самоидентификации приведено ниже:

• phy_ID — идентификатор узла;
• L (Link Active) — признак активности LINK-уровня;
• gap_cnt — счетчик для определения зазоров арбитража;
• sp (PHY Speed) — скорость, поддерживаемая PHY-уровнем данного узла (может быть и выше, чем поддерживает уровень LINK): 00 — S100, 01 — S200, 10 — S400, 11 — скорость определяется по регистру PHY;
• brdg (bridge) — поле зарезервировано для IEEE 1394.1 (мосты между шинами). В 1394 на этом месте было поле del (PHY Delay) — максимальная задержка повторителя: 00 — ≤ 144 нс, остальные значения зарезервированы;
• c (contender) — претендент на роль диспетчера;
• pwr (Power Class) — отношение к питанию;
• p0…p6 (Port status, 2 бита на порт) — состояние порта: 11 — активен (или в состоянии Standby), подключен к c-узлу, 10 — активен (или в состоянии Standby), подключен к p-узлу, 01 — неактивен (запрещен, не подключен, приостановлен), 00 — нет порта;
• i (Initiated reset) — признак того, что текущий сброс на шине вызвал этот узел;
• m (More packets) — признак наличия последующих пакетов самоидентификации;
• r — зарезервированные поля (на рисунке заштрихованы).

Форматы управляющих пакетов физического уровня приведены на рисунке 2.

Пакеты физического конфигурирования являются широковещательными, их принимают все узлы шины. Пакеты используются двояко:

• для выборов нового корня (R = 1, T = 0) пакет посылается с указанием в поле root__ID идентификатора узла, которому надлежит стать корнем после грядущего сброса. Этот узел должен установить бит RHB (задержка при идентификации дерева), остальные узлы — его сбросить;
• для оптимизации зазоров арбитража (R = 0, T = 1) пакет посылается с указанием phy_ID корневого узла. В пакете указывается значение gap_cnt, рассчитанное для текущей топологии.

Длительность зазора арбитража и зазора сброса арбитража определяется через значение gap_cnt по формулам:

TSubaction_gap=(29+16×gap_cnt)/98,304 (мкс), диапазон значений 0,3–10,6 мкс; TArb_reset_gap=(51+32×gap_cnt)/98,304 (мкс), диапазон значений 0,5–21 мкс. По сбросу, связанному с изменением топологии шины (и по включению питания), принимается максимальное значение gap_cnt=63. В зависимости от топологии шины диспетчер шины может вычислить минимально допустимое значение gap_cnt и сообщить его всем узлам. Это новое значение будет действовать до следующего изменения топологии (PHY способен определить, связан ли сброс с подключением/отключением устройства; если не связан — значение gap_cnt сохраняется).

Пакет Link_On является директивой включения питания LINK-уровня (и вышестоящих) узлу, адресованному полем phy_ID.

Расширенные физические пакеты были введены в 1394a для удаленного доступа к PHY-регистрам, посылки пробного пакета и пакета возобновления:

• пробный пакет (Ping, рис. 3, а) заставляет узел с идентификатором phy_ID послать пакет(ы) самоидентификации. Диспетчер шины посылает эти пакеты всем узлам шины и измеряет время отклика, что позволяет ему рассчитать допустимое (минимальное) значение зазоров арбитража;
• пакет удаленного доступа (Remote Access Packet, рис. 3, б) позволяет прочитать PHY-регистр удаленного узла. Пакет удаленного ответа (Remote Access Reply, рис. 3, в) возвращает считанные данные;
• пакет удаленной команды (Remote Command Packet, рис. 3, г) позволяет подать команду узлу. В ответ на него узел через короткий интервал ack_gap посылает пакет подтверждения выполнения, в котором передается и текущее состояние (Remote Confirmation Packet, рис. 3, д);
• пакет возобновления (Resume Packet, рис. 3, е) предназначен для инициирования возобновления работы всех приостановленных портов адресованного устройства или всех устройств (может передаваться с широковещательным адресом 3Fh). Этот пакет не предполагает подтверждений.

Форматы расширенных физических пакетов 1394a приведены на рис. 3, назначение полей приведено ниже:

• phy_ID — идентификатор узла;
• type — тип команды: 0 — пробный пакет, 1 — чтение одного из базовых регистров, 5 — чтение страничного регистра, 8 — удаленная команда, код команды в поле cmd, Ah — удаленное подтверждение, Fh — возобновление;
• page — номер страницы;
• port — номер порта;
• reg — адрес регистра;
• cmd — код удаленной команды: 0 — NOP (нет операции), 1 — передать уведомление TX_DISABLE_NOTIFY и запретить порт, 2 — инициировать приостановку порта (Suspend Port), 4 — сбросить биты отказа порта (Fault и Standby_Fault), 5 — разрешить порт, 6 — инициировать возобновление работы порта (Resume Port); 7 — расширенная команда (код в поле e_cmnd);
• e_cmnd (в 1394b) — расширенная команда: 0 — NOP (нет операции), 1 — инициировать переход в Standby для партнера; 2 — инициировать выход из Standby для партнера, 3–7 — резерв;
• s (standby_fault, 1394b) — состояние одноименного бита страницы состояния порта;
• f (Fault) — состояние одноименного бита страницы состояния порта;
• c (Connected) — состояние одноименного бита страницы состояния порта;
• b (bias) — состояние одноименного бита страницы состояния порта;
• d (disabled) — состояние одноименного бита страницы состояния порта;
• ok — состояние команды: 1 — принята, 0 — отвергнута.

В IEEE 1394b для восстановления из состояния Standby используется пакет физического конфигурирования, который передается только от «дяди» к «племяннику» (рис. 4, а). При этом назначение полей становится следующим:

• phy_ID — идентификатор узла (возможно, изменившийся);
• R = 1 (игнорируется);
• бит T содержит копию переменной gap_count_reset_disable «дядиного» узла. Переменная gap_count_reset_disable — запрет сброса счетчика зазора в исходное значение, устанавливается по приему пакета физического конфигурирования, задающего длительность зазора;
• gap_cnt — новое значение зазора;
• MLP — восстанавливаемое значение max_Legacy_path_speed;
• L — признак наличия корня в локальном B-облаке;
• B (B_bus) — признак отсутствия старых узлов на шине;
• Q — копия бита R из R0 передающего узла;
• P — копия бита PS из R0 передающего узла;
• A — текущая асинхронная фаза: 1 — нечетная, 0 — четная;
• N — признак сбросов шины, происшедших с момента перехода в состояние Standby.

Пакет тестирования на петли (Loop Test Packet, рис. 4, б), введенный в 1394b, содержит следующие поля:

• m (mode) — режим: 0 — тест, 1 — идет процесс подключения;
• G (Generation) — номер генерации, чередующиеся 0 и 1 указывают на изменение значения test_value
• test_value — значение, используемое для сравнения переданного и принятого пакетов.

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

Подробности

Родительская категория: Шина 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), по которому идентифицируется данный пакет.

Организация потоковых передач и изохронный обмен

Подробности

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

Категория: Передача данных по шине IEEE 1394

Потоковые передачи могут быть изохронными и асинхронными. В обоих случаях используются пакеты одного и того же формата, но есть разница в организации:

• изохронные передачи выполняются в специально выделенном периоде цикла, право на их передачу получается с коротким зазором арбитража. Для использования изохронных передач узел должен у диспетчера изохронных ресурсов получить номер канала и выделенную полосу пропускания шины (максимальное время передачи пакета в каждом цикле). Каждый активный передающий узел в каждом цикле шины должен посылать по одному изохронному пакету для каждого из своих каналов. Если для данного канала в очередном цикле нет передаваемых данных, должен посылаться изохронный пакет с нулевой длиной поля данных. Регулярность посылок пакетов является основой поддержания синхронизации передатчика и приемников;
• асинхронные потоковые передачи выполняются в оставшееся время цикла. Для них у диспетчера изохронных ресурсов запрашивается только номер канала. Полоса пропускания асинхронного потокового канала не нормируется.

Пакеты изохронных передач передаются широковещательно и физически адресуются по номеру канала (0–63), указанному в заголовке пакетов.

Получение номера канала и выделение полосы пропускания осуществляется обращениями узла к регистрам диспетчера изохронных ресурсов CHANNEL_AVAILABLE и BANDWIDTH_AVAILABLE. Если канал и полосу получить не удалось, узел может периодически повторять запросы. Когда изохронный обмен становится ненужным узлу, он должен освободить свою полосу и номер канала, чтобы этими ресурсами смогли воспользоваться другие устройства. Обмен управляющей информацией с диспетчером производится асинхронными транзакциями.

Для выполнения изохронных обменов прикладной драйвер пользуется сервисами LINK-уровня:

• Запрос изохронной передачи (Link Isochronous Request), в котором драйвер передает:

1. номер канала;
2. длину данных;
3. данные;
4. скорость;
5. тег, определяющий формат данных;
6. код синхронизации (специфичен для приложений).

• Индикация изохронной передачи (Link Isochronous Indication), в которой драйвер получает те же данные. LINK-уровень будет давать индикацию только при приеме пакетов с требуемыми номерами каналов;
• управление изохронным обменом (Link Isochronous Control), в котором драйвер указывает номер канала, прием которого следует начать или завершить;
• синхронизация циклов (Link Cycle Synch) — индикация приема пакета начала цикла с сообщением текущего значения счетчика циклов и счетчика секунд. По этой информации и своим часам приложение может определить опоздание начала цикла и обеспечить свою синхронизацию с остальными участниками обмена.

Регистры и структуры данных для управления энергопотреблением

Подробности

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

Категория: Управление шиной IEEE 1394

Узлы, участвующие в управлении энергопотреблением, должны иметь единичное значение бита pmc в информационном блоке последовательной шины. Новые регистры CSR, введенные для управления энергопотреблением, располагаются в начальном пространстве узла, начиная с адреса FFFF F001 0000h или выше. Регистры делятся на две группы:

• регистры, относящиеся к узлу (node-specific CSR);
• регистры, относящиеся к блоку (unit-specific CSR).

Форматы регистров, относящихся к узлу, приведены на первом рисунке. На положение этого блока регистров указывает элемент Node_Power_Management в конфигурационной памяти. Ниже в скобках указано смещение регистров от начала блока. Обязательный регистр состояния питания узла NODE_POWER_STATE (00h) предназначен для сообщения текущего уровня потребления.

Обязательный регистр управления питанием узла NODE_POWER_CONTROL (04h) служит только для управления сменой уровня потребления (поле lvl). Значения поля func: 0 — резерв, 1 (grant) — разрешение смены состояния на последнее запрошенное; 2 (deny) — запрет смены состояния; 3 (wait) — выдержка 5 с перед отработкой последующей команды смены состояния; 4…7 (Set Level 0… Set Level 3) — установка указанного уровня (отразится в поле lvl в регистре состояния питания узла).

Необязательный регистр адреса уведомления NOTIFICATION_ADDRESS (08h) содержит полный адрес, по которому следует посылать уведомление о смене уровня потребления (идентификатор узла в поле destination_node_id, адрес в полях destination_offset_hi и destination_offset_lo). Бит e разрешает узлу генерировать уведомление.

Необязательный регистр состояния кабельного питания CABLE_POWER_SOURCE_STATE (0Ch) имеет следующие поля:

• power — мощность, отдаваемая узлом в кабель (в десятых долях ватта);
• voltage — напряжение питания (в десятых долях вольта);
• rlvl — текущий запрашиваемый уровень потребления (0…3);
• src — текущее состояние питания узла: 0 — от шины, 1 — от батареи, 2 — от сети, 3 — резерв;
• v — признак действительности полей power и voltage;
• lvl — текущий уровень потребления узла (0…3), соответствует состояниям N0…N3.

Необязательный регистр управления кабельным питанием CABLE_POWER_SOURCE_CONTROL (10h) управляет отработкой команд. Значения поля func: 0 — резерв, 1 (grant) — разрешение смены состояния на последнее запрошенное; 2 (deny) — запрет смены состояния; 3 (wait) — выдержка 5 с перед отработкой последующей команды смены состояния; 4…7 (Set Level 0… Set Level 3) — установка указанного уровня (поле lvl в регистре состояния кабельного питания).

Регистр смены уровня потребления POWER_CHANGE, обязательный для узла, управляющего потреблением, позволяет его приложениям управлять состоянием энергопотребления любого узла или блока. Поле lvl задает желаемый (запрашиваемый) уровень потребления узла, заданного полем PHY_ID. Поле csr_offset задает конкретный блок или весь узел, для которого требуется смена уровня.

Форматы регистров, относящихся к блоку, аналогичны приведенным на первом рисунке а и б. На положение этого блока регистров указывает элемент Unit_Power_Management в конфигурационной памяти.

Регистр состояния питания блока UNIT_POWER_STATE (00h) имеет следующие поля:

• power — мощность, отдаваемая блоком в кабель или потребляемая (в десятых долях ватта);
• voltage — напряжение питания (в десятых долях вольта);
• k — признак того, что блок является источником события пробуждения;
• rlvl — текущий запрашиваемый уровень потребления (0…3);
• src — текущее состояние питания блока: 0 — от узла, 1 — от собственной батареи, 2 — от сети, 3 — блок подает питание в кабель;
• v — признак действительности полей power и voltage;
• lvl — текущий уровень потребления (0…3), соответствует состояниям D0…D3.

Регистр управления питанием блока UNIT_POWER_CONTROL (04h) служит для установки уровня потребления с помощью поля func: 0…3 — резерв; 4…7 (Set Level 0… Set Level 3) — установка указанного уровня (поле lvl в регистре состояния питания блока).

Для описания возможностей управления потреблением узла в корневом каталоге памяти конфигурации введен элемент, ссылающийся на PM-каталог узла Node_Power_Directory. Аналогичный элемент, ссылающийся на PM-каталог блока, может присутствовать в каталоге блока. В PM-каталогах могут присутствовать элементы, приведенные на следующем рисунке.

Описатели уровней потребления узла Node_Power_Level должны присутствовать для всех уровней потребления, поддерживаемых устройством. Аналогичные описатели уровней потребления блока Unit_Power_Level могут присутствовать в PM-каталоге блока. В описателях содержатся следующие поля:

• power_requrements — мощность, потребляемая узлом или блоком на данном уровне (в десятых долях ватта);
• voltage — требуемое напряжение: 0 — в соответствии с 1394–1995 (8–40В), 1 — 3,3 В, 2 — 5 В, 3 — 12 В, 4–Fh — резерв;
• lvl — уровень потребления (0–3), описываемый данным элементом (соответствует N0…N3 для узла и D0…D3 для блока);
• w — способность приостановки (standby) LINK-уровня (бит действителен только в описателе нулевого уровня);
• v — признак действительности описателя.

Описатели кабельного питания Cable_Power_Source_Level сообщают возможности поставки питания в шину на каждом уровне потребления. Описатели относятся только к узлу. В них содержатся следующие поля:

• power_requrements — мощность, подаваемая узлом в кабель на данном уровне (в десятых долях Вт);
• voltage — подаваемое напряжение: 0 — в соответствии с 1394–1995 (8–40 В), 1 — 12 В, 2–Fh — резерв;
• lvl — уровень потребления (0–3), описываемый данным элементом;
• v — признак действительности описателя.

Указатель Node_Power_Management в поле csr_offset содержит смещение в области регистров CSR, по которому находится группа регистров управления энергопотреблением узла.

Указатель Unit_Power_Management в поле csr_offset содержит смещение в области регистров CSR, по которому находится группа регистров управления энергопотреблением блока.

Батареи питания (в том числе и аккумуляторные) могут относиться как к узлу в целом, так и к его отдельным блокам. К каждой батарее относится регистр состояния батареи BATTERY_STATE_REGISTER со следующими полями (см. рисунок ниже):

• capacity — емкость полностью заряженной батареи в ватт-часах;
• available — текущий уровень заряженности (в процентах от полной емкости);
• voltage — напряжение батареи (в десятых долях вольта);
• st — состояние: 0 — батарея отсутствует, 1 — резерв, 2 — батарея установлена и используется, 3 — батарея заряжается.

На местоположение регистров состояния батарей указывают элементы Battery_State, находящиеся в каталогах групп батарей Battery_Group. На каталоги групп батарей имеются ссылки в PM-каталоге узла Node_Power_Directory (для батарей узла) и/или в PM-каталогах блоков Unit_Power_Directory (для индивидуальных батарей блоков).