I3C , также известный как SenseWire , [1] [2] является спецификацией [3] для обеспечения связи между компьютерными чипами путем определения электрического соединения между чипами и используемых шаблонов сигнализации. Сокращение от «Improved Inter Integrated Circuit» [4] стандарт определяет электрическое соединение между чипами как двухпроводную, общую ( многоточечную ) последовательную шину данных , один провод ( ) используется как часы для определения времени выборки, другой провод ( ) используется как линия данных, напряжение которой может быть оцифровано. Стандарт определяет протокол сигнализации, в котором несколько чипов могут управлять связью и, таким образом, действовать как контроллер шины.SCLSDA
Спецификация I3C берет свое название от шины I²C, использует те же электрические соединения, что и шина I²C , фактический стандарт для межчиповой связи, широко используемый для низкоскоростных периферийных устройств и датчиков в компьютерных системах, и допускает некоторую обратную совместимость с ней. Стандарт I3C разработан для сохранения некоторой обратной совместимости с системой I²C, в частности, позволяя разрабатывать конструкции, в которых существующие устройства I²C могут быть подключены к шине I3C, но при этом шина все еще может переключаться на более высокую скорость передачи данных для связи на более высоких скоростях между совместимыми устройствами I3C. Таким образом, стандарт I3C объединяет преимущество простой двухпроводной архитектуры I²C с более высокими скоростями связи, общими для шин с большим количеством выводов, таких как последовательный периферийный интерфейс (SPI).
Стандарт I3C был разработан в результате совместных усилий компаний, работающих в сфере электроники и компьютеров, под эгидой Mobile Industry Processor Interface Alliance ( MIPI Alliance ). Стандарт I3C был впервые представлен публике в конце 2017 года, [5] [6], хотя для доступа к нему требуется раскрытие частной информации. Google и Intel поддержали I3C как стандарт интерфейса датчиков для устройств Интернета вещей (IoT). [7]
Цели рабочей группы MIPI Sensor были впервые объявлены в ноябре 2014 года на Конгрессе руководителей MEMS в Скоттсдейле, штат Аризона. [8]
Поставщики средств автоматизации электронного проектирования , включая Cadence [9] , Synopsys [10] и Silvaco [11], выпустили IP-блоки контроллеров и соответствующее программное обеспечение для проверки для внедрения шины I3C в новые конструкции интегральных схем.
В декабре 2016 года компания Lattice Semiconductor интегрировала поддержку I3C в свою новую ПЛИС, известную как iCE40 UltraPlus. [12]
В 2017 году Qualcomm анонсировала мобильную однокристальную систему Snapdragon 845 с интегрированной поддержкой контроллера I3C. [13] [ проверка не пройдена ]
В декабре 2017 года спецификация I3C 1.0 была выпущена для публичного ознакомления. [7] [14] Примерно в то же время Борисом Брезиллоном был предложен патч для ядра Linux, вводящий поддержку I3C. [15]
В 2021 году DDR5 представила I3C.
В июне 2022 года компания Renesas Electronics представила первые интеллектуальные коммутаторы I3C. [16]
До публичного выпуска спецификации значительный объем общей информации о ней был опубликован в виде слайдов с MIPI DevCon 2016 года. [17] Цели этого интерфейса были основаны на опросе организаций-членов MIPI и членов MEMS Industry Group (MIG). Результаты этого опроса были обнародованы. [18]
Первоначальная разработка I3C была направлена на улучшение I²C по следующим направлениям: [19]
После того, как стандарт I3C 1.0 стал общедоступным, организация впоследствии опубликовала спецификацию I3C Basic, подмножество, предназначенное для реализации организациями, не являющимися членами, по лицензии RAND-Z . I3C Basic допускает бесплатную реализацию I3C и предназначен для организаций, которые могут рассматривать членство в MIPI как препятствие для принятия. Базовая версия включает в себя многие из нововведений протокола в I3C 1.0, но в ней отсутствуют некоторые потенциально более сложные для реализации, такие как дополнительные режимы высокой скорости передачи данных (HDR), такие как DDR. Тем не менее режим SDR по умолчанию со скоростью до 12,5 Мбит/с является значительным улучшением скорости/емкости по сравнению с I²C. [21]
Данная спецификация, опубликованная в декабре 2019 года, доступна только членам MIPI.
Опубликованный в июне 2021 года, он исключил термины «ведущий/ведомый» и теперь использует обновленные нормативные термины «контроллер/цель». Технические определения таких устройств и их роли на шине I3C остаются неизменными.
I3C использует те же два сигнальных контакта, что и I²C, называемые SCL (последовательные часы) и SDA (последовательные данные). Основное отличие заключается в том, что I²C всегда использует их как выходы с открытым стоком , поэтому его скорость ограничена полученным медленным временем нарастания сигнала . I3C использует режим открытого стока, когда это необходимо для совместимости, но переключается на двухтактные выходы , когда это возможно, и включает изменения протокола, чтобы сделать это возможным чаще, чем в I²C.
Обычно SDA изменяется сразу после заднего фронта SCL, а результирующее значение принимается по следующему переднему фронту. Когда контроллер передает SDA цели, он делает это также по заднему фронту SCL. Однако, когда цель I3C возвращает управление SDA контроллеру (например, после подтверждения своего адреса перед записью), она освобождает SDA по переднему фронту SCL , и контроллер отвечает за удержание полученного значения (повторное управление копией бита цели) на время высокого уровня SCL. Поскольку контроллер управляет SCL, он сначала увидит передний фронт, поэтому будет краткий период перекрытия, когда оба управляют SDA, но поскольку они оба управляют одним и тем же значением, конфликта шины не возникает.
Все коммуникации в I²C и I3C требуют кадрирования для синхронизации. В пределах кадра изменения на линии SDA должны всегда происходить, пока SCL находится в низком состоянии, так что SDA можно считать стабильным при переходе SCL с низкого на высокий уровень. Нарушения этого общего правила используются для кадрирования (по крайней мере, в устаревших и стандартных режимах скорости передачи данных).
Между кадрами данных контроллер шины удерживает SCL на высоком уровне, фактически останавливая тактовый генератор, а драйверы SDA находятся в состоянии высокого импеданса, позволяя подтягивающему резистору перевести его в высокий уровень. Переход SDA с высокого уровня на низкий, когда SCL на высоком уровне, называется символом START и сигнализирует о начале нового кадра данных. Переход SDA с низкого уровня на высокий, когда SCL на высоком уровне, называется символом STOP, завершающим кадр данных.
START без предшествующего STOP, называемый «повторным START», может использоваться для завершения одного сообщения и начала другого в рамках одной транзакции шины.
В I²C символ START обычно генерируется контроллером шины, но в I3C даже целевые устройства могут потянуть SDA на низкий уровень, чтобы указать, что они хотят начать кадр. Это используется для реализации некоторых расширенных функций I3C, таких как внутриполосные прерывания, поддержка нескольких контроллеров и горячие соединения. После запуска контроллер шины перезапускает часы, управляя SCL, и начинает процесс арбитража шины.
Как и I²C, I3C использует 9 тактовых циклов для отправки каждого 8-битного байта. Однако 9-й цикл используется по-другому. I²C использует последний цикл для подтверждения, отправляемого в противоположном направлении первым 8 битам. I3C работает таким же образом для первого (адресного) байта каждого сообщения и для сообщений, совместимых с I²C, но при взаимодействии с целями I3C байты сообщения после первого используют 9-й бит как бит нечетности при записи и флаг конца данных при чтении.
Запись может быть прекращена только контроллером.
Либо контроллер, либо цель могут прекратить чтение. Цель устанавливает SDA на низкий уровень, чтобы указать, что больше нет доступных данных; контроллер отвечает, перехватывая SDA и генерируя STOP или повторный START. Чтобы разрешить продолжение чтения, цель устанавливает SDA на высокий уровень, пока SCL находится на низком уровне до 9-го бита, но позволяет SDA плавать (открытый сток), пока SCL находится на высоком уровне. Контроллер может установить SDA на низкий уровень (повторное условие START) в это время, чтобы прервать чтение.
В начале кадра несколько устройств могут конкурировать за использование шины, и процесс арбитража шины служит для выбора того, какое устройство получит контроль над линией SDA. Как в I²C, так и в I3C арбитраж шины выполняется с линией SDA в режиме открытого стока, что позволяет устройствам, передающим двоичный 0 (низкий), переопределять устройства, передающие двоичную 1. Конкурирующие устройства контролируют линию SDA, управляя ею в режиме открытого стока. Всякий раз, когда устройство обнаруживает низкое состояние (0 бит) на SDA во время передачи высокого (1 бит), оно проигрывает арбитраж и должно прекратить конкуренцию до начала следующей транзакции.
Каждая транзакция начинается с целевого адреса, и реализация отдает приоритет целевым адресам с меньшим номером. Разница в том, что I²C не имеет ограничений на продолжительность арбитража (в редкой, но законной ситуации, когда несколько устройств конкурируют за отправку сообщения одному и тому же устройству, конфликт не будет обнаружен до окончания байта адреса). Однако I3C гарантирует, что арбитраж будет завершен не позднее конца первого байта. Это позволяет использовать драйверы push-pull и более высокие тактовые частоты в большинстве случаев.
Это делается несколькими способами:
0x7E(1111110 2 ). Поскольку он имеет более низкий приоритет, чем любое устройство I3C, после прохождения арбитража контроллер знает, что никакое другое устройство не претендует на шину.0x7Eвыиграл арбитраж для достаточного количества ведущих битов, чтобы отличить его от любого назначенного адреса, контроллер знает, что арбитраж завершен, и он может переключиться на работу push-pull на SDA. Если все назначенные адреса меньше 0x40, это после первого бита. Если все адреса меньше 0x60, это после второго бита и т. д.Запись, адресованная зарезервированному адресу, 0x7Eиспользуется для выполнения ряда специальных операций в I3C. Все устройства I3C должны получать и интерпретировать записи по этому адресу в дополнение к своим индивидуальным адресам.
Прежде всего, запись, состоящая только из байта адреса и без байтов данных, не влияет на цели I3C, но может использоваться для упрощения арбитража I3C. Как описано выше, этот префикс может ускорить арбитраж (если контроллер поддерживает оптимизацию переключения на push-pull mid-byte), и он упрощает контроллер, избегая немного сложного арбитражного случая.
Если за записью следует байт данных, байт кодирует «общий код команды», стандартизированную операцию I3C. Коды команд 0–0x7F— это широковещательные команды, адресованные всем целям I3C. За ними могут следовать дополнительные параметры, специфичные для команды. Коды команд 0x80–0xFE— это прямые команды, адресованные отдельным целям. За ними следует серия повторяющихся START и записи или чтения для определенных целей.
Пока действует прямая команда, записи или чтения для каждой цели передают параметры, специфичные для команды. Эта операция заменяет обычный ответ цели на сообщение I3C. За одной прямой командой может следовать несколько сообщений для каждой цели, каждое из которых предваряется повторным START. Этот специальный режим заканчивается в конце транзакции (символ STOP) или следующим сообщением, адресованным 0x7E.
Некоторые коды команд существуют как в широковещательной, так и в прямой форме. Например, команды для включения или отключения внутриполосных прерываний могут быть отправлены отдельным целям или широковещательно всем. Команды для получения параметров от цели (например, команда GETHDRCAP для запроса устройству поддерживаемых им высокоскоростных режимов передачи данных) существуют только в прямой форме.
На шине I3C в режиме по умолчанию (SDR) могут поддерживаться четыре различных класса устройств:
Каждая транзакция шины I3C начинается в режиме SDR, но контроллер I3C может выдать команду широковещательной передачи CCC «Enter HDR», которая сообщает всем целям I3C, что транзакция будет продолжена в указанном режиме HDR. Цели I3C, которые не поддерживают HDR, могут затем игнорировать трафик шины, пока не увидят определенную последовательность «HDR exit», которая сообщит им, что пора снова прослушивать шину. (Один из общих кодов команд I2C позволяет контроллеру спрашивать цель, какие режимы HDR она поддерживает. Это 8-битная маска, позволяющая добавлять дополнительные режимы HDR в будущем.)
Некоторые режимы HDR также совместимы с устройствами I²C , если устройства I²C имеют фильтр пиков длительностью 50 нс на линии SCL; то есть они будут игнорировать высокий уровень на линии SCL, который длится менее 50 нс. Это требуется спецификацией I²C, но реализовано не повсеместно, и не все реализации игнорируют часто повторяющиеся пики, [24] поэтому совместимость с I3C HDR должна быть проверена. Совместимые режимы HDR используют высокие импульсы SCL длительностью не более 45 нс, чтобы устройства I²C их игнорировали.
Режим HDR вводится перед обращением к какой-либо конкретной цели; адрес цели и сама команда отправляются с высокой скоростью передачи данных. Сообщение HDR завершается одной из двух последовательностей, которые не используются ни одним режимом HDR:
Хотя перезапуск HDR должен распознаваться только теми целями, которые поддерживают этот режим HDR, поэтому его можно перепроектировать в каком-то будущем режиме HDR, выход HDR должен распознаваться всеми целями I3C, даже теми, которые поддерживают только SDR, чтобы они могли правильно игнорировать сообщения HDR.
Режимы HDR отправляют данные 16-битными словами, всегда передавая четное число байтов. За каждым словом следуют два бита четности, которые чередуются : первый применяется к нечетным битам, а второй — к четным битам.
В режиме HDR контроллер отправляет серию сообщений, каждое из которых начинается с команды и адресного слова, разделяется перезапусками HDR и заканчивается выходом из HDR.
Команда HDR и адресное слово состоят из 16 бит:
Режим HDR-DDR использует двойную скорость передачи данных на линии SDA с тактовой частотой 12,5 МГц для достижения необработанной скорости передачи данных 25 Мбит/с (эффективная скорость 20 Мбит/с). Это требует изменения линии SDA, пока SCK находится на высоком уровне, что является нарушением протокола I²C, но поскольку длительность импульса высокого уровня составляет всего 40 нс, устройства I²C проигнорируют его и, таким образом, не заметят нарушения.
HDR-DDR сопровождает каждое 16-битное слово данных 2-битной преамбулой и 2-битной нечетной постамбулой, что составляет 20 бит. Каждое слово начинается с нарастающего фронта на SCK. Преамбула имеет три возможных состояния:
Если контроллер видит преамбулу "11" сразу после команды, это означает, что ни одна цель не отвечает, и обрабатывается так же, как NACK в режиме SDR. Чтобы гарантировать, что линия SDA будет видна высокой, если ни одна цель не отвечает, дополнительный бит в команде и адресном слове устанавливается таким образом, чтобы конечный бит четности, отправленный контроллером, был равен 1.
Для последующих слов во время операций чтения (от цели к контроллеру) цель устанавливает первый бит преамбулы на высокий уровень, но освобождает шину (позволяя подтягивающим резисторам поддерживать SDA на высоком уровне) для второго бита. Контроллер может установить SDA на низкий уровень во время второго бита (падающий фронт SCL), чтобы запросить отмену чтения.
Если сообщение не прерывается, оно завершается 13-битным словом CRC. Оно имеет преамбулу 01, фиксированный шаблон 1100 (другие шаблоны зарезервированы для будущего использования), затем 5-битную циклическую проверку избыточности для всего сообщения (включая слово команды/адреса, но не преамбулу или биты четности или любую часть слова CRC) и два бита "1" (первый управляемый, второй пассивно удерживается на высоком уровне, чтобы контроллер мог взять управление на себя). Это оставляет шину с высокими уровнями как SCK, так и SDA, после чего контроллер должен сгенерировать перезапуск HDR или выйти.
Режимы HDR-TSP и HDR-TSL используют один из трех символов в качестве троичных цифр (тритов):
Два байта плюс два бита четности (всего 18 бит) разбиваются на шесть 3-битных триплетов, и каждый триплет кодируется как два трита. (3 бита берутся сначала msbit, чтобы получить значение от 0 до 7, которое затем преобразуется в два трита с использованием числовых значений из списка выше, и отправляется первым наиболее значимый трит.) При отправке со скоростью 25 Мтрит/с достигается эффективная скорость передачи данных 33,3 Мбит/с.
Пара тритов 22, состоящая только из двух переходов SDA, не используется для кодирования данных, а вместо этого используется для кодирования последовательностей перезапуска HDR и выхода HDR, которые завершают сообщение. Хотя это ограничивает максимальное время между переходами SCL тремя временами тритов, это превышает предел в 50 нс для устаревших устройств I²C, поэтому режим HDR-TSP (троичный символ, чистый) может использоваться только на шине без устаревших устройств I²C.
Чтобы разрешить шины, включающие устройства I²C (с фильтром пиков), необходимо использовать режим HDR-TSL (троичный символ, устаревший). Это поддерживает совместимость с I²C с помощью заполнения тритов : после любого нарастающего фронта на SCL, если следующий трит не равен 0, отправитель вставляет 1 трит (переход только на SCL) и игнорирует его получателем. Это гарантирует, что SCL никогда не будет высоким более одного трита, но за счет передачи 2,67 тритов на 3 бита полезной нагрузки, эффективной скорости передачи данных 25 Мбит/с (предполагая случайные данные).
В режиме троичного символа контроллер завершает команду чтения, оставляя линии SDA и SCL высокими, после чего цель управляет обеими с любой желаемой скоростью. Контроллеру не предусмотрено прерывание операции чтения; если контроллер не доверяет цели остановиться вовремя, он должен выбрать другой режим передачи. Когда передача завершена, цель возвращает шину контроллеру следующим образом:
Обратите внимание, что троичный режим данных не включает CRC.
Растягивание тактовой частоты является необязательным, и на самом деле большинство целевых устройств не включают драйвер SCL, поэтому они не могут растягивать тактовую частоту.
Ширина импульса игнорируется (входной фильтр на SCL и SDA) - одиночный сбой: 100 нс макс.