Как стать автором
Обновить

1x PCIe чтобы управлять всем

Время на прочтение 10 мин
Количество просмотров 9.7K

Введение

Высокоскоростные интерфейсы PCIe стали неотъемлемой частью современных процессоров. Производители чипов конкурируют в количестве интегрированных линий PCIe, что влияет на возможности ввода/вывода вычислительных платформ, требования к которым постоянно растут.

Несмотря на развитие технологий, производители серверных решений не спешат использовать интерфейс PCIe для выполнения функций управления платформой. Вероятно это связано с вызовами и издержками, которые неизбежно возникают при переходе на новые архитектурные решения.

Между тем, использование PCIe в качестве интерфейса управления платформой потенциально несет ряд преимуществ, например положительно влияет на общую готовность и надежность системы, снижает издержки дизайна при масштабировании платформы, повышает скорость и снижает задержки при обмене информации внутри системы управления платформой.

В этой статье будут рассмотрены вызовы, издержки, преимущества, а также возможные варианты применения, связанные с использованием PCIe в качестве интерфейса управления платформой, а также сделан вывод, что преимущества использования PCIe в качестве интерфейса управления платформой способны преодолеть стоимость издержек и предоставить конкурентные преимущества конечным решениям.

Преимущества

Мультплексирование

В традиционной модели интерфейс управления платформой предназначен для:

  • Мониторинга состояния платформы: температура, напряжение, скорость вращения вентиляторов, состояние источников питания, наличие ошибок шины, физическая безопасность системы, и др.

  • Адаптивного управления охлаждением и питанием платформы.

  • Журналирования различных событий, в том числе событий сбоев и выхода контролируемых параметров за пределы допустимых значений.

  • Нотификации удаленных получателей об изменениях в состоянии платформы и происшествиях.

  • Предоставления удаленного доступа к управлению платформой, ее состоянию и инвентарной информации о ней.

  • Предоставления удаленного интерфейса для отладки и диагностики серверного ПО.

Типичной реализацией интерфейса управления платформой является отдельная микропроцессорная система — система управления платформой, расположенная на серверной плате. Система управления платформой функционирует безотносительно состояния самой платформы. Центральным звеном системы управления платформой является BMC (Board Management Controller). В зависимости от решения, в систему управления платформой могут включаться различные устройства, а также другие контроллеры. BMC соединяется с серверной платформой различными интерфейсами.

Долгое время для интерфейса управления платформой использовался стандарт IPMI[1], изначально появившийся в 1998м году, и прошедший ряд итераций и расширений. В настоящее время этот стандарт морально устарел и рынок серверных решений постепенно переходит на стандарты PMCI[2] и Redfish[3] от DMTF.

Количество различных соединений между серверной платформой и BMC может исчисляться десятками линий. Так, программное обеспечение для управления системой на сервере имеет доступ к системе управления платформой через системный интерфейс (LPC, eSPI или I2C). Кроме того, практически повсеместно используются следующие интерфейсы:

  • последовательный интерфейс (UART) для перенаправления системной консоли до удаленного клиента.

  • высокоскоростной интерфейс (PCIe) для перенаправления видео и звука до удаленного клиента.

  • высокоскоростной интерфейс (USB или PCIe) для организации виртуальных устройств хранения (virtual media).

  • высокоскоростной сетевой интерфейс (RMII или PCIe) для стороннего обмена через сетевой контроллер серверной платформы.

  • Jtag интерфейс для организации удаленной отладки серверного ПО.

  • низкоскоростные интерфейсы для обмена информацией между устройствами системы управления платформой.

  • набор сигнальных линий для передачи различных состояний и статусов от серверной платформы, и в обратную сторону.

На рисунке ниже представлена типовая схема соединений между серверным процессором (Host CPU) и BMC.

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

Внедрение интерфейса PCIe в качестве интерфейса управления платформой позволяет значительно сократить число необходимых соединений путем мультиплексирования потоков информации в рамках одного физического соединения. Этому способствуют архитектурные особенности стандарта PCIe, которые позволяют одному окончанию на шине реализовывать множество функций, а также высокая скорость передачи информации, при которой совмещение нескольких потоков информации не приведет к увеличению задержек.

Таким образом, множество физических соединений разного назначения возможно заменить несколькими функциями оконечного устройства на единственной шине PCIe.

На рисунке ниже представлена схема соединений серверного (Host CPU) процессора с BMC, когда большинство ранее представленных соединений заменено на функции единственного окончания на шине PCIe.

Соединения для GPU/Video и Virtual Media остаются неизменными по причине разницы в направленности соединений.

Скорость

В первом стандарте PCIe, вышедшим в 2002м году, скорость передачи достигает 2,5 GT, что обеспечивает пропускную способность одной линии шины в 250МБ/с в каждом направлении. Второй стандарт позволяет передавать по одной линии уже 500МБ/с, третий до 1ГБ/с, а четвертый до 2ГБ/с. [4]

Для сравнения, широко использующаяся до сих пор шина LPC, формирующая базовые соединения между серверным процессором и BMC, имеет частоту 33МГц с пропускной способностью до 16,5МБ/с, а пришедшая ей на замену шина eSPI — 66МГц и до 33МБ/с соответственно. [5][6]

Подобное преимущество в пропускной способности одной линии PCIe позволяет мультиплексировать несколько функций в одном окончании, не опасаясь превысить пропускную способность канала. Более того, это позволяет выделить большую пропускную способность на те каналы связи, которые традиционно были медленными, но требования к скорости которым выросли. Например, так выросли требования к системному интерфейсу с переходом от стандарта IPMI к DMTF Redfish (в DMTF стандарте он называется Host Interface), т. к. количество данных передаваемых по этому интерфейсу значительно возросло.

Одним из примечательных следствий наличия высокой скорости обмена между BMC и серверным процессором является возможность загрузки встроенного ПО сервера быстрее, чем загрузка по таким интерфейсам как: NAND, SPI, SD или EMMC, которые часто используются в существующих решениях. Этот факт открывает возможность активного использования шины PCIe в качестве альтернативного способа загрузки или обновления встроенного ПО на сервере. В свою очередь возможность обновления встроенного ПО сервера или восстановления работоспособности сервера (в случае повреждения хранимых образов) без необходимости прямого доступа к хранилищу встроенного ПО сервера привносит дополнительный элемент защиты системы от нежелательного проникновения со стороны BMC.

Масштабируемость

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

На рисунке ниже показаны варианты решений на основе процессоров Inte, использующие PCH, а также процессоры других производителей, у которых соединение к BMC происходит напрямую с одним из серверных узлов.

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

На рисунке ниже показаны варианты соединения BMC, имеющим единственную линию PCIe, и с несколькими линиями.

Важным следствием возможности масштабирования является то, что соединения всех узлов в системе имеют идентичную функциональность, а это ведет к еще одном преимуществу — повышению общей готовности системы, т. к. любой сокет либо осуществляет общение напрямую с BMC, либо потенциально способен осуществлять функции общения с BMC в случае выхода из строя узла, который осуществлял общение до этого.

Для сравнения, в решениях со специализированным сокетом общая надежность и готовность платформы не превышает надежности этого сокета. Выходя из строя, такой сокет выводит из строя всю систему. Но при идентичной функциональности соединений BMC с узлами, при выходе любого серверного сокета из строя, система может быть переконфигурирована для работы с оставшимися исправными сокетами, и пусть и с меньшей мощностью, но доступна для использования.

Примеры использования

В этой части будут представлены варианты использования того, какие функции могли бы выполняться на каждом узле (окончании PCIe) для выполнения задач системы управления платформой.

Cтатус загрузки

Одним из требований к интерфейсу, по которому рапортуется статус загрузки, является доступность на ранних стадиях, чтобы код, исполняющийся в это время, мог рапортовать прогресс загрузки. Для этого драйвер интерфейса должен быть как можно более прост, чтобы его можно было легко отладить и поместить даже в ROM.

Известные мне дизайны серверных платформ используют два варианта физических интерфейсов для сообщения прогресса загрузки системы: набор GPIO сигналов, или ведомый I2C.

В случае использования GPIO одним из недостатков было выделение 8 сигнальных линий исключительно для передачи статуса загрузки, тогда как в остальное время эти линии не использовались. Вторым недостатком был тот факт, что смена статуса предполагала изменения нескольких сигналов сразу, которые менялись хоть и сразу один за другим, но все-таки последовательно. Такая смена приводила к наличию транзиентных состояний сигналов и возможности считывания неверных значений статусов.

В случае с интерфейсом I2C возникали задержки с чтением статуса в следствие низкой скорости обмена.

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

В случае использования шины PCIe, оконечное устройство реализует функцию, при которой ПО на серверном процессоре записывает определенное значение статуса по определенному адресу, а BMC его считывает из адресного пространства устройства, отображенного в адресное пространство самого BMC. При этом на стороне устройства инициализация и согласование соединения происходит по несложным установкам регистров, а запись нового статуса простой записью значений в определенный адрес.

При необходимости реализация функции может включать FIFO, что решает проблему с потерей быстро сменяющихся статусов.

Репликация соединения в многосокетных решениях дополнительно позволяет следить за загрузкой каждого узла по отдельности.

Виртуальные GPIO

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

Оконечное устройство PCIe может реализовать функцию набора виртуальных GPIO в том количестве, которое необходимо для передачи любой статусной информации в обе стороны. Это могут быть сигналы для конфигурации загрузки (bootstrap) системы, сигналы различных ошибок или состояния оборудования.

Системный (хост) интерфейс

Оконечное устройство PCIe на серверном процессоре может реализовать как традиционные системные интерфейсы IPMI (KCS, BT, SMIC), так и Redfish хост интерфейс. В последнем случае, окончание будет эмулировать Ethernet интерфейс.

PLDM. Замена IPMB

Современные серверные процессоры содержат в себе сопроцессоры, отслеживающие и управляющие состоянием связанных с процессором параметров — температура, входящее напряжение, ток, потребляемая мощность. Традиционно сопроцессоры были соединены с BMC через выделенные каналы связи (IPMB) и входят в общую систему управления платформой как дополнительные управляющие контроллеры.

Оконечное PCIe устройство на серверном процессоре может реализовать окончание протокола MCTP с поддержкой PLDM сообщений и стать частью системы управления платформой, выставляя набор сенсоров и элементов управления, реализуя необходимый набор команд из соответствующих спецификаций DMTF PLDM.

NC-SI

Наиболее распространенным решением в дизайнах серверных платформ является наличие двух способов сетевого доступа к системе управления платформой — выделенный сетевой порт для сети управления, и сторонний доступ через сетевой порт серверной платформы (sideband interface, NC-SI).

Обычно серверный сетевой порт, через который осуществляется сторонний доступ к BMC разведен как отдельный LAN чип (LOM — LAN on motherboard), но также встречались решения, когда сетевой порт был частью серверного процессора. И в том и другом случае сторонний канал (NC-SI) был отдельным физическим интерфейсом RMII, выведенный либо с LOM, либо с серверного сокета, и соединенный напрямую с BMC.

В случае когда один или несколько сетевых портов встроены в серверный чип, реализация окончанием PCIe на процессоре поддержки NC-SI через MCTP позволяет организовать сторонний сетевой доступ к BMC из любого узла в многосокетном дизайне без усложнения системной платы.

Недостатки и вызовы

Разобрав преимущества и возможные случаи применения PCIe как интерфейса управления платформой, следует также обратить внимание, какие вызовы и недостатки такое решение несет.

Сложность

Простота работы с PCIe устройством на программном уровне является безусловным преимуществом. Однако эту простоту обеспечивает изрядная сложность аппаратного обеспечения. Передатчики, машина состояний, логика реализованных оконечных аппаратных функций и устройств несоразмерно (на несколько порядков) выше, чем при работе с интерфейсами I2C, SPI или GPIO.

С одной стороны реализация набора логики для всех функций PCIe окончания влечет несоразмерно больший транзисторный бюджет по сравнению даже с несколькими I2C, SPI и GPIO интерфейсами вместе взятыми. С другой стороны экономия на контактных площадках должна компенсировать эти потери.

Потребление питания

Интерфейсы I2C и SPI известны экономностью потребления, тогда как затраты на питание PCIe интерфейса значительно выше. С другой стороны, шина PCIe запитывается только во время работы серверной платформы, и даже в активном использовании шины затраты на нее на несколько порядков ниже затрат питания на основную функцию процессора — вычисления и ввод/вывод. Кроме того, опыт использования PCIe в мобильных, энергоемких устройствах привел к вводу новых, энергоэффективных состояний передатчиков PCIe, при которых затраты на потребления уменьшаются в десятки и сотни раз.

Разработка и дизайн

Безусловно, разработка целого ряда аппаратных устройств потребует значительных инвестиций в их разработку, дизайн и отладку. Хорошим подспорьем в данном случае было бы вынесение части данной работы, касающейся разработки интерфейсов или протоколов, на откуп объединенных рабочих групп производителей. В этом случае решение бы априори устраивало и было бы востребовано частью рынка, а значит подключило бы и другие заинтересованные стороны к разработке необходимого аппаратного обеспечения на основе разработанных спецификаций, упростив ввод новой архитектуры в эксплуатацию.

Заключение

В этой статье были рассмотрены преимущества, недостатки и вызовы интерфейса управления платформой на основе шины PCIe. Дизайны серверных платформ, реализующие такое решение, имеют очевидные преимущества и большой потенциал для дальнейших улучшений. В то же время обнаруженные недостатки не столь значительны, чтобы поставить целесообразность перехода под вопрос. Вынесение вопросов по разработке стандартов в рабочие группы заинтересованных производителей способно снизить издержки на разработку и дизайн, необходимых для выведения новых решений на рынок. Не вызывает сомнений, что растущие требования к системам управления платформой сделают разработанные решения на основе PCIe интерфейса управления платформой востребованными на рынке.

Ссылки на источники

Теги:
Хабы:
+16
Комментарии 17
Комментарии Комментарии 17

Публикации

Информация

Сайт
hr.auriga.ru
Дата регистрации
Дата основания
Численность
501–1 000 человек
Местоположение
Россия