Jump to content

    
MegaVolt

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

Recommended Posts

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

Share this post


Link to post
Share on other sites
44 минуты назад, fguy сказал:

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

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

Share this post


Link to post
Share on other sites
31 минуту назад, makc сказал:

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

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

Share this post


Link to post
Share on other sites
On 10/1/2021 at 12:11 PM, MegaVolt said:

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

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

Share this post


Link to post
Share on other sites
19 часов назад, fguy сказал:

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

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

Share this post


Link to post
Share on other sites

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

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

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

 

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

Share this post


Link to post
Share on other sites
46 минут назад, sonycman сказал:

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

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

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

Share this post


Link to post
Share on other sites
42 минуты назад, Alex77 сказал:

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

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

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

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

Share this post


Link to post
Share on other sites
2 hours ago, makc said:

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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 лучшее.

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites
46 минут назад, Alex77 сказал:

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

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.