Перейти к содержанию
    

Маленький процессор для Xilinx

А что не так с микроблэйзом - он конфигурируется под задачу и можно свести к достаточно компактному варианту. У "дефолтного" варианта правда есть проблема - он реально не работает на тех тактах что заявлены в бенче - например для ультракинтекс более менее работает на 125 МГц вместо 300. Если нужна замена автоматам на языке высокого уровня типа С/С++, то можно попробовать и HLS - конечно вещь в себе и не без проблем и фокусов на ровном месте. Соорудить автомат средней сложности с фиксированным числом тактов на цикл и работающий на 300 МГц для тех же ультракинтексов можно легко и быстро. Бонусом работа с axis, bram, slave axi lite и master axi. Из минусов то что любое изменение алгоритма потребует переразводки проекта.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

44 минуты назад, fguy сказал:

Из минусов то что любое изменение алгоритма потребует переразводки проекта.

Почему? Ведь есть возможность обновления кода прошивки в готовом bit-файле через updatemem.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

31 минуту назад, makc сказал:

Почему? Ведь есть возможность обновления кода прошивки в готовом bit-файле через updatemem.

Речь о HLS - изменив алгоритм работы ядра вам необходимо будет его пересинтезировать и соответственно пересобрать проект.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

On 10/1/2021 at 12:11 PM, MegaVolt said:

Задача - замена сложных автоматов на некий сопроцессор.

Можно просто разбить каждый сложный автомат на несколько простых, описав все на Верилоге одной "простыней", в "программистском" стиле.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

19 часов назад, fguy сказал:

А что не так с микроблэйзом - он конфигурируется под задачу и можно свести к достаточно компактному варианту.

По объему Микроблейз не идет ни в какое сравнение с Пикоблейзом, которых в самый маленький кристалл можно несколько штук запихать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А еще у микроблейза отвратительный компилятор. 

Единственный вызов printf обрамляется такой кучей сохранения/восстановления регистров, что это занимает сотню байт памяти программ. 

И это под максимальной оптимизацией! 

 

Жуть какая-то. Я знаю, конечно, что гнутый компилятор это поделка та еще, по сравнению с армовским, но что с микроблейзом все так запущено - никак не ожидал... :(

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

46 минут назад, sonycman сказал:

Жуть какая-то. Я знаю, конечно, что гнутый компилятор это поделка та еще, по сравнению с армовским, но что с микроблейзом все так запущено - никак не ожидал... :(

Это довольно спорное утверждение, т.к. из моей практики получается, что по плотности кода тестового проекта с размером выходного бинарника порядка 120 кБ на первом месте (меньший по объему бинарник) была сборка для Cortex-M3, следом с небольшим отрывом шла сборка для microblaze и далее с заметным отрывом сборка для RV32IMC. Всё собиралось gcc с -Os. Поэтому сравнивать нужно не на одной функции, а на проекте.

PS: что меня очень удивило, так это отставание RV32IMC, у которого C означает упаковку кода для оптимизации по размеру. Но эта упаковка оказалась весьма неэффективной в сравнении с Thumb2 у Cortex-M3.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

мысли в слух...

Thumb2 это 2 байта на команду (если не склероз), а в microblaze 4 байта на команду.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

42 минуты назад, Alex77 сказал:

мысли в слух...

Thumb2 это 2 байта на команду (если не склероз), а в microblaze 4 байта на команду.

Это всё понятно, но плотность кода не определяется только лишь числом байт на команду. И это как раз иллюстрирует мой опыт.

PS: посмотрите в качестве примера на VLIW, но там есть свои проблемы и их более чем достаточно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 hours ago, makc said:

Это довольно спорное утверждение, т.к. из моей практики получается, что по плотности кода тестового проекта с размером выходного бинарника порядка 120 кБ на первом месте (меньший по объему бинарник) была сборка для Cortex-M3, следом с небольшим отрывом шла сборка для microblaze и далее с заметным отрывом сборка для RV32IMC. Всё собиралось gcc с -Os. Поэтому сравнивать нужно не на одной функции, а на проекте.

Какой GCC версии? И какое отставание в процентах (хотя бы приблизительно)?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

VLIW в этом случае не применимо для сравнения. я ктому что при "условно одинаковом размере" кода в Cortex-M3 использовано больше процессорных команд, чем у microblaze. как вариант можно сказать что система команд microblaze лучшее.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 hours ago, makc said:

Это довольно спорное утверждение, т.к. из моей практики получается, что по плотности кода тестового проекта с размером выходного бинарника порядка 120 кБ на первом месте (меньший по объему бинарник) была сборка для Cortex-M3, следом с небольшим отрывом шла сборка для microblaze и далее с заметным отрывом сборка для RV32IMC. Всё собиралось gcc с -Os. Поэтому сравнивать нужно не на одной функции, а на проекте.

Может быть я просто не умею готовить микроблейз, но после вот такого кода, где при вызове мелкой функции запросто сохраняется два десятка регистров, у меня пропало всякое желание использовать его (просто взял корку Cortex-M3 из армового DesignStart, и дело в шляпе):

00000f64 <xil_printf>:
     f64:	f8a10004 	swi	r5, r1, 4
     f68:	f8c10008 	swi	r6, r1, 8
     f6c:	f8e1000c 	swi	r7, r1, 12
     f70:	f9010010 	swi	r8, r1, 16
     f74:	f9210014 	swi	r9, r1, 20
     f78:	f9410018 	swi	r10, r1, 24
     f7c:	3021ff90 	addik	r1, r1, -112
     f80:	fa610044 	swi	r19, r1, 68
     f84:	f9e10000 	swi	r15, r1, 0
     f88:	fac10048 	swi	r22, r1, 72
     f8c:	fae1004c 	swi	r23, r1, 76
     f90:	fb010050 	swi	r24, r1, 80
     f94:	fb210054 	swi	r25, r1, 84
     f98:	fb410058 	swi	r26, r1, 88
     f9c:	fb61005c 	swi	r27, r1, 92
     fa0:	fb810060 	swi	r28, r1, 96
     fa4:	fba10064 	swi	r29, r1, 100
     fa8:	fbc10068 	swi	r30, r1, 104
     fac:	fbe1006c 	swi	r31, r1, 108
     fb0:	f8a10038 	swi	r5, r1, 56
     fb4:	32610078 	addik	r19, r1, 120
     fb8:	e8610038 	lwi	r3, r1, 56
     fbc:	be03001c 	beqid	r3, 28		// fd8
     fc0:	e9e10000 	lwi	r15, r1, 0
     fc4:	e0a30000 	lbui	r5, r3, 0
     fc8:	90a50060 	sext8	r5, r5
     fcc:	be250040 	bneid	r5, 64		// 100c
     fd0:	aac50025 	xori	r22, r5, 37
     fd4:	e9e10000 	lwi	r15, r1, 0
     fd8:	ea610044 	lwi	r19, r1, 68
     fdc:	eac10048 	lwi	r22, r1, 72
     fe0:	eae1004c 	lwi	r23, r1, 76
     fe4:	eb010050 	lwi	r24, r1, 80
     fe8:	eb210054 	lwi	r25, r1, 84
     fec:	eb410058 	lwi	r26, r1, 88
     ff0:	eb61005c 	lwi	r27, r1, 92
     ff4:	eb810060 	lwi	r28, r1, 96
     ff8:	eba10064 	lwi	r29, r1, 100
     ffc:	ebc10068 	lwi	r30, r1, 104
    1000:	ebe1006c 	lwi	r31, r1, 108
    1004:	b60f0008 	rtsd	r15, 8

Оптимизация тоже Os. Странно, что размер кода не меняется при изменении опции оптимизации O1, O2, O3 или Os.

Может, какой-то баг компилятора?

Xilinx SDK 2019.1

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

57 минут назад, Raven сказал:

Какой GCC версии? И какое отставание в процентах (хотя бы приблизительно)?

Это было 2.5 года назад, поэтому могу ошибаться, но по-моему gcc был из серии 8.х для arm, а для микроба по-моему 7.х или вроде того.

26 минут назад, sonycman сказал:

Оптимизация тоже Os. Странно, что размер кода не меняется при изменении опции оптимизации O1, O2, O3 или Os.

Может, какой-то баг компилятора?

Да, очень странно. Но у gcc для МБ ещё есть ряд опций, ЕМНИП, которые определяют функциональность сгенерированного ядра и может быть дело в них.

1 час назад, Alex77 сказал:

VLIW в этом случае не применимо для сравнения.

Только поскольку Cortex-M и микроб не суперскалярные. Но по сути мы имеем тот же торг, что между CISC и RISC, у которых плотность кода на некоторых задачах может очень сильно различаться из-за особенностей системы команд и работы оптимизатора в компиляторе. 

1 час назад, Alex77 сказал:

я ктому что при "условно одинаковом размере" кода в Cortex-M3 использовано больше процессорных команд, чем у microblaze. как вариант можно сказать что система команд microblaze лучшее.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

сей "спор" ни о чём. есть много нюансов... но говорить что microblaze "поделка студентов" не стоит. он достаточно шустрый, компактный итд.

пс: опять же как было сказано про опции: есть опция "barrelshift" для microblaze и как следствие в коде программы будет либо одна команда либо с десяток команд одноразрядных сдвигов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

46 минут назад, Alex77 сказал:

сей "спор" ни о чём. есть много нюансов... но говорить что microblaze "поделка студентов" не стоит. он достаточно шустрый, компактный итд.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...