Шины.PCI,.USB.и.FireWire
.pdf
Рис. 25.5. Форматы данных для контекстов асинхронной передачи: а — начало заголовка асинхронного пакета; б — формат данных для физического пакета
Контекст асинхронного приема
Контроллер асинхронного приема работает с двумя контекстами:
контекст приема асинхронных запросов, AR_Request, который используется для приема пакетов запросов транзакций чтения, записи и блокированных, а также пакетов физического уровня (кроме пакетов самоидентификации, принятых в фазе инициализации шины);
контекст приема асинхронных ответов, AR_Response, который используется для приема пакетов ответов на запросы транзакций чтения, записи и блокирован$ ных, посланных к другим узлам.
Контекстная программа асинхронного приема является списком команд, описы$ вающих цепочку буферов, которыми контроллер заполняет принятыми асинхрон$ ными пакетами, не обрабатываемые блоком физической обработки. Эта програм$ ма является линейной. Цепочка буферов, описанная контекстной программой, для контроллера является логически непрерывной областью памяти. Границы приня$ тых пакетов и границы буферов не связаны друг с другом (кроме начала первого пакета, совпадающего с началом первого буфера). Такой режим приема пакетов называется bufferFill mode. Извлечением пакетов из этого буфера занимается про$ грамма хоста.
В контекстах асинхронного приема используется только один тип команды — INPUT_MORE, формат ее дескриптора приведен на рис. 25.6. Назначение полей
вдескрипторе команды приведено далее:
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 — счетчик байтов свободного места в буфере.
Рис. 25.6. Формат дескриптора команды INPUT_MORE
Программа хоста должна инициализировать контекстные программы и следить за наличием свободного места в буферах. Контроллер укладывает в буферы только корректно принятые пакеты. Пакеты, принятые с ошибками 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) с меткой времени и состоянием кон$ текста (рис. 25.7, а):
timeStamp — метка времени приема пакета (3 младших бита second_count
и 13 бит cycle_count);
xferStatus — состояние приема, значения младших 16 бит регистра управ$ ления контекстом на момент приема пакета;
принятые PHY$пакеты помещаются в четыре квадлета буфера в соответствии с рис. 25.7, б.
Рис. 25.7. Форматы данных в буферах асинхронного приема: а — концевик пакета; б — пакет физического уровня; в — синтезированный пакет сброса шины
Пакеты физического уровня, принятые с шины, попадают в контекст AR_Request (сюда попадают и пакеты самоидентификации, принятые не в фазе инициализа$ ции шины). Признаком PHY$пакетов являются длина в два квадлета и неверный
CRC$код. Корректность пакета (соответствие прямой и инверсных копий инфор$ мации) проверяется программой хоста. Прием пакетов физического уровня разре$ шается установкой rcvPhyPkt = 1 в регистре LinkControl.
Сброс на шине отмечается помещением в буфер контекста AR_Request (если там есть место) синтезированного пакета сброса шины. Это позволяет программе оп$ ределить, какие пакеты пришли до сброса шины, а какие — после. Такая пометка необходима, поскольку после сброса могут поменяться физические идентифика$ торы узлов. Формат пакета приведен на рис. 25.7, в, назначение полей приведено далее:
tcode — метка транзакции (Eh), указывающая на PHY$пакет;
selfIDGeneration — номер генерации, соответствующий новому значению поля selfIDGeneration регистра selfIDCount на момент создания пакета;
event — код события (09h), по которому идентифицируется данный пакет.
Контексты изохронной передачи
Для передачи изохронных пакетов контроллер может иметь от 4 до 32 контекстов, с каждым из которых связан свой изохронный канал шины. Число контекстов мож$ но определить, записав FFFF FFFF в регистр масок прерываний от контекстов и прочитав его значение: единицы останутся только в битах, соответствующих су$ ществующим контекстам. Контексты изохронных передач отличаются от контек$ стов асинхронных тем, что требуют привязки начала передачи к определенному моменту времени, а также реакции на невозможность своевременной передачи пакета.
Контекстные программы изохронной передачи содержат команды описания паке$ тов, передаваемых данным контекстом в изохронном периоде каждого цикла шины. Контекстная программа может быть ветвящейся, и для каждого пакета указыва$ ются два адреса перехода:
адрес перехода в случае нормальной передачи пакета (branchAddress);
адрес пропуска — адрес перехода в случае пропуска цикла (skipAddress). По этому адресу программа переходит в случае, если в данном цикле передача па$ кета не удалась.
Каждый пакет описывается блоком из 1–8 дескрипторов, в которых используются следующие команды:
OUTPUT_MORE — не первая и не последняя команда в блоке, задающая адрес и длинубуфераданных,которыеследуетпоместитьвсобираемыйпакет(рис.25.8, а). Эта команда используется для помещения блока данных в середину пакета;
OUTPUT_MORE Immediate — первая команда в блоке, используемая для пере$ дачи заголовка пакета с ненулевой длиной данных. Буфер (2 квадлета) нахо$ дится в самом теле дескриптора (рис. 25.8, б). В команде задается адрес пропуска;
OUTPUT_LAST — последняя команда в блоке, задающая адрес и длину буфера данных, которые следует поместить в собираемый пакет, а также адрес перехо$
да или пропуска (рис. 25.8, в). В дескриптор команды при передаче контроллер помещает состояние контекста и метку времени. Команда используется двояко:
для помещения данных (но не заголовка) из буфера в конец пакета, при этом длина буфера ненулевая и в команде содержится адрес пропуска. В этом слу$ чае данной команде должна предшествовать команда OUTPUT_MORE или
OUTPUT_MORE Immediate;
как признак отсутствия пакета для передачи в данном цикле, при этом ука$ зывается нулевая длина буфера и в команде содержится адрес перехода.
В этом случае команде не должны предшествовать команды OUTPUT_MORE
или OUTPUT_MORE Immediate;
OUTPUT_LAST Immediate — команда, используемая для формирования пакетов с нулевой длиной поля данных; буфер (2 квадлета) находится в самом теле де$ скриптора (рис. 25.8, г). Для такого пакета переход в любом случае происходит по одному и тому же адресу. В дескриптор команды при передаче контроллер помещает состояние контекста и метку времени;
STORE_VALUE — команда, обеспечивающая программный мониторинг испол$ нения контекста без использования прерываний. Эта команда может быть вве$ дена в начало блока дескрипторов, при ее исполнении контроллер выполняет запись определенного слова данных по указанному адресу в случае успешной отработки блока. В дескрипторе указываются адрес пропуска, адрес записыва$ емых данных и сами данные (рис. 25.8, д). В случае пропуска цикла (перехода по адресу пропуска) запись данных не производится.
Назначения полей в дескрипторах команд изохронной передачи следующие:
cmd — код команды;
key — ключ команды (расширение кода);
b (branch control) — управление переходом: 0 — для OUTPUT_MORE или OUT PUT_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), устанавливается аппаратно при передаче;
Рис. 25.8. Форматы дескрипторов команд изохронной передачи: а — OUTPUT_MORE;
б— OUTPUT_MORE Immediate; в — OUTPUT_LAST; г — OUTPUT_LAST Immediate;
д— STORE_VALUE
S (status control) — признак модификации полей xferStatus и timeStamp, устанавливается контроллером;
storeDoublet — младшее слово записываемых данных мониторинга (старшее слово — нулевое).
В контекстной программе должны быть описаны пакеты для каждого цикла. Если для данного цикла нет данных, в контексте должен быть описан пакет нулевой длины (командой OUTPUT_LAST Immediate). Если канал в каком$то цикле не дол$ жен передавать пакет, это описывается единственной командой OUTPUT_LAST с нулевой длиной буфера. Останов контекстной программы происходит при пере$ ходе, для которого указан Z = 0.
Для определения цикла, с которого должна активизироваться работа контекста, в управляющем регистре контекста (рис. 25.9) введены дополнительные поля:
cycleMatchEnable — разрешение активизации контекста по началу определен$ ного цикла (только для изохронных контекстов);
cycleMatch — указатель цикла, в котором активизируется контекст (только для изохронных контекстов).
Остальные поля имеют то же назначение, что и для асинхронных контекстов (см. выше).
Рис. 25.9. Формат управляющих регистров изохронных контекстов
Каждая контекстная программа обычно связана со своим изохронным каналом, номер канала присутствует в заголовках передаваемых пакетов (формируется про$ граммно).
Пакеты всех контекстов DMA изохронной передачи укладываются в один и тот же буфер FIFO, из которого они выбираются LINK$уровнем для передачи в шину. Пакеты соседних циклов в FIFO отделяются друг от друга специальным раздели$ телем. Контроллер может укладывать пакеты в FIFO с опережением до двух цик$ лов. В каждом цикле шины LINK$уровень из FIFO забирает на передачу пакеты до очередного разделителя, а контроллер DMA укладывает в FIFO очередные па$ кеты из контекстов. Возможна ситуация, когда за очередной цикл LINK$уровень не может выбрать все пакеты до разделителя. При этом контроллер DMA не мо$ жет поместить в буфер очередные пакеты — это и есть пропуск цикла. Как правило, такая ситуация возникает из$за сброса шины. Ветвления контекстной программы позволяют отрабатывать эту ситуацию различными способами, как это иллюстри$ рует рис. 25.10:
пропускать передачи пакета в случае пропуска цикла (контекст A) — адрес про$ пуска и адрес перехода указывают на один и тот же блок дескрипторов пакета для следующего цикла;
настойчиво передавать каждый пакет (контекст B) — адрес пропуска в дескрип$ торе указывает на начало того же блока дескрипторов. При этом, естественно, появляется задержка доставки данных;
в случае пропуска любого цикла послать (настойчиво) специальный заверша$ ющий пакет и остановить контекстную программу (контекст C) — адрес про$ пуска во всех дескрипторах цепочки указывает на дескриптор завершающего пакета;
останавливать передачу по пропуску любого цикла (контекст D) — адрес про$ пуска во всех дескрипторах цепочки указывает на нуль$дескриптор.
Рис. 25.10. Поведение контекстов изохронной передачи при пропуске цикла из за сброса шины
Квадраты на рис. 25.10, а обозначают блоки дескрипторов контекста; выходящие из них прямые стрелки (снизу) указывают на нормальные переходы, изогнутые (сверху) — на переходы по пропускам. На рис. 25.10, б показаны состояния FIFO$ буфера на моменты начала каждого цикла. Здесь показаны пакеты, собранные по соответствующим блокам дескрипторов, и разделители циклов. Как видно из ри$ сунка, сброс на шине (BUS RESET) и процесс идентификации дерева и узлов (ID) прерывают передачу изохронных пакетов. В результате этого по шине передаются изохронные пакеты следующим образом:
для контекста А: A1, A2, <пропуск двух циклов>, A3, A6, A7, — из$за сброса про$ пущены два цикла и потеряны (позже!) два пакета;
для контекста B: B1, <пропуск двух циклов>, B2, B3, B4, B5, — из$за сброса про$ пущены два цикла (задержка доставки), но пакеты не потеряны;
для контекста C: C1, <пропуск двух циклов>, C2, C3, Cx (специальный пакет, сигнализирующий останов), останов — из$за сброса пропущены два цикла, чуть позже передача останавливается с предварительным уведомлением слушателей;
для контекста D: D1, <пропуск двух циклов>, D2, D3, останов — из$за сброса пропущены два цикла, чуть позже передача останавливается без предупрежде$ ния.
Если во время передачи FIFO$буфер переопустошается (underrun), то передавае$ мый пакет теряется (в его дескрипторе поле состояния не обновляется), а програм$ мы всех оставшихся контекстов продвигаются по ветке пропуска цикла.
Программа хоста помещает пакеты изохронной передачи данных в буферы, опи$ санные блоками дескрипторов. Формат пакетов данных (рис. 25.11) почти соответ$ ствует формату потоковых пакетов IEEE 1394 (см. главу 18). Отличие заключается в переносе поля длины пакета data_length во второй квадлет ради помеще$ ния в первый квадлет кода скорости spd (эта информация при передаче нужна раньше всего). Поля CRC заголовка и данных контроллер строит сам при пе$ редаче.
Рис. 25.11. Формат изохронного пакета в буфере передачи
Контекст изохронного приема
Для приема изохронных пакетов контроллер может иметь от 4 до 32 контекстов, каждый из которых обеспечивает прием одного канала. Один из этих контекстов можно запрограммировать на мультиканальный прием.
Контекстная программа содержит список буферов, заполняемых принимаемыми пакетами. Каждый контекст может быть сконфигурирован на определенный спо$ соб обработки принятых пакетов. В буфер пакеты могут помещаться как целиком, так и освобожденные от заголовков и концевиков, содержащих метку времени и состояние контекста. По способу заполнения буферов возможны следующие ре$ жимы:
packet per buffer — укладывать в каждый буфер по одному пакету;
buffer fill — соединять пакеты в поток, полностью заполняющий каждый буфер цепочки;
dual buffer — соединять первые части поля данных пакетов в поток, укладыва$ емый в одну цепочку буферов, а вторые части — в другой поток и другую цепоч$ ку. Этот режим позволяет при приеме из пакетов выделять два потока (напри$ мер, аудио и видео).
В контекстных программах используются следующие команды:
INPUT_MORE (рис. 25.12, а) — команды, используемые в режимах packet per buffer и buffer fill. В дескрипторах этих команд задается адрес перехода и опи$ сывается один буфер данных;
INPUT_LAST — команды аналогичного формата, используемые как обязатель$ ное завершение блока дескрипторов в режиме packet per buffer;
DUALBUFFER (рис. 25.12, б) — команды, используемые в одноименном режи$ ме. В дескрипторах этих команд кроме адреса перехода задается пара буферов, в которые раскладывается принятый пакет.
Рис. 25.12. Формат дескрипторов команд изохронного приема: а — INPUT_MORE |
и INPUT_LAST; б — DUALBUFFER |