Контексты изохронной передачи

Подробности

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

Потоковые передачи выполняются в широковещательной форме, в которой присутствует только пакет запроса и нет ни квитирования, ни ответов. Потоковые данные передаются пакетами с tcode = Ah. Этот код транзакции указывает на то, что пакет адресуется не по номеру узла, а по номеру канала channel. Формат данных в пакете определяется 2-битным полем tag: 00 — неформатированные данные, 01 — общий формат CIP (Common Isochronous Packet), 1x — резерв. Информацию о синхронизации, специфическую для приложений, может нести поле sy (4 бита). Длина блока данных data_length (в байтах) ограничивается. Пакет может иметь и нулевую длину данных, при этом размер пакета сокращается до двух квадлетов заголовка. Если длина данных не кратна квадлету, то последний квадлет данных дополняется до целого байтами-заполнителями.

Мастер циклов регулярно (с периодом 125 мкс) передает пакеты начала цикла (рис. б). В каждом таком пакете мастер циклов передает значение 32-битного счетчика времени (CYCLE_TIME), инкрементируемого с частотой 24,576 МГц. Метки времени нужны каждому узлу, поддерживающему изохронный обмен. Если к моменту подачи очередного пакета начала цикла шина оказывается занятой передачей, то пакет начала цикла задерживается до момента освобождения шины. В поле данных cycle_time_data передается значение регистра CYCLE_TIME мастера циклов на момент его фактической передачи, так что точная синхронизация узлов обеспечивается и при опозданиях пакета. Пакет передается во время асинхронной части цикла, но с коротким зазором арбитража, что обеспечивает приоритетность данных пакетов. Пакет передается широковещательно (destination_ID = 3Fh), его принимают все узлы, интересующиеся изохронными передачами. В поле destination_offset указывается адрес регистра CYCLE_TIME (смещение 200h в пространстве регистров CSR). Поле tl не используется (ответов не предусматривается), rt = = 00 (без квитирования). Поле source_ID содержит номер шины и идентификатор корневого узла, который и должен быть мастером циклов.

Состояние Standby

Подробности

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

Категория: Физический уровень шины IEEE 1394

В новом энергосберегающем состоянии порта и узла — Standby, введенном в 1394b, PHY не обеспечивает взаимодействия своего узла с шиной. В режим Standby порт узла переходит по получении пакета Standby с идентификатором данного узла. Этот пакет посылает узел, управляющий энергопотреблением. Переход произойдет только при соблюдении ряда условий:

• порт является единственным подключенным портом данного узла и работает в бета-режиме;
• узел не является корневым;
• LINK-уровень узла поддерживает бета-режим;
• порту не запрещен переход в состояние Standby (флаг enable_standby = 1).

Узел, порт которого перешел в состояние Standby, получает статус «племянника» (nephew node). Этот узел теряет представление о событиях, происходящих на шине (даже таких, как сброс). Этот узел и сам не может стать инициатором сброса (запись в его регистр ibr игнорируется). «Интересы племянника» на шине представляет его «дядя» (uncle node) — узел-партнер его по связи. Порт «дяди», обращенный к «племяннику», также переводится в состояние Standby (по приему символа STANDBY, который посылает «племянник»). Если теперь произойдет сброс на шине, то «дядя» будет посылать пакеты самоидентификации не только за себя, но и за своего «племянника». Переход порта узла-«племянника» в нормальное рабочее состояние происходит либо по запросу шины от своего LINK-уровня, либо по пробуждающему тональному сигналу, принимаемому по линии от «дяди». При этом нормальную работу узел может начинать только после получения от «дяди» пакета восстановления Restore, содержащего идентификатор узла-племянника (он мог поменяться из-за сброса на шине), значение зазора (gap_count), указание фазы шины и уведомление о происшедшем сбросе (если он был). Этот пакет LINK-уровню не передается; в ответ на него порт должен выполнить действия в соответствии с функциями BOSS-арбитража (как на последний пакет в субакции). Многопортовый узел, который вернулся из состояния Standby по событию подключения к его другому порту, должен в этом случае послать маркер BUS_RESET, чтобы шина отработала подключение новых узлов.

Для того чтобы представлять интересы «племянников», узел должен сохранять пакеты самоидентификации, принимаемые им по каждому из портов. Тогда, получив символ STANDBY от какого-либо своего порта, он сможет представлять интересы своего появившегося «племянника». «Дядя» должен восстановить нормальную работу «племянника» по получении пакета Restore со своим идентификатором, в котором указан номер порта восстанавливаемого «племянника». По этому событию «дядя» посылает в данный порт тональный сигнал восстановления. Если восстановление инициируется «племянником», то он посылает тональный сигнал восстановления. Сгенерировав или получив тональный сигнал, «дядя» и «племянник» устанавливают взаимную синхронизацию своих портов. Затем «дядя», запросив и выиграв арбитраж на шине, посылает в порт «племянника» пакет восстановления (в остальные порты и в свой LINK он посылает нуль-пакеты). Пакет восстановления завершается символом DATA_END, по которому «племянник» становится «боссом» и переводит свой порт в активное состояние.

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

Подробности

Родительская категория: Шина 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 без заголовков в буферы укладываются только поля данных.