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

Подробности

Родительская категория: USB

Категория: Хабы USB

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

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

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

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

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

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

Периодические транзакции (изохронные и прерывания), критичные к времени выполнения, транслятором обрабатываются по конвейерной схеме. Данные запусков периодических транзакций помещаются в SS-буфер, из которого они выбираются F/LS-обработчиком (буфер реализует дисциплину FIFO) и запускаются в виде транзакций на вторичную шину. Результаты этих транзакций помещаются в CS-буфер (тоже FIFO), откуда их извлекает хост. За порядок наполнения и опустошения этих буферов отвечает хост — он планирует транзакции SS и CS. Транзакции запусков проходят без подтверждений со стороны транслятора; хост узнает о судьбе транзакции только в фазе завершения.

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

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

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

В расщепленных транзакциях фаза маркера, определяющая продолжение транзакции, состоит из двух пакетов-маркеров: специального маркера SPLIT, формат которого приведен в таблице, за которым следует маркер обычной транзакции (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 трактуются как признаки начала и конца данных соответственно.

Таблица. Формат маркеров SPLIT

Поле	Sync	PID	Check	Hub Addr	SC	Port Addr	S	E	ET	SRC	EOP
Длина, бит	32	4	74	7	1	7	1	1	2	5	8

«Универсальный» хост-контроллер — UHC

Подробности

Родительская категория: USB

Категория: Хост USB

Хост-контроллер UHC от Intel появился в микросхеме PIIX3 (мост PCI-ISA) чипсетов системных плат для процессоров Pentium и используется во многих последующих изделиях Intel. Это FS/LS хост-контроллер, который большую часть забот по планированию транзакций перекладывает на ПО, — драйвер контроллера UHC (UHCD). Интерфейс контроллера UHC описан в документе Universal Host Controller Interface (UHCI) Design Guide, версия 1.1 вышла в 1996 году.

Драйвер UHC формирует для хост-контроллера дескрипторы, называемые в UHCI «дескрипторами передач» (TD — Transfer Descriptor), на самом деле описывающие каждую шинную транзакцию. Напомним, что в терминах спецификации USB одна передача (transfer) может состоять из нескольких транзакций, а в управляющих передачах используется еще и свой тип транзакции для каждой фазы. Для транзакций передач с гарантированной доставкой дескрипторы TD приходится организовывать в очереди. Очереди нужны для таких передач, поскольку заранее не известно, сколько раз придется пытаться их исполнить. Продвижение очереди возможно только по успешному выполнению транзакции, находящейся в голове очереди, — это правило обеспечивает гарантированный порядок (в пределах своей очереди) доставки пакетов. Каждая очередь имеет свой заголовок (QH). Изохронные передачи исполняются всегда однократно (здесь нет гарантированной доставки), что упрощает их планирование. Драйвер размещает дескрипторы TD и QH в памяти и связывает их между собой в соответствии с планом выполнения транзакций в каждом кадре. Драйверу UHC приходится составлять детальное «расписание» для каждого будущего кадра, для чего используется список Frame List на 1024 кадра. Хост-контроллер обходит списки дескрипторов, начиная с точки, на которую указывает Frame List для текущего кадра, и выполняет соответствующие транзакции. Результат исполнения транзакции помечается в ее дескрипторе, отработанная транзакция помечается как «неактивная», и контроллер, встретив ее при очередном обходе, просто переходит к следующей. Драйвер должен периодически просматривать дескрипторы, извлекая уже отработанные и передавая результаты выполнения клиентскому драйверу. Логика работы контроллера подразумевает, что одному запросу ввода/вывода (IRP) от клиентского драйвера может соответствовать несколько «передач» — элементов очереди. Драйвер UHC разбивает запрос на транзакции и помещает дескрипторы этих транзакций в соответствующую очередь, а очередь включает в ближайшие планы. Драйвер отвечает за балансировку загрузки шины в каждом кадре, в частности, за гарантию предоставления не менее 10% полосы для транзакций управляющих передач. Планированием кадров также обеспечивается требуемая частота обращений к точкам периодических передач.

Контроллер UHC является активным устройством PCI (Bus-Master). Основное взаимодействие драйвера с хост-контроллером происходит с помощью дескрипторов, расположенных в памяти. Контроллер имеет регистры (в пространстве ввода/вывода), с помощью которых можно управлять его поведением: выполнять сброс, глобальную приостановку и пробуждение, подстраивать частоту кадров, управлять запросами прерываний, управлять портами встроенного корневого хаба. Контроллер позволяет работать в отладочном режиме, останавливаясь после выполнения каждой транзакции.

В процессе отработки плана контроллер считывает из памяти дескрипторы и данные, необходимые для начала транзакции. Как только в FIFO-буфер контроллера из памяти поступает информация, достаточная для начала транзакции, контроллер начинает транзакцию на шине USB. В процессе ее исполнения производится передача данных, после завершения контроллер модифицирует дескрипторы в памяти в соответствии с условиями завершения транзакции. В процессе отработки транзакции могут возникать ошибки переполнения или переопустошения FIFO-буфера, связанные с перегрузкой контроллера системной памяти или шины PCI. Эти серьезные ошибки инициируют аппаратные прерывания. В состав хостконтроллера входит и корневой хаб на 2 или более порта.

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

В контроллере UHC имеется специальная поддержка традиционного интерфейса клавиатуры и мыши через контроллер 8042 — перехват обращений к портам 60h и 64h пространства ввода/вывода. При разрешенной эмуляции по обращениям ПО к этим портам UHC вызывает системное прерывание SMI (System Management Interrupt), обрабатывающееся в ПК на процессорах x86 в режиме SMM (System Management Mode), невидимо для обычных программ. Обработчик SMI, перехватывающий эти обращения, формирует последовательности действий, необходимые для их исполнения с помощью клавиатуры и (или) мыши USB. Единственное исключение делается при перехвате команд, управляющих вентилем GateA20, — вместо генерации SMI манипуляции этим вентилем выполняются аппаратно (как это давно делается и в 8042). Эта аппаратная поддержка включается установкой соответствующих параметров CMOS Setup.

Большое неудобство работы с UHC возникает из-за необходимости программного просмотра всех дескрипторов передач на предмет выявления завершенных. Дескрипторы завершенных передач необходимо программно извлекать из цепочек, сохраняя связанность элементов. Планирование транзакций (составление списков дескрипторов и заголовков) — тоже достаточно трудоемкая задача для драйвера. Очевидно, преследовалась цель упрощения аппаратных средств хост-контроллера. Однако это может обернуться зависимостью эффективной производительности шины USB от мощности и загрузки центрального процессора. Такой подход к организации ввода/вывода трудно назвать эффективным.

Устройства хранения данных

Подробности

Родительская категория: USB

Категория: Применение шины USB

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

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

Запрос	bmRequestType	bRequest	Применимость для протоколов
Get_Max_Lun	10100001b	FEh	50h
Bulk-Only_Mass_Storage_Reset	00100001b	FFh	50h
ADSC	00100001b	00	00, 01

Протокол Bulk-Only-транспорт (код 50h) применяется в устройствах хранения со скоростями FS и HS, он рекомендован для всех новых разработок. Этот протокол обеспечивает взаимную синхронизацию устройства и хоста, используя никак не синхронизируемые (системой USB) потоки независимых каналов Bulk-IN и Bulk-OUT через пару соответствующих точек. Кроме того, используются два классовых запроса для определения числа доступных логических устройств и сброса интерфейса.

По запросу Get_Max_LUN устройство возвращает байт с максимальным возможным номером логического устройства (LUN, нумерация с нуля). В запросе в поле wIndex указывается номер интерфейса, wLength = 1.

По запросу Bulk-Only_Mass_Storage_Reset выполняется сброс интерфейса, указанного в поле wIndex: точки Bulk-IN и Bulk-OUT разблокируются, переключатель (Toggle Bit) устанавливается в положение DATA0, интерфейс переводится в состояние ожидания команды, все предыдущие запросы сбрасываются.

Блоки команд и состояний распознаются в последовательности пакетов по фиксированной длине пакета (они всегда ложатся точно в один пакет), сигнатурам и соответствию содержимого полей соглашениям (проверяются и нули в резервных полях). Командный блок длиной до 16 байтов позволяет транспортировать любые наборы команд, используемые в устройствах хранения с традиционными интерфейсами (ATA/ATAPI, SCSI и другие). Протокол передачи команд и данных работает следующим образом:

• хост посылает командный блок CBW (Command Block Wrapper) «в обертке» — пакет фиксированной длины (31 байт), включающий:

1. 4-байтную сигнатуру (dCBWSignature = 43425355h);
2. 4-байтный тег (dCBWTag), который служит для пометки и идентификации ответного блока состояния;
3. 4-байтное поле длины передаваемых данных (dCBWDataTransferLength);
4. байт флагов (bmCBWFlags), в котором используется лишь бит 7, указывающий направление передачи данных остальные биты — нули;
5. байт с 4-битным номером логического устройства, к которому обращается данный командный блок (bCBWLUN в битах [3:0], остальные биты — нули);
6. байт длины командного блока (bCBWCBLength в битах [4:0], допустимо 1–16,
7. собственно командный блок (CBWCB) длиной от 1 до 16 байт и заполнитель, доводящий длину этого поля до 16 байт;

• устройство подтверждает успех приема ACK’ом, анализирует пакет и, если «обертка» корректна и командный блок действителен, выполняет прием или передачу заказанного блока данных. Обмен данными инициирует хост в соответствии с посланной командой (данные могут и не предполагаться, тогда указывается их нулевая длина);
• на каждый командный блок (после успешного исполнения или отвергая его) устройство отвечает блоком состояния CSW в аналогичной «обертке» — 13-байтным пакетом, содержащим:

1. 4-байтную сигнатуру (dCSWSignature = 53425355h);
2. 4-байтный тег (dCSWTag), привязывающий этот ответ к конкретному командному блоку;
3. 4-байтное поле (dCSWDataResidue), в котором указывается разность между заказанным (и переданным) количеством данных и количеством, реально отработанным устройством;
4. байт состояния (bCSWStatus) выполнения команды: 00 — успешно, 01 — отказ (failed), 02 — фазовая ошибка (нарушение последовательности команд и данных).

Если устройство получает недопустимый командный пакет, оно его отвергает соответствующим CSW (с байтом состояния 01). На каждый выпущенный командный пакет хост должен получить ответ — состояние с тем же тегом (теги назначает хост, устройство ими только метит ответ). Фазовая ошибка (нарушение этой последовательности) отрабатывается с помощью классового запроса «сброс интерфейса», передаваемого через EP0, — интерфейс переходит в исходное состояние (готов принять командный блок). Этим же сбросом устраняется возможная блокировка конечных точек.

Протокол Control-Bulk-Interrupt (CBI, коды 00 и 01) предназначен только для FSустройств, для новых разработок он не рекомендуется, на HS его применение не допускается. Для доставки команд служит классовый запрос ADSC (Access_Device_Specific_Command), передаваемый через точку EP0 (Основной канал сообщений). Для доставки данных используются точки Bulk-IN и Bulk-OUT. Через эти же точки (включая и EP0) передается и информация о состоянии завершения команды; в протоколе с кодом 00 для передачи состояний выделяется дополнительная точка Interrupt-IN с длиной пакета 2 байта.

Командный блок передается в фазе данных транзакции управления, реализующей запрос ADSC. В запросе в поле wIndex указывается номер интерфейса, wLength — длина командного блока. Положительное подтверждение (ACK) на стадии состояния означает, что команда успешно принята (этот ответ может быть задержан на неопределенное время посылкой NACK’ов).

Состояние выполнения команды может передаваться несколькими способами:

• по прерыванию: когда у устройства есть что сообщит о состоянии выполнения команды, оно в транзакции с точкой Interrupt-IN возвращает два байта, трактовка которых зависит от подкласса устройства;
• по основному каналу сообщений — устройство в фазе завершения может ответить пакетом STALL, что будет означать отвергнутую команду. Уточнить состояние можно, послав соответствующую команду, предполагающую получение состояния в фазе данных через точку Bulk-IN;
• по каналу передачи данных: обнаружив ошибку в процессе выполнения команды, устройство на очередную транзакцию Bulk-IN/OUT ответит пакетом STALL. Уточнить состояние можно будет, послав следующий командный блок (предварительно разблокировав точки запросом Clear_EP_Halt).

Данные передаются пакетами через точки Bulk-IN и Bulk-OUT, укороченный пакет служит признаком конца блока данных. Хост и устройство отслеживают соответствие объема передаваемых данных запрошенному в команде. В случае обнаружения несоответствия устройство может сигнализировать об этом передачей состояния через точку Interrupt-IN или через ответ STALL в транзакциях передачи данных.

Сброс устройства можно выполнить, послав в запросе ADSC специальный командный блок с содержимым 1D, 04, FF, FF, FF... По этой команде устройство предпримет попытку безопасного прекращения текущей операции, очистит все буферы и очереди. После этого хост должен выполнить запросы Clear_EP_Halt, чтобы разблокировать точки и привести в исходное состояние переключатели Toggle Bit. Сброс через порт USB (по запросу к хабу) во время исполнения команды чреват потерей данных.

Прерывания (точка Interrupt-IN) используются только для протокола 00. На каждый посланный ADSC хост ждет прерывание; если устройство ответит на ADSC условием STALL, то для этой команды прерывание уже не ожидается. Если у устройства есть непереданный запрос прерывания, а хост посылает уже следующий ADSC, то прежний запрос прерывания устройство аннулирует.

Каналы

Подробности

Родительская категория: USB

Категория: Организация шины USB

Коммуникационные каналы USB разделяются на два типа:

• потоковый канал (streaming pipe) доставляет данные от одного конца канала к другому, он всегда однонаправленный. Один и тот же номер конечной точки может использоваться для двух разных потоковых каналов — ввода и вывода. Передачи данных в разных потоковых каналах друг с другом не синхронизированы. Это означает, что запросы клиентских драйверов для разных каналов, поставленные в определенном порядке друг относительно друга, могут выполняться другом порядке. Запросы для одного канала будут исполняться строго в порядке их поступления; если во время исполнения какого-либо запроса происходит серьезная ошибка (об этом устройство сообщает ответом STALL), поток останавливается. Поток может реализовывать передачи массивов, изохронные и прерывания. Потоки несут данные произвольного формата, определенного разработчиком устройства (но не спецификацией USB). В потоках типично использование транзакций, в которых длина поля данных соответствует максимальному размеру, допустимому для его конечной точки. Если требуется разделение потока на логические блоки данных, то это можно сделать, применяя в качестве признака конца блока укороченные пакеты. Если оказывается, что блок укладывается в целое число пакетов максимального размера, в качестве разделителя можно использовать пакеты с нулевой длиной поля данных;
• канал сообщений (message pipe) является двунаправленным. Передачи сообщений во встречных направлениях синхронизированы друг с другом и строго упорядочены. На каждое сообщение противоположная сторона обязана ответить подтверждением его приема и отработки. Последующее сообщение не может быть послано до обработки предыдущего, но при отработке ошибок возможен сброс необслуженных сообщений. Форматы сообщений определяются спецификацией USB: имеется набор стандартных сообщений (запросов и ответов) и зарезервированных идентификаторов сообщений, формат которых определяется разработчиком устройства или интерфейса.

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

Каналы различаются и по назначению:

• основной канал сообщений (Default pipe, он же Control pipe 0), владельцем которого является USBD, используется для доступа к конфигурационной информации всех устройств. Этот канал устанавливается с нулевой конечной точкой, EP0 (endpoint zero), которая у всех устройств всегда поддерживает только управляющие передачи;
• клиентские каналы (Client pipes), владельцами которых являются драйверы устройств. По этим каналам могут передаваться как потоки, так и сообщения; они поддерживают любые типы передач USB (изохронные, прерывания, массивы и управление).

Интерфейс устройства, с которым работает клиентский драйвер, представляет собой связку клиентских каналов (pipe’s bundle). Для этих каналов драйверы устройств являются единственными источниками и потребителями передаваемых данных.

Владельцем основных каналов сообщений всех устройств является драйвер USB (USBD); по этим каналам передается информация конфигурирования, управления и состояния. Основным каналом сообщений может пользоваться и клиентский драйвер для текущего управления и чтения состояния устройства, но опосредованно через USBD. Например, сообщения, передаваемые по основному каналу, используются драйвером принтера USB для опроса текущего состояния (передаются три признака в формате регистра состояния LPT-порта: ошибка ввода/вывода, принтер выбран, отсутствие бумаги).