Не так давно екатеринбургская компания ОАО «Мультиклет» начала программу по активной популяризации своего микропроцессора, основанного на уникальной мультиклеточной архитектуре. Для продвижения микропроцессора компанией была разработана тестовая плата НW1-MCp04, которая вначале продавалась за нереальные 45 тыс. руб. Но сейчас ценник упал до 16 тыс. руб., и к тому же ОАО «Мультиклет» развернуло компанию по тестовому удаленному доступу к отладочной плате:
Я записался на тестирование по принципу "на всякий случай", не особенно расчитывая в нем участвовать. Но в конце концов поучаствовать мне все же удалось, о результатах я и отчитываюсь в данной статье.
Тема отечественной электроники мне очень интересна, и я пристально слежу за новостями в этой сфере по личным причинам. Я учился на кафедре микроэлектроники и полупроводниковых приборов в самый разгар перестройки, когда развалили всё что можно, а нового не построили. Интернета не было, а был полный информационный вакуум, немного разбавленный конференциями ФИДО. Упор в учебе делался только на теорию - математика, физика твердого тела, кристаллическая химия. По технологии разработки микросхем не было ни одного курса, и мы не знали ничего про Verilog, VDHL, библиотеки стандартных ячеек. Топологию микросхем предполагалось разводить "врукопашную", ни о какой автоматизации процесса речи не шло. Да вот, пожалуйста, пример из 2005 года такого же ВУЗа:
http://window.edu.ru/resource/332/26332/files/_7.pdf
читаем раздел "Проектирование топологии полупроводниковых ИМС". Хоть учебный материал уже и не перестроечный, а воз и ныне там, этакий привет из восьмидесятых.
В общем, как вы понимаете, по специальности я никогда не работал. Все практические знания ограничены пятёркой электронных самоделок, самые сложные из которых - самодельное светодиодное табло "бегущая строка" 64x8 на комплекте К580 и самодельная голосовая сигнализация в автомобиле с прошивкой оцифровки голоса в микросхемы К573РФ2. Но тема отечественной микроэлектроники мне близка, и я, что называется, душой болею за все события, которые происходят в этой сфере.
С самого начала все пошло не так. Я вынужден был отложить тестирование по причине срочной командировки, и екатеринбуржцы любезно пошли мне навстречу, перенеся время на неделю. В назначенный день, из идеи прийти после работы прямиком домой, конечно, ничего не получилось. Пришлось задержаться на работе, после чего бежать в поликлинику, потом на почту, в довершение всего на почте была забыта сумка, и пришлось возвращаться. В результате из отведенных мне 4-х часов я смог воспользоваться только двумя с половинкой.
Время на вдумчивое чтение документации я так и не нашел, только пару раз силой заставлял себя засунуть в мозги материалы с сайта multiclet.com. В тестировании меня больше интересовала производительность микропроцессора - в любых "попугаях", лишь бы было с чем сравнивать. Я расчитывал сделать тройку программ. Первую (естественно, с большим количеством итераций) для тестирования элементарных арифметические операций с целочислительными значениями, вторую - со значениями с плавающей точкой, а третья программа с тригонометрическими функциями должна была проверить по большей части не вычислительные возможности самого процессора, а качество математических библиотек. Такие же программы я хотел впоследствие запустить на имеющейся у меня Arduino Uno, чтобы получить сравнительную производительность Мультиклета в "Ардуинах ATmega328p". Понятно, что такое сравнение очень некорректно (и битность не та, и архитектура другая), но некоторое представление о производительности дать сможет.
Мультиклеточная архитектура - это начинающее сейчас развиваться направление в вычислительных системах. Традиционные микропроцессоры опираются на фон-нейманскую или гарвардскую архитектуру, в которой вычислительное устройство последовательно выполняет поток команд. Микропроцессор "Мультиклет" построен по так называемой пост-фон-нейманской архитектуре, в которой поток команд одновременно выполняется на нескольких вычислительных устройствах (клетках), и основной вопрос состоит в том, как распределять команды по клеткам. Впрочем, алгоритм распределения команд довольно прост, и его можно понять из следующих документов:
Концепция мультиклеточного процессора
Краткий обзор архитектуры
Говоря другими словами, в "Мультиклет" используется как явный параллелизм, задаваемый в машинном коде компилятором, так и "аппаратный" параллелизм, позволяющий эффективно распараллеливать код на клетки на аппаратном уровне в реальном времени (распарралеливание триад с ожиданием готовности данных).
Итак, начнем.
Удаленное подключение к стенду
Тестовый стенд представлял собой компьютер с операционной системой Linux, к которому подключена тестовая плата НW1-MCp04. Изначально не было информации, что за операционка стоит на стенде. Для подключения к стенду необходимо было использовать RDP-протокол, а в рекомендациях по подключению было написано следующее:
Для получения доступа Вам необходимо набрать в строке браузера:
https://тутнашIP/remacc/ляляля"
Для подключения к удаленному рабочему столу используется протокол RDP
На вопрос «Это значит что нужно заходить в Windows через браузер Internet Explorer? Уточните, пожалуйста, среду, в которой возможен вход», был ответ:
Пуск/все программы/стандартные/подключение к удаленному рабочему столу
Всё указывало на то, что тестирование будет проводиться в среде ОС Windows. Но по факту оказалось, что тестовая машина работает на Linux Fedora 18. А протокол RDP был выбран для того, чтобы обеспечить простое подключение Windows пользователей. Но так как у меня на домашнем компьютере Windows отсутствует, пришлось срочно разбираться, чем в Linux можно работать через RDP протокол.
В начале я попробовал подключиться через рекомендованное гуру Remmina. Но оказалось, что начиная с какого-то релиза в Remmina разломали декодирование картинки десктопа, поэтому человеческая работа была невозможна:
Увеличить
В принципе, консоль кое-как отрисовывалась (если не двигать окно), и ее было бы достаточно, но проблема в том, что было неясно, что вообще на этом стенде делать. Куда подключена плата? Где искать компиляторы? Есть ли тестовые примеры? Как оказалось, авторы заботливо положили на рабочий стол файл с говорящим названием read.me, но Remmina не могла отрисовать содержимое рабочего стола, и поэтому наличие этого файла не было вообще видно.
Поигравшись с настройками Remmina я понял, что правильно работать её не заставишь. Поэтому решил подключиться через rdesktop. Поначалу и им невозможно было прицепиться, так как по-умолчанию выставлялась русская раскладка (даже если в системе при запуске rdesktop стояла английская, раскладка, видимо, определялась по локали), а логин-пароль нужно было на английском набирать. Копи-паст не работал. При попытке переключить язык клавишами Shift+ALT выдавалась ошибка:
Решить проблему удалось с помощью явного указания языка в опциях:
rdesktop -k en-us -g 1024x768 <адрес>
После чего можно было увидеть нормальный рабочий стол и начать исследовать Multiclet. Серьезно мешающая проблема была только одна: через rdesktop не работал буфер обмена (в Remmina, кстати, работал), поэтому невозможно было оперативно записывать свои действия и быстро копипастить что-то из своих заготовок. Кое-как обошелся сервисом paste.bin.org (браузер работал, доступ в интернет был), но это было очень неудобно и в разы уменьшало производительность труда.
И еще одна проблема - в системе не был настроен переключатель раскладки, так что можно было писать только латинскими символами. Поэтому в специально созданой теме на Linux.Org.Ru мне приходилось писать транслитом, если я писал с удаленной машины.
Тестирование
Посмотрев первые пару примеров, я обнаружил, что они делают такие действия, которые невозможно удаленно проверить. Например, мигают лампочками на тестовой плате. Если бы к компьютеру была подключена веб-камера, направленная на плату, свои действия можно было бы увидеть воочию. Но вебкамеры небыло, поэтому протестировать Мультиклет можно было только передавая и получая байтики.
Я решил разбить тестирование на несколько этапов:
1. Протестировать факт что вообще работает флешер и прошивку можно загонять в плату Multiclet. Прошивку брать из тестового комплекта ПО;
2. Протестировать компилирование простого кода через компилятор и окончательную сборку бинарника;
3. Протестировать возможность заливки самостоятельно изготовленного на этапе 2 бинарника;
4. Протестировать возможность получения каких-нибудь байтов от платы;
5. Написать и протестировать примитивный эхо-сервер;
6. Написать и выполнить программу, передающую лог своей работы через порт;
7, 8, 9. Протестировать программы с целочислительной и вещественной арифметикой, протестировать тригонометрические функции.
Сразу скажу, что мне удалось добраться только до пункта 4.
Тестирование флешера прошло быстро и просто. Бинарники шустро закачивались на плату. В логе работы флешера ошибок не обнаруживалось. Так что я убедился, что плата живая, подключена к компьютеру, и прошивается. Как оказалось, это был преждевременный вывод, ибо дальше меня ждал сюрприз.
Тестирование компиляции в принципе прошло успешно. Для компиляции ненужно было пользоваться отдельно компилятором и отдельно линкером, так как в наборе ПО была готовая исполняемая программа mc-lcc, которая создавала бинарный файл. Пример команды компиляции следующий:
mc-lcc -v -target=mcp -Wp-I/usr/local/include/Multiclet/MCp0411100101/ -Wa--arch=MCp0411100101 -Wl-L/usr/local/lib/Multiclet/MCp0411100101/ -Wl-lmath -Wl-M -o image.bin /usr/local/lib/Multiclet/MCp0411100101/crt0.o example_01.c
Долго не мог понять, как скомпилировать программу, которая использует библиотеку UART:
#include <uart.h>
Ведь без нее ничего протестировать не получилось бы. Оказалось, что для компиляции надо было добавить опцию:
-Wl-luart
Решение простое и очевидное, тем более что в глубинах документации об этой опции было написано. Но по факту потратил на эту проблему много времени.
Но самый главный сюрприз меня ждал на третьем этапе, когда я попытался залить самостоятельно скомпилированную программу в Multiclet. Процесс заливки бинарника через программу mc-ploader доходил до 100% и шел далее. В какой-то момент происходил сегфолт и на этом все заканчивалось:
$ mc-ploader image.bin
info: selected device: "PicoTAP A"
info: erasing device: 100%
info: image loading: 1484%Segmentation fault (core dumped)
На этом примере видно, что залилось аж 1484% машинного кода. Я бился с этой проблемой, пока не решил самостоятельно скомпилировать стандартный пример с UART библиотекой и залить его в Multiclet. Оказалось, что даже стандартный пример после компиляции не заливается в Multiclet. А предкомпилированный кем-то бинарник с этим же примером заливается без проблем.
Как позже выяснилось, была какая-то проблема в Linux-флешере, и он мог корректно заливать только те бинарники, которые были созданы через компилятор, входящий в комплект SDK под Windows. Поэтому предкомпиленные бинарники примеров заливались нормально (они были собраны в Windows), а скомпилированные непосредственно в Linux - нет. Не сказать, чтобы вообще флешер не работал - ведь пару раз мне удалось залить свои бинарники. Но при каких обстоятельствах, и что повлияло на положительный результат заливки, я так и не понял. Позже авторы сообщили, что ошибка в Linux-загрузчике была исправлена, и была сделана краткая инструкция по сборке проекта.
В конечном итоге я добрался до четвертого этапа, и был готов к тому, чтобы начать получать байтики от Multiclet. Я смог скомпилировать и залить стандартный пример из документации, который после истечения некоторого времени отправляет в виртуальный COM-порт, под которым видится Multiclet, значение 0xAB:
#include <HDL51001_ccf.h>
#include <uart.h>
void pause(unsigned int a)
{
unsigned int i;
for(i=a;i>0;i--);
}
void main()
{
UART_InitTypeDef UART_InitStructure;
UART_InitStructure.BaudRate = 38400; //set baudrate
UART_InitStructure.TypeParity = 0x00000000; //parity control type
UART_InitStructure.Parity = 0x00000000; //enable parity control
UART_InitStructure.FlowControl = 0x00000000; //enable cts/rts
UART_InitStructure.Mode = 0x00000003; //rx enable - 1 bit, tx enable - 2 bit (rx + tx en)
GPIOB->BPS = 0x00000300; //alternative port function for uart0
uart_init(UART0, &UART_InitStructure);
DM2UART(UART0, 0x00000000, 0x00000800);
GPIOB->DIR = ((uint32_t)0x60000000);
GPIOB->OUT = ((uint32_t)0x60000000);
pause(10000);
UART_SEND_BYTE(0xAB, UART0);
}
Чтобы увидеть ответ от Multiclet, я воспользовался программой CuteCom, которая была обнаружена в Fedora. После настройки параметров порта, я увидел заветный байт:
Увеличить
Далее я начал делать эхо-сервер, но завершить его написание не успел, так как закончилось время тестирования. Позже сотрудники ОАО "Мультиклет" предложили еще раз выбрать время и поработать с платой. Но я отказался из-за дефицита свободного времени.
Результат
Результат тестирования следующий: российский микропроцессор Мультиклет и его отладочная плата реально существуют и работают. В настоящий момент дорабатываются инструменты разработчика, и они уже позволяют полноценно работать с платой. Учитывая, что проблемы оперативно решаются, можно сказать что мы видим инновационный и конкурентноспособный продукт, который обязательно займет достойное место в своей области применения.
Что касается нестабильно работающей процедуры заливки прошивки на плату Multiclet (который на момент написания статьи уже исправлен), я хочу сказать что в той же мегапопулярной Arduino дела под Linux обстоят не лучшим образом: в какой-то момент заливка перестает работать, и приходится совершать нетривиальные магические действия, чтобы флешер все-таки смог залить программу без перезапуска компьютера разработчика.
В любом случае хочу пожелать команде Мультиклет дальнейшего развития и совершенствования. Они большие молодцы, что разработали свою архитектуру и смогли ее воплотить в железе. Я очень рад, что архитектура работоспособна и опирается на глубокие научные познания коллектива разработчиков. Мультиклеточный микропроцессор показал свою состоятельность, и я желаю этому продукту широко выйти на российский и международный рынок, чтобы обеспечить получение прибыли, которая окупит и этап НИОКР, и этап разработки и все этапы производства. Ведь именно это мы понимаем под термином "инновационная экономика".