-
petrmikheev
-
 Автор темы
-
Не в сети
-
Новый участник
-
-
Сообщений: 19
-
Спасибо получено: 5
-
-
|
Добрый день.
Я сделал SoC на плате marsohod2.
Была поставлена задача выжать из платы производительность, достаточную для отображения 3д графики в реальном времени.
Рабочая частота 108MHz. Шестистадийный конвеер.
Архитектура относится к классу SIMD.
За один такт выполняется четыре 16-битных арифметических операции.
Пиковая производительность получается более чем в 10 раз выше, чем у
Amber SoC
на той же плате.
Поддерживаемая периферия:
VGA 640x480
Serial port
USB 1.1 (может грузиться с флешки)
2 х PS/2
Цель проекта заключалась в освоении работы с ПЛИС.
Разработанная SoC ни с чем не совместима и практической ценности не имеет.
Тем не менее, если кто-нибудь заинтересуется, могу выложить исходники (systemverilog), документацию по ассемблеру, компилятор (python), симулятор (qt) и демонстрационные программы.
|
|
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
|
-
Leka
-
-
Не в сети
-
Живу я здесь
-
-
Сообщений: 635
-
Спасибо получено: 54
-
-
|
petrmikheev пишет: ...для отображения 3д графики в реальном времени.
...SoC ни с чем не совместима
...компилятор (python)
А картинка на экране как тогда получена, программный код с нуля написан, без использования сторонних библиотек? Ведь если использовался сторонний код, это уже совместимость...
В какой мере поддерживается python? (Сам не знаю этот язык).
|
|
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
Последнее редактирование: от Leka.
|
-
petrmikheev
-
Автор темы
-
Не в сети
-
Новый участник
-
-
Сообщений: 19
-
Спасибо получено: 5
-
-
|
Не использовано ни сторонних библиотек, ни готовых HDL блоков. Всё написано с нуля, включая контроллер sdram и usb host. Используется своя, отдаленно напоминающая ARM, но ни с чем не совместимая система команд. Вывод графики реализован на ассемблере.
Если у меня появится вдохновение, то я когда-нибудь модифицирую lcc (компилятор си), чтобы он мог работать с этой архитектурой. Но сейчас -- только ассемблер.
Про компилятор, прошу прощения, неоднозначно написал. Это транслятор моего ассемблера в машинный код. А на python написан он сам.
|
|
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
|
-
Leka
-
-
Не в сети
-
Живу я здесь
-
-
Сообщений: 635
-
Спасибо получено: 54
-
-
|
petrmikheev пишет: система команд
Лично мне сейчас интересно было-бы взглянуть на краткое описание системы команд, тк довольно долго занимался самопальными процессорами. Остальное требует времени, которого нет (и есть много своих мелких разрозненных проектов, в которых хочется навести порядок, и собрать все в единую SoC - тогда загрузка/работа с USB-флешки заинтересует, но это нескоро...).
|
|
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
Последнее редактирование: от Leka.
|
-
petrmikheev
-
Автор темы
-
Не в сети
-
Новый участник
-
-
Сообщений: 19
-
Спасибо получено: 5
-
-
|
Вот
. Будет интересно услышать ваше мнение, как человека, занимавшегося подобным :)
|
|
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
|
-
Leka
-
-
Не в сети
-
Живу я здесь
-
-
Сообщений: 635
-
Спасибо получено: 54
-
-
|
Это векторный процессор, если правильно понял (сам не делал векторную архитектуру).
Думаю, тут важно дать простую и ясную программную модель, четко разделив скаляры и вектора.
Без этого сложно как программировать, так и анализировать архитектуру.
Например, ассемблерные строки из rhomb.S: loop_x: ADD tmp, X, Y
TST tmp, 16 - нельзя понять, где вектор, где скаляр, если не знать архитектурные особенности,
что r0 и r1 - вектора 4*16-бит, а r14 - 16-бит скаляр (если правильно понял): #define X r0
#define Y r14
#define tmp r1
|
|
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
|
-
petrmikheev
-
Автор темы
-
Не в сети
-
Новый участник
-
-
Сообщений: 19
-
Спасибо получено: 5
-
-
|
Leka пишет: - нельзя понять, где вектор, где скаляр, если не знать архитектурные особенности,
что r0 и r1 - вектора 4*16-бит, а r14 - 16-бит скаляр (если правильно понял):
Да, Вы правильно поняли.
Предполагается, что в основном работает блок PU0, а векторность используется только в немногих наиболее критичных по производительности местам (для графики -- цикл по пикселам в строке). Вытащить данные из регистров блоков PU1-PU3 можно только указав ключевое слово ALL при записи из регистров в кеш. Если "ALL" не использовать, то можно вообще забыть про векторность и работать с r0-r15 как со скалярными 16-битными регистрами. Регистры блоков PU1-PU3 при этом тоже будут меняться, но пока они не нужны, на это можно не обращать внимания.
Вообще Вы правы -- получилось не слишком понятно. Но это было сознательное решение -- увеличить производительность за счет удобства программирования. Можно это частично исправить, сделав более понятные defin-ы или изменив синтаксис ассемблера (к примеру, добавить к r0-r7 синонимы v0-v7). Но чтобы получить нужную производительность, без знания архитектурных особенностей в данном случае все равно не обойтись.
|
|
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
|
-
Leka
-
-
Не в сети
-
Живу я здесь
-
-
Сообщений: 635
-
Спасибо получено: 54
-
-
|
petrmikheev пишет: увеличить производительность за счет удобства программирования.
Производительность увеличивается за счет векторных операций. Насколько удобно программировать векторную архитектуру - совершенно другой вопрос.
Думаю, представление хорошо известной векторной архитектуры в виде нескольких процессорных блоков только затрудняет понимание и анализ, лучше рассматривать один векторный PU, без деления на PU0..PUn. Взять, например, 64х-разрядный скалярный процессор, умеющий работать с 8-16-32-64-разрядными данными - его принято рассматривать, как устройство с одним PU, а не с 8-ю.
|
|
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
|
-
petrmikheev
-
Автор темы
-
Не в сети
-
Новый участник
-
-
Сообщений: 19
-
Спасибо получено: 5
-
-
|
Здесь основное отличие от векторного процессора -- у каждого PU свой регистр флагов. Счетчик команд общий, но используя раздельные флаги и условное выполнение команд, можно легко реализовать логические конструкции внутри ускоряемого цикла.
Пример: for (int x = x1; i < x2; ++i) { // реализация буфера глубины при работе с графикой
int color = f1(x);
int depth = f2(x);
if (depth < depth_buf[x]) {
color_buf[x] = color;
depth_buf[x] = depth;
}
}Реализуется в ассемблере примерно так: MOV r8, x1
SUB r10, x2, 4
AND r0, IN_FLAGS, 3 // получить номер PU
loop:
ADD r1, r8, r0 // r1 = {r8, r8+1, r8+2, r8+3} -- в каждом PU будет использоваться свое значение Х
... // r2 = f1(r1)
... // r3 = f2(r1)
ADD r9, r8, COLOR_BUF_OFFSET
CMP r8, r10
JLT loop // после перехода еще 4 команды выполняется со старого адреса
CMP r3, [ALL r8] // сравнение может дать различный результат в разных PU
MOVLT [ALL r8], r3 // из 4-х последовательных ячеек [r8], [r8+1], [r8+2], [r8+3]
MOVLT [ALL r9], r2 // будут изменены только те, для которых f2(x)<depth_buf[x]
ADD r8, r8, 4 // счетчик цикла увеличивается сразу на 4При написании подобных конструкций мне удобнее думать в терминах нескольких исполняющих блоков, одновременно исполняющих один и тот же код.
|
|
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
|
Время создания страницы: 0.176 секунд
