Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Промышленная инженерия доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 21
Спасибо за статью. Подскажите, у Вас в конфигурации IM(max) в обоих ядрах используется однотактный аппаратный умножитель?
Для ядра picorv32 я поставил параметры
localparam ENABLEMUL = 1;
localparam ENABLEFAST_MUL = 1;
Для ядра SCR1 в конфигурации SCR1_CFG_RV32IMC_MAX так же определяется
`define SCR1_FAST_MUL
Но не могу с уверенностью сказать что эти определения дадут одно-тактный или двух-тактный умножитель. При желании можно это выяснить рассматривая waveforms или внимательно смотреть исходники.
я посмотрел времянку SCR1 на этом тесте. Скажу так - тест выбран очень неудачно. Сами представьте: всего 453 такта на итерацию в которой только одна операция умножения. Поэтому и выводы такие, что лучше выбирать минимальную конфигурацию SCR1 (без умножения) т.к. она не уступает максимальной (с аппаратным однотактным умножителем). Все верно, но только для этого теста. Попробуйте другой тест.
Наверное вы правы.
Но есть еще один момент, который меня смущает. В конфигурации EC / MIN посчитано CyclesPerInstruction 1,540, а в конфигурации IM / MAX посчитано CyclesPerInstruction 1,742 Кажется какая-то ерунда, что MAX даже медленнее и тратит больше циклов на инструкцию? При этом конфигурация MAX явно выигрывает бенчмарк.
Я для себя объясняю это тем, что в конфигурации MIN исполняется больше простых инструкций и в целом программа видимо длиннее. А в конфигурации MAX программа короче, но появляются более сложные инструкции требующие более одного такта.
Если добавить в dhry_1.c строку
User_Insn = End_Insn - Begin_Insn; sc_printf(“Insn begin: %ld end: %ld Num %ld\n”, Begin_Insn, End_Insn, User_Insn);
То можно посмотреть сколько же инструкций выполнялось за тест.
В моем случае я вижу:
EC/MIN: 152525
IM/MAX: 130033
То есть да, для IM компилятор создает код который при исполнении получился короче. Но инструкции видимо появились и более сложные требующие больше одного такта.
При этом вторая странность - в конфигурации MAX сегмент .text при всём при этом оказывается большего размера.
Есть над чем задуматься.
YRV софтовое умножение, 50МГц. За измерение PicoRV32 огромное спасибо. Интересно было сравнить.
Однако учтите, что сейчас в моем проекте я подключил к линиям JTAG просто константы ноль, то есть они не работают и значит компилятор выбросил из анализа всю связанную логику. С работающим JTAG процессор scr1 будет занимать гораздо больше места в ПЛИС.
Не совсем корректно. В этом случае будет оптимизирован только TAP-контроллер(он и так очень маленький), а вот система отладки("debuger") скорее всего полностью останется.
Если хотите отключить "debuger" - нужно закомментировать "`define SCR1_DBG_EN" в файле конфигурации.
Все-таки нужно здесь применить CoreMark - он гораздо лучше расставляет процессорные ядра по рангам (в среднем по больнице).
Этот тест был бы информативнее, но на мой взгляд, в статье нужно было немножко больше рассказать об особенностях исполнения команд в PicoRV32. Суть в том, что у него нет никакого конвейера и если вы выставите наилучшие условия для быстрой работы, то даже NOP команда будет исполняться за 3 такта. Если память работает не идеально, т.е. запрос на чтение команды в текущем такте, а сама команда в следующем такте, то уже как минимум 4 такта на любую команду. Поэтому нужно ожидать , что по тактам Picorv32 будет в 4 раза проигрывать SCR1 на одинаковом коде. Если используется С расширение, то иногда команда уже выбрана и тогда для неё 3 такта. Итого ухудшение по тактам будет меньше 4-х. Сравнивать эти ядра как-то даже не интересно если есть мысли о каком-то быстродействии.
Тогда уж аспект конвейеризации нужно рассмотреть для обоих сравниваемых ядер (и их конфигов, т.к. SCR1 Min/Max конвейеры разнятся по числу стадий).
Да, для оптимизации по объему HW ресурсов ("площади") PicoRV32 не применяет конвейер. И это закономерно отражается даже в результатах Dhrystone:
Cycles per Instruction:
PicoRV32 (min/max): 5.8 / 5.6
SCR1 (min/max): 1.5 / 1.7
Но PicoRV32 явно создавался не для взятия высот по производительности, а чтобы дать возможность встроить даже в относительно малые FPGA программируемое ядро RISC-V. У него в коде есть привязки к технологическому базису FPGA-вендоров? Не удивлюсь, если так.
У SCR1 и PicoRV32 - несколько разные области применения. И данный анализ еще раз это показывает.
Самая главная фищка PicoRV32, как мне кажется в его примерах с использованием внешней последовательной флеш памяти для программ. Здесь то я поставил 32К статической памяти для теста, но picorv32 не для этого делался. Я думаю производитель подразумевал ему поставить условно говоря 1К памяти, как scratchpad над памятью внешнего флэш чипа. И тогда память программы может быть очень большой и разработчик почти не ограничен её размером.
несколько разные области применения
Вот над этим хорошо бы акцентировать внимание. Когда-то я делал ASIC для автомобильного ключа на 8-разрядном МК: ядро+SRAM+ flash+простой последовательный интерфейс. Нажимаем кнопку - подается питание, МК читает из флэша число, шифрует его , отправляет, записывает во флэш новое число и отключается. Какое ядро из этих двух лучше подойдет для такого применения? Требования - чтобы батарейка работала как можно дольше и чип был как можно дешевле.
PS. ИИ рекомендует использовать SCR1 :)
ИИ он такой.
Честно говоря я не очень верил в эти ИИ до недавнего времени. Пока не попробовал попросить github Copilot сделать мне тестбенч к модулю, ну чисто для эксперимента. Очень впечатляет. Даже написал про это статью
https://marsohod.org/459-github-copilot-for-fpga
А вот яндексовый sourcecraft.dev с этой же задачей не справился, как я его не просил.
Правда на другой задаче (создать на логике быстрый умножитель) и у яндекса получилось вполне хорошо. Плюсом sourcecraft.dev что он сразу создает репозиторию для запроса и все правки туда идут, видно как проект меняется от запроса к запросу:
https://sourcecraft.dev/organization-marsohod-org/fast-8-bit-multiplier-verilog
Я не очень понимаю, как они это делают, ведь Verilog не очень популярный язык, как они могли ИИ натренировать?
Пока мой фаворит среди свободных RISC-V ядер это neorv32. Компактное, шустрое и готовая SoC инфраструктура с богатой периферией.
Сравните с VexRiscv. По моим тестам у него лучшее отношение производительности к площади.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сравнительный анализ RISC-V микропроцессоров picorv32 и scr1 при использовании в FPGA