Отдельный контекстный стек процессора. Как думате, стоит ли?

Question

[EvgenySbl]

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

К чему это приведет?
Контекстная шина процессора, может быть достаточно широкой, вплоть до передачи всех регистров параллельно за один такт. Теоретически, это позволит делать вызов функции за один (или несколько) тактов, и при этом не сохранять не только регистр возврата, но и другие временные регистры, или регистры передающие параметры. С защитой все понятно, все становится намного лучше. Адрес возвртата недоступен, и его не только не перезапишут, но и не узнают.

Но теперь самое интересное. Если шина широкая, то можно реализвать команду отката значения регистра на начальное значение. Т.е. предположим в функцию передавались аргументы, теперь, регистр с аргументом, может быть использован как временный, а в нужный момент, его значение можно откатить на начальное. Отсается только не откатывать значения регистров, которые возвращают результат, при возврате из функции. Теоретически, можно даже уложиться в ARM ABI, только комилятору, нужно будет убрать пролог и эпилог функции (это будет делаться аппаратно на параллельной шине).

Как считаете, стоит ли?

Вот что мне ответил ChatGPT

Ты описываешь очень интересный и продвинутый подход к организации стека вызовов и сохранению контекста процессора, который действительно может дать ряд преимуществ как по производительности, так и по безопасности. Позволь мне прокомментировать и расширить некоторые из твоих идей.

Отдельный стек для адресов возврата и контекста
Аппаратная шина стека:
Идея выделить отдельную шину для стека адресов возврата и контекста действительно может ускорить операции сохранения и восстановления. Если эта шина реализована аппаратно и не связана напрямую с основной памятью, это позволит выполнять операции push/pop почти за один такт, значительно уменьшая накладные расходы при вызове функций и обработке прерываний.

Защищённый доступ:
Ограничение доступа к стеку возвратов только защищённым режимом работы процессора — отличная идея с точки зрения безопасности. Это позволит предотвратить атаки, связанные с переполнением стека (stack smashing), так как пользовательский код не сможет напрямую изменить адрес возврата.

Сохранение и откат регистров:
Возможность аппаратного отката регистров и состояния второго стека до исходных значений за один такт — очень удобная функция. Это может упростить реализацию функций с сохранением контекста, повысить надёжность и упростить отладку.

Расширение набора инструкций
Введение инструкций для быстрого сохранения/восстановления контекста, отката регистров и управления отдельным стеком контекста — это мощный инструмент, который может повысить эффективность и безопасность программ.

Однако расширение ISA (Instruction Set Architecture) требует серьёзной проработки, поддержки со стороны компиляторов, отладчиков и операционных систем.

Безопасность и изоляция кода
Запрет на чтение констант из кода и хранение их в отдельной области памяти, доступной только для чтения, — классический приём повышения безопасности. Это усложняет анализ и модификацию кода вредоносными программами.

Современные процессоры уже используют подобные техники (например, W^X — Write XOR Execute), но твоя идея может быть расширена и усилена.

Возможные сложности и вызовы
Совместимость:
Введение такого аппаратного механизма потребует поддержки на уровне компиляторов, операционных систем и существующего ПО. Это большой вызов с точки зрения экосистемы.

Сложность аппаратной реализации:
Реализация отдельной шины стека и дополнительного набора инструкций усложнит дизайн процессора, что может увеличить стоимость и энергопотребление.

Обучение и адаптация:
Разработчикам ПО и инструментам потребуется время, чтобы освоить новые возможности и правильно их использовать.

Итог
Твоя концепция — это пример архитектурного решения, которое может значительно повысить безопасность и производительность, особенно в критичных по времени и безопасности приложениях. Подобные идеи иногда реализуются в специализированных процессорах (например, в системах с аппаратной поддержкой защищённых зон, типа ARM TrustZone или Intel SGX), но широкого распространения пока не получили.

Если интересно, могу помочь обсудить, как такие идеи можно было бы прототипировать или какие существуют аналогичные решения в современных архитектурах. Что думаешь?

Answer 1

[jcmvbkbc]

Теоретически, это позволит делать вызов функции за один (или несколько) тактов, и при этом не сохранять не только регистр возврата, но и другие временные регистры, или регистры передающие параметры.

Это будет иметь последствия для реализации многозадачности (переключение с задачи на задачу должно будет выгружать весь контекст одной и загружать весь контекст другой задачи), а так же для функций типа setjmp()/longjmp() и getcontext()/setcontext().

Адрес возвртата недоступен, и его не только не перезапишут, но и не узнают.

Это будет иметь последствия для реализации функций раскрутки стека, на основе которых обычно сделаны механизмы обработки исключений в ЯВУ.

Вам нужно обсуждать свои идеи с программистами которые будут делать низкоуровневый софт для вашего процессора, потому что именно перед ними будет стоять выбор: портировать существующий код или писать своё. Портировать существующий код будет тем сложнее, чем больше будет у вашего процессора особенностей. Писать своё начиная с самого низа -- это колоссальный объём страданий, а нежелание страдать по полной программе приведёт к тому, что ваш процессор станет нишевым, а значит бенефиты, которые могли бы принести его странности просто не реализуются.

Comments

[Алексей Уколов]

Автор всерьёз борется с Матрицей (почитайте его прошлые вопросы). Из этого два следствия: а) никакие трудности его не остановят и б) никакой процессор он никогда не сделает.
Просто имейте это в виду, если решите вступить в обсуждение.

[EvgenySbl]

Добрый день!

Это будет иметь последствия для реализации многозадачности (переключение с задачи на задачу должно будет выгружать весь контекст одной и загружать весь контекст другой задачи), а так же для функций типа setjmp()/longjmp() и getcontext()/setcontext().

За 15 лет прогаммирования с применением setjmp/longjmp сталкивался только один раз. В коде отладчика BlackMagic. В этом коде, механизм используется как замена механизма обработки исключений try/catch.

Это будет иметь последствия для реализации функций раскрутки стека, на основе которых обычно сделаны механизмы обработки исключений в ЯВУ.

Вероятно Вы правы, но раскрутка стека, как правило требуется при обработке исключительных ситуаций (в блоке try/catch. Если в специальном, защищенном режиме доступ к окну будет, то гипотетеически стек раскручивать не только быстрее но и удобнее. По сути call stack уже содержит все регистры, включая адрес возврата, а значит, насколько я понимаю, можно просто пропустить одну из итераций если на этом уровне вложенности нет обработчика исключений. В классическом варианте, требуется знать глубину стека, т.к. нужно добраться до SP. Есть вероятность, что это увеличит скорость обработки исключительных ситуаций.

Писать своё начиная с самого низа -- это колоссальный объём страданий, а нежелание страдать по полной программе приведёт к тому, что ваш процессор станет нишевым, а значит бенефиты, которые могли бы принести его странности просто не реализуются.

Если реализовать классическую ISA ARM или популярную на cегодня ISA Risc-V, то переделать придетcя в основном компиляторы, планировщики задач и обработчики прерываний. Т.е. компилятор и низкоуровневое ПО.

На самом деле, беспокоят вопросы, свзязанные с безопасностью. Много лет назад, разработал прототип отладчика для микроконтроллера Cortex M3 ( "BluePill Debug Over USB" ). Это был именно прототип позволяющий загружать код на STM32F103 и отлаживать его при помоши GDB без использования дополнительной аппратуры. Некий аналог Arduino но со встроенным отладчиком, и пока без библиотек. Breakpoint-ы это намного круче чем просто printf который, кстати, тоже работл на USB, через системный вызов (SVC).

Цель, в том, чтобы быстро проверить работу. В коде есть решения, которые со стороны Host-а не позволяют работать долго (временный тяп-ляп в желании быстро проверить функционал). Однако, прототип выявил ряд хотелок, которые можно было бы реализовать в процессоре. Одна из основных хотелок, это защита памяти. Другая,- встроить многозадачность прямо в отладчик. Ведь по сути, он уже сохранял и восстанавилвал контекст, осталось добавить планировщик и примитивы синхронизации.
Однако, меня беспокоила защита задач. Тогда показалось, что это можно реализовать частично. Например, если пересобрать компилятор... Можно изменить направление стека, а значит классическое переполнение буффера приведет лишь к повреждению локальных переменных и выход за границу стека. Стек может быть ограничен регионом MPU, а значит, в ряде случаев, это вызовет исключения. Про стековые канарейки, я не упоминаю. Суть проста. Учебная архитектура, с безопасным многозадачным выполнением и отладкой, в которой нельзя повредить отладчик.

По сути, на данный момент, я учусь писать код процессора. Да, мой уровень можно сказать начальный. Но изучая код на Verilog из открытых источников, обратил внимание что никто не стремится изначально оптимизировать архитектуру. Так, например, если это ALU, то отдельно стоит несколько сумматоров. Один для сложения, другой для вычитания. Несколько умножителей. Простой пример. Если инвертировать аргументы для сумматора, и инвертировать перенос, то можно получить вычитание вместо умножения. Это экономит LUT-ы в FPGA или место на кристалле, если процессор в реальном железе. Я не нигде не видел конвейеризаци например суммирования, хотя в моих тестах если делать это без использования блоков ALU, далеко не везде получается реализовать суммирование на заданной частоте без конйверизации.

Перовое, что хотел проверить, это две вещи. Простенький процессор, c ALU вроде "Hack" из курса "From Nand To Tetris", но с набором регистров и командами вроде Risc-V (RV32I). И второе, это эмуляцию MMU. У меня на руках ПЛИС. В этой FPGA имеется динамическая память (64Mbit), и блоки статической памяти, которые можно использовать для прямой трансляции адресов, т.е. реализовать TLB прямо в этой памяти, скушав в ней 8Кбайт, на описание страничной памяти со страничками по 4Kb. Т.е. этот буфер, который в обычной системе работает как буфер, будет использоваться фиксированно и напрямую, ничего не кэшируя из нетрансилируемой памяти.
Как выяснилось, работа с оперативкой или какой лбио (последовательной) шиной наподобе AHB, автоматически приводит как минимум к необходимости кэширования кода и к Wait-stat-ам. Так, как что оперативная память работает Burst-ами, что шины работают с задержками, а это приводит к необходимости выполнения из кэша, т.к. праямая выборка команд приведет к длительному ожиданию.
Скажем так, на данный момент, я учусь и перебираю варианты, но хочется свой процессор. Не потому что свой, а потому что хочется безопасный. Т.е. в системе не должно быть запрещенных состояний, а соответственно, неопределенного поведения.

[jcmvbkbc]

Если реализовать классическую ISA ARM или популярную на cегодня ISA Risc-V, то переделать придетcя в основном компиляторы, планировщики задач и обработчики прерываний. Т.е. компилятор и низкоуровневое ПО.

Я говорю о том, что для поддержки какой-то мелкой фичи железа объём того, что надо будет поменять в низком уровне может варьироваться от "поменять один define" до "придумать и реалиовать новый механизм", и без хорошего понимания софтовой части оценить этот объём сложно.

За 15 лет прогаммирования с применением setjmp/longjmp сталкивался только один раз.

Это слабое утешение, потому что когда setjmp() или другая редкая штука с неочевидной для вашего случая реализацией таки понадобится, обойтись без неё будет очень сложно.

[EvgenySbl]

Алексей Уколов,

никакой процессор он никогда не сделает

Звучит, как вызов, или как провокация. Знаете, есть такой психологический прием, навзяать что-то человеку, а потом попытаться заствить его что-то доказать. Я делаю это потому что мне это интересно, а как Embedded/System Engineer я паботал уже много лет.

никакие трудности его не остановят

Не уверен что правильно понимаю что Вы имели ввиду, поскольку многие вещи в этом мире вызвают сложности, которые приостанавливают решение задачи.

Автор всерьёз борется с Матрицей

Это серьезное заявление, с Вашей стороны, и это не по теме. Но, на самом деле, никто не знает как устроен мир. Например прямо сейчас, я обращаю внимание на то, как количество солнечной энергии поступившей на поверхность Земли в локации где нахожусь я менятся. И со стороны можно провести корреляцию между тем что я делаю/пишу, и солнечной активностью. Вообще, я сторонник того что количество энергии попадающей на единицу площади, зависит только от положения Земли (угла наклона) и естественных природных факторов, сдерживающих солнечную активность (поток энергии доходящий до поверхности). Я уже достаточно давно, замечаю корреляцию между своей реакцией, иногда своими постами и небом. Да, понимаю, что звучит это как минимум странно. Но статистика и временные соотношения говорят о том, что скорее всего это имеет прямую или косвенную связь. Прямая, это например, мои действия как-то влияют на состояние мира, в это вызвает изменение облачности. Это звучит и выглядит странно, но к сожалению корреляция наблюдается. Еще в университетские годы, один из преподавателей, рассказывал о экспериментах, проводимых Американцами по управлению погодой, с использованием антенных решеток на севере США. Т.е. косвенное взаимодействие можно было бы свести к тому факту что за мной наблюдают, и подстраивают под меня погоду. Это тоже звучит и выглядит мягко говоря странно. Я сам себе задаю вопрос: кто я такой, чтобы погода была связана с моими действиями? Теория вероятностей, дает практически 100% корреляцию этих событий. Но объяснения почему события связаны, у меня нет. Есть еще ряд наблюдений, которые говорят о том что нас фактически окружает лишь информация, т.е. этот мир скорее всего не материален. И это вызывает у меня подозрение, что он похоже, действительно похож на матрицу. Касательно бороться или нет... А как бороться с тем, внутри чего существуешь, если неизвестно даже, существуешь ли за пределами этого информационного окружения? Все не так просто как кажется.
Если предположить что мир устроен таким образом, что представляет собой модель реального мира. Возможно упрощенную, для ускорения процессов. Т.е. например, использующую поведенческое моделирование объектов для ускорения взаимодействия. То можно предположить что на уровне реальности, некто стремится использовать наработки сделанные в виртуальном мире. Т.е. проецирование проблем реального мира на симуляцию, для того чтобы симулятор сам искал решение их задач. По сути это аналогия того, что мы сегодня делаем с нейросетями. Однако в контексте концепта симуляции, нет смысла делать изделия (например процессоры) правильно. Есть смысл реализовывать их в концепте двойного назначения. Хотите пример? Например, некоторые процессоры могут иметь два направления роста стека. Вверх или вниз. Если компилятор формирует общую схему роста стека вниз, это может привести к ошибкам его переполнения, и получения несанкционированного доступа к изделию. Сдругой стороны, ПО может иметь концепт роста стека вверх, и это приведет к возможности атаки, но невозможности захвата управления, используя цепочки команд, таких как 0x90 в ассемблере x86, c последующим кодом. Так вот. Как соотнести симулятор и процессоры? Если процессор вдруг будет использоваться за пределами симуляции, то нет смысла делать его абсолютно безопасным. Смысл проектровани сводится к такому построению системы чтобы там, за пределами матрицы, он использовался с уязвимостью, а здесь, на нашем уровне, он этой уязвимости не имел. Тогда, при наличии некого канала свзяи, туда, можно будет однажды проэксптуатировать уязвимость в одном из реализованных решений, и получить окно в тот мир. Это теоретически, если он создан по образу и подобию. Но а я просто замечаю что есть в этом мире необычные явления. И похоже "это жжжжж... неспроста" (© Пух).

Answer 2

[15432]

Уже придумали похожее, архитектура Tensilica Xtensa с вращающимся регистровых окном. При вызове вращение вперёд, при возврате назад.

Comments

[jcmvbkbc]

В xtensa регистры программно сбрасываются в общий стек при переполнении и программно загружаются обратно.
То, что аппаратное сохранение и загрузка регистров, задуманные в микроархитектуре NX, так до сих пор и не реализованы, кое-что говорит нам о соотношении сложности реализации к ожидаемому приросту производительности.

[EvgenySbl]

jcmvbkbc, спасибо.
Это очень ценный комментарий.
Я уже попробовал отельно сбрасывать набор регистров в отдельныую BSRAM. На данный момент выглядит интересно. Правда, до тех пор, пока эту область как страничку кэша, не требуется сбрасывать в определенную область общей оперативной памяти. Хотя, в общем-то это может стать одной транзакцией на AHB при доступе к общей оперативной памяти.

[15432]

jcmvbkbc, ага, но сброс в стек происходит относительно редко из-за огромного числа регистров

[jcmvbkbc]

15432, ну да, и тем более сомнительно выглядит попытка это место оптимизировать перекладывая работу обработчика исключений overflow и underflow полностью на железо.

Answer 3

[VoidVolker]

А в чём суть-то вашего вопроса? Стоит или не стоит делать? Если вам надо или интересно его сделать - возьмите и сделайте. Не очень надо или не очень интересно - не делайте. Это решать только вам. Хотите сравнить в реальном применении? Берёте ПЛИС, реализуете на ней ваш процессор и сравниваете с другими софт-процессорами с разными архитектурами.

Comments

[EvgenySbl]

Берёте ПЛИС, реализуете на ней ваш процессор и сравниваете с другими софт-процессорами с разными архитектурами.

Приблизительно этим сейчас и занимаюсь. Скажем так, прохожу курс по проктированию процессоров, и натыкаюсь на все то, на что натыкались разарботчики с момента создания процессоров.

[VoidVolker]

EvgenySbl, в таком случае просто продолжайте учёбу и пробуйте делать то, что вам интересно. Например - найдите проблему и попробуйте сделать процессор для её решения. Процессор - это не устройство в воздухе, а устройство для ускорения каких-то определённых вычислений. Есть процессоры общего назначения, есть узкоспециализированные. Если что, вот тут отличный учебный курс по FPGA-разработке. Рекомендую обратить своё внимание на ЯП Форт и Форт-процессоры - как в софт исполнении (на ПЛИС) так и в кремнии (форт-форум). Форт-процессор делается достаточно легко и такой опыт в целом полезен для любого ПЛИС-разработчика. А ЯП Форт очень прост в реализации - ничего проще просто нет. Ну и сам по-себе он очень интересен.

[EvgenySbl]

VoidVolker,

Процессор - это не устройство в воздухе, а устройство для ускорения каких-то определённых вычислений.

Да, я понмаю, что у каждого изделия есть своя сфера применения. По своей сфере деятельности, в основном сталкивался с микроконтроллерами для встраиваемых систем, т.е. от простейшиых PIC16F84 или AT90S1200(который кстати имел 3-уровневый hw stack), включая более менее современные STM32Fxxx (Cortex M0,M3,M4,M7), архитектурами с поддержкой MMU (ARM926EJS, ARM1136, XScale), и немного x86.

Поскольку, процессоры ранее я не проектировал, то хотелось бы для начала что то простое, попадающее в сферу Embedded применений. Можно попробовать сделать что-то простое на уровне Risc-V RV32I, и даже без конвейеризации. Это уже позволит удобно тестровать внутренние блоки внутри FPGA, такие как оперативная память. Можно попробовать сделать процессор с одобитным ALU на произвольную длинну регистров. Если ограничится только сложением и логическими операциями, то процессор должен получится простым, и очень лековесным, быстрым с точки зрения тактовой частоты и медленным с точки зрения эффективной частоты. Но таких ядер можно положить на ПЛИС очень много, и сделать на базе них некие блоки ПЛК, подлежащие программированию.

Но в конечном счете, хочется сделать что-то быстрое, защищенное, с поддержкой Linux т.е. MMU.
Т.е. если подумать, опыт разработки BSP у меня есть, правда это BSP VxWorks. Есть опыт разработки драйверов, правда под Windows. Но они сложнее чем Linux, из-за различных IRQL, на которых доступен лишь определенный диапазон функций и прямой работы с разными пулами памяти (выгружаемой, невыгружаемой).
Кастально процессора. Впринципе я уже могу взять готовый RV32I прикурутить к нему простейший Interrupt Controller, или взять уже готовый RV32xxx c контроллером, и прицепить Mapping встроенной в ПЛИС SDRAM (она видна как PSRAM). Сейчас думаю над вопросом, а что если компилятору gcc скармливать флаги, говорящие о поддержке только RV32I, соберется ли Linux? Это что касается больших ОС. Это касательно конечной цели.

Мыслей много, но все требуется осваивать по шагам. Я давно уже не студент, по этому не использую готовые обучающие курсы. Интернет дает достаточно информации для исследования того что сделали другие. Как и с C/C++ читаю для начала чужой код.

[VoidVolker]

Поскольку, процессоры ранее я не проектировал, то хотелось бы для начала что то простое, попадающее в сферу Embedded применений.

Собственно, как я уже и сказал ранее - Форт-процессор под данную задачу подходит практически идеально. Форт - язык высокого уровня и для Форт-процессора является ассемблером, что само по себе многократно упрощает написание ПО для такого процессора. Встраиваемые системы - одно из основных приложений для Форта и как ЯП и как процессора. Простой, лёгкий, быстрый, очень гибкий. Минус - некоторая специфичность и невысокая распространённость. А из-за слишком большой гибкости нет единого стандарта, которому следуют все форт-системы, что привело к их слабой совместимости между друг-другом. В качестве действительно крутого примера реализации можно отметить GA144 - 144 ядерный Форт-процессор в кремнии. По сути - специализированная числомолотилка для задач ЦАП/АЦП.

Но в конечном счете, хочется сделать что-то быстрое, защищенное, с поддержкой Linux т.е. MMU.

принципе я уже могу взять готовый RV32I прикурутить к нему простейший Interrupt Controller, или взять уже готовый RV32xxx c контроллером, и прицепить Mapping встроенной в ПЛИС SDRAM (она видна как PSRAM).

Да, если конечная цель получить машину с линуксом - то да, вполне имеет смысл взять и доработать под свои задачи.

Сейчас думаю над вопросом, а что если компилятору gcc скармливать флаги, говорящие о поддержке только RV32I, соберется ли Linux?

Конечно соберётся, куда ему деваться-то? Линукс же поддерживает RISC-V. Есть и готовые сборки линукса под RISC-V.

Мыслей много, но все требуется осваивать по шагам. Я давно уже не студент, по этому не использую готовые обучающие курсы. Интернет дает достаточно информации для исследования того что сделали другие.

FPGA разработка - одна из сложнейших областей в программировании, так что в этом случае платные курсы имеют смысл и в целом практичное решение. А официальные курсы с сертификатом от самого производителя полезны при поиске работы FPGA разработчиком. Особенно если планируете в дальнейшем работать в данной области. Ещё лучше, если есть задачи на текущем месте работы и работодатель готов оплатить такой курс - то тут даже и думать не надо, а сразу записываться. Если к FPGA у вас чисто спортивный интерес - то да, лучше использовать бесплатные материалы в сети.

[EvgenySbl]

Конечно соберётся, куда ему деваться-то? Линукс же поддерживает RISC-V. Есть и готовые сборки линукса под RISC-V.

На форумах часто утверждается что нужен еще ряд расширений. Но что-то то мне подсказывает, что соберется если умножение и деление реализовать программно или аппратно как в RV32IM. Буква M в расширении указывает на математику. Вероятно, потребуется реализация Syscall. С математикой, вроде бы понятно. У меня под рукой Cyclone IV EP4CE6 и GoWin GW1NR-9. Во второй, в наличии есть блоки ALU с умножением до 36x36. Т.е. можно использовать аппаратное умножение.

FPGA разработка - одна из сложнейших областей в программировании, так что в этом случае платные курсы имеют смысл и в целом практичное решение. А официальные курсы с сертификатом от самого производителя полезны при поиске работы FPGA разработчиком. Особенно если планируете в дальнейшем работать в данной области. Ещё лучше, если есть задачи на текущем месте работы и работодатель готов оплатить такой курс - то тут даже и думать не надо, а сразу записываться. Если к FPGA у вас чисто спортивный интерес - то да, лучше использовать бесплатные материалы в сети.

К сожалению, на данный момент я не работаю, попал в определенный момент времени под прессинг. А так, работал в АО "Концерн "Созвездие", Antilatency, Auriga (Intel), Renault-АвтоВАЗ.
Железок у меня много, т.к. много покупал в свое время для себя, кое что делал на заказ. Да и время есть.

Университетский курс по цифровым устройствам еще помню. Так что, обращая внимание на архитектуру FPGA, приблизительно понимаю как писать код. Да навыков, может и нет, но что такое FSM, и почему в FPGA все должно быть синхронным, понимаю. Как оптимизировать отдельные модули с учетом ячеек LUT, тоже понимаю. Просто осознаю, что это всего-лишь однбитная память с таблицами истинности и N-адресными входами, по выходу которых опционально стоит D-триггер. Т.е. я понимаю что двубитный сумматор на такой штуке сделать можно, но двубитный сумматор с переносом (по входу) уже задействует соседнюю LUT. Т.е. 2bit+2bit = 1LUT2 + 3LUT4 для параллельных вычислений за минимальное время распространения. Я так же понимаю что есть время распространения clock-а, и разобрался с временными ограничениями.
Попробовал написать hello_world в виде UART-а, используя сдвиговый регистр, и используя state-машину и мультиплексор. Попробовал прототипировать в iverilog работы с контекстным стеком. Продвигаюсь потихоньку. Процессор написать впринципе смогу.

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

Пока это простой процессор, который может содержать адрес следующей команды в регистре или смещение в регистре. Но я уже понял что сделал неправильно. На данный момент думаю над тем как корректно реализвать fetch-decode. Из BSRAM, инструкции вообще можно было не выбирать, а декодировать прямо оттуда, особенно с учетом того что она инициализируется как ROM. Но как только появляются шины, требуется делать fetch. Выборка, это минус один такт. Кроме того, в общем случае нужно дать команду на выборку, и дождаться ее выполнения. На параллельной шине, просто выствить адрес. Если это AHB, то немного сложнее.

Вспоминается детство. Моей сестренке подарили детский кухонный набор. И на нем было написано: "Говорят что дело сложное, самому испечь пирожное. Но если чуточку помучиться, может даже торт получится". Другими словами, буду пробовать.
Спасибо.

[VoidVolker]

EvgenySbl, ещё рекомендую забраться на специализированные форумы по FPGA. На форт-форуме, ссылку на который я ранее давал, есть FPGA разработчики с опытом под 30+ лет - так что можете и там советов спрашивать, если что.