В бета-режиме обнаружение подключения и согласование скорости портов происходит без использования сигнализации постоянным током, как это было в IEEE 1394 и 1394a. Сигнализация подключения осуществляется тональными сигналами, передаваемыми по линии TPA и прослушиваемыми с линии TPA. Двуязычные узлы имеют оба механизма обнаружения подключения: тональный и с сигнализацией постоянным током. Алгоритм работы обнаружения подключения работает таким образом, чтобы по возможности установить соединение в бета-режиме. Если это не удается (партнер не посылает тональный сигнал, а упорно подает смещение), то включается традиционная схема обнаружения подключения и согласование скорости.
Для согласования скорости в бета-режиме используются серии тональных посылок. Эти серии отличимы от одиночных посылок обнаружения подключения, а также от непрерывных тональных сигналов пробуждения (resume), хотя в них используется одна и та же частота (48–61 МГц). Диаграмма посылок приведена на рисунке ниже. Каждый тональный сигнал представляет один бит (есть тон — бит единичный). Узел передает посылки, в которых закодирована максимальная поддерживаемая им скорость, одновременно прослушивая сигнал от партнера. Обнаружив посылку от партнера, он посылает посылку с битом ack = 1 (до того было ack = 0), в которой теперь указывает согласованную скорость (минимальную из передаваемой и принимаемой посылок). Приняв посылку с единичным битом ack, порт прекращает посылки согласования, и соединение устанавливается на общедоступной скорости. В посылке согласования скоростей два бита — P (PIL_Capable) и F (FOP_Capable) относятся к свойствам интерфейса порта.
После согласования скорости порты должны взаимно синхронизироваться: установить битовую синхронизацию, определить границы символов и синхронизировать друг с другом свои скремблеры и дескремблеры. Для этого выполняется процедура тренировки (training) — порты обмениваются специальными тренировочными последовательностями символов.
Установленная синхронизация в процессе работы может быть потеряна. Порт отслеживает потерю синхронизации: у него имеется счетчик неверных принятых символов. Прием каждого неверного символа инкрементирует счетчик, прием подряд двух верных символов декрементирует счетчик (в пределе до нуля). Если счетчик успевает досчитать до четырех, порт считает, что синхронизация потеряна и ее требуется восстановить с помощью тренировочной последовательности. Тренировку может инициировать и его партнер, послав запрос TRAINING.
Петлевые соединения узлов недопустимы и запрещены в шине IEEE 1394; за их отсутствие отвечает пользователь, соединяющий устройства. Петлевые соединения приводят к «зависаниям» конфигурирования и арбитража, а также к бесконечно повторяющимся сбросам. В дополнении 1394b введен механизм автоматического исключения петлевых соединений, правда, пригодный только для узлов с портами, работающими в бета-режиме.
При соединении устройств их порты согласуют скорости и выполняют тренировку, после чего переходят в состояние Untested (не тестирован). Для каждого нетестированного порта узел должен проверить, не приведет ли разрешение его работы к петле в шине. Если тест дает отрицательный результат (петли не будет), то порт переводится в активное состояние (Active); если петля будет, то порт переводится в запрещенное состояние (Loop-disabled). Проверка на петлевые соединения производится посылкой тестового пакета LTP (Loop-Test Packet) в тестируемый порт и сравнением символов, принимаемых с остальных портов, с тестовым символом, передаваемым в LTP. Если принимаемые символы не совпадают, значит, петли нет и можно разрешить работу порта. Если символ совпадает, то делается попытка тестирования с другим значением символа (это может быть случайным совпадением). Если совпадение происходит на нескольких разных символах, это является признаком петли и работу порта разрешать нельзя. Для того чтобы тестировать свои порты, узел должен получить управление шиной, выиграв арбитраж.
Для передачи изохронных пакетов контроллер может иметь от 4 до 32 контекстов, с каждым из которых связан свой изохронный канал шины. Число контекстов можно определить, записав FFFF FFFF в регистр масок прерываний от контекстов и прочитав его значение: единицы останутся только в битах, соответствующих существующим контекстам. Контексты изохронных передач отличаются от контекстов асинхронных тем, что требуют привязки начала передачи к определенному моменту времени, а также реакции на невозможность своевременной передачи пакета.
Контекстные программы изохронной передачи содержат команды описания пакетов, передаваемых данным контекстом в изохронном периоде каждого цикла шины. Контекстная программа может быть ветвящейся, и для каждого пакета указыва- ются два адреса перехода:
Каждый пакет описывается блоком из 1–8 дескрипторов, в которых используются следующие команды:
Назначения полей в дескрипторах команд изохронной передачи следующие:
В контекстной программе должны быть описаны пакеты для каждого цикла. Если для данного цикла нет данных, в контексте должен быть описан пакет нулевой длины (командой OUTPUT_LAST-Immediate). Если канал в каком-то цикле не должен передавать пакет, это описывается единственной командой OUTPUT_LAST с нулевой длиной буфера. Останов контекстной программы происходит при переходе, для которого указан Z = 0.
Для определения цикла, с которого должна активизироваться работа контекста, в управляющем регистре контекста (рис. 2) введены дополнительные поля:
Каждая контекстная программа обычно связана со своим изохронным каналом, номер канала присутствует в заголовках передаваемых пакетов (формируется программно).
Пакеты всех контекстов DMA изохронной передачи укладываются в один и тот же буфер FIFO, из которого они выбираются LINK-уровнем для передачи в шину. Пакеты соседних циклов в FIFO отделяются друг от друга специальным разделителем. Контроллер может укладывать пакеты в FIFO с опережением до двух циклов. В каждом цикле шины LINK-уровень из FIFO забирает на передачу пакеты до очередного разделителя, а контроллер DMA укладывает в FIFO очередные пакеты из контекстов. Возможна ситуация, когда за очередной цикл LINK-уровень не может выбрать все пакеты до разделителя. При этом контроллер DMA не может поместить в буфер очередные пакеты — это и есть пропуск цикла. Как правило, такая ситуация возникает из-за сброса шины. Ветвления контекстной программы позволяют отрабатывать эту ситуацию различными способами, как это иллюстрирует рис. 3:
Квадраты на рис. 3, а обозначают блоки дескрипторов контекста; выходящие из них прямые стрелки (снизу) указывают на нормальные переходы, изогнутые (сверху) — на переходы по пропускам. На рис. 3, б показаны состояния FIFOбуфера на моменты начала каждого цикла. Здесь показаны пакеты, собранные по соответствующим блокам дескрипторов, и разделители циклов. Как видно из рисунка, сброс на шине (BUS RESET) и процесс идентификации дерева и узлов (ID) прерывают передачу изохронных пакетов. В результате этого по шине передаются изохронные пакеты следующим образом:
Если во время передачи FIFO-буфер переопустошается (underrun), то передаваемый пакет теряется (в его дескрипторе поле состояния не обновляется), а программы всех оставшихся контекстов продвигаются по ветке пропуска цикла.
Программа хоста помещает пакеты изохронной передачи данных в буферы, описанные блоками дескрипторов. Формат пакетов данных (рис. 4) почти соответствует формату потоковых пакетов IEEE 1394. Отличие заключается в переносе поля длины пакета data_length во второй квадлет ради помещения в первый квадлет кода скорости spd (эта информация при передаче нужна раньше всего). Поля CRC заголовка и данных контроллер строит сам при передаче.
Потоковые передачи выполняются в широковещательной форме, в которой присутствует только пакет запроса и нет ни квитирования, ни ответов. Потоковые данные передаются пакетами с 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, введенном в 1394b, PHY не обеспечивает взаимодействия своего узла с шиной. В режим Standby порт узла переходит по получении пакета Standby с идентификатором данного узла. Этот пакет посылает узел, управляющий энергопотреблением. Переход произойдет только при соблюдении ряда условий:
Узел, порт которого перешел в состояние Standby, получает статус «племянника» (nephew node). Этот узел теряет представление о событиях, происходящих на шине (даже таких, как сброс). Этот узел и сам не может стать инициатором сброса (запись в его регистр ibr игнорируется). «Интересы племянника» на шине представляет его «дядя» (uncle node) — узел-партнер его по связи. Порт «дяди», обращенный к «племяннику», также переводится в состояние Standby (по приему символа STANDBY, который посылает «племянник»). Если теперь произойдет сброс на шине, то «дядя» будет посылать пакеты самоидентификации не только за себя, но и за своего «племянника». Переход порта узла-«племянника» в нормальное рабочее состояние происходит либо по запросу шины от своего LINK-уровня, либо по пробуждающему тональному сигналу, принимаемому по линии от «дяди». При этом нормальную работу узел может начинать только после получения от «дяди» пакета восстановления Restore, содержащего идентификатор узла-племянника (он мог поменяться из-за сброса на шине), значение зазора (gap_count), указание фазы шины и уведомление о происшедшем сбросе (если он был). Этот пакет LINK-уровню не передается; в ответ на него порт должен выполнить действия в соответствии с функциями BOSS-арбитража (как на последний пакет в субакции). Многопортовый узел, который вернулся из состояния Standby по событию подключения к его другому порту, должен в этом случае послать маркер BUS_RESET, чтобы шина отработала подключение новых узлов.
Для того чтобы представлять интересы «племянников», узел должен сохранять пакеты самоидентификации, принимаемые им по каждому из портов. Тогда, получив символ STANDBY от какого-либо своего порта, он сможет представлять интересы своего появившегося «племянника». «Дядя» должен восстановить нормальную работу «племянника» по получении пакета Restore со своим идентификатором, в котором указан номер порта восстанавливаемого «племянника». По этому событию «дядя» посылает в данный порт тональный сигнал восстановления. Если восстановление инициируется «племянником», то он посылает тональный сигнал восстановления. Сгенерировав или получив тональный сигнал, «дядя» и «племянник» устанавливают взаимную синхронизацию своих портов. Затем «дядя», запросив и выиграв арбитраж на шине, посылает в порт «племянника» пакет восстановления (в остальные порты и в свой LINK он посылает нуль-пакеты). Пакет восстановления завершается символом DATA_END, по которому «племянник» становится «боссом» и переводит свой порт в активное состояние.
Для приема изохронных пакетов контроллер может иметь от 4 до 32 контекстов, каждый из которых обеспечивает прием одного канала. Один из этих контекстов можно запрограммировать на мультиканальный прием.
Контекстная программа содержит список буферов, заполняемых принимаемыми пакетами. Каждый контекст может быть сконфигурирован на определенный способ обработки принятых пакетов. В буфер пакеты могут помещаться как целиком, так и освобожденные от заголовков и концевиков, содержащих метку времени и состояние контекста. По способу заполнения буферов возможны следующие режимы:
В контекстных программах используются следующие команды:
Назначения полей дескрипторов следуюшие:
В контекстах изохронного приема управляющий регистр ContextControl (рис. 2, а) имеет дополнительные биты:
Один из контекстов изохронного приема можно запрограммировать на мультиканальный прием (установкой бита multiChanMode в его регистре ContextControl). Каналы, данные которых должны приниматься в этот контекст, отмечаются единицами в соответствующих им битах 64-битного регистра IRMultiChanMask (старший бит соответствует каналу 63). Биты данного регистра можно устанавливать и сбрасывать через регистры IRMultiChanMaskHiSet (070h), IRMultiChanMaskLoSet (078h), IRMultiChanMaskHiClear (074h) и IRMultiChanMaskLoClear (07Ch).
Регистр ContextMatch (+10h) используется для активации контекста в указанном цикле, фильтрации пакетов по полю тега (tag) и ожидания пакета с указанным значением поля синхронизации (sy). Запись в регистр допустима лишь при неактивном состоянии контекста. Формат регистра приведен на рис. 2, б; назначения полей следующие:
С каждым номером канала должно быть связано не более одного контекста приема; в противном случае неизвестно, в какой контекст попадет принятый пакет из FIFO-буфера. Если номер канала для какого-либо контекста используется в мультиканальном режиме другого контекста, то пакет попадет в контекст с мультиканальным приемом.
Формат данных в приемных буферах зависит от режима приема: