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

маются данные по линии B, а стробы — по линии A. Синхронизация данных осу$ ществляется с помощью стробов весьма своеобразным способом. Сами данные передаются в NRZ$коде — уровень сигнала во время битового интервала соответ$ ствует значению данного передаваемого бита (рис. 22.5). Стробы при передаче формируются из тактового сигнала — меандра с периодом в два битовых интерва$ ла — и самих данных. При приеме данные и стробы поступают на логический эле$ мент Исключающее ИЛИ (функция XOR). Немного задержанный выходной сиг$ нал этого элемента является сигналом битовой синхронизации, по фронтам и спадам которого «защелкиваются» биты последовательных данных. Для того что$ бы все биты пакета были извлечены из декодера приемника, приходится добав$ лять дополнительные биты (Dribble bits): 1 для S100, 3 для S200 и 7 для S400. Эти биты при передаче вводит PHY, он же их исключает при приеме, так что LINK$ уровень с ними дела не имеет. Значение дополнительных битов соответствует тому сигналу, в который должен завершать пакет: Data_Prefix или Data_End (см. ниже).

Рис. 22.5. Кодирование данных в DS режиме

Передача данных начинается с префикса данных (Data Prefix) — состояния линий [0 1]. Префикс данных длится не менее 140 нс. Во время префикса данных переда$ ется и сигнал идентификации скорости (Speed Signal) — синфазное смещение уров$ ней сигнала на паре B. Смещение вводится с помощью управляемых источников тока (в передатчике B) и измеряется компараторами (в приемнике A). Этот ток смещает среднее напряжение на линии относительно смещения TpBias. Величина тока и, соответственно, величина смещения на TPB кодируют скорость передачи пакета:

S100 — нет тока смещения, среднее напряжение на TPB — не ниже 1,17 В;

S200 — ток смещения 3,5 мА, среднее напряжение на TPB — 0,94–1,17 В;

S400 — ток смещения 10 мА, среднее напряжение на TPB — 0,52–0,94 В.

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

Обычным признаком окончания пакета является сигнал Data End — состояния линий [1 0] длительностью 0,25 мкс. В соединенных транзакциях пакеты разделя$ ются префиксом данных, который будет играть роль признака конца данных для предшествующего пакета.

На рис. 22.6. приведены временные диаграммы одной субакции. Здесь изображены сигналы на парах TPA, TPB порта узла, посылающего пакет субакции и принимаю$ щего пакет подтверждения. В нижней части рисунка показаны сигналы, передава$ емые портом (Tx:) и принимаемые им (Rx:). Увеличенная амплитуда дифферен$ циального сигнала на TPA в начале передачи префикса данных обусловлена столкновением сигнала префикса, посылаемого данным портом, с сигналом пре$ доставления права на передачу, еще не снятым узлом$партнером. На рисунке изображена нормальная форма выполнения транзакции (с передачей одиноч$ ного пакета). В случае соединенной (concatenated) формы выполнения (на$ пример, передачи одним узлом нескольких пакетов самоидентификации) пакеты разделяются лишь префиксами данных, а признак конца (Data_End) вводится толь$ ко после передачи последнего пакета.

Рис. 22.6. Передача пакетов 1394 и 1394a

Интерфейс в бета режиме IEEE 1394b

Интерфейс бета$режима построен с учетом возможности использования различ$ ных сред передачи сигналов по двум встречным однонаправленным линиям. Здесь исключена сложная дифференциально$линейная сигнализация с распознаванием различных уровней смещения и анализом состояния сигналов арбитража, являю$ щихся результатом одновременной работы передатчиков соединенных устройств на одну и ту же сигнальную пару. Вся информация в бета$режиме передается с помощью 10$битных символов, передаваемых последовательно простым коди$ рованием по методу NRZ. Чтобы избежать электромагнитных помех от шины, со$ средоточенных в узких полосах спектра при передаче монотонных данных или служебных сигналов, передаваемые потоки скремблируются. Скремблирован$ ные данные проходят через кодер 8B/10B, который из байтов данных делает 10$бит$ ные символы. Это избыточное кодирование позволяет сформировать битовый по$ ток, в котором ограничена длина повторяющихся битов (не более пяти нулей или единиц подряд) и среднее число нулей совпадает со средним числом единиц. Такой поток удобно передавать по различным средам передачи (отсутствует постоянная составляющая) и декодировать, синхронизируясь по перепадам сигнала, встречаю$

щимся не реже чем через 5 битовых интервалов. При приеме битовая последователь$ ность подвергается обратным преобразованиям. Аналогичное кодирование$декоди$ рование применяется в Ethernet, FDDI и других коммуникационных технологиях.

Вструктуре PHY узла 1394b появился сменный нижний уровень PMD (Physical Media Dependent), соответствующий физической среде передачи. Для коротких медных линий (STP) это дифференциальные приемопередатчики, для длинных (UTP) они содержат и разделительные трансформаторы. Для оптоволокна это оптические трансиверы с лазерным или светодиодным излучателем. «Двуязыч$ ный» порт должен иметь и традиционный набор дифференциальных и линейных приемопередатчиков, работающих только на традиционный кабель.

Вбета$режиме в линию передаются символы, несущие полезную и служебную информацию:

байты данных — заголовки и тела передаваемых пакетов;

байты запросов, которые могут содержать:

асинхронные и изохронные запросы BOSS$арбитража, упакованные в один байт: 3 бита на код асинхронного запроса (NONE_ODD, NONE_EVEN, CUR RENT, NEXT_ODD, NEXT_EVEN, CYCLE_START_REQ, BORDER), 3 бита на код изохронного запроса (ISOCH_NONE, ISOCH_EVEN, ISOCH_ODD,

ISOCH_CURRENT) и два бита нулевые). Асинхронные и изохронные запро$ сы независимы друг от друга;

запрос и фазу традиционного арбитража (LEGACY_REQUEST, LEGACY_ PHASE, номер фазы кодируется двумя битами);

конфигурационные запросы: TRAINING, DISABLE_NOTIFY, CHILD_ NOTIFY IDENT_DONE$PARENT_HANDSHAKE, OPERATION, STANDBY, SUSPEND, PARENT_NOTIFY.

Управляющие маркеры (4$битные коды): BUS_RESET, CYCLE_START_EVEN,

CYCLE_START_ODD, ASYNC_EVEN, ASYNC_ODD, ATTACH_REQUEST ARB_ CONTEXT, DATA_PREFIX, DATA_END, DATA_NULL, GRANT, GRANT_ISOCH, SPEEDa, SPEEDb, SPEEDc.

Байты данных и запросов скремблируются и кодируются в 10$битные символы единообразно, их можно различать только по контексту. Управляющие маркеры кодируются так, что они в 10$битных символах явно отличимы от данных и запро$ сов. Избыточное кодирование является помехозащищенным — недопустимые ком$ бинации считаются ошибочными. Для обеспечения побайтной синхронизации используются специальные символы, не совпадающие с символами, представляю$ щими байты передаваемой информации.

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

нее 1/2, 1/4, 1/8, …, 1/32 части. Последний случай относятся к порту, работающе$ му на S3200 и передающему пакет на скорости S100.

Пакеты могут передаваться как в традиционном (Legacy) формате, так и в бета$ формате. Пакеты бета$формата передаются только между бета$узлами, в традици$ онные фрагменты гибридной шины они не транслируются. Передачи на скоростях S800 и выше возможны только в бета$формате. Общая структура формата переда$ чи приведена на рис. 22.7. Для сохранения возможности обмена с узлами, поддер$ живающими различные скорости и форматы, применяются специальные меры:

управляющие маркеры размножаются — передаются столько раз, во сколько эффективная скорость меньше скорости работы порта;

вводится префикс пакета, в котором передается код скорости и определяется формат пакета;

если эффективная скорость ниже скорости порта, между символами содержи$ мого пакета вводятся символы$заполнители.

Рис. 22.7. Передача пакетов 1394b

Префикс пакета начинается с кода скорости, за которым следует один или несколь$ ко символов$маркеров начала данных DATA_PREFIX. Код скорости определяет относительную скорость передачи (отношение эффективной и согласованной ско$ рости) и формат. Отсутствие кода скорости означает передачу традиционного па$ кета на скорости S100. Кодирование скорости и формата приведено в табл. 22.5. Здесь буквой В обозначен символ SPEEDb, буквой C обозначен символ SPEEDc, Cm означает m повторов символа SPEEDc. Букве X соответствует SPEEDа для тра$ диционного пакета и SPEEDb для бета$пакета, по этим символам и определяется формат пакета. В таблице приведено и время Ts, отводимое для сигнализации ско$ рости.

Содержимое пакета — символы, кодирующие передаваемые байты, — «разбавля$ ется» управляющими маркерами SPEEDc. Их количество определяется отноше$ нием скоростей: 1 для 1/2, 3 для 1/4, 7 для 1/8, 15 для 1/16 и 31 для 1/32. На рис. 22.7 изображены символы$заполнители Cz для случая, когда скорость порта в 4 раза выше эффективной скорости передачи пакета. По пути к узлу$получателю пакет может проходить через сегменты с различными согласованными скоростями, в ре$ зультате количество символов$заполнителей может меняться (сокращаться при прохождении через «медленные» сегменты или увеличиваться при прохождении более скоростных). Понятно, что пройти через сегмент, для которого согласован$ ная скорость ниже эффективной, пакет не сможет.

Признаком завершения пакета может быть любой из символов$маркеров (возмож$ но, повторяющийся многократно) ARB_CONTEXT, DATA_END, DATA_PREFIX,

DATA_NULL, GRANT, GRANT_ISOCH или LEGACY_PHASE. Традиционные паке$ ты могут завершаться и одним из символов DATA_END/GRANT/GRANT_ISOCH (их цепочкой), за которым следует LEGACY_PHASE (один или несколько).

Таблица 22.5. Кодирование скорости и формата передач

Обнаружение подключения и согласование скорости

В бета$режиме обнаружение подключения и согласование скорости портов проис$ ходит без использования сигнализации постоянным током, как это было в IEEE 1394 и 1394a. Сигнализация подключения осуществляется тональными сигналами, передаваемыми по линии TPA и прослушиваемыми с линии TPA. Двуязычные узлы имеют оба механизма обнаружения подключения: тональный и с сигнализа$ цией постоянным током. Алгоритм работы обнаружения подключения работает таким образом, чтобы по возможности установить соединение в бета$режиме. Если это не удается (партнер не посылает тональный сигнал, а упорно подает смеще$ ние), то включается традиционная схема обнаружения подключения и согласова$ ние скорости.

Для согласования скорости в бета$режиме используются серии тональных посы$ лок. Эти серии отличимы от одиночных посылок обнаружения подключения, а так$ же от непрерывных тональных сигналов пробуждения (resume), хотя в них исполь$ зуется одна и та же частота (48–61 МГц). Диаграмма посылок приведена на рис. 22.8. Каждый тональный сигнал представляет один бит (есть тон — бит единич$ ный). Узел передает посылки, в которых закодирована максимальная поддержи$ ваемая им скорость, одновременно прослушивая сигнал от партнера. Обнаружив посылку от партнера, он посылает посылку с битом ack = 1 (до того было ack = 0), в которой теперь указывает согласованную скорость (минимальную из передавае$ мой и принимаемой посылок). Приняв посылку с единичным битом ack, порт пре$ кращает посылки согласования, и соединение устанавливается на общедоступной скорости. В посылке согласования скоростей два бита — P (PIL_Capable) и F (FOP_Capable) относятся к свойствам интерфейса порта (см. главу 23).

Рис. 22.8. Посылки согласования скоростей

После согласования скорости порты должны взаимно синхронизироваться: уста$ новить битовую синхронизацию, определить границы символов и синхронизиро$ вать друг с другом свои скремблеры и дескремблеры. Для этого выполняется процедура тренировки (training) — порты обмениваются специальными трениро$ вочными последовательностями символов.

Установленная синхронизация в процессе работы может быть потеряна. Порт от$ слеживает потерю синхронизации: у него имеется счетчик неверных принятых символов. Прием каждого неверного символа инкрементирует счетчик, прием под$ ряд двух верных символов декрементирует счетчик (в пределе до нуля). Если счет$ чик успевает досчитать до четырех, порт считает, что синхронизация потеряна и ее требуется восстановить с помощью тренировочной последовательности. Трениров$ ку может инициировать и его партнер, послав запрос TRAINING.

Предотвращение петлевых соединений

Петлевые соединения узлов недопустимы и запрещены в шине IEEE 1394; за их отсутствие отвечает пользователь, соединяющий устройства. Петлевые соедине$ ния приводят к «зависаниям» конфигурирования и арбитража, а также к беско$ нечно повторяющимся сбросам. В дополнении 1394b введен механизм автомати$ ческого исключения петлевых соединений, правда, пригодный только для узлов с портами, работающими в бета$режиме.

При соединении устройств их порты согласуют скорости и выполняют трениров$ ку, после чего переходят в состояние Untested (не тестирован). Для каждого нете$ стированного порта узел должен проверить, не приведет ли разрешение его рабо$ ты к петле в шине. Если тест дает отрицательный результат (петли не будет), то порт переводится в активное состояние (Active); если петля будет, то порт перево$ дится в запрещенное состояние (Loop disabled). Проверка на петлевые соединения производится посылкой тестового пакета LTP (Loop$Test Packet) в тестируемый порт и сравнением символов, принимаемых с остальных портов, с тестовым сим$ волом, передаваемым в LTP. Если принимаемые символы не совпадают, значит, петли нет и можно разрешить работу порта. Если символ совпадает, то делается попытка тестирования с другим значением символа (это может быть случайным совпадением). Если совпадение происходит на нескольких разных символах, это является признаком петли и работу порта разрешать нельзя. Для того чтобы тес$

тировать свои порты, узел должен получить управление шиной, выиграв арбит$ раж.

Состояние Standby

В новом энергосберегающем состоянии порта и узла — 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, по которому «племянник» становится «боссом» и переводит свой порт в активное состояние.

Интерфейс для кросс шины (Backplane)

Физический интерфейс для использования в кросс$шине имеет ряд особенностей, отличающих его от кабельного варианта. Эти особенности касаются только PHY$ уровня; на работе LINK$уровня и вышестоящих они не сказываются. Интерфейс отличается следующими моментами.

Вместо двух дифференциальных пар (TPA и TPB), соединяющих порты узлов по$ парно, используются два сигнальных провода STRB и DATA, к которым подключены все соединяемые порты 1394 на шасси. Уровни сигналов на этих линиях стандар$ том не оговариваются. Для работы шины существенно лишь, чтобы в случае столкновения передач логического «0» и «1» состояние линии воспринималось бы всеми узлами как «1». То есть шина должна обеспечивать логическую функцию «Проводное ИЛИ». В случае ТТЛ$интерфейса шины логической единице соответ$ ствует низкий уровень напряжения и передатчиками являются элементы с откры$ тым коллектором. Приемопередатчики узлов должны быть способными одновре$ менно и передавать, и принимать сигнал.

Здесь также используется DS$кодирование, но с более низкими скоростями: фор$ мальной скорости S100 соответствует скорость около 50 Мбит/с, S200 — 100 Мбит/с.

Механизм арбитража для такой физической шины изменен. Для получения до$ ступа к шине устройство должно послать 10$битную последовательность арбитра$ жа. Последовательность арбитража передается с использованием DS$кодирования, причем всегда на низкой скорости (49,152 Мбит/с). Последовательность начина$ ется с 4$битного кода приоритета, за которым следует 6$битный арбитражный но$ мер узла (его PHY_ID). Посылая эту последовательность, узел следит за состоянием линии (принимает эту последовательность). Как только узел видит, что очеред$ ной принимаемый бит отличается от передаваемого, он понимает, что арбитраж в данной попытке проигран. Последовательность арбитража узел имеет право по$ сылать, только дождавшись покоя шины. При этом последовательность одновре$ менно могут начать посылать несколько узлов. Выиграет арбитраж тот узел, кото$ рый посылает последовательность с самым большим значением кода приоритета, а из узлов с одинаковым приоритетом — тот, у которого самый большой номер. Исходя из этого код приоритета 0000 используется для запроса справедливого ар$ битража, код 1111 — для запроса передачи пакета мастером циклов.

Межпакетные зазоры в кросс$шине значительно сокращены; здесь они определя$ ются в арбитражных тактах (частоты 49,152 МГц):

зазор пакета подтверждения Acknowledge Gap — 4 такта на обнаружение (около 183 нс), на шину пакет подтверждения выдается после 8 тактов покоя;

зазор между субакциями (Subaction Gap) — 16 тактов на обнаружение, пакет передается после 20 тактов покоя (около 410 нс);

зазор сброса арбитража (Arbitration Reset Gap) — 28 тактов на обнаружение, шину можно занимать после 32 тактов покоя (около 651 нс).

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

Кросс$шина 1394 используется как дополнительная шина в составе параллельных шин VME64, FutureBus, GTLP. Здесь ее роль является вспомогательной (как SMBus в PCI). Несмотря на низкую (по отношению к кабельному варианту) ско$ рость, последовательная шина остается высокопроизводительным каналом связи, поддерживающим все передачи 1394.

Трансляция сигналов (функции повторителя)

Соединение более двух узлов в шину IEEE 1394 возможно только при использова$ нии многопортовых узлов. Многопортовость реализуется в PHY$уровне узла, ко$ торый для этого должен иметь в своем составе несколько интерфейсных портов и повторитель. Повторитель (Repeater) служит для передачи пакетов между пор$ тами и кодером$декодером своего узла:

пакет, исходящий с другого узла и не предназначенный для данного узла, транс$ лируется с порта, на который он пришел, во все остальные активные порты, для которых согласованная скорость достаточна для передачи данного пакета;

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

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

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