Комментарии 56
Диаграмм не хватает, куда что идет. Можно набросать в excalidraw скажем, тогда проще читаются verilog модули... Либо я привык к кряктусу ;)
Может быть, сам то я в C++ привык писать. Пробовал в Quartus смотреть графический вид, там регистры взорвались в кучу мультиплексоров на несколько экранов, пришлось выносить их в отдельный модуль просто чтобы было видно остальные элементы. Но вообще картинка для привлечения внимания не совсем КДПВ, тут же логика максимально простая, прочитали, сложили по всякому, записали. lui так вообще проводки со входного регистра в выходной перекидывает.
Как я понял, диаграмма здесь простая - один период клока. В этом периоде выдается адрес, читается из памяти команда, декодируется, исполняется и в конце такта защелкивается результат и новый адрес команды :) Уникальный процессор - в нем даже нет регистра инструкции.
Пока только непонятно мне как быть с записью данных, чтобы остаться в одном периоде клока. Память снаружи асинхронная. Нужен, в конце периода клока, короткий импульс записи, в момент когда выдаваемые адрес и данные достоверны.
//здесь читаем с заданного адреса с выравниванием
wire [31:0] old_data = rom[d_addr[31:2]];
wire [1:0] addr_tail = d_addr[1:0];
//здесь посылаем прочитанное в процессор
assign d_data_in = d_addr == 32'h40000008 ? timer :
d_addr < `MEMORY_SIZE * 4 ? (old_data >> (addr_tail * 8)) : 0;
//здесь выравниваем
wire [31:0] aligned_out = d_data_out << addr_tail * 8;
//и обнуляем лишнее
assign byte_mask = d_width == 0 ? 4'b0001 << addr_tail :
d_width == 1 ? 4'b0011 << addr_tail :
4'b1111;
//здесь записываем
always@(posedge clock) begin
if (data_w) begin
rom[d_addr[31:2]] <= {byte_mask[3] ? aligned_out[31:24] : old_data[31:24],
byte_mask[2] ? aligned_out[23:16] : old_data[23:16],
byte_mask[1] ? aligned_out[15:8] : old_data[15:8],
byte_mask[0] ? aligned_out[7:0] : old_data[7:0]};
end
endНо это уже для следующей статьи.
Смело. По сути внешняя память у Вас аналогична описанному в процессорном ядре регистровому файлу.
Ассинхронное чтение? Не думаю что fpga одобрит.
Оно и не одобрило, поэтому пришлось добавлять конвейер. Но когда при выносе регистров в отдельный модуль неодобрение продолжилось, пришлось искать, как это исправить. Флаг AUTO_RAM_RECOGNITION в Quartus отключает автозамену регистровой памяти на встроенную.
Да, но у латчей такой огромный потенциал, если повезет с таймингами ;) Можно все в такт уложить:D
Мне интересно как автор собирается решать проблему арбитража. Сигналов ожидания готовности шины у него не предусмотрено. Сейчас из предложенного ядра можно сделать что-то типа гарварской схемы с раздельной памятью данных и команд, при этом память всегда должна отрабатывать за один так. Что делать с периферией которая за один такт отработать не может ?
Когда добавлял конвейер, пришлось и сигнал паузы добавить, так что не проблема прокинуть. Но пока кэша и внеочередного исполнения инструкций нет, и так сойдёт.
В интерфейсе модуля который Вы приводите в статье нет никакого намёка на арбитраж, он выглядит как однотактовый процессор без схем ожидания. У Вас уже есть конвейерная реализация ? Было бы интересно почитать. Особенно про то, как разрешены различные зависимости (hazards).
Есть в следующих коммитах, в конце статьи упоминал. Эта статья называется "ч.1". Ну и поскольку я не специалист, то могу неправильно понимать значение терминов. Проблема была с тем, что регистр, который записывается на следующем этапе, может читаться следующей командой на предыдущем этапе. И ещё внезапным было то, что компилятор генерирует код, который пишет данные в стек и сразу читает с того же места.
Ваша текущая реализация хороша своей простотой, она легка для понимания и вхождения в тему, но работает только в сферическом вакууме. Не спорю, какие-то простые приложения на нём можно реализовать уже сейчас. Однако, как только потребуется взаимодействие с внешними устройствами и динамической памятью, тут же вырастает проблема с регулированием доступа к шине и ожидания готовности устройств или памяти. Не менее сложная задача - обработка внешних прерываний. Для решения этих проблем в интерфейсе вычислительных ядер должны быть предусмотрены соответствующие сигналы и ядро должно быть спроектировано соответствующим образом - как минимум останов конвейра при отсутствии сигнала готовности. Есть несколько способов реализовать арбитраж и весь интерес как раз состоит в таких решениях. В общем, ждем "ч.2". :-)
На всякий случай, если Вы вдруг не знали, есть отличная Книга Двух Харрисов где детально обрисованы три реализации ядра RISC-V: однотактовая, многотактовая и конвейерная. Книга написана очень увлекательно, я её прочёл с большим удовольствием. RTL дизайнером себя не считаю, но свои ядра написать могу. :)
Что делать с периферией которая за один такт отработать не может ?
Я полагал, что раз входа "подождать" нет, то все вышеописанные проблемы с необходимостью подождать будут решаться через блокировку прохождения синхросигнала.
Сейчас из предложенного ядра можно сделать что-то типа гарварской схемы с раздельной памятью данных и команд, при этом память всегда должна отрабатывать за один так.
Если внешняя статическая ТСМ память просто как регистровый файл с 2 портами чтения и одним портом записи, то все отлично :)
Автор ядра DarkRiscV похвастался, что собрал ядро за один день. У меня за плечами опыта разработки микроэлектроники не было, поэтому когда ядро так же удалось собрать за один день, осталось только сказать: "Лол, и это работает".
По легенде, он сделал это за одну ночь. Но если Ваш день был короче чем его ночь, то Вы круче.
Автор - мАлАдец. Я тоже ядра писал далеко давно. Сначала такое, потом мультитактовое. Бросил (со всей силы в стену)))) на конвеере с его ловушками, подменой регистров и сливом бачка ))
Супер.
Единственно, моя ложечка каки в бочку - 2 АЛУ - это не хорошо. Переходите на мультитакт. Там одного достаточно, хотя для современных ФПГА, наверное количество АЛУ не так уж и важно, тем более что одно их просто для + счетчика инструкций в переходах.... там jal/r, beq и пр.
Если под вторым АЛУ имеются в виду вычисления в branch_fired, то там жалкое вычитание и сравнение, остальное вроде флагами на конце сумматора разруливается. А на конвейер я уже перешёл, вот там действительно пришлось следить, какие данные какому этапу соответствуют. Теперь флаги блокировки конвейера есть, регистры в модуль вынесены, осталось шину многоканальную с кэшем сделать и можно out-of-order выполнение инструкций прикручивать. Оно вроде не сложно выглядит, если предыдущие ядра регистр не пишут, значит можно его читать.
даёт 1.29 CM
Проверил. Цифры аналогичные :)
Вычислительное ядро у Вас есть. Теперь осталось сделать остальные 95% работы - написать Сrossbar, контроллер SDRAM (или хотя бы SRAM), контроллер QSPI (с XiP), контроллер SPI, контроллер I2C, контроллер GPIO, пару-тройку таймеров с поддержкой ШИМ, контроллер MAC, контроллер прерываний и можно подключать к ЧПУ станку. ;-) /s
Думаю, что с этими модулями у автора проблем не будет. Кроме контроллера прерываний, т.к. вход IRQ процессорного ядра висит в воздухе :)
Я вообще не вижу где у модуля module RiscVCore вход для внешних прерываний. В целом автор конечно молодец, но путь он выбрал очень тернистый. Я обычно беру готовую СнК на базе VexRiscv и адаптирую для своих задач.
На микроконтроллере код килобайт 20 занимает, так что может и встроенной памятью удастся обойтись, а остальная периферия - генераторы шагов и uart. Когда первый раз пытался переводить, генераторы уже написал, так что не всё так страшно.
Когда то немного копался с verilog/vhdl/FPGA и зависал на opencores - как хобби. Был подписан на TI,AD, как тестовый инженер, чтобы всякие пелезняшки в виде пробников получать. Но со временем паять стало все труднее и труднее -. форм фактор мельчал.
Что зацепило в свое время из учебных проектов:
JOP -java optimized processor. Проект из Австрии, к нему прилагается полноценная научная работа, простой процессор для байткода , заливается на небольшую плату с fpga, можно расширять, делать I/O.
И второй проект, не помню уже вытащил, примитивный risk процессор, проект system on chip, разжевано создание настроек для компилятора gcc чтобы с проект собрать под этот процессор, контроллеры VGA, клавиатура, мышь. Код приведен для загрузчика.
В общем эти два проекта по хорошему надо было у нас в вузе давать как практикум.
Verilog и vhdl талмуды пылятся на полке, там же с++ шикарная книжка купленная в Торонто в свое время, мелованная бумага. Рука не поднимается выкинуть, но похоже меня уже окончательно засосало болото. Java. Железо ошибок не прощает и там экономия 10% и поднятие эффективности реальные деньги, а в java enterprise можно дерьмо писать, никто не заметит. Еще нейронки подтянулись.
Вчера chatgpt мне галлюцинации гнал по настройке maven, nexus docker repo - плюнул в итоге глянул документацию. Только расслабишься с нейронкой, как она норовить текст написанный под грибами подсунуть...
Можете поделиться ссылками?
jop сразу находится но могу запостить ссылку в ответ на телефоне, напечатал jopdesign.com Martin Schoberl.
Второй проект быстро но не найду, давно это было но похоже что на opencores.org типа simple risk CPU system on chip.
Классный проект для обучения, поэтому запомнился - от ядра до компиляции С.
Я лет 15 не касаюсь почти этой темы, увы.
Добрался до дома, глянул https://opencores.org/projects - зависают пункты меню, не открываюся - то ли браузер у меня не тот, то ли впн нужен.
Поискал в сети - что то похожее "32 bit CPU with GCC toolchain", похоже на ZPU.
https://opencores.org/projects/zpu
https://github.com/freecores/zpu/blob/master/zpu/docs/zpu_arch.html
wishbone шина, цепляй что хочешь.
на опенкорс надо посмотреть секцию system on chip, скорее всего там будет. Либо уже отрефакторили проект - кто знает, столько времени прошло
Глупый вопрос от человека, который всё никак не подступится к верилогу - icarus проверяет синтезируемость?
Icarus Verilog генерирует нетлист, но он не может проверить синтезируемость под конкрентый ПЛИС. Фактически это симулятор который используют для верификации и дебага. В сочетании с gtkwave - очень мощный тул.
Подступиться к Verilog-у совершенно не проблема, установите тулы и побалуйтесь с лабораторками от Юрия Панчулы, желательно имея в руках какую нибудь из поддерживаемых плат, но это не обязательно. Порог входжения в эту тему сейчас очень низкий - пару ночных сейшнов и можно писать своё ядро RISC-V. ;-)
Спасибо, статья интересная! Но в каком плане лицензированность arm/x86 может помешать использованию этих технологий на станке? Разве кто-то будет разбираться, что за интегральную схему, ЦП и тд вы использовали?...
С большой долей вероятности x86 и ARM подвинутся с рынка, потому что они дорогие и устаревшие.
Весьма спорное утверждение, на мой взгляд. Да, х86 очень сильно мешает легаси, это так. Но вот насчет арма… из личного опыта могу сказать, что пока арм в подавляющем количестве случаев имеет сильное преимущество над RISC-V в плане скорости. Безусловно, RISC-V очень хорош для embedded systems, мест, где нужен open source и тд. Но по-моему, маловероятно, что он в ближайшем будущем заменит собой AArch64, особенно теперь, когда ноутбучный сегмент потихоньку переезжает с х86 на арм.
Сначала в персоналках был повальный x86, и он был слабенький. Потом прошло некоторое время, и его вычислительная мощность выросла на порядки. Даже на смартфоны начали его ставить. Среди микроконтроллеров были PIC, AVR, пользователям надо было страдать и напрягаться, чтобы случайно не прожечь неправильные фьюзы. Потом году так в 2010 на рынок ворвался ARM с помощью ST Microelectronics. Они завалили прилавки дешёвыми мощными микроконтроллерами, которые можно было легко сконфигурировать программно. ARM стал модным, привычным, его начали использовать в смартфонах. Потом его мощность выросла так, что начала обгонять x86, и Apple решила не терять время, переведя свои десктопы на ARM.
"Род приходит и род проходит, и нет ничего нового под небом". ARM микроконтроллеры стали дорогими, китайцы начали заваливать рынок дешёвой альтернативой STM в виде аналогов на RISC-V ядре. Пошла разработка видеокарт с RISC-V ядрами. В это же время у Intel проблемы с новыми процессорами и соответственно, с направлением развития. Новые ядра - довольно очевидный выход.
Итак, пожалуй, напишу по пунктам:
1. В своем комментарии вы ставите вместе микроконтроллерные, десктопные и мобильные архитектуры. Это не совсем правильно. Например, ARM для микроконтроллеров (ARM-M) и ARM для телефонов/ноутбуков (ARM-A) достаточно сильно различаются. И популярны они в своих сферах по разным причинам.
2. Как я и написал ранее, RISC-V действительно хорош в сфере микроконтроллеров. Там он имеет громадные преимущества над остальными архитектурами (например, малое количество инструкций и открытость).
3. Про х86 также соглашусь: intel мало чего делает в последнее время для улучшения своих процессоров (да и в самом интеле сейчас большие проблемы). К тому же, переход apple и всех потянувшихся следом на ARM сильно повлиял на популярность х86.
4. Насчет мобильных систем, таких как смартфоны и ноутбуки: в этом сегменте RISC-V пока достаточно сильно уступает арму. На то есть весомые причины, как, например более специализированные инструкции арма, которые, как не крути, будут выполнять задачу быстрее, чем несколько инструкций RISC-V. По энергоэффективности сильного различия пока не наблюдается. Нет особого смысла здесь про это говорить, тк существует огромное множество статей, в которых авторы досконально анализируют различия. Куча софта написанного под арм и не всегда портируемого тоже усложняет переход. Да, собственно, и зачем переходить, когда у арма сейчас нет существенных проблем, как у x86. Архитектура на данный момент хорошо развивается и справляется с требуемыми задачами. В общем, как я и сказал, в этом сегменте вряд ли ARM будет вытеснен RISC-V в ближайшее время.
более специализированные инструкции арма, которые, как не крути, будут выполнять задачу быстрее, чем несколько инструкций RISC-V
Вы в курсе векторных и прочих расширений RISC V? Согласен, что мощного железа на RISC V пока нет (хотя подвижки есть - какие то ноутбуки продаются, возможно вот это увидим не только на бумаге), но ограничений самой архитектуры в этом плане не вижу.
Здесь я скорее говорю не про векторные расширения, которые есть и у ARM, и у RISC-V, а, например, про более специализирванные инструкции load/store. Минимализм RISC-V в данном случае является и плюсом, и минусом по сравнению с подходом того же ARM. Наклепать различных расширений можно, и это делается вполне успешно, но базовая ISA остается той же самой со своими недостатками. В любом случае, в нынешнем состоянии ARM-A вполне успешно справляется и apple, qualcomm, huawei и прочим гигантам
переделывать свои процессоры на RISC-V просто невыгодно
Вы опять смешиваете встроенные и мобильные/десктопные платформы. Чип для телевизора (3я ссылка) - это далеко не то же самое, что телефон и ноутбук. Задачи и требуемая производительность совершенно разные. В остальных двух статьях также речь про embedded. Я же в своем комментарии пишу про телефоны и ноутбуки.
но базовая ISA остается той же самой со своими недостатками.
Так базовым минимальным набором никто не пользуется, обычно есть по крайней мере GC; в серверном процессоре ожидаётся всё, что, может увеличить производительность.
С серверами ситуация может быть особой (это моё имхо). Чем обычно занимается серверный код? Читает файлы, тасует строки, json распарсивает/запарсивает, посылает запросы по сети и разбирает ответ. Какой для этого нужен набор инструкций? Базовый и умножение для арифметики указателей, ещё немного атомарных и криптографии. А дальше как в Футураме: "У вас хлеб бесплатно? Тогда нам больше ничего не надо". Все эти дополнительные расширения умножают стоимость разработки и греют плату. У сервера не столько проблема во времени, потраченном на вычисления одного запроса, сколько в возможности параллельно за недорого переварить кучу запросов.
Читает файлы, тасует строки, json распарсивает/запарсивает
А ещё обучает нейросетки, моделирует термояд, считает прогноз погоды и т.п.
Есть подозрение, что это делается на GPU. В любом случае PHP/JS/Go и т.д. разработчики не скажут спасибо за удорожание аренды. Сколько имел дела с серверным кодом, там никаких сложных вычислений не было.
Если закладываться на подобные применения, думаю, большой разницы между архитектурами не будет, векторные расширения порешают.
Есть подозрение, что это делается на GPU
Необязательно, скажем тут никаких акселераторов нет.
В любом случае PHP/JS/Go и т.д. разработчики не скажут спасибо за удорожание аренды
Кто их на такую систему пустит )
большой разницы между архитектурами не будет, векторные расширения порешают.
Uncore подсистема тоже существенна, в память счётные коды достаточно часто упираются. Но базовая ISA особой роли не играет, к чему и клоню.
Даже принимая в рассмотрение GC extensions, ситуация кардинально не меняется. Ассемблер risc-v достаточно многословен и использование compressed инструкций не всегда спасает положение. Вполне реальна ситуация, когда инструкция на арме (32 бита) заменяет несколько сжатых инструкций risc-v (16 бит каждая). В итоге размер кода растет и code cache, шины и прочее страдают. Что важнее, с добавлением extensions возникают другие проблемы. Во-первых, не всегда имеется поддержка со стороны компилятора (с той же векторизацией все компиляторы справляются поголовно плохо). Понятное дело, что и на арме ситуация схожая, но там это в некоторой степени сглаживается меньшим количеством расширений и изначальным наличием большего количества инструкций в ISA. Ведь разработчику проще взять инструкцию, которая точно в наличии без поиска более быстрых альтернатив в куче расширений. Во-вторых, расширения risc-v уводят его от того изначального минимализма. В итоге отличий от арма становится не так уж и много. Достаточно посмотреть на векторный extension, который кратно увеличивает количество инструкций базовой ISA. В итоге, например, в случае с векторами назревает вопрос: «а чем это лучше NEON к которому все привыкли»?
В итоге размер кода растет и code cache, шины и прочее страдают.
Вот тут картинка другая. Если у вас есть другие цифры на реальных приложениях, было бы интересно посмотреть.
В итоге, например, в случае с векторами назревает вопрос: «а чем это лучше NEON к которому все привыкли»?
Сначала подумайте, зачем в ARM при наличии NEON добавили SVE.
Ещё добавлю. Никто к NEON не привыкал, компилятор автоматически инструкции добавляет. На фирму может найтись 1-2 человека, которые в паре мест сделают ассемблерные вставки, так что тоже негде особо привыкать. Остаётся вопрос: "А чем это хуже NEON". Если ничем, то вроде нет смысла отваливать деньги за лицензию.
Еще раз хочу сказать: я не утверждаю, что risc-v плох. Наоборот, в нем есть множество достойных моментов. Но утверждение автора, что он с высокой вероятностью заменит все остальные архитектуры считаю гиперболизированным.
Про гиперболу согласен, будущее в любом случае туманно. Но проблемы на мой взгляд скорее с экосистемой, чем с самой ISA.
Моё утверждение основано на следующих предположениях.
У стартапов нет лишнего миллиона долларов в кармане, тем более если бесплатный вариант не сильно хуже.
Когда стартап вырастает до уровня, при котором он может позволить себе лицензию, в этом уже нет смысла из-за кодовой базы и клиентов.
Акулы рынка состоят из бывших стартапов.
Конечно, может случиться что угодно, например, ARM до какого-то размера доходов сделают бесплатным, или AMD выложит свою идеальную архитектуру. Но если нет, тогда давайте не забывать, что случается с гигантами рынка: IBM-совместимые PC остались, а самих IBM PC не осталось.
Процессор на коленке ч.1