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

Подробности

Родительская категория: Шина 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 — OHCI

 

Для передачи изохронных пакетов контроллер может иметь от 4 до 32 контекстов, с каждым из которых связан свой изохронный канал шины. Число контекстов можно определить, записав FFFF FFFF в регистр масок прерываний от контекстов и прочитав его значение: единицы останутся только в битах, соответствующих существующим контекстам. Контексты изохронных передач отличаются от контекстов асинхронных тем, что требуют привязки начала передачи к определенному моменту времени, а также реакции на невозможность своевременной передачи пакета.

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

• адрес перехода в случае нормальной передачи пакета (branchAddress);
• адрес пропуска — адрес перехода в случае пропуска цикла (skipAddress). По этому адресу программа переходит в случае, если в данном цикле передача пакета не удалась.

Каждый пакет описывается блоком из 1–8 дескрипторов, в которых используются следующие команды:

• OUTPUT_MORE — не первая и не последняя команда в блоке, задающая адрес и длину буфера данных, которые следует поместить в собираемый пакет (рис. 1, а). Эта команда используется для помещения блока данных в середину пакета;
• OUTPUT_MORE-Immediate — первая команда в блоке, используемая для передачи заголовка пакета с ненулевой длиной данных. Буфер (2 квадлета) находится в самом теле дескриптора (рис. 1, б). В команде задается адрес пропуска;
• OUTPUT_LAST — последняя команда в блоке, задающая адрес и длину буфера данных, которые следует поместить в собираемый пакет, а также адрес перехода или пропуска (рис. 1, в). В дескриптор команды при передаче контроллер помещает состояние контекста и метку времени. Команда используется двояко:
       -----для помещения данных (но не заголовка) из буфера в конец пакета, при этом длина буфера ненулевая и в команде содержится адрес пропуска. В этом случае данной команде должна предшествовать команда OUTPUT_MORE или OUTPUT_MORE-Immediate;
       -----как признак отсутствия пакета для передачи в данном цикле, при этом указывается нулевая длина буфера и в команде содержится адрес перехода. В этом случае команде не должны предшествовать команды OUTPUT_MORE или OUTPUT_MORE-Immediate;
• OUTPUT_LAST-Immediate — команда, используемая для формирования пакетов с нулевой длиной поля данных; буфер (2 квадлета) находится в самом теле дескриптора (рис. 1, г). Для такого пакета переход в любом случае происходит по одному и тому же адресу. В дескриптор команды при передаче контроллер помещает состояние контекста и метку времени;
• STORE_VALUE — команда, обеспечивающая программный мониторинг исполнения контекста без использования прерываний. Эта команда может быть введена в начало блока дескрипторов, при ее исполнении контроллер выполняет запись определенного слова данных по указанному адресу в случае успешной отработки блока. В дескрипторе указываются адрес пропуска, адрес записываемых данных и сами данные (рис. 1, д). В случае пропуска цикла (перехода по адресу пропуска) запись данных не производится.

Назначения полей в дескрипторах команд изохронной передачи следующие:

• cmd — код команды;
• key — ключ команды (расширение кода);
• b (branch control) — управление переходом: 0 — для OUTPUT_MORE или OUTPUT_MORE-Immediate , 3 — для OUTPUT_LAST или OUTPUT_LAST -Immediate, 1 и 2 — недопустимо;
• reqCount — длина буфера (в байтах);
• dataAddress — адрес буфера данных (нет требования выравнивания) или адрес записи для команды мониторинга;
• i (interrupt control) — управление прерываниями: 0 — нет прерываний, 1 и 2 — недопустимо, 3 — прерывание при переходе по адресу пропуска;
• branchAddress — адрес нормального перехода, указывающий на начало следующего блока дескрипторов;
• skipAddress — адрес перехода по пропуску;
• Z — длина следующего блока дескрипторов. Нулевая длина является указанием на останов контекстной программы;
• xferStatus — состояние передачи, в котором содержатся значения младших 16 бит регистра управления контекстом на момент завершения команды;
• timeStamp — метка времени помещения пакета в FIFO-буфер (3 младших бита second_count и 13 бит cycle_count), устанавливается аппаратно при передаче;
• S (status control) — признак модификации полей xferStatus и timeStamp, устанавливается контроллером;
• storeDoublet — младшее слово записываемых данных мониторинга (старшее слово — нулевое).

В контекстной программе должны быть описаны пакеты для каждого цикла. Если для данного цикла нет данных, в контексте должен быть описан пакет нулевой длины (командой OUTPUT_LAST-Immediate). Если канал в каком-то цикле не должен передавать пакет, это описывается единственной командой OUTPUT_LAST с нулевой длиной буфера. Останов контекстной программы происходит при переходе, для которого указан Z = 0.

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

• cycleMatchEnable — разрешение активизации контекста по началу определенного цикла (только для изохронных контекстов);
• cycleMatch — указатель цикла, в котором активизируется контекст (только для изохронных контекстов).

Каждая контекстная программа обычно связана со своим изохронным каналом, номер канала присутствует в заголовках передаваемых пакетов (формируется программно).

Пакеты всех контекстов DMA изохронной передачи укладываются в один и тот же буфер FIFO, из которого они выбираются LINK-уровнем для передачи в шину. Пакеты соседних циклов в FIFO отделяются друг от друга специальным разделителем. Контроллер может укладывать пакеты в FIFO с опережением до двух циклов. В каждом цикле шины LINK-уровень из FIFO забирает на передачу пакеты до очередного разделителя, а контроллер DMA укладывает в FIFO очередные пакеты из контекстов. Возможна ситуация, когда за очередной цикл LINK-уровень не может выбрать все пакеты до разделителя. При этом контроллер DMA не может поместить в буфер очередные пакеты — это и есть пропуск цикла. Как правило, такая ситуация возникает из-за сброса шины. Ветвления контекстной программы позволяют отрабатывать эту ситуацию различными способами, как это иллюстрирует рис. 3:

• пропускать передачи пакета в случае пропуска цикла (контекст A) — адрес пропуска и адрес перехода указывают на один и тот же блок дескрипторов пакета для следующего цикла;
• настойчиво передавать каждый пакет (контекст B) — адрес пропуска в дескрипторе указывает на начало того же блока дескрипторов. При этом, естественно, появляется задержка доставки данных;
• в случае пропуска любого цикла послать (настойчиво) специальный завершающий пакет и остановить контекстную программу (контекст C) — адрес пропуска во всех дескрипторах цепочки указывает на дескриптор завершающего пакета;
• останавливать передачу по пропуску любого цикла (контекст D) — адрес пропуска во всех дескрипторах цепочки указывает на нуль-дескриптор.

Квадраты на рис. 3, а обозначают блоки дескрипторов контекста; выходящие из них прямые стрелки (снизу) указывают на нормальные переходы, изогнутые (сверху) — на переходы по пропускам. На рис. 3, б показаны состояния FIFOбуфера на моменты начала каждого цикла. Здесь показаны пакеты, собранные по соответствующим блокам дескрипторов, и разделители циклов. Как видно из рисунка, сброс на шине (BUS RESET) и процесс идентификации дерева и узлов (ID) прерывают передачу изохронных пакетов. В результате этого по шине передаются изохронные пакеты следующим образом:

• для контекста А: A₁, A₂, <пропуск двух циклов>, A₃, A₆, A₇, — из-за сброса пропущены два цикла и потеряны (позже!) два пакета;
• для контекста B: B₁, <пропуск двух циклов>, B₂, B₃, B₄, B₅, — из-за сброса пропущены два цикла (задержка доставки), но пакеты не потеряны
• для контекста C: C₁, <пропуск двух циклов>, C₂, C₃, C_x (специальный пакет, сигнализирующий останов), останов — из-за сброса пропущены два цикла, чуть позже передача останавливается с предварительным уведомлением слушателей;
• для контекста D: D₁, <пропуск двух циклов>, D₂, D₃, останов — из-за сброса пропущены два цикла, чуть позже передача останавливается без предупреждения.

Если во время передачи FIFO-буфер переопустошается (underrun), то передаваемый пакет теряется (в его дескрипторе поле состояния не обновляется), а программы всех оставшихся контекстов продвигаются по ветке пропуска цикла.

Программа хоста помещает пакеты изохронной передачи данных в буферы, описанные блоками дескрипторов. Формат пакетов данных (рис. 4) почти соответствует формату потоковых пакетов IEEE 1394. Отличие заключается в переносе поля длины пакета data_length во второй квадлет ради помещения в первый квадлет кода скорости spd (эта информация при передаче нужна раньше всего). Поля CRC заголовка и данных контроллер строит сам при передаче.

 

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

Подробности

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

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

Для приема изохронных пакетов контроллер может иметь от 4 до 32 контекстов, каждый из которых обеспечивает прием одного канала. Один из этих контекстов можно запрограммировать на мультиканальный прием.

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

• packet-per-buffer — укладывать в каждый буфер по одному пакету;
• buffer-fill — соединять пакеты в поток, полностью заполняющий каждый буфер цепочки;
• dual-buffer — соединять первые части поля данных пакетов в поток, укладываемый в одну цепочку буферов, а вторые части — в другой поток и другую цепочку. Этот режим позволяет при приеме из пакетов выделять два потока (например, аудио и видео).

В контекстных программах используются следующие команды:

• INPUT_MORE (рис. 1, а) — команды, используемые в режимах packet-perbuffer и buffer-fill. В дескрипторах этих команд задается адрес перехода и описывается один буфер данных;
• INPUT_LAST — команды аналогичного формата, используемые как обязательное завершение блока дескрипторов в режиме packet-per-buffer;
• DUALBUFFER (рис. 1, б) — команды, используемые в одноименном режиме. В дескрипторах этих команд кроме адреса перехода задается пара буферов, в которые раскладывается принятый пакет.

Назначения полей дескрипторов следуюшие:

• cmd — код команды: 0 — DUALBUFFER, 2 — INPUT_MORE, 3 — INPUT_LAST;
• s (status control) — управление статусом: в режиме packet-per-buffer разрешает запись состояния, в остальных режимах должно быть «1»;
• key — ключ команды (0);
• i (interupt control) — управление прерываниями: 0 — нет прерываний, 3 — прерывание по исполнении команды, 1 и 2 — недопустимо;
• b (branch control) — управление переходом: 3 — дескриптор содержит указатель перехода (для INPUT_LAST и DUALBUFFER), 0 — не содержит (для INPUT_MORE), остальные значения недопустимы;
• w (wait control) — управление ожиданием совпадения поля sync с шаблоном: 3 — ожидать совпадения, 0 — не ожидать. В режиме packet-per-buffer значение «3» используется только в первом дескрипторе блока, в остальных режимах это значение применимо к любым дескрипторам блока;
• reqCount — длина буфера (в байтах). Буфер должен вмещать не менее одного пакета максимальной длины (его размер определяется в bus_info_block), включая 5 квадлетов его заголовка и концевика. При этом любой пакет может пересекать не более одной границы буфера;
• dataAddress — адрес буфера данных (должен быть выровнен по границе квадлета);
• branchAddress — адрес перехода, указывающий на начало следующего блока дескрипторов;
• Z — длина следующего блока дескрипторов (допустимо Z = 0 или 1). Нулевая длина является указанием на останов контекстной программы;
• xferStatus — состояние передачи, значения младших 16 бит регистра управления контекстом на момент модификации поля resCount;
• resCount — счетчик байтов свободного места в буфере;
• firstSize — размер части пакета, укладываемой в первый буфер в режиме dual buffer;
• firstReqCount — размер первого буфера;
• secondReqCount — размер второго буфера;
• firstResCount — свободное место в первом буфере;
• secondResCount — свободное место во втором буфере;
• firstBuffer — адрес первого буфера;
• secondBuffer — адрес второго буфера.

В контекстах изохронного приема управляющий регистр ContextControl (рис. 2, а) имеет дополнительные биты:

• bufferFill — признак режима соединения пакетов в единый поток;
• isochHeader — разрешение записи заголовка пакета в буфер;
• cycleMatchEnable — разрешение ожидания запрошенного номера цикла;
• multiChanMode — признак многоканального приема;
• dualBufferMode — признак режима двойной буферизации. При установленном бите недопустима установка бит bufferFill и multiChanMode.

Один из контекстов изохронного приема можно запрограммировать на мультиканальный прием (установкой бита multiChanMode в его регистре ContextControl). Каналы, данные которых должны приниматься в этот контекст, отмечаются единицами в соответствующих им битах 64-битного регистра IRMultiChanMask (старший бит соответствует каналу 63). Биты данного регистра можно устанавливать и сбрасывать через регистры IRMultiChanMaskHiSet (070h), IRMultiChanMaskLoSet (078h), IRMultiChanMaskHiClear (074h) и IRMultiChanMaskLoClear (07Ch).

Регистр ContextMatch (+10h) используется для активации контекста в указанном цикле, фильтрации пакетов по полю тега (tag) и ожидания пакета с указанным значением поля синхронизации (sy). Запись в регистр допустима лишь при неактивном состоянии контекста. Формат регистра приведен на рис. 2, б; назначения полей следующие:

• tag3 — разрешение приема пакетов с тегом tag = 11;
• tag2 — разрешение приема пакетов с тегом tag = 10;
• tag1 — разрешение приема пакетов с тегом tag = 01;
• tag0 — разрешение приема пакетов с тегом tag = 00;
• cycleMatch — 15-битное поле, задающее значение двух старших бит счетчика секунд и 13-битного счетчика циклов, при котором контекст активизируется (если в его управляющем регистре бит cycleMatchEnable = 1).
• sync — значение, которое ожидается в поле sy принимаемых пакетов, когда в дескрипторе команды установлено поле w = 3;
• tag1SyncFilter — признак дополнительной фильтрации по полю sy. При установке этого бита и tag1 = 1 пакеты с тегом tag = 01 будут приниматься лишь при sy = 00xx; пакеты с другими тегами фильтруются по обычным правилам;
• channelNumber — номер изохронного канала, с которым связан данный контекст.

С каждым номером канала должно быть связано не более одного контекста приема; в противном случае неизвестно, в какой контекст попадет принятый пакет из FIFO-буфера. Если номер канала для какого-либо контекста используется в мультиканальном режиме другого контекста, то пакет попадет в контекст с мультиканальным приемом.

Формат данных в приемных буферах зависит от режима приема:

• в режиме bufferFill с заголовком формат соответствует формату изохронного пакета, но поле CRC заголовка отсутствует, а вместо CRC данных записывается концевик с меткой времени и состоянием контекста;
• в режиме bufferFill без заголовка в буферы укладываются только поля данных из пакетов;
• в режимах Packet-per-buffer и dual-buffer с заголовками буфер начинается с квадлета, в котором младшие 16 бит содержат метку времени (старшие 16 бит не используются). Далее следует пакет, освобожденный от полей CRC и заполнителя данных (его длина может быть не выровненной по границе квадлета);
• в режимах Packet-per-buffer и dual-buffer без заголовков в буферы укладываются только поля данных.

Блок физических запросов

Подробности

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

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

Ряд запросов к памяти и регистрам узла отрабатывается на аппаратном уровне OHC, без привлечения программного обеспечения хоста. Отработкой этих запросов занимается блок физических запросов, в котором имеется контроллер DMA принимающий с шины запросы на транзакции, и контроллер DMA, посылающий на них ответы. Запросы в зависимости от смещения, указанного в адресе назначения, отрабатываются по разному.

Если смещение попадает в область нижних адресов узла, то запрос направляется к памяти хоста. При этом смещение трактуется как физический адрес памяти в пространстве хоста. В этой области физически (обменом с памятью по каналу DMA) отрабатываются запросы чтения, записи и блокированных транзакций с нулевым кодом расширенной команды, прошедшие фильтр по идентификатору источника (см. выше). Остальные запросы будут переданы в контекст AR DMA Request.

Запросы блокированных транзакций compare_swap и чтения квадлета по адресам автономных регистров диспетчера изохронных ресурсов направляются к этим регистрам. На другие запросы по этим адресам OHC отвечает квитанцией ошибки типа запроса (ack_type_error). К адресам автономных регистров относятся следующие:

• FFFFF000021Ch — регистр идентификатора диспетчера шины BusManagerID;
• FFFFF0000220h — регистр доступной полосы пропускания BandwidthAvailable;
• FFFFF0000224h — старший квадлет регистра доступных каналов, Channels-AvailableHi;
• FFFFF0000228h — младший квадлет регистра доступных каналов, Channels-AvailableLo.

Запросы чтения квадлета по специальным адресам памяти конфигурации направляются к регистрам OHC. На другие запросы по этим адресам, а также при некорректности образа памяти OHC отвечает квитанцией ошибки типа запроса ack_type_error. К специальным адресам памяти конфигурации относятся следующие:

• FFFFF0000400h — заголовок памяти конфигурации (Config ROM header), запрос направляется к регистру ConfigROMhdr;
• FFFFF0000404h — идентификатор шины, первый квадлет Bus_Info_Block, запрос направляется к регистру BusID;
• FFFFF0000408h — опции шины, второй квадлет Bus_Info_Block, запрос направляется к регистру BusOptions;
• FFFFF000040Ch и FFFFF0000410h — глобальный идентификатор, 3-й и 4-й квадлеты Bus_Info_Block, запрос направляется к регистрам GlobalIDHi и GlobalIDLo.

Запросы чтения памяти конфигурации по адресам FFFFF0000414–FFFFF00007FFh направляются к памяти хоста. Память конфигурации отображается на 1-килобайтный блок системной памяти в соответствии со значением регистра ConfigROMmap. При некорректности образа памяти (в регистре HCControl бит BIBimageValid = 0) OHC на эти запросы отвечает квитанцией ошибки ack_type_error.

Если принятый пакет запроса содержит ошибку CRC поля данных или имеет неправильную длину, контроллер ответит на него квитанцией ack_busy_* (вместо * подставляется буква A, B или X в соответствии с используемым однофазным или двухфазным протоколом). Это вынудит инициатора повторить запрос.

Генерируемые ответы на аппаратно-обрабатываемые запросы содержат метку транзакции, соответствующую запросу, и адрес назначения, соответствующий адресу источника запроса. Если на ответ контроллер получает квитанцию ack_busy, то число повторов ограничивается полем MaxPhysRespRetries регистра ATRetries.

Запросы записи могут выполняться как отправленные записи (Posted Writes) — подтверждение на них посылается сразу, не дожидаясь фактической записи. Если выполнение фактической записи не удается, то в регистре IntEvent устанавливается бит PostedWriteErr, а 48-битное смещение из адреса неудавшегося шинного запроса фиксируется в регистрах PostedWriteAddressLo, PostedWriteAddressHi (038h, 03Ch).

Запросы прерываний при нормальном выполнении аппаратно-обрабатываемых запросов не вырабатываются; прерыванием сигнализируется только ошибка при выполнении отправленной записи и невозможность доставки ответа на блокированные транзакции.

После сброса на шине все аппаратно-обрабатываемые запросы, на которые OHC должен был ответить, аннулируются. После сброса OHC автоматически начинает отрабатывать только запросы к регистрам диспетчера изохронных ресурсов (в CSR), остальные запросы будут отрабатываться только после инициализации фильтров.