Usb phy что это
Всем хороши современные проводные интерфейсы для компьютеров и электроники FireWire и USB. С треском выгнав на пенсию "тормозных" старичков LPT и COM параллельного типа (да-да, подрабатывают пенсионеры вечерами, но это уже давно не мейнстрим), новые последовательные интерфейсы прижились везде – в качестве аналогий вспомним Serial ATA и Serial Attached SCSI (SAS) на месте SCSI и PCI-Express на смену PCI/AGP. Да, всем хороши FireWire и USB – первый в своей новой версии добрался до скоростей 800 Мбит/с, а второй наконец-то обзавёлся одноранговым расширением "On-The-Go". Одна беда – пару метров постоянно путающихся проводов. И баста.
Что там у нас без проводов для ближних дистанций? Bluetooth? Увы, даже в современной версии - Bluetooth Version 2.0, его производительность порядка 2,1 Мбит/с, мало пригодна для обмена большими файлами или передачи современного мультимедийного контента, равно как и Zigbee: звук ещё туда-сюда, а видео – уже никак, даже в стандартном разрешении, не говоря уж о HD Video. Может быть, Wi-Fi? Может, но не панацея. Во-первых, стандарты IEEE802.11a/g с производительностью до 54 Мбит/с и даже IEEE802.11n с производительностью вдвое большей всё равно не заменяют проводные USB/FireWire. Во-вторых, Wi-Fi – это всё же в большей степени сеть, нежели интерфейс для перекачки файлов, а если и так, то в качестве "пушки по воробьям". Прямых конкурентов проводным интерфейсам USB и FireWire не было, и возникла нехитрая идея: воспользоваться уже имеющимся пулом протоколов и спецификаций, дабы попросту отрезать эти самые провода и пустить обмен данными на расстоянии до 10 метров посредством радиоканала. Желательно, с сохранением полной аналогии с основными потребительскими свойствами USB и FireWire, а именно, простотой подключения, идентификации, сохранением скорости передачи и защищённости данных. Отмечу, что подразумевается разработка беспроводной технологии FireWire в полной аналогии с WUSB, однако это уже за рамками нашей сегодняшней темы.
Итак, Wireless USB 1.0. Желающих подробно изучить принцип функционирования этой технологии отправлю к двум предыдущим публикациям, а сейчас – лишь в общих чертах. Стандарт Wireless USB базируется на концепции платформы сверхширокополосной (Ultra Wideband, UWB) беспроводной технологии для передачи данных на короткие - до 10 метров, расстояния; с высокой пропускной способностью (до 480 Мбит/с) и низким энергопотреблением. Платформа UWB - это решение для беспроводной передачи высококачественного мультимедийного контента, например видео, между устройствами бытовой электроники и периферийными устройствами ПК. Одно из основных преимуществ технологии UWB заключается в том, что она не создает помех для других беспроводных технологий, используемых в настоящее время, таких как Wi-Fi, WiMAX и сотовой связи. Схематически интерфейс Wireless USB можно описать таким образом: стандарт подразумевает использование двух основных "слоев" для обмена данными - транспортного и физического уровня. Транспортный уровень базируется на выше упомянутой сверхширокополосной (UWB) технологии; физический представляет собой уровень формирования среды передачи данных, где помимо WUSB с легкостью могут фигурировать W1394 (Wireless FireWire), Bluetooth и прочие, к настоящему времени еще не изобретенные и не сформулированные протоколы. Стандарт Wireless USB - первый UWB-интерфейс, доведенный до коммерческого стандарта.
Сверхширокополосная модуляция (UWB, IEEE 802.15.3a), в свою очередь, весьма схожа с применяемой в стандарте Bluetooth: передатчик генерирует миллиарды импульсов в очень широком - порядка нескольких гигагерц, частотном спектре, а приемная часть преобразовывает импульсы в данные путем отслеживания схожих последовательностей импульсов; модуляция производится мультиплексированием по ортогональным несущим частотам (OFDM, Orthogonal Frequency Division Multiplexing), что в совокупности с принципом использования нескольких частотных диапазонов составляет технологию MultiBand OFDM. Что касается передачи пакетов данных, здесь всё просто – практически полная аналогия формирования транзакций по принципу USB 2.0. Благодаря использованию сверширокополосной модуляции с низкой спектральной плотностью, сигнал как бы "размазывается " в виде своеобразного "белого шума" по широкому спектру частот, при этом рекомендованная спектральная плотность излучения не должна превышать в среднем уровня -41,3 дБм/МГц. Отсюда вытекают два полезных практических вывода: отсутствие влияния на работу других средств связи и мизерное энергопотребление.
Стандарт транспортного уровня MultiBand OFDM для Wireless USB регламентирует спектральный участок шириной 7,5 ГГц, который разделен на пять каналов и несколько отдельных 528 МГц поддиапазонов в каждом канале. В результате получается 14 поддиапазонов шириной 528 МГц каждый, сгруппированных в 5 частотных участков, при этом каждый из 14 поддиапазонов применительно к стандарту Wireless USB обладает возможностью поддержки обмена данными со скоростью до 480 Мбит/с! Гибкость нового беспроводного стандарта как раз в том, что в разных странах могут быть разрешены к использованию не все поддиапазоны, однако на финальную работоспособность и производительность это практически не влияет.
Что касается топологии Wireless USB, здесь также просматривается аналогия с проводным USB - устройства обладают собственным адресом, получаемым при подключении или перечислении, при этом каждое устройство WUSB поддерживает один или несколько каналов для связи с хостом, может работать как MAC Layer устройство. Ключевым же топологическим отличием Wireless USB можно назвать то, что хост-контроллер может поддерживать до 127 устройств в кластерной группе, что, впрочем, не исключает обычного варианта "точка-точка" как частного случая. Интересно отметить, что концентраторы в определении Wireless USB отсутствуют как класс по причине их полной невостребованности в такой архитектуре: кластеры сосуществуют в перекрывающейся пространственной среде с минимальными взаимными помехами, что позволяет функционировать нескольким WUSB-кластерам в пределах общей зоны действия. Плюсы такой топологии – в возможности двойного применения, когда устройство может в ограниченном объеме выполнять функции хоста - эта модель позволит устройству получить доступ к данным, расположенным за пределами кластера, к которому в текущий момент подключено это устройство; для этого устройство должно создать второй кластер, выступая в качестве хоста с ограниченными возможностями. Обратная совместимость Wireless USB с проводным USB также позволяет создавать прозрачные мосты на проводные USB-устройства и хост-контроллеры, то есть, организовывать передачу данных между двумя кластерами. Фактически, это можно назвать "работой над ошибками" USB, где устраненными для проводной версии лишь с появлением протокола USB 2.0 - USB-On-The-Go. Каждое Wireless USB устройство, равно как его драйверы, обладают собственной системой управления энергопотреблением, без перекладывания этой проблемы на хост-контроллер. Имеются три схемы экономии энергии: нормальный обмен данными (прекращение излучения в промежутках между посылками и везде, где это имеет смысл в текущий момент); спящий режим (увеличение промежутков опроса наличия канала); разъединение. Суммарная мощность, потребляемая устройствами Wireless USB, для PHY первого поколения ограничено максимальным уровнем 130 - 160 мВт; ожидается ужесточение этого показателя. Скорость обмена данными интерфейса Wireless USB значительно зависит от расстояния между хостом и устройством и может изменяться в многозадачном окружении в пределах от 53,3 Мбит/с до 480 Мбит/с: порядка 106,7 Мбит/с на расстоянии до 10 метров; 200 Мбит/с на расстоянии более 4 метров и до 480 Мбит/с на расстоянии более 2 метров. Пример навскидку: типичный поток видео с качеством SDTV/DVD составляет 3 -7 Мбит/с и порядка 19 - 24 Мбит/с в стандарте HDTV. По словам разработчиков стандарта, технология Wireless USB в перспективе будет обладать очень надежной защитой трафика от несанкционированного доступа, на уровне проводного стандарта USB 2.0. На практике в первом поколении Wireless USB будет применено шифрование AES-128 с применением CBC-MAC (CCM) - стандартный потоковый криптоалгоритм с применением блоков AES. Технология Wireless USB обеспечивает шифрование трафика с открытыми ключами, применяемыми для аутентификации. Шифрование с использованием открытых ключей может использовать типичный уровень шифрования и более защищенный - RSA с 3072-битным ключом и хэшем SHA-256. Архитектура шифрования при смешенных проводных USB/WUSB соединениях также подразумевает шифрование трафика, проходящего через проводные соединения, это позволяет избежать путаницы и ошибок при сортировке трафика на проводной/беспроводной. Наконец, программная часть. Компания Microsoft, участвовавшая во всех этапах становления стандарта, обеспечила совместимость уже существующих драйверов почти без изменения, за исключением USB ISOC, плюс единственный функциональный драйвер для проводных/беспроводных PAL (Protocol Abstraction Layer). Программная хост-архитектура реализации поддержки UWB включает поддержку шин PCI и PCI Express для интерфейсных слотовых карт плюс автоматически вытекающую из этого поддержку версий CardBus и ExpressCard. Помимо этого, поддерживаются WUSB-решения со стандартными интерфейсными разъемами "проводного USB" (USB Dongles). В конечном итоге, операционной системе совершенно без разницы, используется ли EHCI (USB 2.0) или WHCI (Wireless USB) контроллер, на практике Wireless USB линк воспринимается операционной системой как обычное проводное USB соединение.
Завершить технологический экскурс стоит на том, что в настоящее время индустриальный альянс UWB - WiMedia Alliance насчитывает более 200 компаний-участников, которые работают над коммерциалиацией своих устройств в рамках спецификаций стандарта Wireless USB. Теперь – пожалуй, самое интересное, рассказ о реальных устройствах Wireless USB.
Вполне возможно, кто-то из наших читателей уже встречал на прилавках компьютерных магазинов первые устройства с интерфейсом Wireless USB. Не удивлюсь, ибо появляться им самое время. По крайней мере, появление таких новинок ближе к новогоднему сезону прогнозировали многие представители компаний на сентябрьском Форуме Intel для разработчиков в Сан-Франциско, где мне удалось впервые увидеть великое множество серийных образцов устройств Wireless USB.
Логичный вопрос: в каких именно случаях есть смысл "перебираться" на Wireless USB? Ответ более чем очевиден – везде, где ныне используется обычный проводной USB, и даже там, где его пока нет. Интерфейсы USB настолько плотно вошли в нашу жизнь, что в большинстве случаев мы принимаем как должное, что он имеется в наличии у большинства компьютеров, смартфонов, коммуникаторов, портативной цифровой техники и бытовой электроники. Во всех этих случаях ожидается частичный переход на использование Wireless USB, однако этот процесс будет происходить в два этапа. По информации индустриальной группы USB-IF/WUSB Promoters Group, занимающейся сертификацией устройств Wireless USB, первая волна розничных продуктов с поддержкой этого стандарта – ноутбуков, хабов, "удлинителей" с интерфейсом USB, уже сертифицирована в третьем-четвёртом квартале 2007 года; новинки уже начинают появляться на прилавках магазинов. Отметим, что на данном этапе речь идёт о дискретных решениях или отдельных модулях, встраиваемых в готовые изделия.
Следующая волна решений с поддержкой Wireless USB будет включать в себя устройства с контроллерами, уже интегрированными в чипсеты. Среди них – цифровые видеомагнитофоны, плееры и телевизоры; принтеры, компактные цифровые камеры, PMP/MP3 плееры, внешние HDD, мобильники, смартфоны и так далее. Большинство компаний, демонстрировавших на своих стендах в рамках сентябрьского IDF свои сертифицированные Wireless USB новинки, как раз представляли решения "первой волны" – дискретные карты и устройства, концентраторы, хотя, также попадались работоспособные концепты "второй волны". Пожалуй, наиболее зрелищная демонстрация возможностей Wireless USB была представлена на стенде компании LucidPort Technology. Только представьте: в одном углу импровизированной комнаты установлена Web-камера, совершенно без проводов подключенная к ноутбуку. Сфотографировав меня, сотрудники стенда тут же отправили её на принтер – опять же, без проводов, с интегрированным интерфейсом WUSB. Спору нет, всё это можно организовать и с помощью Wi-Fi, но как представишь объём возни для инициализации; плюс, энергопотребление в последнем случае было бы совсем иным – прощай, батарейка Web-камеры!
Множество интересных экспонатов было представлено на стенде компании Alereon - кстати, одной из первых получившей сертификацию USB-IF на свой WUSB-чипсет AL4000. Хабы, интерфейсны WUSB карты с традиционным разъёмом USB, или под слоты Compact Flash и SDIO – не проблема.
Максимальное на данном этапе количество розничных изделий с интерфейсом Wireless USB было представлено комплектами из 2/4-портового хаба и WUSB-адаптера с разъёмом USB, такие устройства красовались на большинстве стендов.
Впрочем, были и достаточно неожиданные решения – как, например, сетевые карты под шину PCI Express с поддержкой 10/100/1000 Гбит/с LAN на стенде компании Realtek.
Среди решений Wireless USB следующего поколения – с интегрированными контроллерами, следует отметить такой интересный вариант, как цифровая камера от компании Samsung: только представьте себе, насколько упростится скачивание многочисленных фотографий и видеороликов без проводов!
Среди стендов с прототипами и розничными образцами особняком стоит выделить компании, демонстрировавшие ряд специализированных приборов для тестирования Wireless USB устройств, такие как Ellisys, Agilent и другие.
Wireless USB 1.0? Да здравствует Wireless USB 1.1!
И всё же ключевым событием этого сезона в рамках продвижения стандарта Wireless USB стал анонс новой его версии. В настоящее время индустриальная группа Wireless USB Promoter Group занимается разработкой стандарта Wireless USB 1.1, который учтёт все "узкие места" нынешней версии. Как было отмечено выше, максимальная производительность интерфейса стандарта Wireless USB 1.0 достигает 480 Мбит/с на расстояние до 3 м. Именно этот параметр в будущей версии стандарта будет увеличен до 1 Гбит/с! Помимо этого, в версии Wireless USB 1.1 больше внимания будет посвящено более высокочастотным диапазонам UWB – тем, что располагаются выше 6 ГГц, это в совокупности с новыми режимами энергосбережения - Sleep, Listen, Wake, Conserve, по задумке, обеспечит большую экономию расхода батарей. В плане повышения защищённости обмена данными в спецификации Wireless USB 1.1 предполагается активное использование технологии NFC (Near Field Communication). Это позволит реализовать на практике возможности класса "touch and go", среди которых такие интересные функции, как, например, приложения для беспроводных платежей, когда для оплаты или идентификации с помощью шифрованных данных будет достаточно поднести к приёмнику смарт-карту или мобильный телефон. В плане упрощения использования интерфейса в версии Wireless USB 1.1 предполагается реализация такого режима, когда для идентификации будет достаточно всего лишь разместить устройство в непосредственной близости от хоста, в результате чего произойдёт мгновенное распознавание, без необходимости введения дополнительных ручных установок - в полной аналогии с проводным USB. В итоге, ожидается, что финальная версия Wireless USB 1.1 будет завершена в первом полугодии 2008 года. Аппроксимируя традиционные для подобных спецификаций сроки реализации можно прогнозировать с высокой долей вероятности, что розничные изделия с поддержкой Wireless USB 1.1 появятся на прилавках в последующее полугодие. Вот, собственно, и весь сказ, на данном этапе развития технологии ничего существенного к уже рассказанному, пожалуй, не добавить. Лично у меня есть такие подозрения, что первое время устройства с интерфейсом Wireless USB, как водится в таких случаях, будут восприниматься этакой диковинкой; не исключено, что не обойдётся без курьёзов – помните, как обычные USB-кабели на заре внедрения стандарта были жутким дефицитом и стоили неприличных денег? Однако очень быстро шумиха уляжется, Wireless USB чипы значительно подешевеют, а затем и вовсе поддержка стандарта будет реализовываться непосредственно в чипсетах для настольных и мобильных компьютерных платформ, смартфонов и коммуникаторов, игровых консолей, телевизоров и плееров, принтеров и фотоаппаратов – как нынешний, всем привычный проводной USB.
Вряд ли распространение Wireless USB в ближайшем времени приведёт к смерти других "локальных" беспроводных интерфейсов – вроде Bluetooth. Однако в более долгосрочной перспективе – как знать, ибо конкурентов, равных ему по производительности, пока не предвидится… Список литературы для более серьёзного изучения технологии Wireless USB
ULPI это интерфейс для организации высокоскоростных IP-систем USB 2.0. Он определяет взаимодействие между контроллерами USB и микросхемами PHY или трансиверами, которые соединяются с реальной физической шиной USB. Аббревиатура ULPI означает UTMI+ low pin interface (UTMI+ с уменьшенным количеством выводов), и он был специально разработан для уменьшения количества выводов корпусов микросхем high-speed USB PHY. Уменьшение количества выводов минимизирует стоимость и место на плате, необходимое для установки и разводки чипа PCB, и уменьшает количество выводов, назначенных для связи с высокоуровневым контроллером USB. В результате этих свойств ULPI быстро стал новым стандартом интерфейса среди разработчиков систем и чипов (SMSC, NXP Semiconductors, Mentor Graphics).
Стандарты UTMI+ и ULPI. ULPI это расширение стандарта UTMI+ PHY. Оба стандарта определяют интерфейсы между высокоуровневым контроллером USB и микросхемами PHY для организации физического соединения с шиной USB, однако ULPI специально предназначен для микросхем PHY. Стандарт UTMI (расшифровывается как USB transceiver macrocell interface) был разработан компанией Intel® для высокоскоростных периферийных устройств (USB v2.0). UTMI позволяет периферийным устройствам подключаться к компьютеру либо на высокой high-speed, либо на полной (full-speed) скорости (для совместимости со старыми PC). Стандарт UTMI+ это расширение оригинального UTMI, которое поддерживает контроллеры OTG и контроллеры хоста на всех скоростях.
Наподобие UTMI+ для встроенного в чип PHY, стандарт ULPI предоставляет основную выгоду для разработчиков решений USB при использовании отдельных микросхем PHY. Оба стандарта поддерживаются организацией ULPI Working Group. Хотя ULPI это не полностью открытая спецификация, любой может свободно присоединиться и стать пользователем ULPI. Зарегистрируйтесь на сайте ULPI Working Group, чтобы получить бесплатную копию документации стандарта.
Сегодня использование девайсов на ПЛИС с сетью Ethernet (или как острят некоторые мои знакомые, «Азернет») – общее место. Особенно если речь идёт о высокоскоростной передачи данных (АЦП/ЦАП с сетевым выходом, обработка видео, «сырца» с радиолокаторов и гидроакустических комплексов, сбора данных с большой сети (решётки датчиков и т.д. и т.п.). Когда я вижу, как люди, покрывшись испариной, пытаются упихать поток отсчётов с квадратурного демодулятора SDR в USB 3.0, мне их становится откровенно жалко.
Отдельная огромная тема — это на чём это реализовывать. Вариантов несколько, но, в большинстве своём, плисоводы приходят к выводу, что лучший вариант — это «рукопашный».
В начале стоит внешняя «физическая» микросхема (PHY), которая выполняет работу нулевого уровня (если строго следовать модели OSI), т.е. преобразование аналоговых сигналов в цифровые, битовую и кадровую синхронизации. Затем следует MAC-уровень, т.е. всё, начиная от проверки контрольной суммы (КС) пакета до разборки и вытаскивания «полезной нагрузки» из многочисленных IP-протоколов: начиная от TCP, UDP и ARP и заканчивая экзотикой типа H.248.
В И-нете, да и здесь на Easyelectronics описывались проекты, которые вообще напрямую стыкуют микроконтроллер с сетью. Но такие решения — это максимум, что бы раз в минуту послать пакетик с какого-нибудь датчика температуры со скоростью 10Мбит/с. Для скоростей выше — внешняя микросхема PHY с соответствующей обвеской. Пару слов (а то это — тоже обширная тема) об интерфейсах PHY. 1Gb PHY-микросхемы наследуют от своих более тихоходных предшествнников, но и превносят новое (а не только изменение частоты оцифровки). Управляются они также.
Во-первых, это — интерфейс настройки MDIO. Это — некоторая помесь SPI и I2C, эдакий двухпроводный SPI. По этому интерфейсу задаются режимы работы микросхемы путём записи/чтения в определённые регистры. Список основных регистров (адреса и содержимое) стандартизован IEEE 802.3. И, в целом, производители этого стандарта придерживаются, но добавляют обычно много своих регистров с более тонкими настройками. А в некоторых микросхемках, например, в популярной PHY 88E1111 от Марвелла, даже добавляют вторую «страницу» регистров (дело в том, что эта микросхема может работать и по витой паре и по оптике и каждая линия имеет свой набор регистров «страницу»).
Самые основные настройки (типа выбора интерфейсов и скорости работы) обычно могут быть выбраны внешними перемычками (которые обычно спарены с выводами светодиодов). Т.е., в принципе, можно не заворачиваться с написанием MDIO-блока, но только в принципе, ибо тогда будут не доступны многие реально полезные вещи (в частности, жёсткое задание скорости и внутренний ФАПЧ для сдвига тактовой частоты (см. далее).
Теперь об основном интерфейсе. В отличии от 100Мбит-прородителей в 1Гбит-микросхемах появились новые форматы: это SGMII, GMII и RGMII.
SGMII — это последовательный интерфейс, который хорош тем, что ему требуется всего одна пара проводов (в одну сторону, есс-но дифференциальных, конкретнее — LVDS), если работа идёт без опорного генератора. А огромный минус его в том, что работа идёт на частоте аж 625МГц по обоим фронтам. Далее этот поток (если речь о приёме) следует преобразовать в параллельный код. В принципе, топовые микросхемы, типа того же Stratix'а IV и V с максимальными суффиксами в состоянии выполнить такое преобразование «на себе», т.е. на схеме, реализованной на внутреннем массиве логических элементов (ЛЭ). Но, такая схема будет весьма нестабильна (ибо работать будет почти на пределе возможностей, когда, по-сути, цифровая схема превращается в «полу-аналоговую» и всё, что показывают имитаторы типа Modelsim'а — никакого отношения к действительности не имеет), да и ставить мегадорогущие каменюги ради стыковки с PHY — не очень серьёзно. Поэтому, во многие ПЛИСины втискивают аппаратные приёмопередатчики SGMII. Но настройка этих блоков — отдельная и непростая штука. Кроме того, нужно помнить про сложности разводки печатной платы, ибо даже исходная частота (625МГц), мягко говоря, не детская, а с учётом требований к фронтам и спадам (типично, максимум — 0,2нС) — можете легко посчитать требуемую широкополосность линий. Поэтому, мой совет — с SGMII связываться только в крайнем случае!
Гораздо проще ситуация с GMII и RGMII-интерфейсами. Это — параллельные (8 и 4, соответственно) линии связи. Тактовая частота снижена до разумных 125МГц, хотя даже такая частота может представлять определённую проблему для дешёвых вариантов современных ПЛИС, особенно если нужно «выжать» всё, что можно из 1Гбит-интерфейса и, соотвественно, пакеты должны формироватся «на лету». Поскольку, для RGMII-интерфейса при тактировании по одному фронту понадобилась бы тактовая частота в 250МГц (что уже совсем тяжеловато для большинства современных ПЛИС), здесь также производится тактирование по фронту и спаду тактового сигнала.
Если очень страшно связываться с двойным тактированием, то можно использовать GMII-интерфейс и тут, фактически, разработчик почти спокойно может использовать наработки, взятые из MII-интерфейса, разве что не забыв, что по GMII передаются байты, а не полубайты(нибблы) и, есс-но, подняв скорость передачи в 5 раз.
Но лишние выводы в современных ПЛИС'инах весьма дороги и RGMII-интерфейс предоставляет возможность разумной экономии (между GMII и SGMII) ценой некоторого (на самом деле, небольшого) усложнения схемы. И, кстати, если ваше устройство должно иметь возможность работать и с 1Гбит и с 100Мбит-устройствами, то, на самом деле, наиболее простой переход с MII обеспечивает RGMII.
Как стыковать RGMII с ПЛИС. Достаточно просто. Теоретически двухтактный буфер можно создать в основном массиве ЛЭ, используя (лучше всего) графику, или поизвращавшись (вообще, убогость этих языков — отдельная тема) в VHDL или Verilog'е (не забыв указать *useioff* у соответствующих выводов). Но, как показала практика, работать это всё будет весьма убого (ибо, с учётом требований к крутизне фронтов, широкополосность должна достигать 400МГц!), правда, даст подсмотреть генирируемые сигнал в СигналТапе(ЧипСкоупе).
Более правильный путь — использовать специализированные двухтриггерные буфера, например, в альтеровском случае — это ALTDDIO в соответствии с документом AN477 «Designing RGMII Interfaces».
Строб пакета tx_en, как показывает практика, лучше тоже протаскивать через ALTDDIO (что и сделано под именем dataout[4]).
Показанная схема будет работать только при условии, что тактовая частота gtx_clk сдвигается на 90 градусов на внутреннем ФАПЧ микросхемы PHY (см. выше диаграмку с RGMII-сигналами). Такая весьма удобная опция предусмотрена в большинстве 1Гбит-PHY, но она включается в соответствующем регистре через MDIO. Например, для 88E1111 — это бит 1 регистра 20. Если же MDIO-приёмопередатчик писать лень, то тогда сдвинутую последовательность нужно сгенерить в ПЛИС с помощью ФАПЧ(PLL) и подать её на выход GTX_CLK. К сожалению, такой вариант часто не обеспечивает нужной стабильности и приводит к редким пропаданием отдельных пакетов.
В качестве дополнения к посту прилагается работающий модуль-шаблон для RGMII-шины как для 100Мбит/с, так и для 1Гбит/с режимов (задаётся параметром SPEED). Код тщательно комментирован, но некоторые пояснения сделаем. Модуль предназначен для проверки скорости работы сетевой системы. Поэтому он шлёт длинные UDP-пакеты с заданной паузой. Длина полезной нагрузки (не пакета!) задаётся параметром DATA_LENGTH. Контрольная сумма (КС) IP прописывается руками, КС UDP не вычисляется (нули). А вот CRC32 считается на лету с помощью модуля CRC32, но в данном примере она тоже была высчитана заранее (благо, не меняется :)) В качестве полезной нагрузки идут просто постоянные байты (в версии с расчётом CRC32 — в начале идёт счётчик байт). Собственно и всё.
Модуль вполне можно использовать как заготовку для своих целей. В этом случае, просьба, оставить в комментах к коду ссылку на этот пост и автора. Кстати, при сборке модуля нужно проверять максимальные задержки в «ТаймКвесте» или аналогичном инструменте. Дело в том, что из-за двух гигантских case'ов код легко читаем, но приводит к генерации огромного массива переключателей, которые, соответственно, могут легко не пойти по задержке для данной ПЛИС. Если такое случилось, то нужно либо подрезать кол-во ветвлений, либо генерить часть данных во внешней ПЗУ. Короче, дальше — всё в ваших руках. С помощью данного модуля удавалось «выжать» полезную (т.е. уже за вычетом всех заголовков) скорость передачи до почти 970Мбит/с.
В качестве сигнала reset в простейшем случае можно использовать выход locked ФАПЧ.
Ещё один момент. Во многих микросхемах, в частности, семейства Cyclone IV, Сигнал Тап не имеет возможности снять сигнал после модуля DDIO_out. Да-да! Как известно, СигналТап часто при компиляции «не может» дотянутся до нужных вам сигналов, даже если на них навешен LCELL (или атрибут *keep* в Verilog'е). Это происходит по разным причинам, это — тема для отдельной статьи.
Но, среди плисоводов (даже весьма опытных) бытует «городская легенда», что, что бы 100% увидеть нужный сигнал в СигналТапе достаточно его повесить на какую-либо ногу микросхемы. Так вот — ничего подобного! Вот вам пример. Это хорошо видно по схемотехнике выходных цепей соответствующей микросхемы. Так что сигналы на RGMII-шине штатной смотрелкой подсмотреть скорее всего не удастся. А при попытке их завернуть на какой-нибудь вход ПЛИС всё закончится, скорее всего, разбалансировкой линий и соответствующими проблемами.
Появилось немного свободного времени, и я решил написать небольшую «внеплановую» статью.
Итак, из предыдущей статьи, мы знаем, что для обмена данными используются некие виртуальные каналы – «конечные точки». Давайте рассмотрим, как происходит обмен.
Обмен данными по USB
Нужно помнить, что интерфейс USB предусматривает использование разветвлителей – хабов. Более того, допускается каскадное включение хабов. Следовательно, необходимо как-то идентифицировать конкретное USB устройство в «гирлянде» из хабов и USB устройств. Для этого каждому устройству присваивается адрес.
Здесь остановимся немного подробнее. Адрес кодируется 7 битами. Изначально (в момент подключения), устройство, грубо говоря, само себе назначает адрес 0. Этот адрес зарезервирован стандартом как раз для вновь подключаемых устройств. Далее, в процессе инициализации (об этом поговорим позже), хост присваивает устройству уникальный адрес отличный от 0, а адрес 0 «освобождается» для вновь подключаемых устройств.
И так, для того чтобы передать данные конкретному устройству, нужно знать адрес устройства и номер виртуального канала «внутри» устройства (адрес «конечной точки»).
Как мы уже выяснили, сразу после включения, устройство имеет особый, «нулевой» адрес. Каждое устройство, согласно стандарту, имеет «нулевую конечную точку» типа Control. Соответственно, сразу после подключения, хост может начинать обмениваться данными с новым устройством (адрес = 0, номер конечной точки = 0).
Рассмотрим, как происходит обмен данными.
Сам обмен осуществляется пакетами. Стандартом предусмотрено несколько типов пакетов. «Побайтно» мы пока разбирать пакеты не будем, но коснемся этого вопроса в практической части.
Дело в том, что часть работы по формированию и передаче пакетов (например, вопросы синхронизации, расчет контрольных сумм и т. д.) возьмет на себя USB периферия МК. Для тех, кто хочет сразу углубиться в биты и байты могу порекомендовать ознакомиться с разделом 8 официальной спецификации USB 2.0
Пока нам достаточно знать, что существуют «пакеты данных» и несколько типов «служебных пакетов».
USB и Plug and Play
Давайте рассмотрим, что с нашим устройством будет происходить дальше, после того как хост определил подключение нового устройства и готов начать обмен данными. Нам нужно ненадолго подняться на «высокий» уровень – уровень ОС.
Дело в том, что в стандарт USB поддерживает концепцию Plug and Play (подключи и играй). Данная концепция подразумевает, что пользователю достаточно «воткнуть» устройство в соответствующий порт ПК. Дальше ОС автоматически определит тип подключенного устройства, найдет подходящий для данного устройства драйвер, сконфигурирует устройство и т. д. (правда, это конечно в идеале :))
Для того чтобы вся эта красота работала, стандартом USB предусмотрены некие общие требования для всех устройств:
1. Каждое устройство содержит «собственное описание» (дескриптор устройства).
2. Есть некий, общий для всех USB устройств, механизм который позволяет ОС прочитать дескриптор устройства для того, чтобы идентифицировать устройство, узнать его характеристики.
3. Есть некий, общий для всех USB устройств, механизм который позволяет ОС выполнить первичную конфигурацию устройства (например, присвоить устройству новый адрес, о чем мы говорили выше).
Данными вещами (чтение дескриптора устройства, идентификация устройства) занимается некая служба ОС, которая отвечает за базовую поддержку USB.
После того как устройство будет идентифицировано и проведена некая первичная инициализация, данная служба передаст управление устройством драйверу, который «закреплен» за данным типом устройств (или конкретно за этим устройством).
Что будет, если служба не сможет найти «подходящий» драйвер для данного устройства знают все :)
Теперь возвращаемся на наш «низкий» уровень.
Начало работы с устройством. Стандартные заросы.
На практике, для чтения дескриптора устройства и первичной инициализации используются та самая «нулевая конечная точка». Есть несколько предусмотренных стандартом запросов (Standard Device Requests), которые должны обрабатываться всеми USB устройствами. Пока приведу несколько примеров таких запросов:
GET_DESCRIPTOR – запрос на получения дескриптора устройства. Данный запрос содержит дополнительную информацию о том, какой именно дескриптор должно вернуть (в устройстве «хранится» несколько разных дескрипторов, но об этом позже).
GET_CONFIGURATION – запрос на получение текущей конфигурации устройства.
SET_ADDRESS – данный запрос используется для присвоения устройству «нормального» (отличного от 0) адреса. Сам адрес содержится в запросе.
Нужно понимать, что запрос — это не более чем стандартизированная структура данных, которая содержит код запроса (bRequest) и дополнительные данные. Ответы на каждый из запросов тоже, естественно, стандартизированы.
Кроме стандартных запросов, которые устройство «обязано» поддерживать, можно определить «свои» запросы, специфические для конкретного устройства (класса устройств).
Заодно, для того чтобы показать как выглядит тот самый дескриптор устройства приведу пример:
Пока это просто иллюстрация того, как выглядит дескриптор, вникать в значение полей не стоит, этим мы займемся в следующей статье.
На этом, предлагаю завязывать с голой теорией и постепенно переходить к практике. В следующей статье начнем потихоньку писать код.
Комментарии ( 33 )
емнип, с интервалом в 1 мс, но «низкоскоростные» устройства могут опрашиваться не каждый раз, а, например раз за 10 циклов опроса
автор молодец! давно хотел освоить УСБ но никак не доходили руки да и не понимал ничего. тут все описано просто, красиво и понятно. так держать!
PHY это очень распространенный термин, когда речь идет о сетей и действительно, даже если вы никогда не слышали этого раньше, это то, что ваш сетевая карта есть, даже тот, который интегрирован с материнская плата. Это довольно важный компонент, поэтому в этой статье мы собираемся объяснить, что это такое, что это такое. для и вообще все что ты должен знать об этом.
Обычно, когда речь идет о PHY, это обычно делается в сочетании с сетевым контроллером, который, конечно, является частью сетевой карты. Сегодня он есть у всех сетевых карт, в том числе на материнских платах. Итак, давайте посмотрим, что это такое и что он делает.
Что такое PHY?
PHY - это сокращение от ” Физический слой «Или« физический уровень »на испанском языке. Это электронная схема, обычно реализуемая в интегральная схема (в разговорной речи известный как «таракан») и является чем-то необходимым для точной реализации физических соединений сетевых карт. Поэтому является частью сетевой контроллер и служит для соединения канального уровня (называемого MAC-адресом от Media Control Access) с физическим уровнем соединения, таким как разъем RJ-45 сетевой карты.
Устройство PHY обычно включает в себя дополнительный уровень кодирования, называемый PCS (подуровень физического кодирования), и уровень, зависящий от физической среды (PDM), который кодирует и декодирует данные, которые передаются и принимаются.
Таким образом, PHY - это интегрированный чип, который соединяет сетевой контроллер и физический разъем сетевой карты.
Типы и примеры использования
В начале мы говорили вам, что все сетевые карты имеют PHY, но реальность такова, что это только в том случае, если у них есть физические разъемы (вы можете подумать, что было бы абсурдно не иметь их, но в профессиональной среде там есть). являются сетевыми контроллерами, которые не имеют PHY, потому что их функция заключается в управлении другими сетевыми картами, поэтому у вас нет своих собственных разъемов).
Wireless USB 1.0? Да здравствует Wireless USB 1.1!
И всё же ключевым событием этого сезона в рамках продвижения стандарта Wireless USB стал анонс новой его версии. В настоящее время индустриальная группа Wireless USB Promoter Group занимается разработкой стандарта Wireless USB 1.1, который учтёт все "узкие места" нынешней версии. Как было отмечено выше, максимальная производительность интерфейса стандарта Wireless USB 1.0 достигает 480 Мбит/с на расстояние до 3 м. Именно этот параметр в будущей версии стандарта будет увеличен до 1 Гбит/с! Помимо этого, в версии Wireless USB 1.1 больше внимания будет посвящено более высокочастотным диапазонам UWB – тем, что располагаются выше 6 ГГц, это в совокупности с новыми режимами энергосбережения - Sleep, Listen, Wake, Conserve, по задумке, обеспечит большую экономию расхода батарей. В плане повышения защищённости обмена данными в спецификации Wireless USB 1.1 предполагается активное использование технологии NFC (Near Field Communication). Это позволит реализовать на практике возможности класса "touch and go", среди которых такие интересные функции, как, например, приложения для беспроводных платежей, когда для оплаты или идентификации с помощью шифрованных данных будет достаточно поднести к приёмнику смарт-карту или мобильный телефон. В плане упрощения использования интерфейса в версии Wireless USB 1.1 предполагается реализация такого режима, когда для идентификации будет достаточно всего лишь разместить устройство в непосредственной близости от хоста, в результате чего произойдёт мгновенное распознавание, без необходимости введения дополнительных ручных установок - в полной аналогии с проводным USB. В итоге, ожидается, что финальная версия Wireless USB 1.1 будет завершена в первом полугодии 2008 года. Аппроксимируя традиционные для подобных спецификаций сроки реализации можно прогнозировать с высокой долей вероятности, что розничные изделия с поддержкой Wireless USB 1.1 появятся на прилавках в последующее полугодие. Вот, собственно, и весь сказ, на данном этапе развития технологии ничего существенного к уже рассказанному, пожалуй, не добавить. Лично у меня есть такие подозрения, что первое время устройства с интерфейсом Wireless USB, как водится в таких случаях, будут восприниматься этакой диковинкой; не исключено, что не обойдётся без курьёзов – помните, как обычные USB-кабели на заре внедрения стандарта были жутким дефицитом и стоили неприличных денег? Однако очень быстро шумиха уляжется, Wireless USB чипы значительно подешевеют, а затем и вовсе поддержка стандарта будет реализовываться непосредственно в чипсетах для настольных и мобильных компьютерных платформ, смартфонов и коммуникаторов, игровых консолей, телевизоров и плееров, принтеров и фотоаппаратов – как нынешний, всем привычный проводной USB.
Вряд ли распространение Wireless USB в ближайшем времени приведёт к смерти других "локальных" беспроводных интерфейсов – вроде Bluetooth. Однако в более долгосрочной перспективе – как знать, ибо конкурентов, равных ему по производительности, пока не предвидится… Список литературы для более серьёзного изучения технологии Wireless USB
ULPI это интерфейс для организации высокоскоростных IP-систем USB 2.0. Он определяет взаимодействие между контроллерами USB и микросхемами PHY или трансиверами, которые соединяются с реальной физической шиной USB. Аббревиатура ULPI означает UTMI+ low pin interface (UTMI+ с уменьшенным количеством выводов), и он был специально разработан для уменьшения количества выводов корпусов микросхем high-speed USB PHY. Уменьшение количества выводов минимизирует стоимость и место на плате, необходимое для установки и разводки чипа PCB, и уменьшает количество выводов, назначенных для связи с высокоуровневым контроллером USB. В результате этих свойств ULPI быстро стал новым стандартом интерфейса среди разработчиков систем и чипов (SMSC, NXP Semiconductors, Mentor Graphics).
Стандарты UTMI+ и ULPI. ULPI это расширение стандарта UTMI+ PHY. Оба стандарта определяют интерфейсы между высокоуровневым контроллером USB и микросхемами PHY для организации физического соединения с шиной USB, однако ULPI специально предназначен для микросхем PHY. Стандарт UTMI (расшифровывается как USB transceiver macrocell interface) был разработан компанией Intel® для высокоскоростных периферийных устройств (USB v2.0). UTMI позволяет периферийным устройствам подключаться к компьютеру либо на высокой high-speed, либо на полной (full-speed) скорости (для совместимости со старыми PC). Стандарт UTMI+ это расширение оригинального UTMI, которое поддерживает контроллеры OTG и контроллеры хоста на всех скоростях.
Наподобие UTMI+ для встроенного в чип PHY, стандарт ULPI предоставляет основную выгоду для разработчиков решений USB при использовании отдельных микросхем PHY. Оба стандарта поддерживаются организацией ULPI Working Group. Хотя ULPI это не полностью открытая спецификация, любой может свободно присоединиться и стать пользователем ULPI. Зарегистрируйтесь на сайте ULPI Working Group, чтобы получить бесплатную копию документации стандарта.
Сегодня использование девайсов на ПЛИС с сетью Ethernet (или как острят некоторые мои знакомые, «Азернет») – общее место. Особенно если речь идёт о высокоскоростной передачи данных (АЦП/ЦАП с сетевым выходом, обработка видео, «сырца» с радиолокаторов и гидроакустических комплексов, сбора данных с большой сети (решётки датчиков и т.д. и т.п.). Когда я вижу, как люди, покрывшись испариной, пытаются упихать поток отсчётов с квадратурного демодулятора SDR в USB 3.0, мне их становится откровенно жалко.
Отдельная огромная тема — это на чём это реализовывать. Вариантов несколько, но, в большинстве своём, плисоводы приходят к выводу, что лучший вариант — это «рукопашный».
В начале стоит внешняя «физическая» микросхема (PHY), которая выполняет работу нулевого уровня (если строго следовать модели OSI), т.е. преобразование аналоговых сигналов в цифровые, битовую и кадровую синхронизации. Затем следует MAC-уровень, т.е. всё, начиная от проверки контрольной суммы (КС) пакета до разборки и вытаскивания «полезной нагрузки» из многочисленных IP-протоколов: начиная от TCP, UDP и ARP и заканчивая экзотикой типа H.248.
В И-нете, да и здесь на Easyelectronics описывались проекты, которые вообще напрямую стыкуют микроконтроллер с сетью. Но такие решения — это максимум, что бы раз в минуту послать пакетик с какого-нибудь датчика температуры со скоростью 10Мбит/с. Для скоростей выше — внешняя микросхема PHY с соответствующей обвеской. Пару слов (а то это — тоже обширная тема) об интерфейсах PHY. 1Gb PHY-микросхемы наследуют от своих более тихоходных предшествнников, но и превносят новое (а не только изменение частоты оцифровки). Управляются они также.
Во-первых, это — интерфейс настройки MDIO. Это — некоторая помесь SPI и I2C, эдакий двухпроводный SPI. По этому интерфейсу задаются режимы работы микросхемы путём записи/чтения в определённые регистры. Список основных регистров (адреса и содержимое) стандартизован IEEE 802.3. И, в целом, производители этого стандарта придерживаются, но добавляют обычно много своих регистров с более тонкими настройками. А в некоторых микросхемках, например, в популярной PHY 88E1111 от Марвелла, даже добавляют вторую «страницу» регистров (дело в том, что эта микросхема может работать и по витой паре и по оптике и каждая линия имеет свой набор регистров «страницу»).
Самые основные настройки (типа выбора интерфейсов и скорости работы) обычно могут быть выбраны внешними перемычками (которые обычно спарены с выводами светодиодов). Т.е., в принципе, можно не заворачиваться с написанием MDIO-блока, но только в принципе, ибо тогда будут не доступны многие реально полезные вещи (в частности, жёсткое задание скорости и внутренний ФАПЧ для сдвига тактовой частоты (см. далее).
Теперь об основном интерфейсе. В отличии от 100Мбит-прородителей в 1Гбит-микросхемах появились новые форматы: это SGMII, GMII и RGMII.
SGMII — это последовательный интерфейс, который хорош тем, что ему требуется всего одна пара проводов (в одну сторону, есс-но дифференциальных, конкретнее — LVDS), если работа идёт без опорного генератора. А огромный минус его в том, что работа идёт на частоте аж 625МГц по обоим фронтам. Далее этот поток (если речь о приёме) следует преобразовать в параллельный код. В принципе, топовые микросхемы, типа того же Stratix'а IV и V с максимальными суффиксами в состоянии выполнить такое преобразование «на себе», т.е. на схеме, реализованной на внутреннем массиве логических элементов (ЛЭ). Но, такая схема будет весьма нестабильна (ибо работать будет почти на пределе возможностей, когда, по-сути, цифровая схема превращается в «полу-аналоговую» и всё, что показывают имитаторы типа Modelsim'а — никакого отношения к действительности не имеет), да и ставить мегадорогущие каменюги ради стыковки с PHY — не очень серьёзно. Поэтому, во многие ПЛИСины втискивают аппаратные приёмопередатчики SGMII. Но настройка этих блоков — отдельная и непростая штука. Кроме того, нужно помнить про сложности разводки печатной платы, ибо даже исходная частота (625МГц), мягко говоря, не детская, а с учётом требований к фронтам и спадам (типично, максимум — 0,2нС) — можете легко посчитать требуемую широкополосность линий. Поэтому, мой совет — с SGMII связываться только в крайнем случае!
Гораздо проще ситуация с GMII и RGMII-интерфейсами. Это — параллельные (8 и 4, соответственно) линии связи. Тактовая частота снижена до разумных 125МГц, хотя даже такая частота может представлять определённую проблему для дешёвых вариантов современных ПЛИС, особенно если нужно «выжать» всё, что можно из 1Гбит-интерфейса и, соотвественно, пакеты должны формироватся «на лету». Поскольку, для RGMII-интерфейса при тактировании по одному фронту понадобилась бы тактовая частота в 250МГц (что уже совсем тяжеловато для большинства современных ПЛИС), здесь также производится тактирование по фронту и спаду тактового сигнала.
Если очень страшно связываться с двойным тактированием, то можно использовать GMII-интерфейс и тут, фактически, разработчик почти спокойно может использовать наработки, взятые из MII-интерфейса, разве что не забыв, что по GMII передаются байты, а не полубайты(нибблы) и, есс-но, подняв скорость передачи в 5 раз.
Но лишние выводы в современных ПЛИС'инах весьма дороги и RGMII-интерфейс предоставляет возможность разумной экономии (между GMII и SGMII) ценой некоторого (на самом деле, небольшого) усложнения схемы. И, кстати, если ваше устройство должно иметь возможность работать и с 1Гбит и с 100Мбит-устройствами, то, на самом деле, наиболее простой переход с MII обеспечивает RGMII.
Как стыковать RGMII с ПЛИС. Достаточно просто. Теоретически двухтактный буфер можно создать в основном массиве ЛЭ, используя (лучше всего) графику, или поизвращавшись (вообще, убогость этих языков — отдельная тема) в VHDL или Verilog'е (не забыв указать *useioff* у соответствующих выводов). Но, как показала практика, работать это всё будет весьма убого (ибо, с учётом требований к крутизне фронтов, широкополосность должна достигать 400МГц!), правда, даст подсмотреть генирируемые сигнал в СигналТапе(ЧипСкоупе).
Более правильный путь — использовать специализированные двухтриггерные буфера, например, в альтеровском случае — это ALTDDIO в соответствии с документом AN477 «Designing RGMII Interfaces».
Строб пакета tx_en, как показывает практика, лучше тоже протаскивать через ALTDDIO (что и сделано под именем dataout[4]).
Показанная схема будет работать только при условии, что тактовая частота gtx_clk сдвигается на 90 градусов на внутреннем ФАПЧ микросхемы PHY (см. выше диаграмку с RGMII-сигналами). Такая весьма удобная опция предусмотрена в большинстве 1Гбит-PHY, но она включается в соответствующем регистре через MDIO. Например, для 88E1111 — это бит 1 регистра 20. Если же MDIO-приёмопередатчик писать лень, то тогда сдвинутую последовательность нужно сгенерить в ПЛИС с помощью ФАПЧ(PLL) и подать её на выход GTX_CLK. К сожалению, такой вариант часто не обеспечивает нужной стабильности и приводит к редким пропаданием отдельных пакетов.
В качестве дополнения к посту прилагается работающий модуль-шаблон для RGMII-шины как для 100Мбит/с, так и для 1Гбит/с режимов (задаётся параметром SPEED). Код тщательно комментирован, но некоторые пояснения сделаем. Модуль предназначен для проверки скорости работы сетевой системы. Поэтому он шлёт длинные UDP-пакеты с заданной паузой. Длина полезной нагрузки (не пакета!) задаётся параметром DATA_LENGTH. Контрольная сумма (КС) IP прописывается руками, КС UDP не вычисляется (нули). А вот CRC32 считается на лету с помощью модуля CRC32, но в данном примере она тоже была высчитана заранее (благо, не меняется :)) В качестве полезной нагрузки идут просто постоянные байты (в версии с расчётом CRC32 — в начале идёт счётчик байт). Собственно и всё.
Модуль вполне можно использовать как заготовку для своих целей. В этом случае, просьба, оставить в комментах к коду ссылку на этот пост и автора. Кстати, при сборке модуля нужно проверять максимальные задержки в «ТаймКвесте» или аналогичном инструменте. Дело в том, что из-за двух гигантских case'ов код легко читаем, но приводит к генерации огромного массива переключателей, которые, соответственно, могут легко не пойти по задержке для данной ПЛИС. Если такое случилось, то нужно либо подрезать кол-во ветвлений, либо генерить часть данных во внешней ПЗУ. Короче, дальше — всё в ваших руках. С помощью данного модуля удавалось «выжать» полезную (т.е. уже за вычетом всех заголовков) скорость передачи до почти 970Мбит/с.
В качестве сигнала reset в простейшем случае можно использовать выход locked ФАПЧ.
Ещё один момент. Во многих микросхемах, в частности, семейства Cyclone IV, Сигнал Тап не имеет возможности снять сигнал после модуля DDIO_out. Да-да! Как известно, СигналТап часто при компиляции «не может» дотянутся до нужных вам сигналов, даже если на них навешен LCELL (или атрибут *keep* в Verilog'е). Это происходит по разным причинам, это — тема для отдельной статьи.
Но, среди плисоводов (даже весьма опытных) бытует «городская легенда», что, что бы 100% увидеть нужный сигнал в СигналТапе достаточно его повесить на какую-либо ногу микросхемы. Так вот — ничего подобного! Вот вам пример. Это хорошо видно по схемотехнике выходных цепей соответствующей микросхемы. Так что сигналы на RGMII-шине штатной смотрелкой подсмотреть скорее всего не удастся. А при попытке их завернуть на какой-нибудь вход ПЛИС всё закончится, скорее всего, разбалансировкой линий и соответствующими проблемами.
Появилось немного свободного времени, и я решил написать небольшую «внеплановую» статью.
Итак, из предыдущей статьи, мы знаем, что для обмена данными используются некие виртуальные каналы – «конечные точки». Давайте рассмотрим, как происходит обмен.
Обмен данными по USB
Нужно помнить, что интерфейс USB предусматривает использование разветвлителей – хабов. Более того, допускается каскадное включение хабов. Следовательно, необходимо как-то идентифицировать конкретное USB устройство в «гирлянде» из хабов и USB устройств. Для этого каждому устройству присваивается адрес.
Здесь остановимся немного подробнее. Адрес кодируется 7 битами. Изначально (в момент подключения), устройство, грубо говоря, само себе назначает адрес 0. Этот адрес зарезервирован стандартом как раз для вновь подключаемых устройств. Далее, в процессе инициализации (об этом поговорим позже), хост присваивает устройству уникальный адрес отличный от 0, а адрес 0 «освобождается» для вновь подключаемых устройств.
И так, для того чтобы передать данные конкретному устройству, нужно знать адрес устройства и номер виртуального канала «внутри» устройства (адрес «конечной точки»).
Как мы уже выяснили, сразу после включения, устройство имеет особый, «нулевой» адрес. Каждое устройство, согласно стандарту, имеет «нулевую конечную точку» типа Control. Соответственно, сразу после подключения, хост может начинать обмениваться данными с новым устройством (адрес = 0, номер конечной точки = 0).
Рассмотрим, как происходит обмен данными.
Сам обмен осуществляется пакетами. Стандартом предусмотрено несколько типов пакетов. «Побайтно» мы пока разбирать пакеты не будем, но коснемся этого вопроса в практической части.
Дело в том, что часть работы по формированию и передаче пакетов (например, вопросы синхронизации, расчет контрольных сумм и т. д.) возьмет на себя USB периферия МК. Для тех, кто хочет сразу углубиться в биты и байты могу порекомендовать ознакомиться с разделом 8 официальной спецификации USB 2.0
Пока нам достаточно знать, что существуют «пакеты данных» и несколько типов «служебных пакетов».
USB и Plug and Play
Давайте рассмотрим, что с нашим устройством будет происходить дальше, после того как хост определил подключение нового устройства и готов начать обмен данными. Нам нужно ненадолго подняться на «высокий» уровень – уровень ОС.
Дело в том, что в стандарт USB поддерживает концепцию Plug and Play (подключи и играй). Данная концепция подразумевает, что пользователю достаточно «воткнуть» устройство в соответствующий порт ПК. Дальше ОС автоматически определит тип подключенного устройства, найдет подходящий для данного устройства драйвер, сконфигурирует устройство и т. д. (правда, это конечно в идеале :))
Для того чтобы вся эта красота работала, стандартом USB предусмотрены некие общие требования для всех устройств:
1. Каждое устройство содержит «собственное описание» (дескриптор устройства).
2. Есть некий, общий для всех USB устройств, механизм который позволяет ОС прочитать дескриптор устройства для того, чтобы идентифицировать устройство, узнать его характеристики.
3. Есть некий, общий для всех USB устройств, механизм который позволяет ОС выполнить первичную конфигурацию устройства (например, присвоить устройству новый адрес, о чем мы говорили выше).
Данными вещами (чтение дескриптора устройства, идентификация устройства) занимается некая служба ОС, которая отвечает за базовую поддержку USB.
После того как устройство будет идентифицировано и проведена некая первичная инициализация, данная служба передаст управление устройством драйверу, который «закреплен» за данным типом устройств (или конкретно за этим устройством).
Что будет, если служба не сможет найти «подходящий» драйвер для данного устройства знают все :)
Теперь возвращаемся на наш «низкий» уровень.
Начало работы с устройством. Стандартные заросы.
На практике, для чтения дескриптора устройства и первичной инициализации используются та самая «нулевая конечная точка». Есть несколько предусмотренных стандартом запросов (Standard Device Requests), которые должны обрабатываться всеми USB устройствами. Пока приведу несколько примеров таких запросов:
GET_DESCRIPTOR – запрос на получения дескриптора устройства. Данный запрос содержит дополнительную информацию о том, какой именно дескриптор должно вернуть (в устройстве «хранится» несколько разных дескрипторов, но об этом позже).
GET_CONFIGURATION – запрос на получение текущей конфигурации устройства.
SET_ADDRESS – данный запрос используется для присвоения устройству «нормального» (отличного от 0) адреса. Сам адрес содержится в запросе.
Нужно понимать, что запрос — это не более чем стандартизированная структура данных, которая содержит код запроса (bRequest) и дополнительные данные. Ответы на каждый из запросов тоже, естественно, стандартизированы.
Кроме стандартных запросов, которые устройство «обязано» поддерживать, можно определить «свои» запросы, специфические для конкретного устройства (класса устройств).
Заодно, для того чтобы показать как выглядит тот самый дескриптор устройства приведу пример:
Пока это просто иллюстрация того, как выглядит дескриптор, вникать в значение полей не стоит, этим мы займемся в следующей статье.
На этом, предлагаю завязывать с голой теорией и постепенно переходить к практике. В следующей статье начнем потихоньку писать код.
Читайте также: