Шины.PCI,.USB.и.FireWire

решили введением защиты от дребезга: узел посылает сброс по обнаружении сме$ ны состояний не сразу, а через 330–350 мс (когда дребезг закончится).

Соединяемые узлы воспринимают факт смены состояния не одновременно — раз$ ница в моментах определения изменения может составлять десятки миллисекунд (они проверяют замыкание разных цепей). В 1394a приняты меры, чтобы устрой$ ство, определившее факт смены позднее, не давало лишнего сброса. Порт, который во время выжидания интервала защиты от дребезга обнаружил сигнал сброса (от более быстрого устройства), должен прекратить выжидание и начать трансляцию сигнала сброса.

Из$за особенностей интерфейса PHY–LINK сигнал сброса должен быть весьма длительным, чтобы уведомление о нем получили LINK$уровни всех узлов. Сигнал сброса приходит в любой момент времени. В узле, ведущем передачу пакета, ин$ терфейсом PHY–LINK владеет LINK. Таким образом, PHY не имеет возможно$ сти сигнализировать LINK’у о сбросе, пока передача пакета не будет завершена. Из$за этого длительность сигнала сброса должна быть больше длительности мак$ симального пакета, поэтому принято Treset = 166,7 мкс. Поскольку во время сбро$ са трафик по шине передаваться не может, такой длинный сброс приводит к поте$ рям изохронных данных (может быть потерян целый 125$микросекундный цикл шины). В 1394a эту проблему решили, введя новый вариант сброса — короткий сброс (Short Bus Reset) длительностью 1,3–1,4 мкс. Короткий сброс узел может подать, только выиграв арбитраж (Arbitrated Bus Reset), — это гарантия того, что ни один узел в это время не передает пакет. Однако применение короткого сброса имеет свою специфику:

Рис. 20.1. Варианты сброса по подключению узла: a — сброс со штормом (1394); б — сброс с защитой от дребезга (1394a); в — короткий сброс (1394a)

если обнаруживается отключение на p$порте, то арбитраж попросту невозмо$ жен (корень уже недоступен);

если при попытке арбитража срабатывает тайм$аут, сброс должен быть длинным;

одиночный узел при подключении должен задержать подачу сброса на 1 с, что$ бы дать возможность другому узлу подать короткий сброс (по обнаружении подключения). Если сброс не приходит, то узел генерирует обычный сброс, если приходит — генерировать дополнительный сброс уже не надо.

Три различных варианта сброса шины по факту подключения узла приведены на рис. 20.1. Из диаграммы видно, как усовершенствование механизма сброса позво$ ляет сократить время простоя шины с сотен миллисекунд (1394) до 167 мкс (1394a) и даже до 1,56 мкс (короткий сброс в 1394a).

Идентификация дерева

Во время идентификации дерева узлы выстраиваются в иерархическую структуру и выбирается корень шины. Для узлов идентификация дерева сводится к опреде$ лению статуса активных портов: присвоение им типов: c порт (к которому под$ ключен дочерний узел) или p порт (которым он подключается к родительскому). Этап идентификации дерева начинается после сброса. Для идентификации исполь$ зуется сигнализация арбитража (см. табл. 22.4 на стр. 412).

В начале идентификации дочерние узлы ищут своих родителей, посылая им сиг$ нал уведомления Parent_Notify, а родители признают свои дочерние узлы сигна$ лом Child_Notify. Сигнал Parent_Notify безусловно посылают узлы$листья (имею$ щие всего по одному порту). Узлы$ветви могут послать сигнал Parent_Notify только на один из своих портов, при условии, что на все остальные активные порты при$ шли аналогичные сигналы. При этом порты, на которые пришел сигнал Parent_ Notify, помечаются как c$порты. На эти порты посылается уведомление Child_ Notify, но не раньше, чем когда сигнал Parent_Notify будет обнаружен на всех ак$ тивных портах, кроме одного. Порт, на который пришел сигнал Child_Notify, поме$ чается как p$порт; он перестает посылать сигнал Parent_Notify, что является под$ тверждением приема сигнала Child_Notify.

Узел, у которого на все порты приходят сигналы Parent_Notify, становится кор$ нем. Все его порты становятся c$портами. Он посылает на эти порты сигнал Child_ Notify, а получив подтверждение (снятые сигналы Parent_Notify), и сам прекраща$ ет подавать сигналы Child_Notify. На этом идентификация дерева заканчивается, и шина переходит к этапу самоидентификации узлов.

Возможна ситуация, когда два соединенных узла пытаются друг в друге найти своих родителей, посылая сигнал Parent_Notify. При этом столкновение данных сигна$ лов приводит к приему каждым портом состояния Root_Contention — признака состязания за роль корня. В этом случае оба узла перестают подавать сигнал на эти порты и через случайный интервал проверяют их состояние. Узел, обнаруживший состояние покоя на данном порте, посылает сигнал Parent_Notify. Узел, обнару$ живший этот сигнал, посылает сигнал Child_Notify и становится корнем. В начале

состязания каждый узел случайным образом устанавливает для себя время задерж$ ки из двух вариантов:

ROOT_CONTEND_FAST (0,24–0,26 мкс) — быстрый участник;

ROOT_CONTEND_SLOW (0,57–0,6 мкс) — медленный участник.

Тот узел, который окажется быстрее, корнем не станет (он раньше начнет искать родителя). Если оба участника выберут одинаковое время, то они опять столкнут$ ся и повторят состязание с новыми значениями задержки.

На том, что в состязании за роль корня побеждает самый медленный участник, построен механизм принудительного назначения корня. У каждого PHY есть бит RHB, единица в котором заставляет этот узел задерживать подачу сигнала поиска родителей на 83–167 мкс от начала идентификации дерева. Специальный пакет физического конфигурирования позволяет установить этот бит у заданного узла и сбросить у всех остальных, что обеспечит победу данному узлу в последующих выборах корня по ближайшему сигналу сброса. Если вдруг окажется, что бит RHB установлен у нескольких узлов, то они разыграют право стать корнем по выше$ описанному правилу случайных состязаний.

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

бесконфликтный (рис. 20.2, а);

с состязанием между узлами B и C (рис. 20.2, б);

с принудительным назначением роли корня для узла E (рис. 20.2, в). В этом примере показано, как благодаря выдержке узла E из той же топологии соеди$ нений, что была и на рис. 20.2, а, вырастает иное дерево.

В случае образования петли процесс идентификации дерева «зависает». Эта ситу$ ация выявляется по срабатывании тайм$аута арбитража (167 мкс); она сигнализи$ руется через LINK приложению и пользователю, который должен принять меры к разрыву петли (физическим переключением кабелей). В 1394b приняты меры по автоматической борьбе с петлями путем запрещения работы какого$либо порта по результатам проверки (см. главу 22).

Самоидентификация узлов

На этапе самоидентификации узлы назначают себе уникальные идентификаторы, согласуют скоростные возможности и (не обязательно) выбирают диспетчера изо$ хронных ресурсов. Самоидентификация выполняется под управлением корневого узла, организующего последовательное предоставление прав на самоидентифика$ цию всем узлам сети. Получив это право, узел посылает пакет (или серию паке$ тов) самоидентификации, которые распространяются по всей шине. Закончив по$ сылку пакетов, узел обменивается со своим родителем информацией о доступной скорости. В результате этого обмена пара соединенных портов становится скон$

фигурированной. Сконфигурированный порт — это активный порт, для которого установлен его тип (c$порт или p$порт) и согласована скорость.

Рис. 20.2. Варианты роста дерева: a — бесконфликтный; б — с состязанием за роль корня; в — с принудительным назначением корня

Промежуточные узлы$ветки и корневой узел организуют передачу права самоиден$ тификации всем узлам по порядку. Порядок, в котором узлы выполняют само$ идентификацию, определяется нумерацией портов в промежуточных узлах (ветках и корне). Первым будет самоидентифицироваться конечный узел (лист), который подключен к порту корня с наименьшим номером и путь к которому лежит в уз$ лах$ветках через порты с наименьшими номерами. Этот узел получит PHY_ID=0. Последним идентифицируется корень — он получает наибольший идентификатор. На рис. 20.3 приведены два варианта назначения идентификаторов, соответствую$ щие деревьям, взятым из рисунков 20.2, а и в.

Право на самоидентификацию получает узел, которому по p$порту приходит сиг$ нал Self_ID_Grant, а все его c$порты (если таковые есть) уже сконфигурированы. В ответ на предназначенный ему Self_ID_Grant узел отвечает передачей (вверх)

Рис. 20.3. Назначение идентификаторов в шине: а — исходная топология; б, в — полученные номера PHY_ID

префикса данных. Когда в ответ на это узел увидит снятие сигнала Self_ID_ Grant, он посылает пакет(ы) самоидентификации. Пакет самоидентификации (см. рис. 23.12 на с. 448) всегда передается на скорости S100. Пакет содержит ин$ формацию, описывающую физические свойства узла:

идентификатор (PHY_ID), который узел назначает себе сам равным числу услы$ шанных им пакетов самоидентификации (пакетов$0). Самый первый иденти$ фицирующийся узел возьмет PHY_ID=0, корень получает наибольший иденти$ фикатор;

число портов и их состояние: неактивен, c$порт или p$порт. Эту информацию узел получает на предшествующем этапе — при конфигурировании дерева;

зазор арбитража, взятый по умолчанию (при смене топологии) или сохранен$ ный с прошлого сеанса работы (до сброса);

доступная скорость работы (определяется свойствами узла, заложенными раз$ работчиком);

отношение к питанию от шины, определяется аналогично;

состояние LINK$уровня (бит L, определяется по факту включения);

претензии на роль диспетчера (бит C), определяемые с участием прикладного ПО.

При числе портов более трех узел посылает серию пакетов самоидентификации. Пакеты самоидентификации слышат все узлы, по ним они могут строить карту топологии и карту скоростей. Прослушивая пакеты самоидентификации, узлы определяют диспетчера изохронных ресурсов — им станет узел с максимальным номером PHY_ID, у которого в пакете самоидентификации установлены биты C и L.

Завершив передачу пакетов самоидентификации, узел посылает в p$порт сигнал Ident_Done. На это родительский узел отвечает префиксом данных и помечает свой соответствующий c$порт как сконфигурированный. При подаче сигнала Ident_Done узел с помощью смещения уровней сообщает доступную ему скорость работы; его родитель при передаче префикса данных аналогичным образом сообщает свою. Таким образом, на завершающем этапе самоидентификации узла его p$порт и со$ единенный с ним c$порт родительского узла согласуют и устанавливают макси$ мально возможную скорость обмена друг с другом.

Промежуточный узел ветка, получивший сверху сигнал Self_ID_Grant, трансли$ рует его на свой несконфигурированный c$порт с наименьшим номером; на осталь$ ные порты он посылает префикс данных. Получив префикс данных с c$порта, про$ межуточный узел прекращает подачу сигнала Self_ID_Grant (вниз) и транслирует префикс данных вверх. Далее, если после прохождения пакета самоидентифика$ ции на c$порт приходит сигнал Ident_Done, узел ответит ему префиксом данных с указанием своей скорости и пометит данный порт как сконфигурированный. Ког$ да промежуточный узел, у которого все c$порты сконфигурированы, снова полу$ чит сигнал Self_ID_Grant, он сам отправит пакет(ы) самоидентификации (во все активные порты), а затем и сигнал Ident_Done.

Корневой узел посылает сигнал Self_ID_Grant в порт с наименьшим номером из числа активных несконфигурированных. На остальные порты он посылает пре$ фикс данных. Как только с порта, на который корень посылает Self_ID_Grant, он получит префикс данных, подача сигнала Self_ID_Grant прекращается. Когда ко$ рень обнаружит покой шины (после прохождения пакетов самоидентификации от узла, которому досталось это право), он снова пошлет сигнал Self_ID_Grant, опять же на несконфигурированный порт с наименьшим номером. Если самоидентифи$ цировался узел, подключенный к корню, то корень получит сигнал Ident_Done и пометит данный порт как сконфигурированный. Теперь корень пошлет Self_ID_ Grant на следующий порт. Как только все порты перейдут в сконфигурированное состояние, корень пошлет свой пакет самоидентификации, на чем процесс само$ идентификации и закончится — шина переходит в фазу нормального арбитража.

Архитектурные регистры и память конфигурации узла

Пространству регистров узла, в котором располагается и память конфигурации, отводится диапазон адресов FFFF F000 0000–FFFF FFFF FFFFh. В дальнейшем описании в скобках указаны относительные адреса; 48$битный адрес (внутри узла) получается сложением относительного адреса и FFFF F000 0000h. Для получения полного 64$битного адреса этот адрес следует расширить влево 16$битным чис$ лом, состоящим из номера шины и идентификатора узла.

Архитектурные регистры CSR

Шина IEEE 1394 основана на стандарте ISO/IEC13213, известном под названием «CSR$архитектура», и наследует его основные регистры и структуры данных в па$ мяти конфигурации. Архитектурные регистры CSR занимают первые 512 байт в начальном адресном пространстве узла. Часть регистров CSR$архитектуры в IEEE 1394 не используется, их описание здесь опущено.

Регистр состояния и управления STATE (рис. 20.4) доступен для чтения по двум адресам — State_Clear (000h) и State_Set (004h). Некоторые биты доступны лишь для чтения (RO), другие биты допускают программный сброс (записью единиц

в биты State_Clear) и аналогичную установку (через регистр State_Set). На$ значение полей регистра состояния и управления:

unit_depended — биты, специфичные для устройства;

bus_depended — биты, специфичные для шины:

gone — бит, устанавливаемый по любому сбросу (устройства или шины) или по команде. Запрещает устройству посылку запросов. Обнуляется программ$ но (возможно, и удаленно) при инициализации, когда устройство становит$ ся способным отвечать на запросы;

abdicate — бит, предназначенный для смены диспетчера шины. Устанавли$ вается у узла, который должен стать диспетчером шины после грядущего сброса. При этом он не будет ждать положенных 125 мс (как «честные» кан$ дидаты) перед тем, как сделать попытку блокированной транзакции с реги$ стром BUS_MANAGER_ID (см. главу 21);

linkoff — состояние питания LINK$уровня, питающегося от шины (1 — отключено). Может быть установлен программно, обнуляется (и включает$ ся питание) по приему пакета Link_On;

cmstr — признак мастера циклов. Может быть установлен только у корне$ вого узла.

lost — потеря работоспособного состояния (по сбросу питания или фатальной ошибке;

dreq (disable request) — запрет генерации запросов транзакций;

atn, off — резервные биты в 1394;

elog — признак обновления информации в журнале ошибок;

state (RO) — состояние узла: 00 — рабочее (running), инициализация заверше$ на; 01 — идет инициализация; 10 — тестирование (по запуску через запись в ре$ гистр Test_Start); 11 — фатальная ошибка (узел неработоспособен).

Рис. 20.4. Регистр STATE

Регистр идентификатора узла NODE_IDS (рис. 20.5) содержит поля:

bus_id — идентификатор шины (по умолчанию 0), команда сброса на него не влияет; этот идентификатор записывается и считывается программно;

PHY_ID — идентификатор узла, устанавливаемый при автоконфигурировании;

Bus_dependent — поле, зарезервированное для нужд шины.

Рис. 20.5. Регистр NODE_IDS

Регистр команды сброса Reset_Start (00Ch) служит для подачи команды сброса (операцией записи), при этом значим только бит nt (no test, бит 31), единица в котором отменяет начальное тестирование узла при сбросе.

Регистры тайм аута расщепленных транзакций позволяют задать предельное вре$ мя ожидания ответа на запрос транзакции в пределах 8 с с дискретностью 125 мкс. Начальное значение — 100 мс, по сбросу не изменяется. В младших трех битах SPLIT_TIMEOUT_HI (018h) содержится число секунд, в старших 13 битах SPLIT_ TIMEOUT_LO (01Ch) содержится число 125$микросекундных интервалов.

Регистры тестирования (необязательные) служат для запуска теста (TEST_START, 028h), передачи параметров теста (ARGUMENT_HI, 020h, ARGUMENT_LO, 022h) и сооб$ щения состояния выполнения (TEST_STATUS, 02Ch).

Регистры прерываний (необязательные) служат для управления прерываниями, вызываемыми транзакциями записи в регистр INTERRUPT_TARGET (050h). Каждый бит этого регистра соответствует одному из условий (событий) прерывания; са$ мый старший бит соответствует прерыванию с самым высоким приоритетом. Ре$ гистр INTERRUPT_MASK позволяет селективно выбирать условия, вызывающие си$ гнализацию прерывания приложению (процессору) данного узла (единичное значение бита маски разрешает прерывание по данному условию). Прерывания по шине могут посылаться широковещательно (адресуясь к регистру INTERRUPT_ TARGET при Dest_ID = 63) или направленно, с указанием в целевом адресе иденти$ фикатора требуемого узла.

Регистры синхронизации (Clock_Value, Clock_Tick_Period, Clock_Strobe_Arrived,

Clock_Info) в IEEE 1394, как правило, не используются — их функции выполня$ ет регистр CYCLE_TIME).

Регистры сообщений (необязательные) Message_Request, Message_Response слу$ жат для передачи и приема широковещательных сообщений, адресованных всем узлам шины или всем блокам узла.

Специальные регистры последовательной шины

Специальные регистры последовательной шины (Serial Bus Dependent Registers) расположены во втором 512$байтном блоке, специально отведенном в CSR под шинно$зависимые регистры.

Регистры синхронизации изохронных передач Cycle_Time (200h) и Bus_Time (204h) задают время, измеряемое в секундах, циклах (125 мкс) и тиках (частота 24,576 МГц). Описание их полей см. в главе 21, запись в эти регистры влияет только на поле second_count_hi, автоматически инкрементируемое каждые 128 с.

Регистры мониторинга питания (необязательные) позволяют осуществлять преду$ преждение об угрозе пропадания питания. Узел, обнаруживший угрозу пропада$

ния питания, посылает широковещательное сообщение — выполняет запись в ре$ гистр POWER_FAIL_IMMINENT (208h, рис. 20.6, а). В этом сообщении единица в pfi_flag указывает на действительность остальных полей. Поле pfi_delay со$ держит ожидаемое время до пропадания (в сотнях микросекунд); поле pfi_ source — идентификатор узла, пославшего сообщение. Регистр POWER_SOURCE (20Ch, рис. 20.6, б) в поле power_source содержит идентификатор узла, сообще$ ния от которого принимаются во внимание.

Рис. 20.6. Регистры мониторинга питания: а — POWER_FAIL_IMMINENT; б — POWER_SOURCE

Регистр тайм аута повторов по занятости целевого узла BUSY_TIMEOUT (210h) определяет предел времени или количество попыток повторов (см. рис. 18.7). По сбросу устанавливается время ожидания 25 мс и 0 попыток повторов.

Регистр идентификатора диспетчера шины BUS_MANAGER_ID (21Ch) должен при$ сутствовать у любого узла, претендующего на роль диспетчера изохронных ресур$ сов. В нем у выбранного диспетчера изохронных ресурсов будет значение иден$ тификатора диспетчера шины (в младших 6 битах) или признак отсутствия диспетчера — 3Fh (значение, устанавливаемое по начальному сбросу). Этот регистр должен поддерживать блокированную транзакцию (условную запись) для выбора диспетчера шины (подробнее см. в главе 21).

Регистры доступной пропускной способности BANDWIDTH_AVAILABLE (220h) и ка налов CHANNELS_AVAILABLE (224h и 228h) должны быть у диспетчера изохронных ресурсов. Эти регистры должны поддерживать блокированную транзакцию (ус$ ловную запись) для выделения изохронных ресурсов (см. главу 26).

Служебные регистры MAINT_CONTROL (22Ch) и MAINT_UTILITY (230h) служат для отладочных целей. Запись в регистр MAINT_UTILITY не вызывает никаких побоч$ ных действий в узле, чтение возвращает результат последней записи. Для провер$ ки связи и протоколов обработки ошибок можно обращаться к этому регистру любого узла, проверяя достоверность обмена (сравнивая данные чтения и записи) и вводя различные ошибки. Регистр MAINT_CONTROL (рис. 20.7) позволяет прину$ дительно вводить ошибки передачи пакетов:

e_hcrc — искажение CRC заголовка;

e_dcrc — искажение CRC поля данных;

no_pkt — запрет генерации следующего пакета;

f_ack — подмена нормального ответа (квитанции) на поле ack;