Книга: Аппаратные интерфейсы ПК. Энциклопедия

11.1.3. Шина SMBus

11.1.3. Шина SMBus

Шина SMBus (System Management Bus — шина системного управления) — двухпроводной интерфейс для обмена данными между микросхемами различных системных компонентов компьютера, а также связи их с самим компьютером. Основное назначение интерфейса — управление подсистемой питания и сопутствующими подсистемами. Первоначально шина разрабатывалась для интеллектуальных батарей и зарядных устройств, и первые версии спецификации SMBus шли под заголовком «Smart Battery System Specifications» (спецификации системы «умных» батарей). Система с «умными», или «ловкими», батареями (Smart Battery System) состоит из собственно батарей (аккумуляторов) и зарядных устройств, способных обмениваться управляющей информацией между собой и с хост-системой, которую она питает. Этот обмен позволяет батареям сообщать свои параметры (текущие значения, ожидаемые величины), подключаться в режим работы (питания хост-системы) или зарядки. Часть управляющих функций выполняется при участии хоста, а часть — автономно. Первая версия спецификации SMBus вышла в 1995 г., версия 1.1 — в 1998 г. Версия 2.0 вышла в 2000 г., она уже не имеет «батарейного» заголовка. Данное описание основано на документе «System Management Bus (SMBus) Specification Version 2.0», выпущенном форумом разработчиков систем с интеллектуальными батареями (SBS, www.sbs-forum.org), в который входит большое число производителей источников питания, а также фирма Intel. Спецификация покрывает три нижних уровня модели взаимодействия открытых систем (OSI), от физического до сетевого.

Шина SMBus основана на интерфейсе I?C, и к ней применимо все сказанное в п. 11.1.1. В шину введена возможность динамического реконфигурирования (подключения и отключения абонентов шины в процессе работы) и автоматического назначения адресов устройств. По сравнению с I?C в шине несколько изменены граничные требования к уровням сигналов и временным диаграммам (см. п. 11.1.4), но в основном они совпадают. Шина позволяет реализовать все режимы обменов, разрешенные для I?C, но имеет нюансы в правилах генерации подтверждений. Для шины SMBus в BIOS имеется стандартизованная поддержка. Особенностью шины SMBus, связанной с ее ролью в управлении системой питания, является способность автономной работы — соединяемые ею устройства могут обмениваться информацией, даже когда питание на центральном процессоре (и других подсистемах) отсутствует. Конечно, о взаимодействии с устройствами шины через BIOS в таком состоянии нет и речи, поскольку BIOS еще «спит».

На физическом уровне (1-м уровне OSI) спецификация определяет электрические и временные параметры сигналов. По уровням сигналов (и нагрузочной способности) имеются две различные спецификации. Маломощная (low power) спецификация соответствует «родному» применению SMBus в устройствах с батарейным питанием; здесь характерны малые токи. Мощная (high power) спецификация предназначена для работы абонентов SMBus в окружении источников значительных помех (например, на плате PCI). Маломощные и мощные устройства на одной шине вместе работать в общем случае не смогут, но это и не требуется. При необходимости совместного использования устройств разных классов организуются разные сегменты шины, соединенные мостом.

В спецификациях временных параметров приняты меры по ограничению времени отклика и предотвращению «зависания» шины. Частота тактового сигнала ограничена и снизу (10 кГц), и сверху (100 кГц); введены ограничения на максимальную длительность нахождения синхросигнала в высоком и низком состоянии и максимальную суммарную «растяжку» битовых интервалов на каждый байт. Предусматривается механизм тайм-аутов, по которому устройства, обнаружившие «зависание» шины, должны немедленно прекратить обмен и повторно инициализироваться. В спецификации I?C эти моменты не рассматривались.

На шине SMBus могут использоваться дополнительные аппаратные сигналы.

? Сигнал SMBSUS# указывает на приостанов шины и устройств. Этот сигнал вырабатывается устройством управления питанием; во время его активности (низкий уровень) сигналы SDA и SCL штатным образом (как в I?C) не воспринимаются (они могут использоваться для уточнения режима приостанова).

? Сигнал SMBALERT# служит для оповещения ведущего устройства о необходимости обмена с ведомым устройством, не имеющем возможности выступить в роли ведущего устройства. Этот сигнал собирается по схеме «Монтажное И» от всех устройств. Получив его, хост должен дать команду чтения байта по адресу 0001 100, на которое просигналившее устройство должно ответить байтом со своим адресом (возможен вариант и с дополнительным байтом PEC).

На уровне связи (2-м уровне OSI) определяются те же правила передачи данных, что и в I?C: условия S, P, Sr; биты подтверждения; 7-битная адресация и признак RW в первом байте, следующем за условием S (Sr). Как и в I?C, ведущее устройство может выполнять и запись, и чтение данных ведомого устройства; используются и комбинированные транзакции (через условие Sr). В генерации подтверждений на SMBus есть особенности. На собственный адрес устройство всегда должно отвечать битом подтверждения ACK, даже если оно занято внутренними операциями. Это правило обеспечивает работу механизма определения присутствия данного устройства на шине. Ведомое устройство может вводить бит NACK в ответ на любой неадресный байт, если оно занято или запрашиваемые командой данные недоступны. В этом случае у него есть и альтернатива поведения — задержать синхросигнал на низком уровне (в разрешенных пределах). Ведомое устройство должно вводить бит NACK в ответ на недопустимые коды команд или данных. Ответ NACK вынуждает ведущее устройство прекратить транзакцию (ввести P). Ведущее устройство, будучи приемником, ответом NACK информирует передатчик о приеме последнего ожидаемого байта.

Сетевой уровень (3-й уровне OSI) определяет «лицо» шины SMBus и заслуживает более детального рассмотрения.

В шине SMBus введено понятия «хоста» (host) — абонента шины, выполняющего координирующие и конфигурирующие функции. Хост является ведущим устройством шины, при этом должен выполнять ряд функций ведомого устройства и отрабатывать сообщения уведомления.

Каждое ведомое устройство имеет свой уникальный адрес; в диапазоне 7-битных значений адреса выделяются специальные значения (табл. 11.4), которых несколько больше, чем в I?C. 10-битная адресация в текущей версии не рассматривается. Адреса устройств разделяются по типам. Для устройств однозначно понятного назначения SMBus WG выделяет специальные адреса (Purpose-assigned addresses). Например, батареи Smart Battery имеют адрес 0001 011, их зарядные устройства — 0001 001. Устройства с этими адресами обязаны соответствовать требованиям SMBus, предъявляемым к устройствам данного класса. Ряд систем с SMBus определяют и используют эти устройства, основываясь на их адресе. Другие системы могут и не доверять одному только адресу, а определять типы присутствующих устройств иным образом. Для устройств разнообразного назначения, а также устройств, не полностью отвечающих спецификациям SMBus для своего класса, производители назначают иные адреса, с которыми можно ознакомиться на сайте www.smbus.org. Адреса устройств-прототипов задействуются исключительно в экспериментально-отладочных целях и в коммерческих изделиях использоваться не должны. В спецификации SMBus 2.0 появилась возможность автоматического динамического назначения адресов устройств, которая будет рассмотрена ниже.

Таблица 11.4. Специальные адреса SMBus

Типичное устройство SMBus поддерживает определенный набор команд, с помощью которых выполняется обмен данными. Команда кодируется одним байтом, передаваемым в транзакции вслед за адресным байтом. Команды могут использовать один из 11 протоколов, определенных в SMBus.

В версии 1.1 спецификации SMBus введена возможность контроля ошибок пакета PEC (Packet error checking). Механизм PEC основан на добавлении в конец каждого передаваемого пакета байта CRC-кода, вычисляемого по всем предыдущим байтам пакета, начиная с адресного. Почти все протоколы могут иметь два варианта — без PEC и с PEC; на одной шине могут присутствовать устройства и с поддержкой PEC, и без. На байт PEC приемник отвечает подтверждением, но трактовка ответа неоднозначна. Если передатчик в ответ на PEC получил ответ NACK, это означает, что приемник не подтвердил корректный прием пакета. Однако ответ ACK не является подтверждением достоверности приема: приемник может «не понимать» PEC и отвечать на него как на обычный байт данных; приемник может и не выполнять контроль в реальном времени приема потока данных. Более «достоверный контроль достоверности» могут обеспечить лишь протоколы высших уровней. Так, например, для контроля достоверности записи в устройство можно использовать последующее чтение тех же данных с PEC, и по анализу всего принятого пакета ведущее устройство сделает вывод об успешности или ошибке операции записи.

Шинные протоколы SMBus основаны на транзакциях I?C с 7-битной адресацией.

? Quick Command, короткая команда, — посылка адресного байта; действие команды определяется битом RW адресного байта.

? Send Byte, посылка байта, — передача ведущим устройством вслед за адресным байтом (RW=0) одного байта данных. В варианте с PEC передаются два байта, последний — PEC.

? Receive Byte, прием байта, — прием ведущим устройством вслед за адресным байтом (RW=1) одного байта данных. В варианте с PEC принимаются два байта, последний — PEC.

? Write Byte, Write Word, запись байта/слова, — передача ведущим устройством вслед за адресным байтом (RW=0) одного байта команды, за которым следует 1 или 2 байта (младший, а затем старший) данных. В варианте с PEC в конец добавляется контрольный байт.

? Read Byte, Read Word, чтение байта/слова, — комбинированные транзакции: сначала посылается адресный байт (RW=0), за которым передается код команды. Далее, через условие 5 посылается адресный байт с тем же адресом устройства, но RW=1, после которого принимается 1 или 2 байта данных. В варианте с PEC в конце ожидается прием дополнительного (контрольного) байта.

? Block Write, запись блока, — передача ведущим устройством вслед за адресным байтом (RW=0) одного байта команды, за которым следует байт-указатель длины (количество последующих байт) и собственно байты данных. В варианте с PEC в конец добавляется контрольный байт. Указатель длины не учитывает байт PEC; он не может быть нулевым; одной блочной командой можно пересылать до 32 байт данных.

? Block Read, чтение блока, — комбинированная транзакция: сначала посылается адресный байт (RW=0), за которым передается код команды. Далее, через условие S посылается адресный байт с тем же адресом устройства, но RW=1, после которого принимается байт-указатель длины, а за ним и собственно байты данных. В варианте с PEC в конце ожидается прием дополнительного (контрольного) байта. Указатель длины — аналогично блочной записи.

? Process Call, вызов процесса, — комбинация команды Write Word с приемом слова (двух байт) от устройства с тем же адресом. Команда называется вызовом процесса, поскольку ожидает данных, зависящих от посланного кода команды и слова данных. В варианте с PEC контрольный байт ожидается только в самом конце, вслед за последним байтом принятых данных.

? Block Write-Block Read Process Call — комбинация записи блока с последующим чтением блока по тому же адресу устройства. В варианте с PEC контрольный байт ожидается только в самом конце, вслед за последним байтом принятых данных.

В случае, когда ведущим устройством шины собирается выступать рядовое устройство (не хост), оно должно использовать протокол уведомления хоста (SMBus host notify protocol): устройство на адрес хоста с RW=0 (он известен) посылает байт с собственным адресом, за которым следует слово (два байта) собственно уведомления. Хост обязан понимать эти уведомления; дополнительно может использоваться и необязательный сигнал внимания SMBALERT# (см. ниже).

Динамическое реконфигурирование шины SMBus — возможность «горячего» подключения/отключения основано на базовых принципах протокола I?C. Автоматическое назначение адресов, появившееся в версии 2.0, использует еще и контрольные байты пакетов (PEC). Задача динамического реконфигурирования включает распознавание фактов подключения/отключения устройств и обеспечение бесконфликтного распределения их адресов. Подключение новых устройств может распознаваться двумя способами. Устройство, которое может работать ведущим устройством, при подключении (после своей инициализации по включению питания) может послать хосту уведомление, содержащее его адрес. Другой вариант обнаружения — периодический опрос устройств ведущим устройством, ведающим «переучетом» всех устройств на шине.

Для динамического бесконфликтного назначения личных адресов устройств используется протокол ARP (Address Resolution Protocol). Назначение адресов основано на стандартном механизме арбитража (разрешения конфликтов) шины SMBus (и I?C). Назначенный адрес запоминается устройством на все время, пока подано питание. Возможны и устройства PSA (Persistent Slave Address), «вспоминающие» ранее назначенный адрес после повторного включения питания. После назначения адреса обмен с устройством выполняется точно так же, как и с устройством с фиксированным адресом. Назначение адресов может выполнять любое ведущее устройство шины SMBus.

Для динамического назначения адреса требуется изоляция устройств — возможность диалога ведущего устройства-нумератора с каждым устройством без помех со стороны других устройств (типичная задача настройки системы PnP). Изоляция основана на уникальном идентификаторе устройства UDID (Unique Device Identifier) — 128-битной структуре, содержащей описание возможностей, версию, идентификаторы производителя, устройства, подсистемы и специфическую информацию. Идентификатор начинается с байта возможностей (Device Capabilities), в котором два старших бита характеризуют способности динамической адресации, а младший бит — поддержку PEC. Чтение идентификатора выполняется ведущим устройством ARP по протоколу блочного чтения по «дежурному» адресу SMBus. На это чтение отзываются все устройства с еще не назначенными адресами, и на арбитраже этой операции работает изоляция устройств. Первый считанный байт (указатель длины) у всех устройств одинаков, по нему конфликтов нет. Далее устройства передают идентификаторы, и в арбитраже будут иметь приоритет те устройства, у которых нулевое значение бит данных встретится раньше. С учетом этого принята следующая кодировка классов устройств в старших битах первого байта идентификатора:

? 00 — устройства с фиксированными адресами, идентифицируются в первую очередь;

? 01 — динамические устойчивые (persistent) адреса устройств PSA;

? 10 — динамические изменчивые (volatile) адреса;

? 11 — устройства со случайными номерами, идентифицируются в последнюю очередь.

Младший бит этого байта указывает на поддержку PEC и всех возможностей, основанных на идентификаторе. При нулевом значении этого бита о поддержке PEC ничего определенного сказать нельзя.

Последний элемент UDID — 32-битный идентификатор устройства, играющий важную роль в распознавании похожих устройств. Это может быть либо число, назначаемое изготовителем (отвечающим за его неповторимость), либо случайное число, генерируемое (и запоминаемое) устройством каждый раз при включении или выполнении команды сброса.

Устройство, поддерживающее ARP, должно иметь специальные флаги:

? AR (Address Resolved) — данному устройству процедурой ARP назначен адрес;

? AV (Address Valid) — устройство имеет действительный личный адрес, на который оно отзывается в обычных транзакциях (при AV=0 устройство должно игнорировать все адреса, кроме «дежурного»).

При AV=AR=0 устройство не имеет личного адреса и должно участвовать в процессе ARP (отвечать на общий опрос идентификатора). При AV=1 и AR=0 устройство имеет личный адрес, но должно участвовать в ARP. При AV=AR=1 устройство имеет личный адрес, но не должно отвечать на общий запрос идентификатора. При этом оно должно отрабатывать адресованную ему команду назначения адреса (и впоследствии пользоваться новым назначенным адресом). Комбинация AV=0 и AR=1 недопустима.

Для протокола ARP введены специальные команды.

? Get UDID (general) — общий запрос идентификатора — команда чтения блока данных с адресом 1100 001 и кодом команды 3. На нее устройства, поддерживающие ARP, отвечают посылкой блока с длиной 17 байт, сопровождаемого PEC. Первые 16 байт блока — UDID, 17-й байт — адрес устройства (с единицей в младшем бите). Если у устройства флаг AV=0, оно вместо адреса передает код «1111 111». Команда не влияет на флаги AV и AR.

? Assign address — назначить адрес — команда записи блока данных с адресом 1100 001 и кодом команды 4 и длиной 17 байт, сопровождаемого PEC. Первые 16 байт блока — UDID, 17-й байт — назначаемый адрес устройства (младший бит игнорируется). По этой команде устройство, обнаружившее полное совпадение UDID со своим собственным, устанавливает флаги AV=AR=1.

? Get UDID (directed) — направленный запрос идентификатора — команда чтения блока данных с адресом 1100 001, в поле кода команды находится адрес интересующего устройства с единицей в младшем бите. На нее отвечает только устройство, опознавшее свой адрес в поле команды, и отвечает посылкой блока с длиной 17 байт, сопровождаемого PEC. Первые 16 байт блока — UDID, 17-й байт — адрес устройства (с единицей в младшем бите). Команда не влияет на флаги AV и AR.

? Reset device (general) — общий сброс устройства — посылка по адресу 1100 001 байта команды с кодом 2, сопровождаемого байтом PEC. По этой команде все устройства инициализируются и обнуляют флаги AR и AV (PSA-устройства флага AV не изменяют).

? Reset device ARP (dirеcted) — направленный сброс устройства — посылка по адресу 1100 001 байта с адресом целевого устройства (с нулем в младшем бите), сопровождаемого байтом PEC. По этой команде выбранное устройство инициализируется и обнуляет флаги AR и AV (PSA-устройства флага AV не изменяют).

? Notify ARP master — уведомление ведущего устройства ARP — посылка на адрес 0001 000 байта с «дежурным» адресом 1100 0010, за которым следуют два байта нулей. Устройство может посылать это уведомление о необходимости выполнения ARP при включении питания, а также при обнаружении коллизии в процессе выполнении чтения данных по индивидуальному адресу устройства.

На каждый байт команд ARP-устройства, поддерживающие этот протокол, отвечают подтверждением ACK. Отсутствие подтверждений трактуется ведущим ARP-устройством как отсутствие ARP-устройств на шине.

«Переучет» и назначение адресов вкратце выглядит следующим образом: ведущее ARP-устройство выполняет команду общего запроса идентификатора и по ней получает UDID и, возможно, адрес первого «победителя» в арбитраже. Далее этому победителю назначается личный адрес — тот же или по усмотрению ведущего ARP-устройства, после чего он уже не участвует в арбитраже по общему запросу. Сведения об устройстве и его адрес ведущим ARP-устройством заносятся в таблицу устройств. После этого общий запрос и назначение адреса повторяются снова и снова, пока все ARP-устройства не будут удовлетворены. Признаком «общего удовлетворения» для ведущего ARP-устройства будет отсутствие подтверждений приема команд общего запроса.

Шина SMBus, в отличие от ACCESS.bus, сразу получила спецификацию ее поддержки на уровне BIOS. Позже появились спецификации, позволяющие интегрировать устройства SMBus в систему ACPI.

В 1995 г. была опубликована спецификация интерфейса SMBus BIOS — System Management Bus BIOS Interface Specification, основные идеи которой вкратце изложены ниже. Интерфейс позволяет верхним уровням ПО абстрагироваться от аппаратной реализации хост-контроллера. Поддержка BIOS обеспечивается для трех типов режимов работы процессора: реального (и V86), защищенного 16-разрядного и защищенного 32-разрядного. Вызов функций может выполняться либо через BIOS Int 15h (в реальном режиме и в V86), либо через точку входа, полученную при подключении в соответствующем режиме. Для подключения (и отключения) также используется сервис BIOS Int 15h; после подключения доступ через Int 15h блокируется (до отключения). В защищенном режиме вызов интерфейсных функций возможен только через точку входа, полученную при подключении. Поддержка точки входа для реального режима необязательна.

Спецификация SMBus BIOS обеспечивает хост-центрическое обращение к абонентам шины: по инициативе вызывающей программы хост-контроллер посылает устройству команду, которая может предполагать и немедленный ответ устройства. Однако устройства могут посылать хосту сообщения по собственной инициативе, при этом они обязаны использовать протокол Write Word. Хост способен помещать принятые сообщения в небольшую очередь, из которой они могут программно извлекаться путем вызова функции 7 (программа должна периодически выполнять этот вызов для проверки наличия сообщений в очереди). В очереди каждое сообщение представлено байтом адреса источника и парой байт тела сообщения.

Шина SMBus тесно связана с оборудованием, управляющим питанием и участвующим в генерации запросов системного прерывания SMI (System Management Interrupt — особое аппаратное прерывание процессора) и их обработки. Из-за этого в BIOS введен специальный механизм, позволяющий обнаружить обработку SMI во время выполнения транзакций и в иное время. Это необходимо, поскольку обработчик SMI, работающий в режиме SMM, совершенно невидим прикладной программе, а результаты его работы могут существенно влиять на работу программы, вызывающей BIOS SMBus.

Функции общих обращений к SMBus:

? SMBus Installation Check (01h) — проверка наличия функций;

? SMBus Real Mode Connect (02h) — подключение в реальном режиме;

? SMBus 16-Bit Connect (03h) — подключение в 16-битном защищенном режиме;

? SMBus 32-Bit Connect (04h) — подключение в 32-битном защищенном режиме;

? SMBus Disconnect (05h) — отключение от сервиса;

? SMBus Deviсе Address (06h) — получение списка адресов устройств SMBus;

? SMBus Critical Messages (07h) — чтение сообщений устройств, переданных хосту.

Для взаимодействия с конкретными устройствами SMBus предназначен набор функций, позволяющих генерировать запросы протокольных команд SMBus и получать результаты их выполнения. Функции запросов и получения ответов разделены, что позволяет на время выполнения (и передачи) довольно длительных команд не занимать время центрального процессора. Большинство протокольных команд вводится за один вызов BIOS; исключение составляет команда записи блока, данные для которой передаются за один или более последующих запросов продолжения. Результаты большинства команд также принимаются за один вызов; результат чтения блока получается за несколько вызовов продолжения.

Вызовы протокольных команд устройств SMBus:

? SMBus Request (10h) — запрос команды устройству;

? SMBus Request Continuation (11h) — продолжение запроса для записи блока;

? SMBus Request Abort (12h) — отказ от выполнения ранее посланного запроса;

? SMBus Request Data and Status (13h) — запрос данных и состояния.

Шина SMBus является одним из главных коммуникационных средств в ACPI. Интерфейс SMBus для ACPI определен в спецификации SMBus CMI — документе System Management Bus (SMBus) Control Method Interface Specification Version 1.0, опубликованном в конце 1999 г. Этот интерфейс позволяет легко использовать все возможности SMBus независимо от происхождения или особенностей реализации оборудования. Ниже перечислены основные цели спецификации.

? Обеспечить эффективный и надежный интерфейс ACPI для аппаратных средств хост-контроллера независимо от его реализации (со встроенным микроконтроллером или без него).

? Обеспечить системную синхронизацию доступа ко всем ресурсам SMBus.

? Гарантировать соответствие интерфейса версиям 1.0 и 1.1 спецификации SMBus и возможности его расширения для поддержки новых свойств в будущих версиях.

Для успешного функционирования системы требуется поддержка соответствующими драйверами операционной системы. Для управления питанием форум разработчиков «интеллектуальных» батарей — Smart Battery System Implementers Forum (SBS-IF) — разработал спецификацию драйверов для ОС Windows 9x/2000, с которой можно ознакомиться на сайте http://www.sbs-forum.org/smbus/.

Рассмотрение программного интерфейса CMI выходит за рамки данной книги. Отметим лишь, что коды протоколов SMBus, используемые в CMI, отличаются от кодов, используемых в SMBus BIOS. Те же протоколы, но с байтом PEC, кодируются с единицей в старшем бите (значение увеличено на 80h).

Оглавление книги