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

переключения состояния выхода приемника во время нарастания и спада входно$ го сигнала — это приводит к дрожанию фазы (jitter). На невысоких (LS, FS) скоро$ стях дрожание несущественно, поскольку время нарастания/спада сигнала суще$ ственно меньше длительности битового интервала. На скорости 480 Мбит/с это соотношение иное, и накопление дрожания в цепочке повторителей (хабов) при$ вело бы к потере битовой синхронизации. Ресинхронизация выполняется с по$ мощью эластичного буфера — небольшой FIFO$памяти, хранящей последователь$ ность бит транслируемого сигнала. Информация в буфер — биты, извлеченные из NRZI$сигнала, — поступает от приемника порта на частоте входного сигнала (час$ тота подстраивается по полю Sync). Из буфера информация поступает на передат$ чик(и), но синхронизируясь уже от внутреннего генератора хаба. Поскольку час$ тоты входного сигнала и внутреннего генератора абсолютно точно совпадать не могут, темп заполнения буфера отличается от темпа его опустошения. Для ком$ пенсации этих расхождений в начале приема пакета его трансляция задерживает$ ся до тех пор, пока буфер не наполнится до половины; за время передачи пакета наполненность буфера может измениться. Эластичный буфер вносит свою лепту в задержку, вносимую хабом. Глубина буфера определяется исходя из допустимого отклонения скоростей: по спецификации частота синхронизации должна выдер$ живаться с точностью1 ± 0,05%, так что максимальное расхождение частот приема и передачи может достигать ± 0,1%. При этом на пакете максимальной длины (9644 бит) может «набегать» расхождение до 9644×0,1% ≈ 10 бит; с небольшим за$ пасом половинную длину буфера определили в 12 бит. Аналогичная технология применяется в высокоскоростных локальных сетях (Fast Ethernet, FDDI).

HS$пакет, проходя через повторитель хаба, может не только потерять до 4 бит на$ чала синхропоследовательности, но и «обрасти» дополнительным «хвостом» пос$ ле признака EOP, также до 4 бит длиной (dribble bits). Это «обрастание», как и на$ чальная потеря, обусловлено задержкой, вносимой детектором амплитуды сигнала HS$приемника. При прохождении через 5 хабов число лишних бит может дости$ гать 20, но это не страшно — приемник информации все равно верно определит конец пакета по признаку EOP. Вышеуказанная максимальная длина пакета 9644 бит включает в себя эти лишние биты.

Транслятор транзакций

Транслятор транзакций, входящий в хаб USB 2.0, служит для преобразования ско$ ростей обмена по шине: высокой (HS) на стороне восходящего порта в полную или низкую (FS/LS) на стороне нисходящих портов, к которым подключены ус$ тройства USB 1.x. Транслятор выполняет расщепленные транзакции ввода/ вывода и транслирует маркеры микрокадров в маркеры кадров, передаваемые в порты FS.

1В зарубежных источниках принято отклонения выражать в ppm (parts per million — миллионные доли); 0,05% соответствует 50 ppm.

Расщепление транзакций организуется хостом, который знает текущую тополо$ гию шины (к портам каких хабов USB 2.0 подключены устройства или хабы 1.x). Расщепленные транзакции выполняются в два$три этапа, в зависимости от типа и направления передачи:

между хостом и транслятором выполняется специальная транзакция Start Split (SS, расщепленный запуск). Она несет всю информацию, необходимую для за$ пуска транзакции с целевым устройством. На этом этапе транслятор играет роль специфически адресуемого устройства USB;

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

между хостом и транслятором выполняется специальная транзакция Complete Split (CS, расщепленное завершение), которая доносит хосту результаты выпол$ нения транзакции хаба с целевым устройством. Здесь транслятор также играет роль специфически адресуемого устройства USB. Для изохронного вывода этот этап отсутствует, поскольку никакого ответа от целевого устройства не преду$ смотрено.

Во всех этих транзакциях используется обычная «молчаливая» реакция на прием поврежденных пакетов и механизм тайм$аутов.

Каждый нулевой маркер микрокадра хаб транслирует в виде полноскоростного маркера кадра SOF. Расщепленные транзакции на стороне FS/LS выполняются внутри этих кадров. Старт расщепленных транзакций хост планирует на нулевой микрокадр, чтобы к концу последнего (седьмого) микрокадра расщепленная транз$ акция могла быть завершена и все данные оказались бы переданы (чтобы не на$ капливать переходящих остатков). Временные соотношения между транзакциями на обеих сторонах транслятора иллюстрирует рис. 14.3, где в качестве примера рас$ смотрено расщепление транзакции ввода.

Рис. 14.3. Трансляция транзакций

Общая структура транслятора транзакций приведена на рис. 14.4. HS обработчик (HS Handler) помещает информацию расщепленных запусков в свои буферы, а по запросам завершений выбирает из буферов результаты и передает их в виде паке$ тов хосту. Этот обработчик отрабатывает все обычные функции протокола USB, включая генерацию и проверку CRC, посылку хосту подтверждений и т. п. F/LS обработчик (F/LS$Handler) по выбранным из буферов запросам запусков формиру$

ет обычные транзакции USB, начинающиеся с маркеров IN, OUT, SETUP (а для LS$ портов и с преамбулы PRE). Результаты этих транзакций (данные и подтвержде$ ния) он помещает в буферы. Транслятор транзакций обладает буферами, в кото$ рых размещаются все необходимые данные о текущих выполняемых расщепленных транзакциях. По завершении транзакции (на обеих сторонах) буфер освобождает$ ся для обслуживания следующих расщепленных транзакций.

Рис. 14.4. Структура транслятора транзакций

Периодические транзакции (изохронные и прерывания), критичные к времени выполнения, транслятором обрабатываются по конвейерной схеме. Данные запус$ ков периодических транзакций помещаются в SS буфер, из которого они выбира$ ются F/LS$обработчиком (буфер реализует дисциплину FIFO) и запускаются

ввиде транзакций на вторичную шину. Результаты этих транзакций помещаются

вCS буфер (тоже FIFO), откуда их извлекает хост. За порядок наполнения и опу$ стошения этих буферов отвечает хост — он планирует транзакции SS и CS. Тран$ закции запусков проходят без подтверждений со стороны транслятора; хост узна$ ет о судьбе транзакции только в фазе завершения.

Непериодические транзакции (управление и передача массивов) обрабатываются иначе: у транслятора имеется два или более буфера B/C In/Out, каждый из кото$ рых обслуживает по одной транзакции, от начала и до конца. Здесь транзакции запусков подтверждаются транслятором: ответ NAK означает невозможность при$ ема транзакции к исполнению (нет свободных буферов), то есть хосту следует по$ вторить попытку запуска. Ответ ACK означает, что транзакция принята к испол$ нению и через некоторое время следует забрать результат, выполнив транзакцию завершения.

Спецификация предусматривает два варианта реализации транслятора; какой именно применяется, можно узнать из кода протокола интерфейса хаба:

по одному транслятору на каждый нисходящий порт (код протокола — 2); это самый производительный вариант для умножения пропускной способности шины для устройств FS/LS;

один транслятор на все порты (код протокола — 1); здесь возможности умноже$ ния пропускной способности зависят от объема буферов периодических транз$ акций и количества буферов для непериодических.

В расщепленных транзакциях фаза маркера, определяющая продолжение транзак$ ции, состоит из двух пакетов$маркеров: специального маркера SPLIT, формат ко$ торого приведен на рис. 14.5, за которым следует маркер обычной транзакции (IN, OUT, SETUP). Пакет$преамбула PRE в расщепленных транзакциях не использует$ ся — скорость целевого устройства задается в маркере SPLIT, что позволяет хабу провести транзакцию на нужной скорости. Транслятор сам генерирует преамбулу, если вторичный порт, через который обращаются к LS$устройству, опознал FS$ подключение (это означает, что между хабом, транслирующим транзакцию, и це$ левым устройством есть хаб USB 1.x). Маркер SPLIT адресуется к порту хаба (но$ мера в полях HubAddr и PortAddr), а следующий за ним обычный маркер адресует конечную точку целевого устройства. Маркеры SPLIT, используемые для запуска (SS) и завершения (CS) расщепленных транзакций, различаются полем SC: 0 — для SS, 1 — для CS. Поле ET описывает тип целевой конечной точки, с которой будет производиться транзакция (00 — Control, 01 — Isochronous, 10 — Bulk, 11 — Interrupt). Поля S и E трактуются по$разному. Для управляющих транзакций и пре$ рываний поле S определяет скорость (0 — FS, 1 — LS), E = 0. Для остальных тран$ закций, кроме запуска изохронного вывода, поля S и E содержат нули. В транзак$ циях запуска изохронного вывода поля S и E трактуются как признаки начала и конца данных соответственно (см. далее).

Рис. 14.5. Формат маркеров SPLIT

Расщепление периодических транзакций

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

Изохронные транзакции на FS синхронизируются с кадрами (1 мс), в то время как на HS — с микрокадрами (125 мкс). Поскольку за время микрокадра на полной скорости может быть передано всего 187,5 байт данных, при расщеплении транз$ акций на стороне FS можно без ущерба равномерности уменьшить размер переда$ ваемого пакета за один микрокадр (ради облегчения планирования загрузки мик$ рокадров). Исходя из этого, одна транзакция FS, несущая до 1023 байт данных, фрагментируется — разбивается на 1–6 транзакций HS, несущих до 188 байт дан$ ных каждая.

Проще всего расщепляются транзакции изохронного вывода, поскольку здесь не требуется получения от устройства ответа или данных. Одна FS$транзакция изо$

хронного вывода реализуется в виде цепочки из 1–6 HS$транзакций, в каждой из которых после маркера SS посылается маркер OUT, адресующийся к конечной точке целевого устройства, и пакет DATA0 с очередным фрагментом данных. Здесь (и только здесь) в маркере SS поля S (Start) и E (End) определяют местоположе$ ние пакета данных в полноскоростной транзакции: [S:E] = 10 — стартовый, [S:E] = = 01 — последний, [S:E] = 00 — промежуточный, [S:E] = 11 — в пакете все данные транзакции.

Транслятор транзакций, успешно приняв стартовый пакет (с единичным битом S), может начинать транзакцию вывода, полагая, что последующие данные будут хос$ том доставлены своевременно. Отработав пакет с признаком последнего фрагмен$ та, транслятор формирует нормальное окончание пакета (CRC код и EOP). Если промежуточные фрагменты приходят с ошибкой, транслятору придется «испор$ тить» выводимый пакет, введя ошибку вставки бит. Таким образом, целевой при$ емник данные этой транзакции проигнорирует, как некорректные. Транслятор транзакций после приема фрагмента с ошибкой будет игнорировать все расщеп$ ленные транзакции, адресованные к данной конечной точке, у которых нет при$ знака начального фрагмента. Последующую транзакцию со стартовым фрагмен$ том транслятор будет отрабатывать как новую.

Транзакции изохронного ввода расщепляются несколько сложнее, поскольку тре$ буют передачи к хосту данных, которые от целевого устройства будут получены с задержкой. Одна FS$транзакция изохронного ввода реализуется в виде цепочки, состоящей из транзакции запуска, содержащей маркер SS и маркер IN, и несколь$ ких транзакций завершения, в каждой из которых за маркером CS следует тот же маркер IN и ожидается от хаба пакет с очередным фрагментом данных или пакет квитирования. Здесь также данные одной FS$транзакции разбиваются на 1–6 фраг$ ментов (HS$транзакций). Данные всех фрагментов, кроме последнего, возвраща$ ются пакетами MDATA, вынуждающими повторить транзакцию завершения в сле$ дующем микрокадре. Последний фрагмент приходит в пакете DATA0. Вместо пакета данных контроллер может ответить пакетом NYET, если к концу микрокад$ ра он принял от целевого устройства менее трех байт данных. Хост в этом случае повторит транзакцию завершения в следующем микрокадре, если текущий мик$ рокадр не является последним в кадре. Ответ NYET в последнем микрокадре кадра трактуется хостом как ошибка, по которой транзакцию следует завершить и сооб$ щить об этом клиентскому драйверу. Если транслятор транзакций принимает от целевого устройства данные с ошибкой, он ответит пакетом ERR, что тоже выну$ дит хост прекратить транзакцию с сообщением об ошибке.

Транзакции прерываний имеют небольшой размер пакета (до 8 байт данных на LS и до 64 на FS), поэтому для них не нужна фрагментация вывода, а их выполнение укладывается в 1–2 микрокадра.

Транзакция запуска вывода по прерыванию (Interrupt OUT) состоит из последова$ тельности маркеров SS и OUT, за которыми следует пакет данных DATA0 или DATA1. Транзакция завершения состоит из последовательности маркеров CS и OUT, на которую транслятор отвечает пакетом подтверждения:

пакеты ACK, NAK и STALL — это обычные ответы целевой конечной точки;

NYET — признак незавершенности транзакции транслятором; при этом хост должен повторить транзакцию завершения в следующем микрокадре. Если этот ответ получен в седьмом (последнем) микрокадре, данная ситуация считается ошибкой и обрабатывается обычным образом;

ERR — сигнализация об ошибке фазы подтверждения на вторичной шине.

Транзакция запуска ввода по прерыванию (Interrupt IN) состоит из последователь$ ности маркеров SS и IN. Данные от устройства хост получит в пакетах 1–2 транзак$ ций завершения. Транзакция завершения состоит из последовательности марке$ ров CS и IN, на которую транслятор отвечает пакетом данных или подтверждения (NAK, NYET, STALL или ERR с вышеописанными значениями). Если транслятор принял еще не все данные от целевого устройства, они придут в пакете MDATA (если принято менее трех байт, транслятор пошлет NYET), на что хост должен по$ вторить транзакцию завершения в следующем микрокадре. Последняя порция дан$ ных придет в пакете DATA0 или DATA1.

Расщепление непериодических транзакций

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

Транзакции запуска вывода состоит из последовательности маркеров SS и OUT для массивов (Bulk OUT) или SS и SETUP для управления (Сontrol), за которыми сле$ дует пакет данных DATA0 или DATA1. Транслятор подтверждает запуск ответом ACK, после которого хост должен выполнить транзакцию завершения, или отвер$ гает его пакетом NAK, после которого хост должен повторить запуск. Транзакция завершения состоит из маркеров CS и OUT, на что транслятор отвечает подтверж$ дениями ACK, NAK, STALL (это обычные ответы целевой конечной точки) или NYET — транзакция еще не завершена, хосту следует позже повторить транзакцию завер$ шения.

Транзакции запуска ввода состоит из последовательности маркеров SS и IN, транс$ лятор своим ответом подтверждает (ACK) или отвергает (NAK) запуск. Транзак$ ция завершения состоит из маркеров CS и IN, на что транслятор отвечает пакетом данных (DATA0 или DATA1) или подтверждениями NAK, STALL или NYET с вы$ шеописанным значением.

Специфические дескрипторы и запросы к хабам

Хабы USB относятся к стандартным устройствам с кодами класса 09 подкласса 00. Код протокола характеризует транслятор транзакций (для хабов 2.0), он зависит от типа, текущей скорости работы и структуры хаба:

00 — хаб FS (без транслятора транзакций) или хаб HS, подключенный к на FS$ порту;

01 — HS$хаб с одним транслятором транзакций;

02 — HS$хаб с несколькими трансляторами транзакций.

Эти коды классификации хаб сообщает в своих дескрипторах устройства и интер$ фейса.

Кроме стандартных дескрипторов хаб имеет специальный классовый дескриптор (hub class descriptor), содержание которого раскрывает табл. 14.1.

Таблица 14.1. Классовый дескриптор хаба

Сме	Поле	Длина	Содержание
щение
0	bDescLength	1	Длина дескриптора (зависит от числа портов, 9 для
			хабов с числом нисходящих портов 1–7)
1	bDescriptorType	1	Тип (29h — дескриптор хаба)
2	bNbrPorts	1	Число нисходящих портов
3	wHubCharacteristics	2	Характеристики хаба:
			Биты [1:0] — режим управления питанием портов:
			00 — для всех портов одновременно (Ganged power
			switching), 01 — селективное, 1x — нет управления
			(для хабов 1.0);
			Бит 2 — признак комбинированного устройства:
			1 — к некоторым портам хаба всегда подключены
			встроенные устройства;
			Биты [4:3] — Режим защиты от перегрузки
			по питанию: 00 — глобальная защита,
			01 — индивидуальная защита портов, 1x — нет
			защиты (для хабов, питающихся от шины);
			Биты [6:5] — характеристика быстродействия
			транслятора транзакций (TT): 00 — TT делает
			межкадровый зазор на нисходящих портах до 8 FS
			bt, 01 — до 16, 10 — до 24, 11 — до 32;
			Бит 7 — наличие управляемых индикаторов
			состояния нисходящих портов;
			Биты [15:8] — резерв (0); в USB 1.x резервными
			были биты [15:5]
5	bPwrOn2PwrGood	1	Время установления нормального питания
			на нисходящих портах с момента команды
			включения (в 2 мс интервалах)
6	bHubContrCurrent	1	Максимальный ток, потребляемый контроллером
			хаба (мА)
7	DeviceRemovable	?	Признаки возможности отсоединения устройств
			от портов. Бит 0 не используются, биты 1…n
			соответствуют портам 1…n (0 — отсоединяемое
			устройство, 1 — нет). Длина поля (в байтах) зависит
			от числа портов, в «лишних» битах — нули
?	PortPwrCtrlMask	?	Маска управления питанием портов (в USB 1.x),
			единичное значение бита означает, что данный порт
			не подчиняется общей команде управления
			питания. В USB 2.0 все биты единичные. Связь
			битов с портами как и в предыдущем поле

Хаб имеет всего один интерфейс, в котором используется (кроме нулевой) только одна конечная точка типа Interrupt IN для опроса признаков изменения состояния портов (Status Change Endpoint) с максимально возможным периодом опроса (bInterval = FFh). С этой точки хост получает информацию в виде битовой кар$ ты, размер которой (в байтах) зависит от числа портов хаба. Самый младший бит карты (бит 0) несет признак смены состояния хаба (1 — есть смена), бит 1 — смены состояния порта$1, бит 2 — порта$2 и т. д. Обычно эти сообщения однобайтные, поскольку более 7 портов в хабе встречается редко. Если изменения состояния пор$ тов не произошло, то хаб на опрос отвечает NAK’ом (не передает данных). По по$ лучении признака изменения состояния хаба хост выполняет запрос чтения со$ стояния хаба (GetHubStatus), по получении признака изменения состояния порта — запрос чтения состояния этого порта (GetPortStatus).

Хаб поддерживает все стандартные запросы к устройствам, кроме управления ин$ терфейсом (он всего один) и установки метки времени (у хаба нет изохронных точек). Кроме того, он должен поддерживать классовые запросы, определенные для хабов (табл. 14.2).

Таблица 14.2. Классовые запросы хаба

Запрос	bmRequestType	bRequest
ClearHubFeature	00100000B	1
ClearPortFeature	00100011B	1
ClearTTBuffer	00100011B	8
GetHubDescriptor	10100000B	6
GetHubStatus	10100000B	0
GetPortStatus	10100011B	0
ResetTT	00100011B	9
SetHubDescriptor	00100000B	7
SetHubFeature	00100000B	3
SetPortFeature	00100011B	3
GetTTState	10100011B	10
StopTT	00100011B	11

Для опроса состояния хаба и каждого его нисходящего порта имеются специаль$ ные (классовые) запросы GetHubStatus и GetPortStatus (wLength=4). Ответом на

GetHubStatus будет слово состояния хаба wHubStatus, за которым следует слово изменения состояния wHubChange. В запросе GetPortStatus в поле wIndex указыва$ ется номер порта, ответом на него будет слово состояния порта wPortStatus, за которым следует слово изменения состояния порта wPortChange. Форматы этих слов приведены в табл. 14.3.

Таблица 14.3. Форматы слов состояния и изменений состояния хаба и портов

Бит Имя признака Назначение

Слово состояния хаба wHubStatus

0Hub_Local_Power Признак состояния локального источника питания хаба:

0 — локальное питание в норме, 1 — потеряно локальное питание.

1Hub_Over_Current Перегрузка по питанию (только для хабов с общей защитой

для всех портов): 1 — сработала общая цепь защиты, 0 — нет

[2:15] Резерв

(0)

Слово изменения состояния wHubChange

0C_Hub_Local_Power Признак смены состояния локального питания: 1 — была

смена, 0 — нет

1C_Hub_Over_Current Признак смены состояния общей перегрузки: 1 — была

смена, 0 — нет

[2:15] Резерв

(0)

Слово состояния порта wPortStatus

0Port_Connection Текущее состояние подключения к порту: 1 — подключено

		устройство, 0 — нет
1	Port_Enable	Состояние разрешения порта: 0 — disabled, 1 — enabled.
		Устанавливается только программно хостом, сбрасывается
		программно и аппаратно по ошибке устройства
2	Port_Suspend	Состояние приостановки порта: 0 — не приостановлен,
		1 — приостановлен или находится в процессе возобновления.
		Устанавливается только программно, сбрасывается

программно или сигналом удаленного пробуждения от этого порта

3Port_Over_Current Перегрузка порта по питанию (только при селективной

		защите портов): 1 — защита сработала, 0 — нет
4	Port_Reset	Сброс порта: 1 — подается сигнал Reset, 0 — нет.
		Устанавливается программно, сбрасывается аппаратно
		хабом по окончании сигнализации
[5:7]	Резерв	(0)
8	Port_Power	Состояние питания порта (отражает реальную ситуацию
		только при селективном управлении питанием): 0 — порт
		не запитан, 1 — порт не обесточен селективно

9Port_Low_Speed Признак низкой скорости: 1 — обнаружено подключение

		LS устройства, 0 — подключенное устройство (если есть)
		либо FS, либо HS (смотря по биту 10)
10	Port_High_Speed	Признак высокой скорости: 1 — с устройством согласова
		на высокая скорость, 0 — нет
11	Port_Test	Состояние тестирования порта: 1 — порт в режиме
		тестирования, 0 — нет (устанавливается программно)
12	Port_Indicator	Управление индикатором порта: 0 — индикатор управляется
		аппаратно, 1 — программно
[13:15]	Резерв	(0)

Бит	Имя признака	Назначение
Слово изменения состояния порта wPortChange
0	C_Port_Connection	Изменение состояние подключения устройства:
		1 — состояние сменилось, 1 — нет
1	C_Port_Enable	Изменение состояния разрешения порта, устанавливается
		в 1 при автоматическом запрещении работы порта из за
		обнаруженной ошибки

2C_Port_Suspend Изменение состояния приостановки устройства,

устанавливается в 1 при завершении возобновления работы устройства (Resume complete)

3C_Port_Over_Current Изменение состояния индивидуальной защиты порта:

		1 — состояние изменилось, 0 — нет (или нет индивидуальной
		защиты)
4	C_Port_Reset	Изменение состояния сброса порта: 0 — нет изменений,
		1 — сброс завершен
[5:15]	Резерв	(0)

Управление свойствами хаба (запросы SetHubFeature и ClearHubFeature) и каждо$ го из нисходящих портов (запросы SetPortFeature и ClearPortFeature) обеспечива$ ют функции, приведенные в табл. 14.4.

Таблица 14.4. Управление свойствами хаба

Имя свойства	Номер	Запрос установки	Запрос сброса
	(wValue)
Свойства хаба		SetHubFeature	ClearHubFeature
C_Hub_Local_Power	0	Установка (для диагно	Сброс одноименного
		стических целей) одно	признака в слове изменения
		именного признака в слове	состояния хаба
		изменения состояния хаба	(подтверждение, что хост
			его воспринял)
C_Hub_Over_Current	1	То же	То же
Свойства порта		SetPortFeature	ClearPortFeature
Port_Connection	0	Запрос не используется, хаб не выполняет никаких
		операций
Port_Enable	1	Перевод запитанного порта	Перевод порта в состояние
		в состояние Enabled	Disabled
Port_Suspend	2	Приостановка порта	Генерация возобновления
			на приостановленном порте
Port_Over_Current	3	Запрос не используется, хаб не выполняет никаких
		операций
Port_Reset	4	Сброс и перевод запитан	Запрос не используется,
		ного порта в состояние	хаб не выполняет никаких
		Enabled	операций
Port_Power	8	Подача питания на порт	Снятие питания с порта
				продолжение