Сложность и нелогичность архитектуры USB 2.0 вынудила разработчиков USB 3.0 избрать другой путь совершенствования протокола универсальной последовательной шины. Вместо подключения двух контроллеров к одному разъему, как было в предыдущей версии, скоростной вариант USB-шины реализован путем интеграции двух разъемов в едином конструктиве. На какие еще компромиссы вынуждена была пойти IT-индустрия в угоду совместимости?
Какие know-how были применены для достижения приоритетных целей: производительности, минимизации потребляемой мощности и поддержки виртуализации?
Производительность: о чем молчат разработчики?
Контроллер USB 3.0 eXtensible Host Controller Interface поддерживает новый, более скоростной режим передачи данных, который называется SuperSpeed. Он обеспечивает обмен данными по шине до пяти гигабит в секунду. Для сравнения, контроллер USB 2.0 EHCI в режиме High Speed поддерживает скорость до 480 мегабит в секунду.
Архитектура xHCI предусматривает построение контроллера в виде двух раздельных подсистем: USB2 и USB3. Каждая из них использует свою группу сигналов на разъеме USB3. Это сделано для совместимости со «старыми» USB устройствами (Low-, Full-, High-Speed) без использования контроллеров-компаньонов и Rate Matching Hub (RMH). Впрочем, спецификация дает разработчику право самостоятельно выбрать топологию шины. Appendix D этого документа устанавливает правила подключения и декларирования хабов, подразделяя их на Integrated Hubs (реализованные на кристалле контроллера) и Embedded Hubs (реализованные в виде дополнительных микросхем на системной плате).
Рис 1. Иллюстрация правил подключения и декларирования USB-хабов в составе xHCI-контроллера
Позволим себе предположить, что для поддержки Low и Full Speed устройств может существовать программно-невидимый, аппаратно обслуживаемый «прозрачный» RMH, о котором умалчивает спецификация.
Анатомия энергоэффективности
Вспомним, как работает старый EHCI-контроллер USB2.0? Независимо от наличия запросов на передачу данных, он циклически считывает из оперативной памяти расписание транзакций (Schedule), инициируя постоянный трафик на шине памяти, а также генерируя события, требующие обеспечения когерентности кэш-памяти. Разумеется, это приводит к увеличению мощности, потребляемой не только самим USB-контроллером, но и связкой «процессор–память». Данная активность препятствует переходу системы в энергосберегающие состояния.
Для чего нужна такая инициатива со стороны EHCI? Согласно спецификации, разработчики EHCI стремились свести общение драйвера с контроллером к передаче информации через оперативную память. Использование расписания транзакций и минимизация количества обращений драйвера к MMIO-регистрам контроллера, уменьшает утилизацию CPU за счет экономии тактов процессора.
Разработчики xHCI с целью уменьшения потребляемой мощности решили отказаться от постоянной загрузки шины. Контроллер xHCI использует протокол, при котором драйвер подготавливает блоки заданий в оперативной памяти (в кольцевом буфере, который называется Command Ring), после чего процессор выполняет запись в один из MMIO-регистров регистрового блока Doorbell Registers. Запись в этот регистр сообщает контроллеру о том, что в оперативной памяти подготовлен блок задания. Только после этого xHCI инициирует bus-master операции.
Оптимизация шинной архитектуры и использование механизмов отложенной записи для регистра Doorbell, сокращают количество процессорных тактов, затрачиваемых на запись в MMIO регистр.
«Частная жизнь» контроллера
Одним из нововведений в xHCI является Scratchpad Buffers. Контроллер декларирует потребность в специальной области оперативной памяти для приватного использования и взаимодействует с ней в режиме bus-master. Использование RAM для собственных нужд остается внутренним делом контроллера, поэтому и форматирование ее не регламентируется.
Главное отличие Scratchpad от всех остальных структур, размещаемых в оперативной памяти, в том, что они не предназначены для обмена информацией между контроллером и системой, а используются без вмешательства драйвера. Применение таких буферов эффективно при сохранении-восстановлении контекста xHCI-контроллера, связанного с выключением питания в режиме энергосбережения.
Резюме
Поддержка всех режимов передачи данных по шине USB единым xHCI-контроллером не является результатом какого-либо таинственного и изящного решения. Сложность не ликвидируется, а прячется внутрь путем полностью аппаратной реализации технологий, апробированных еще в процессе разработки EHCI-контроллера. Названия этих технологий нам известны: контроллеры-компаньоны и Rate Matching Hub. Новшество в том, что данные ресурсы стали программно-невидимыми. Хотя с другой стороны, это и неплохо: задача разработчиков драйверов упростилась.
P.S. Все цвета USB
Описание USB-архитектуры на языке ACPI AML кода включает не только декларацию топологии, но и указание цветов разъемов в формате R, G, B. Такое решение позволяет программному обеспечению визуализировать на экране «истинный вид» объектов. Это достигается за счет использования ACPI-объекта _PLD (Physical Device Location).
Строго говоря, использование данного ACPI-объекта не связано напрямую с архитектурой USB 3.0 или спецификацией xHCI-контроллера. Теоретически, ничто не мешает использовать его для других устройств. Но вопрос цветовой маркировки разъемов стал актуальным в связи с атрибутированием шины USB 3.0 синим цветом.
- Войдите или зарегистрируйтесь, чтобы оставлять комментарии