Совсем недавно мне в руки попался один из вариантов отладочной платы с SoC Zynq XC7Z020. Поискав в Интернете материалы, а-ля how-to, и попробовав накидать свой минимальный проект обнаружил, что есть целый ряд подводных камней. Именно об этом я и хотел бы рассказать в статье. Кому интересно - добро пожаловать под кат.

Важно! Перед началом повествования, хотелось бы заранее оговориться, что основная цель которую я преследую при написании этой статьи - показать любителям, с чего можно начать, при изучении отладочных плат на базе Zynq. Я не являюсь профессиональным разработчиком под ПЛИС и SoC Zynq и могу допускать какие-либо ошибки в использовании терминологии, использовать не самые оптимальные пути решения задач, etc. Но любая конструктивная и аргументированная критика только приветствуется. Что ж, поехали

Что за отладка такая? Покажи-расскажи...

Мне очень давно хотелось поиграться с SoC Zynq, но никак не доходили руки. Но в очередной раз погуглив - увидел, что за вполне вменяемый ценник продаётся отладка с Zynq на борту, от компании QMTech, называется она Bajie Board. Выпускается отладка в нескольких вариантах с разными вариантами SoC Zynq. Я выбрал для себя вариант на XC7Z020 и тут же ее заказал, через пару недель она у меня уже была в руках.

После распаковки я был приятно удивлен, комплект поставки порадовал. Это была сама отладочная плата, блок питания на 5В/2А, mini-USB кабель и microSD Flash-карта SanDisk на 16Гб с уже залитым на нее Linux. То есть, сразу после получения вы можете подключить к плате питание, воткнуть USB-шнурок, открыть Putty и получить в свое распоряжение полноценный mini-компьютер с Embedded Linux. О Linux для Zynq, я думаю, расскажу в другой статье, поэтому едем дальше...

Итак, рассматривая плату и попутно документацию на нее я увидел относительно не плохой набор всякого-разного:

• SoC: XC7Z020-1CLG400C

• (datasheet:https://www.xilinx.com/support/documentation/data_sheets/ds190-Zynq-7000-Overview.pdf);

• Осциллятор на 33,333 МГц;

• Оперативная память DDR3 на 512 Мб от компании Micron, MT41K256M16TW-107:P;

• Встроенный слот micro SD;

• Источник питания для FPGA TPS563201 с широким диапазоном входных напряжений (от 4.5V до 17V, 3A);

• Один 50-пиновый и две Digilent PMOD совместимых, гребёнки с пинами, с шагом в 2,54 мм. для пользовательских кейсов (как заверяет производитель, все проводники до пинов выровнены по длине);

• Кнопка для логического сброса процессорной системы (PS);

• Гигабитный RGMII Ethernet-контроллер Realtek RTL8211E-VL, подключенный к PS;

• Два пользовательских светодиода, один подключен к программируемой логике (PL) и другой подключен к процессорной системе (PS);

• Встроенный HDMI-совместимый интерфейс дисплея TI TPD12S016;

• Гребёнка для подключения JTAG-отладчика;

Для большинства задач начального уровня такого количества всего будет прям за глаза.

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

Установка необходимого набора ПО для разработки

Итак, прежде чем начать работу с платой мне было необходимо установить ПО Xilinx Vivado и Xilinx SDK. Насколько я понимаю, грубо говоря, Vivado используется для конфигурации аппаратной части используемой платы и для работы с программируемой логикой. А Xilinx SDK (ныне именуется Vitis) используется для создания кода непосредственно для процессорной системы.

Поскольку бОльшая часть примеров из документации и репозитория производителя и разнообразных примеров из роликов на YouTube делались в версии Vivado 2019.1 (видимо из-за того, что это последняя версия поддерживающая работу с Xilinx SDK) - я установил именно её, а не последнюю доступную 2020.2.

Все программные продукты необходимые для работы с Xilinx Zynq - можно взять на официальном сайте Xilinx, тут. Сразу же спешу обратить внимание, что те из вас, кто захочет установить самую новую версию Vivado - нужно скачивать версию 2020.2, а не 2020.3 т.к. последняя поддерживает только Versal SoC, и не поддерживает Zynq.

В моём случае, т.к. я работаю в операционной системе Linux - я перешел в меню Vivado Archive - 2019.1 и нажал на кнопку скачивания по ссылке Vivado HLx 2019.1: WebPACK and Editions - Linux Self Extracting Web Installer в списке Vivado Design Suite - HLx Editions - 2019.1. Для пользователей Windows - выбирайте Windows Self Extracting Web Installer.

После скачивания открываем инсталлятор, установив права на исполнение:

chmod +x ~/Downloads/Xilinx_Vivado_SDK_Web_2019.1_0524_1430_Lin64.bin~/Downloads/Xilinx_Vivado_SDK_Web_2019.1_0524_1430_Lin64.bin 

Вся установка состоит из набора стандартных шагов.

1. Вводим авторизационные данные, которые мы указывали при регистрации;

2. Принимаем условия лицензионных соглашений;

3. Выбираем Vivado HL WebPACK;

4. Удостоверяемся в том, что выбран SoC Zynq в списке предложенного оборудования.

   

5. Далее программа скачает порядка 16Гб всякого-разного, установит это и на Рабочем столе появятся иконки нужных нам приложений.

После установки Vivado необходимо установить драйвер для JTAG-программатора. В Linux это делается так:

cd Xilinx2019.1/Vivado/2019.1/data/xicom/cable_drivers/lin64/install_script/install_drivers/sudo ./install_drivers 

Подключаем все 6 пинов от JTAG-программатора в соответствии с шелкографией на плате. И проверяем установлены ли драйвера и определяется ли наша отладочная плата:

cd ~/Xilinx2019.1/Vivado/2019.1/bin./xsdb xsdb% connect -host localhost   xsdb% jtag targets                                                                                                                                                             1  Platform Cable USB 13724327082b01     2  arm_dap (idcode 4ba00477 irlen 4)     3  xc7z020 (idcode 23727093 irlen 6 fpga)

На этом подготовительных этап можно считать завершенным.

Hello, world или Баяны подъехали

Не будем отходить от традиции и попробуем поморгать LED-иком который подключен к программируемой логике.

Запускаем Vivado и создаем новый проект. Нажимаем File - Project - New

Откроется мастер создания нового проекта, нажимаем Next > и пишем название нашего проекта PL-Blink.

Выбираем RTL Project и ставим галочку у пункта Do not specify sources at this time.

Далее в списке ищем наш процессор xc7z020clg400-1.

Жмём на кнопку Finish.

Перед нами открывается главное окно программы Vivado и мы можем приступать к реализации намеченной нами цели!

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

Находим меню Sources и нажимаем кнопку Add Sources.

Откроется мастер импорта и нам нужно выбрать Add or create constraints.

В следующем меню нажимаем Create file и пишем название нашему файлу physical_constr. Именно в этом файле мы опишем какие ножки и в каком режиме должны работать.

Нажимаем кнопку Finish и в дереве Sourсes ищем только что созданный нами файл и открываем его:

Обратимся к схеме, которую любезно предоставил нам производитель и найдем какая ножка отвечает за тактирование, а какая за наш светодиод.Бегло поискав, я отметил для себя, что из Ethernet-контроллера RTL8211E-VL выведен опорный тактовый сигнал с его внутреннего PLL, частотой в 125МГц и заведен в ножку H16 (IO_L13P_T2_MRCC_35).Так почему бы нам его и не задействовать в нашем примере? =)

Его мы и заюзаем для нашего счетчика, который будет генерировать задержку между включенным и выключенным состоянием светодиода.

Тут же, рядом, на ножке H17 (IO_L13N_T2_MRCC_35) расположен светодиод, которым мы будем моргать.

Итак. Открыв наш constraints-файл запишем в него следующие строки:

# User LED and Clockset_property IOSTANDARD LVCMOS33 [get_ports led_h17_d4]set_property IOSTANDARD LVCMOS33 [get_ports sys_clk]set_property PACKAGE_PIN H17 [get_ports led_h17_d4]set_property PACKAGE_PIN H16 [get_ports sys_clk]

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

В квадратных скобках, после get_ports необходимо указать логическое имя ножки (на ваше усмотрение). Имена стоит придумать осмысленно, потому что мы его будем использовать в Verilog-коде.

Кстати, подробнее о Physical Constraints можно почитать тут в главе 8.

Добавим в наш проект таким же образом Design Source. Находим меню Sources и нажимаем кнопку Add Sources.

Откроется мастер импорта и нам нужно выбрать Add or create design sources. Далее нажимаем Create File, смотрим, что выбран язык Verilog. Нажимаем ОК и Finish.

В следующем меню всё оставляем без изменений и нажимаем ОК и Yes.

Открываем созданный файл и видим небольшую заготовку:

Здесь вместо предложенного кода пишем наш Verilog-код и прокомментируем что значит каждая из строк:

// Директива компилятора, которая определяет единицу времени и точность для моделирования Verilog.// В целом, не очень интересный пункт для нас.`timescale 1ns / 1ps // Определяем стандартный блок-модуль (как класс в С++)module pl_blink(input sys_clk, output led_h17_d4);    // Задаем регистр для хранения записи о текущем состоянии светодиодаreg r_led; // Задаем регистр для хранения значения счётчика, использующегося в задержкеreg [31:0] counter;// Тут мы задаем действия которые должны быть выполнены при старте программыinitial begin    counter <= 32'b0;//  Обнуляем счётчик    r_led <= 1'b0;//  Делаем запись о состоянии светодиодаend// Тут описываем поведенческий блок, который будет реагировать на ниспадающий фронт тактовой частотыalways@(posedge sys_clk)begin    counter <= counter + 1'b1;// Увеличиваем счетчик        if(counter > 12000000)// Если счетчик больше некоторого условного значения    begin        r_led <= !r_led;// Инвертируем запись о значении состоянии светодиода        counter <= 32'b0;// Сбрасываем счетчик    end       endassign led_h17_d4 = r_led;          // Присваиваем текущее состояние ножке (условно)           endmodule

Нажимаем сочетание клавиш Ctrl + S чтобы сохранить код. Смотрим, не подсвечены ли где возможные ошибки. Если нет - то можем приступить к синтезированию, имплементации и генерации бинарного файла который мы потом зальем в нашу плату Zynq и будем наблюдать за морганием светодиода.

Нажимаем кнопку Run Synthesis и дожидаемся завершения синтеза. После окончания программа нам скажет, что синтез успешно завершен и мы можем переходить к следующему шагу:

Выбираем Run implementation и дожидаемся окончания. После выбираем пункт Generate Bitstream для запуска финального этапа:

Тут так же дожидаемся сигнала о том, что всё прошло успешно, выбираем Open Hardware Manager и можем приступать к заливке результата компиляции в нашу плату:

В открывшемся меню Hardware Manager нажимаем кнопку Auto connect, дожидаемся когда произойдет успешное соединение и откроется меню со списком устройств:

В меню слева или через нажатие правой кнопкой по xc7z020_1 в меню Hardware нажимаем пункт Program Device.

В следующем окне убеждаемся, что правильно указан путь к bitstream-файлу и нажимаем кнопку Program.

Программа заливается на нашу плату

И через мгновение на плате загорается светодиод D2, который сообщает нам, что FPGA DONE и в другом конце платы мы видим весело моргающий светодиод. =)

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

Сейчас уже едва ли не у каждого дома, на работе или на учебе есть свой настольный ПК. Кто-то использует его для составления налоговых деклараций, кто-то для гейминга, а кто-то и сам собирает компьютеры. Но насколько хорошо вы знакомы с компонентами, что находятся внутри ПК? Возьмем, к примеру, скромную материнскую плату: она сидит себе там, внутри, тихо поддерживает все в рабочем состоянии и редко получает столько же внимания, как, скажем, процессор или видеокарта.

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

Итак, начнем

А начнем мы с того, какую роль в ПК выполняет материнская плата. По сути, она служит для:

• Обеспечения компонентов электропитанием;

• Обеспечения маршрутов для связи компонентов между собой.

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

Почти все материнские платы для стандартных ПК имеют разъемы для центрального процессора (ЦП), модулей памяти (обычно типа DRAM), дополнительных плат расширения (таких как видеокарта), устройств хранения, блоков ввода/вывода, а также средств связи с другими компьютерами и системами.

Существуют отраслевые стандарты по размерам материнских плат, которых придерживаются одни производители и не придерживаются другие (но их гораздо меньше). Вот основные из них:

• Standard ATX 12 9,6 дюйма (305 244 мм);

• Micro ATX 9,6 9,6 дюйма (244 244 мм);

• Mini ATX 5,9 5,9 дюйма (150 150 мм).

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

Но что же такое материнская плата?

Материнская плата это просто большая печатная плата с множеством разъемов для подключения устройств и сотнями, если не тысячами сантиметров электрических линий, их соединяющих. Теоретически, она не так уж и нужна: все это можно соединить при помощи множества проводов. Однако производительность в таком случае оставит желать лучшего, ведь сигналы будут мешать друг другу, и возникнут заметные потери мощности.

Начнем разбор с типичной материнской платы ATX. Ниже изображена плата Asus Z97-Pro Gamer, внешне и функционально не сильно отличающаяся от десятков ей подобных.

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

Гораздо лучше и понятнее, не так ли? По ней видно, сколько в материнской плате всяких коннекторов и разъемов, о которых стоит поговорить. И начнем мы по порядку, с самого важного, сверху вниз.

Подключаем мозг к ПК

На схеме выше мы видим структуру, имеющую обозначение LGA1150. Это обозначение используется в Intel для разъема, предназначенного для подключения различных процессоров. LGA здесь означает Land Grid Array распространенный тип технологии упаковки центральных процессоров и других чипов.

Системы LGA имеют множество маленьких контактов на материнской плате или в разъеме для обеспечения питания и связи с процессором. Выглядят они так:

Металлический фиксатор помогает закрепить ЦП на месте, но мешает рассмотреть контакты, так что уберем его:

Помните, что это? LGA1150. 1150 здесь указывает на количество выводов в разъеме, и у других материнских плат оно может отличаться. Чем выше производительность ЦП (с точки зрения количества ядер, объема кэш-памяти и т. д.), тем больше контактов будет в разъеме. Большая их часть используется для обмена данными со следующей важной частью материнской планы.

Большому мозгу большая память

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

В нашем примере ЦП в материнской плате имеет 2 контроллера памяти, каждый из которых оперирует 2 картами памяти, всего 4 слота DRAM. На материнской плате они окрашены так, чтобы вы знали, какие из них каким контроллером управляются. Обычно их называют каналами памяти.

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

Допустим, у вас есть два модуля ОЗУ по 8 ГБ каждый. Независимо от того, в какие слоты вы их вставите, у вас всегда будет в общей сложности 16 ГБ доступной памяти. Однако, если оба модуля поместить только в черные или только в серые слоты, ЦП будет иметь два пути доступа к этой памяти. Но если поступить иначе и использовать слоты разных цветов, система будет вынуждена обращаться к памяти только с помощью одного контроллера памяти. Учитывая, что он может управлять только одним маршрутом за раз, нетрудно понять, как при этом изменится производительность.

При такой комбинации ЦП и материнской платы используются микросхемы DDR3 SDRAM (синхронная динамическая память с произвольным доступом с версией 3 двойной скорости передачи данных), и каждый слот может содержать один SIMM или DIMM. IMM обозначает X-рядный модуль памяти (In-line Memory Module); S и D указывают на то, заполнена ли чипами одна или две стороны модуля (Single или Dual, соответственно).

Вдоль нижнего края модуля памяти располагаются позолоченные разъемы для питания и обмена данными. Всего их у этого типа памяти 240 по 120 с каждой стороны.

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

Обычно производители придерживаются 240 контактов в модулях памяти, и нет никаких признаков того, что в ближайшее время это изменится. Чтобы улучшить производительность памяти, с каждой новой версией просто увеличивается скорость чипов. В нашем примере каждый из контроллеров памяти ЦП может отправлять и получать 64 бита данных за такт. Таким образом, с двумя контроллерами карты памяти будут иметь 128 контактов, предназначенных для обмена данными. Так почему же их именно 240?

Каждый чип в DIMM (всего их 16 по 8 на каждую сторону) может передавать 8 бит за такт. Это означает, что каждому чипу требуется 8 контактов только для передачи данных; однако пара чипов использует одни и те же выводы, поэтому только 64 из 240 отвечают за обмен данными. Остальные 176 контактов необходимы для синхронизации и передачи адресов данных (места расположения данных в модуле), управления микросхемами и обеспечения их электроэнергией. Так вы можете убедиться, что наличие более 240 контактов не обязательно улучшит ситуацию.

ОЗУ не единственное, что подключено к процессору

Для повышения производительности системная память подключена напрямую к центральному процессору, но на материнской плате есть и другие разъемы, подключенные примерно так же и в тех же целях. Они используют технологию подключения PCI Express (сокращенно PCIe), и каждый современный ЦП имеет встроенный контроллер PCIe.

Эти контроллеры могут обрабатывать несколько соединений (обычно называемых линиями), даже несмотря на то, что это система точка-точка что означает, что линии в разъеме не используются совместно с каким-либо другим устройством. В нашем примере контроллер PCI Express имеет 16 линий.

На изображении ниже показаны 3 разъема: два верхних это PCI Express, нижний гораздо более старая система под названием PCI (родственная PCIe, но намного медленнее). Маленький слот сверху, обозначенный как PCIEX1_1, имеет одну линию; тот, что ниже, 16 линий.

Если вы проскроллите вверх и снова взглянете на материнскую плату целиком, вы увидите, что у нас есть:

• 2 разъема PCI Express на 1 линию;

• 3 разъема PCI Express на 16 линий;

• 2 разъема PCI.

Но если у контроллера ЦП всего 16 линий, то что тогда происходит? Прежде всего, к процессору подключены только PCIEX16_1 и PCIEX16_2, а третий и два однолинейных подключены к другому процессору на материнской плате (подробнее об этом чуть позже). Кроме того, если задействованы оба разъема на 16 линий PCIe, ЦП выделит каждому только по 8 линий. Это типично для всех современных процессоров: количество линий у них ограничено, и по мере того, как к ЦП подключается все больше устройств, на каждое выделяется все меньшее число линий.

Различные конфигурации процессора и материнской платы имеют собственные способы решения этой проблемы. Например, материнская плата Gigabyte B450M Gaming имеет один разъем PCIe на 16 линий, один PCIe на 4 линии и один M.2, использующий 4 линии PCIe. Поскольку ЦП имеет всего 16 линий, использование любых двух разъемов одновременно приведет к тому, что самый большой слот, 16-тилинейный, будет ограничен всего до 8 линий.

Так что же использует такие разъемы? Наиболее распространенные варианты:

• 16 линии видеокарта;

• 4 линии твердотельные накопители (SSD);

• 1 линия звуковые карты и сетевые адаптеры.

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

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

Теперь двинемся через мост на юг

Глядя на материнские платы 15-тилетней давности, можно заметить, что в них было встроено два дополнительных чипа для поддержки процессора. Вместе они назывались набором микросхем, а по отдельности чипами северного (NB) и южного моста (SB). Первый обрабатывал системную память и видеокарту, второй данные и инструкции для всего остального.

На фото выше показана материнская плата ASRock 939SLI32, где четко видны микросхемы NB и SB. Они обе скрыты под алюминиевыми радиаторами, но ближайшая к разъему ЦП в середине изображения это и есть северный мост. Спустя несколько лет после выхода этой платы и Intel, и AMD откажутся от использования NB и выпустят продукты, в которых NB интегрирован в ЦП. Южный мост, однако, остается отдельным, и, скорее всего, это не изменится в обозримом будущем. Интересно, что оба производителя процессоров перестали называть его SB и теперь часто зовут его просто чипсетом (собственное название Intel PCH, блок контроллеров платформы) несмотря на то, что это один чип.

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

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

• 8 линий PCI Express (версия 2.0 PCIe);

• 14 портов USB (6 для версии 3.0, 8 для версии 2.0);

• 6 портов Serial ATA (версия 3.0).

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

В данном случае это процессор, обрабатывающий слоты PCIe с одной линией, третий слот с 16 линиями и слот M.2. Как и многие новые чипсеты, он обрабатывает все эти различные соединения с помощью набора высокоскоростных портов, которые можно переключить на PCI Express, USB, SATA или сетевое соединение, в зависимости от того, что подключено в данный момент. Это, к сожалению, накладывает ограничение на количество устройств, подключенных к материнской плате, несмотря на наличие всех этих разъемов.

В случае нашей материнской платы Asus порты SATA (используемые для подключения жестких дисков, DVD-приводов и т. д.) из-за этого ограничения сгруппированы так, как показано выше. Блок из 4 портов посередине использует стандартные USB-соединения чипсета, тогда как два слева используются некоторые из этих высокоскоростных соединений. Так что, если вы используете те, что слева, на чипсете будет меньше соединений для других разъемов. То же самое и с портами USB 3.0. В них есть поддержка до 6 устройств, но 2 порта обязательно будут подключены к высокоскоростным соединениям.

Разъем M.2, используемый для подключения SSD-накопителя, также использует быструю систему (вместе с третьим слотом PCI Express на 16 линий на этой материнской плате); однако в некоторых комбинациях ЦП и материнской платы разъемы M.2 подключаются непосредственно к ЦП, поскольку многие новые продукты имеют более 16 линий PCIe.

Слева на нашей материнской плате есть ряд разъемов, обычно называемых блоком ввода/вывода, и в данном случае микросхема южного моста обрабатывает только некоторые из них:

• Разъем PS/2 для клавиатур и мышей (сверху слева);

• Разъем VGA для недорогих и устаревших мониторов (сверху посередине);

• Порты USB 2.0 черные (снизу слева);

• Порты USB 3.0 синие (снизу посередине).

Встроенный графический процессор ЦП обрабатывает разъемы HDMI и DVI-D (внизу в центре), а остальные управляются дополнительными микросхемами. На большинстве материнских плат есть множество дополнительных маленьких процессоров для управления всевозможными разъемами, поэтому давайте взглянем на некоторые из них повнимательнее.

Дополнительные фишки для дополнительной помощи

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

Рассматриваемая нами материнская плата Asus не исключение. Например, микросхема Nuvoton NCT6791D обрабатывает все маленькие разъемы для кулеров и датчики температуры на плате. Расположенный рядом процессор Asmedia ASM1083 управляет двумя устаревшими разъемами PCI, поскольку у чипа Intel Z97 такой возможности нет.

Хоть у чипсета Intel и есть встроенный сетевой адаптер, но он нагружает столь драгоценные высокоскоростные соединения, поэтому Asus добавила еще один чип Intel (I218V) для управления красным разъемом Ethernet, который мы видели в блоке ввода/вывода. На изображении выше не видно, насколько мал этот чип: его площадь составляет всего 0,24 дюйма (6 мм).

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

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

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

Эти маленькие микросхемы представляют собой переключатели PCI Express и помогают процессору и южному мосту управлять 16-линейными разъемами PCIe, когда им необходимо распределить полосы между несколькими устройствами.

Материнские платы с возможностью разгона процессоров, чипсетов и системной памяти теперь стали обычным явлением, и многие из них поставляются с дополнительными интегральными схемами для управления этими функциями. В нашем примере платы, выделенной красным, Asus использует собственную конструкцию, называемую TPU (TurboV Processing Unit), которая регулирует тактовые частоты и напряжения.

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

На каждой материнской плате есть по крайней мере одно устройство флэш-памяти, и оно предназначено для хранения BIOS (базовой операционной системы инициализации оборудования, которая запускает все перед загрузкой Windows, Linux, macOS и т. д.).

Этот чип Winbond имеет объем памяти всего 8 МБ, но этого более чем достаточно для хранения всего необходимого ПО. Этот вид флэш-памяти имеет очень малое энергопотребление при использовании и надежно хранит данные в течение десятилетий.

При включении ПК содержимое флэш-памяти копируется непосредственно в кэш ЦП или системную память, а затем запускается оттуда. Единственное, с чем это не сработает, это время.

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

Кстати о питании для него тоже есть отдельные разъемы.

Игорь, принеси мне питание!

Чтобы обеспечить материнскую плату и подключенные к ней устройства необходимым напряжением, блок питания (PSU) имеет ряд стандартных разъемов. Основной из них 24-контактный разъем ATX12V версии 2.4.

Величина тока зависит от блока питания, но промышленные стандарты напряжения составляют +3,3, +5 и +12 В.

Основная часть питания ЦП поступает от 12-вольтных контактов, но для современных высокопроизводительных систем этого недостаточно. Чтобы обойти эту проблему, существует дополнительный 8-контактный разъем питания, обеспечивающий еще четыре 12-вольтных линии.

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

Линии +3,3, +5 и +12 В подают питание на различные компоненты на самой материнской плате, а также ЦП, DRAM и любые устройства, подключенные к разъемам, таким как USB-порты или PCI Express. Однако все, что использует порты SATA, требует питания непосредственно от блока питания, а разъемы PCI Express могут обеспечить напряжение только до 75 Вт. Если устройству требуется больше энергии, например, как многим видеокартам, то их также необходимо подключить напрямую к блоку питания.

Однако есть и более серьезная проблема, чем наличие достаточного количества выводов на 12 В: процессоры не работают от этого напряжения.

Например, процессоры Intel, совместимые в нашей материнской платой Asus Z97, работают с напряжением от 0,7 до 1,4 В. Это не фиксированное напряжение, поскольку современные процессоры меняют его для экономии энергии и уменьшения нагрева, и в спящем режиме процессор может потреблять менее 0,8 В. Затем, когда все ядра полностью загрузятся и начнут свою работу, оно возрастает до 1,4 В и более.

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

Каждый VRM обычно состоит из 4 компонентов:

• 2 MOSFET сильноточные управляющие транзисторы (синие);

• 1 дроссель (фиолетовый);

• 1 конденсатор (желтый).

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

VRM обычно управляются отдельной микросхемой, которая контролирует устройство и переключает модули в соответствии с требуемым напряжением. Такие схемы называются многофазными контроллерами широтно-импульсных модуляторов; Asus именует их EPU. Такие вещи сильно нагреваются при работе, поэтому их часто накрывают металлическим радиатором, который помогает рассеивать ненужную энергию.

Даже стандартный настольный процессор, такой как Intel i7-9700K, может потреблять ток более 100 А при полной загрузке. VRM очень эффективны, но они не могут изменять напряжение без потерь. Принимая во внимание большой ток потребления, вы получаете отличное устройство для гриля.

Если снова взглянуть на фотографию нашей платы, можно увидеть пару VRM для модулей DRAM, но, поскольку напряжения там гораздо меньше, чем на ЦП, они не так сильно нагреваются (и поэтому радиатор не нужен).

И прочие назойливые мелочи

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

Здесь у нас есть:

• 1 мягкий выключатель питания;

• 1 кнопка сброса;

• 2 светодиодных разъема;

• 1 разъем для динамика.

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

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

Большинство материнских плат имеет аналогичный набор дополнительных разъемов, как показано выше слева направо:

• Разъем аудиопанели если в корпус ПК встроены разъемы для наушников/микрофона, то их можно подключить к встроенному звуковому чипу;

• Цифровой аудиоразъем такой же, как и обычный аудиоразъем, но для S/PDIF;

• Перемычка сброса BIOS позволяет сбросить BIOS до заводских настроек. Также за ним спрятан разъем термозонда;

• Разъем Trusted Platform Module используется для повышения безопасности материнской платы и системы.

• Разъем последовательного порта (COM) древний интерфейс. Кто-нибудь вообще им пользуется? Кто-нибудь?

Также наклеены, но не показаны, разъемы для кулеров и дополнительных USB-портов. Не каждая материнская плата поддерживает все это, но многие.

Соединяя все вместе

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

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

Простые и дешевые материнские платы могут иметь только 4 слоя, но сегодня большинство из них имеет 6 или 8 однако добавление большего количества слоев не улучшает ситуацию автоматически. Нужно уметь их правильно расположить, и важно держать их разделенными и изолированными, чтобы они не мешали друг другу.

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

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

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

В заключение

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

Всем привет! На связи Антон Баширов, разработчик из ИТ-кластера Ростелекома. Импортозамещение набирает обороты, а российский софт всё глубже проникает в нашу повседневную ИТ-шную сущность бытия. Процессоры Эльбрус и Байкал становятся более востребованными, комьюнити расширяется, но мысли о необходимости портировать весь наш любимый технологический стек на неизведанную архитектуру E2K звучат страшнее рассказов про горящий в пламени production-кластер.

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

Итак, гость в студии база данных Reindexer, разработка нашего ИТ-кластера.

Стоит сказать, почему выбор пал именно на Reindexer, а не другую БД. Во-первых, всеми любимый и известный Postgres уже есть в составе пакетов ОС Эльбрус. Переносить его нет необходимости. Во-вторых, наш гость уже прошел испытания на ARM, следовательно, пришло время ему покорить Эльбрус.

Стоит упомянуть, что Reindexer появился на свет как продуктвыбора между Elastic и Tarantool. Это определенно хочется попробовать завести на отечественном процессоре.

День 0. Знакомство с гостем

Несколько слов про нашего гостя:

Имя:NoSQL in-memory database Reindexer с функционалом полнотекстового поиска
Возраст:на момент испытаний версия БД была 3.1.2
Происхождение:Россия
Место рождения:пытливый ум разработчика Олега Герасимова@olegator99
Место жительства:https://github.com/Restream/reindexer
Место работы:Ростелеком
Строение:основная составляющая C++, имеются примеси из языка Ассемблера и немного CMake
Особенности:- Ассемблерные вставки;
- Много С++11 и C++14;
- Используются корутины.

Деятельность:- Хранение данных в памяти и на диске;
- Выполнение SQL запросов со скоростью 500K queries/sec для PK запросов;
- Выполнение запросов типа full-text search (почти как Elastic, только не тормозит);
- Работа в режиме server и embedded;
- Общение с крутыми парнями: Go, Java, Rust, .NET, Python, C/C++ и (да простит меня Хабр) PHP.

Заскучали? На этом нудная часть закончилась. В эфире рубрика Ээээксперименты!

День 1. А ты думал, в сказку попал?

Для начала попробуем нашего друга собрать из того, что есть.Идем на тестовый сервер Эльбрус 8C с ОС Эльбрус 6.0.1, клонируем туда репозиторий и запускаем CMake.

Хорошие новости, мы нашли компилятор! Новость действительно хорошая, ведь у Эльбруса свой компилятор LCC.

К счастью, создатели Эльбрус сделали LCC полностью совместимым с GCC и наши любимые нативные программки и сборщики смогут чувствовать себя хорошо без особых манипуляций. LCC уже сделал за вас нужные линки:gcc -> /opt/mcst/bin/lcc*.

Но вернемся к нашему гостю и тому, что не понравилось CMake.

В скриптах сборки, в CMakeLists.txt выполняется определение операционной системы и архитектуры процессора, на которой собирается Reindexer. Нужно это для того, чтобы подключать правильные исходники ассемблера, ведь как говорится Write once, run anywhere.

Разумеется, на момент написания скриптов никто не знал про процессоры Эльбрус, поэтому наш скрипт и упал. Исправляем.

Программисты люди ленивые, поэтому:

Попытка 2:

А что так можно было? На самом деле да для того, чтобы завелся CMake, этого было достаточно. Теперь ударим в бубен и запустимmake -j8:

Для тех, кто уже успел поработать с кроссплатформенным софтом, не новость, что С/С++ код с помощью макросов разделяют на платформозависимые секции.

Поэтому, в некоторые места кода Reindexer понадобилось добавить парочку новых условий для__E2K__и__LCC__:

После колдовства с макросами нас ждал монстр пострашнее:

Вот что бывает, когда игнорируешь messages у CMake.

Из-за того, что CMake не нашел подходящих исходников, компилятор не смог найти реализации двух функций:jump_fcontextиmake_fcontext. Про назначение этих функций я расскажу чуть позже, а пока что давайте успокоим нашего гостя и подсунем ему пару пустышек:

Этих операций оказалось достаточно, чтобы Reindexer собрался.

Поздравляю, у вас двойня!

Вот они, наши два долгожданных файла:

# file reindexer_serverreindexer_server: ELF 64-bit LSB executable, MCST Elbrus, version 1 (GNU/Linux

# file reindexer_toolreindexer_tool: ELF 64-bit LSB executable, MCST Elbrus, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux.so.2, for GNU/Linux 2.6.33, with debug_info, not stripped

Это можно считать успехом. Мы смогли собрать наш первый Эльбрус-бинарник. Даже два бинарника: reindexer_server и reindexer_tool.

Подведем итоги. Чтобы собрать Reindexer, мы:

• Поправили CMake-скрипты;

• Добавили несколько условий в макросы препроцессора;

• Заглушили ASM функции.

День 3. Наш Гость, попав на Эльбрус, начал подавать признаки жизни

Первый запуск прошел успешно - сервер поднялся, и даже открылся web-ui.

Я привык не останавливаться на достигнутом и решил немного поработать над Reindexer.

Результат меня порадовал - Гость устал и прилег отдохнуть:

Такое поведение наблюдалось только на Эльбрус. На i5 все работало штатно.

Давайте разбираться. Вооружившись отладчиком (gdb кстати под E2K работает прекрасно) и CLion, мне удалось докопаться до истины.

Пару запросов к Reindexer смогли воспроизвести ошибку:

Падает в деструкторе. Интересный момент - упало на free (в данном случае free реализуется через jemalloc). Видимо, здесь идет высвобождение памяти по некорректному указателю. Ошибку эту я исправлял в два этапа:

1. work around - дело в том, что QueryEntry лежит в объекте ExpressionTree, в самом классе примечательного я не нашел, поэтому копнул в сторону родителя. Оказалось, что до вызова деструктора был вызван вот такой копирующий конструктор, в котором есть интересный MakeDeepCopy(), реализованный с помощью библиотечкиmpark-variant.

   Подробнее про expression tree рассказываюттут.

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

   

   Итог - оно заработало.

2. TODO: Исправление тоже есть, но рассказ про него уже выходит за рамки данной статьи. Небольшой спойлер (код из mpark-variant с патчем под e2k):

inline constexpr DECLTYPE_AUTO visit(Visitor &&visitor, Vs &&... vs)#ifdef E2K //Fix for Elbrus    -> decltype(detail::visitation::variant::visit_value(lib::forward<Visitor>(visitor),                                                 lib::forward<Vs>(vs)...))    {     return detail::visitation::variant::visit_value(lib::forward<Visitor>(visitor),                                                 lib::forward<Vs>(vs)...);    }#else    DECLTYPE_AUTO_RETURN(        (detail::all(             lib::array<bool, sizeof...(Vs)>{{!vs.valueless_by_exception()...}})             ? (void)0             : throw_bad_variant_access()),        detail::visitation::variant::visit_value(lib::forward<Visitor>(visitor),                                                 lib::forward<Vs>(vs)...))#endif

День 5. Он ожил! Ну почти

Сервер у нас, действительно, работает, даже удалось получить первые результаты бенчмарков.

Но все это время я упорно игнорировал один компонент.

Помните, как мы убрали завязку на ASM и функцииmake_fcontext и jump_fcontext?

Так вот, ASM исходники в Reindexer нужны для реализации C++ корутин, а эти функции - ключевые для корутин из библиотеки boost/context.

Корутина это функция, которая может быть приостановлена и возобновлена в любой момент. Для реализации достаточно трех основных компонентов:
- функция
- механизм для ее паузы (suspend)
- механизм для возобновления ее с той точки, в которой была сделана пауза (resume).

Реализацию корутин можно увидеть в таких языках и библиотеках, как:

• Libcoro(корутины на C/С++)

• Koishi(тоже корутины, тоже на С/С++)

• Boost(и это тоже корутины, тоже на С/С++, корутин много не бывает!)

• Node-fibers(корутины для NodeJS на базе libcoro)

• Tarantool(fibers на базе libcoro)

• Kotlin(свои корутины, не на C++)

• C++20

• Goroutine

Для наглядности вот скрин теста корутин из Koishi:

Последовательность следующая:

1. Создали корутину, выделили стек, задали функцию;

2. Возобновили корутину - в этот момент вызвалась наша функция;

3. Приостановили корутину с помощьюkoishi_yield здесь мы вернули управление в test1 сразу после строчкиkoishi_resume;

4. Если мы еще раз сделаемkoishi_resumeна нашей корутине мы вернемся на строчку функции cofunc1 сразу после первого вызоваkoishi_yield.

Без корутин не будет работать reindexer_tool, но не можем же мы оставить Reindexer без такой важной конечности. Будем исправлять.

Начнем с анализа ситуации. Ожидаемо, что ASM Эльбруса бустовские корутины не поддерживают (пока что), а значит нам нужно реализовать их самим. Подробности и реализацию бустовских корутин можете посмотретьздесь, а сейчас наступило время скрещивать ужа с ежом.

Есть несколько вариантов реализовать корутины:

• Вариант 1:написать ASM реализацию. Самый очевидный, но при этом самый сложный вариант. У нас есть в планах попробовать именно этот вариант, так как ASM корутины - самые быстрые.

• Вариант 2: забить. Нет, это не наш путь.

• Вариант 3: использовать библиотеку.

По счастливой случайности Koishi оказалось той самой библиотекой, поддерживающей реализацию корутин с помощью встроенных E2K функций:makecontext_e2k()иfreecontext_e2k().

Там, где стандартная медицина бессильна, в дело вступает генная инженерия.

Для начала внедрим Koishi в организм Reindexer:

Заменим больной орган на здоровый:

Стараемся не повредить то, что уже работает:

Одним из backend-ов Koishi для корутин выступает fcontext (те же самые boost исходники, что в Reindexer). Последуем древней мудрости работает не трогай! и оставим как есть в случае, если у нас не E2K архитектура. Для Эльбруса мы будем использоватьucontext_e2k.c

И вот он, наш мутант с корутинами полностью здоров и функционален (и на amd64, и на E2K):

День 11. Проводим финальные испытания

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

Всего в Reindexer около 300 функциональных тестов, и мне не терпится запустить их все.

Тесты бежали, бежали и не добежали. Один из тестов вызвал Segmentation Fault.

Всему виной оказались вот эти строчки:

struct ConnectOpts {  /* тут тоже код, но он не такой интересный */  uint16_t options = 0;  int expectedClusterID = -1;};

Обычный код, что тут такого? скажете вы. Но не все так просто. Запоминаем, что здесь два поля, которые инициализируются при объявлении.

Попробуем воспроизвести на изолированном более простом примере.

ASM, настало твое время

Внимание на скриншот:

Ошибка проявляется именно в том случае, когда отсутствуют не проинициализированные поля. Другими словами, если все ваши поля инициализируются при объявлении вы счастливчик, поймавший Segmentation Fault.

Баг заключается в том, что скомпилированное создание структуры выглядит как странныйaddd. Именно эта строчка и вызывает segfault. Кстати, если вместоbool anyField = falseнаписать простоbool anyField, то код совершенно другой и ошибки нет.

Семь бед, один ответ обновитесь!

Разгадка тайны оказалась проста. На момент работы с Reindexer последней версией компилятора LCC была v.1.25.16, однако в состав пакетов ОС Эльбрус по умолчанию входит 1.25.14, на котором я и запускал тесты. Добрые люди из сообщества подсказали нам, что уже в 15 версии данный баг был исправлен. Я решил обновиться на 16-ую и посмотреть, что будет.

Вот что нам принес новый компилятор LCC v.1.25.16:

C++ код такой же, однако ASM совсем другой, и что самое главное он работает! Последовательно (заранее прошу прощения за мой ломаный asm-русский переводчик):

1. gestp - выделяем стек и кладем его в %dr3

2. setwd - задаем текущее окно в регистровом файле

3. setbn - задаем подвижную базу регистров в текущем окне регистрового файла

4. addd - кладем "дно" стека (стек размером 0x20) в %dr2

5. addd - выделяем на стеке нашу структуру

6. ldb - достаем из констант наш false и кладем его в %r5

7. stb - кладем наш false из регистра %r5 в наше поле anyField1

8. addd - подготовили локальный указатель на структуру для вызова метода

9. addd - передаем указатель в базовый регистр для передачи при вызове anyMethod (в anyMethod мы достаем указатель из регистра %dr0)

10. disp - подготавливаем регистр перехода на anyMethod

11. call - вызываем anyMethod

Дальше все просто пересобрать, перезапустить, обрадоваться.

Тесты прошли успешно, и теперь у нас есть полностью рабочий и протестированный Reindexer на Эльбрусе.

На этом все ?

На самом деле нет. Сейчас мы смогли:

• собрать Reindexer Server

• запустить Reindexer Server

• собрать Reindexer Tool

• запустить Reindexer Tool

• переписать кусочек Reindexer Tool

• уронить Reindexer и поднять его

• добиться 100% проходимости Reindexer тестов

Мы научились:

• собирать C++ софт на Эльбрус

• переписывать C++ софт под особенности и отличия Эльбрусов

• разбираться в ASM E2K

• превозмогать трудности

• разбираться в C++ корутинах даже на Эльбрусе

Что в планах:

• корутины на ASM E2K (может быть даже сравнить fcontext ASM на i5 и ucontext/ASM на E2K)

• оптимизировать Reindexer под архитектуру Эльбрус

• перенести еще несколько интересных приложений на Эльбрус

• дополнить базу библиотек и пакетов Эльбрус

• организовать E2K инфраструктуру и песочницу

Что же можно сказать про Эльбрус со стороны простого разработчика?

Эльбрус это ваш друг. Он уже умеет в 80% современного софта, работать с ним можно и достаточно комфортно. Его архитектура - действительно произведение искусства, идея одноядерного параллелизма достойна уважения и несет в себе большой потенциал. Вопрос лишь в том, получится ли его раскрыть.

На сегодня это всё, что хотелось бы вам рассказать, но я еще вернусь с новыми интересными подробностями про портирование и оптимизацию, и да прибудет с вами сила Эльбруса!

В последнее время всё чаще появляются статьи о производительности российских процессоров Эльбрус на различных задачах. Тема криптографии пока что остаётся за кадром, хотя в разное время были упоминания то о высоких возможностях Эльбруса (некий ГОСТ лучше в 9 раз на Эльбрус-4С, чем на Intel Core i7-2600), то о плохой оптимизации компилятора и, соответственно, крайне низкой скорости реализованных алгоритмов (Кузнечик в 100 раз медленнее, чем на Intel?). Предлагаю наконец разобраться, что может Эльбрус, на примере двух ГОСТ алгоритмов симметричного шифрования.

Чтобы статья не вышла слишком большой, будем считать, что читатель имеет общее представление об архитектурах процессоров, в том числе знает об Эльбрусе. Если же нет, на сайте разработчика (компании МЦСТ) есть отличное руководство по программированию и книга об архитектуре в целом. Именно с этих материалов и началось моё знакомство с Эльбрусами. Также отмечу, что в современных процессорах очень много различных механизмов и особенностей, так что в статье буду касаться только тех, которые, на мой взгляд, важны при реализации выбранных алгоритмов.

Что может предложить архитектура Эльбрус

Для выполнения арифметических операций у Эльбруса есть 6 АЛУ (арифметико-логических устройств), способных выполнять операции параллельно. Начиная с версии 5 архитектуры появилась поддержка упакованных (SIMD) инструкций над 128-битными регистрами.

Для хранения промежуточных результатов присутствует большой регистровый файл: суммарно в процедуре можно использовать более 200 (64-битных) регистров общего назначения. Для SIMD вычислений используются те же самые регистры, а не отдельные, как это часто бывает. Соответственно, с 5 версии архитектуры все регистры стали 128-битными.

Задачу симметричного шифрования можно отнести к потоковой обработке массива данных. Для таких ситуаций в Эльбрусе есть механизм асинхронной подкачки данных из памяти APB (Array Prefetch Buffer). Использование этого механизма позволяет вовремя подгружать данные из памяти, не теряя время на кэш-промахи.

Выбор реализаций

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

Правда, о производительности ГОСТ алгоритмов обычно говорят только в контексте семейства x86-64, другие архитектуры мало кого интересуют. Но это не беда: мне показалось, что при знании команд ассемблера x86-64 ознакомиться с набором целочисленных и логических инструкций Эльбруса проще, чем, скажем, с ARM-овым. То есть прослеживаются определённые параллели, особенно, в области SIMD инструкций, и даже прямые аналоги. В остальном, конечно, у них нет ничего общего.

Итак, для Магмы известна эффективная реализация режимов, допускающих параллельную обработку блоков, то есть когда несколько блоков могут шифроваться независимо друг от друга. Это, например, режимы ECB, CTR, MGM. При этом скорость конкурирует с AES, для которого на x86-64 есть аппаратная поддержка. Реализация заточена именно под параллельную обработку, в случае последовательной (режимы с зацеплением) используются другие подходы. Мне интересно добиться максимальной скорости, поэтому я ограничился только случаем параллельной обработки.

С Кузнечиком немного проще: лучшие результаты что при последовательной, что при параллельной обработке даёт одна и та же реализация её и берём.

Тестовые машины

Магма

В случае x86-64 быстрая реализация Магмы опирается на использование расширений AVX и AVX2. При этом учитывается наличие в процессоре нескольких АЛУ и возможность параллельного исполнения до 3 векторных инструкций за один такт. Естественно, планирование параллельного исполнения остаётся на откуп процессора.

В случае же Эльбруса есть возможность явно распланировать параллельное исполнение. Опуская некоторые детали, можно считать, что на 3 и 4 поколении возможно исполнить 6 целочисленных векторных операций над 64-битными регистрами, а начиная с 5 поколения 4 векторных операции уже над 128-битными регистрами.

Для Эльбруса я написал собственную реализацию Магмы. Она использует те же идеи, что и исходная под x86-64, но при этом адаптирована под другой набор инструкций. Рассматривал перспективу написания на ассемблере и даже пробовал, но довольно быстро осознал, что ассемблер у Эльбруса достаточно сложный в плане программирования на нём (например, есть много нюансов по размерам задержек и зависимостям инструкций, которые тяжело учесть вручную). При этом оптимизирующий компилятор делает свою работу действительно хорошо: переставляет инструкции в рамках большого окна и при подборе опций компиляции выдаёт плотность кода, которая не отличается от теоретических оценок на количество инструкций и тактов. Так что я остановился на реализации на языке Си с использованием intrinsic функций для доступа к некоторым инструкциям процессора.

Для измерения скорости был выбран режим ECB. Обычно именно он (или даже его упрощения) используется при сравнении производительности, а скорость других режимов можно оценить на базе полученных результатов, отличия несущественны. Речь идёт о реализации базового алгоритма шифрования, поэтому накладные расходы от смены ключа также не учитываются. Объём данных для замера порядка 1 ГБ. Естественно, шифрование на одном ядре. Для многоядерной машины можно умножить результат на количество ядер и получить близкую к реальности оценку скорости. По крайней мере, во всех сравнениях я видел именно такую зависимость. Полученные результаты в таблице ниже:

Здесь под выровненными данными подразумевается выравнивание по границе 8 байтов для E2Kv3/E2Kv4 и 16 байтов для E2Kv5/E2Kv6. При наличии такого выравнивания (на версиях до 6) работает механизм APB и данные для шифрования эффективно подкачиваются из памяти. При этом с версии 6 APB уже не требует выравнивания данных, поэтому при любом расположении данных достигается максимальная скорость. Для невыровненных данных на предыдущих версиях архитектуры я не провёл достаточно исследований, так что значения в этом столбце таблицы можно считать нижней границей.

Для сравнения приведу результаты из статьи с описанием базовой реализации на Intel Core i3-7100 @ 3.9 ГГц. При использовании AVX 458 МБ/с, 8.1 такт/байт; AVX2 1030 МБ/с, 3.6 такт/байт. Так что по абсолютной скорости Эльбрус достаточно близок к современным процессорам Intel (это при значительной разнице в тактовой частоте!) и превосходит x86-64 с AVX в тактах более чем в 1.5 раза (для 3 и 4 поколения), а x86-64 с AVX2 в 1.3 раза (для 5 поколения).

Кузнечик

По сравнению с Магмой, структура Кузнечика является более сложной. Несмотря на то, что удалось декомпозировать нелинейное преобразование S, техники реализации, основанные на широком использовании SIMD-инструкций, пока что отстают от "классической" реализации со склеенным LS (линейным и нелинейным) преобразованием и таблицей предвычислений размером 64 КБ (упоминается в статье под именами с LS или более простое описание на Хабре).

В случае x86-64 Кузнечик эффективнее всего реализуется с использованием AVX-инструкций (удобно работать со 128-битными регистрами, так как длина блока и размер значений в таблице равны в точности 128 битам). При этом для вычислений адресов в таблице не удаётся воспользоваться эффективной адресацией Scale-Index-Base-Displacement (именование из статьи), так как в качестве Scale нужно значение 16, а максимально возможное 8. На Эльбрусе можно ожидать конкурирующих результатов за счёт большого кэша L1d (64 КБ) и наличия 4 АЛУ, обеспечивающих произвольный доступ к памяти (насколько мне известно, у абсолютного большинства процессоров x86-64 2 порта для загрузки данных).

Как и в случае с Магмой, для Кузнечика я написал отдельную реализацию на Си под Эльбрус, чтобы добиться максимальных результатов. Начиная с 5 версии архитектуры я явным образом использовал тип __v2di (см. e2kintrin.h в составе компилятора), чтобы быть уверенным, что получится использовать регистры как 128-битные.

Техника замера скорости полностью совпадает с уже описанным случаем Магмы, так что повторяться не буду. Только напомню, на всякий случай, что речь идёт о скорости на одном ядре. Почему-то у многих это вызывало вопросы и ещё чаще удивление.

Итак, в случае строго последовательной обработки данных:

Для сравнения результаты из статьи (лучшие из опубликованных) на Intel Core i7-6700 @ 4 ГГц 170МБ/с, 22.4 такт/байт. В отличие от Магмы, можно говорить о сопоставимой абсолютной скорости и преимуществе в тактах более чем в 2 раза.

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

С параллельной обработкой ситуация намного интереснее:

И традиционное сравнение с Intel Core i7-6700 @ 4 ГГц: на нём достигается 360 МБ/с, 10.6 такт/байт. В отличие от случая последовательной обработки, у E2Kv3 и E2Kv4 преимущество Эльбруса не такое большое, предположительно из-за того, что реализация обработки нескольких блоков вместе обладает более высокой степенью параллельности и планировщику на x86-64 легче справиться с выявлением независимых операций. А вот появление у 5 поколения Эльбруса 128-битных регистров и загрузок из памяти позволяет ему сохранить преимущество в тактах более чем в 2 раза.

Сравнивать E2Kv6 с i7-6700 оказалось несолидно, поэтому я взял ассемблерную реализацию режима ECB и провёл собственный замер. В статье с описанием результатов на i7-6700 данные шифруются на месте, без работы с памятью, поэтому у честного режима ECB результат чуточку хуже: на самом мощном из доступных мне процессоров Intel Core i7-9700K @ 4.7 ГГц вышло 411 МБ/с, 10.9 такт/байт. Эльбрус оказался быстрее, обеспечивая преимущество в тактах в 2.5 раза.

Заключение

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

За время изучения архитектуры Эльбруса у меня сложилось впечатление, что многие полезные инструкции исторически добавлялись для обеспечения работы двоичного транслятора, но ситуация изменилась с 5 версии: Эльбрус начал больше развиваться собственным путём. Эту положительную динамику невозможно не отметить.

С другой стороны, сложившаяся похожесть ряда инструкций упрощает разработку и оптимизацию под Эльбрус. Можно сказать, что эта статья предлагает простой способ портирования и оптимизации алгоритмов под Эльбрус: достаточно взять хорошо зарекомендовавший себя на Intel/AMD алгоритм и немного адаптировать его под Эльбрус. Я искренне верю, что в результате практически любой алгоритм должен работать по крайней мере не хуже, чем в разницу тактовых частот.

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

P.S.

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

Несмотря на то, что для получения описанных результатов мне удалось разобраться с Эльбрусом на основании только открытой информации и документации к компилятору, я хочу выразить благодарность сотрудникам МЦСТ, в особенности, Александру Трушу, за ответы на периодически возникавшие у меня вопросы и, конечно, за предоставление удалённого доступа к новым процессорам.