2012 года. Оно уже устарело окончательно, даже kf532 редко применяем.

KF 332 - конфигурируемое процессорное ядро

https://msyst.ru/index.php/activities/forth/114-kf-3xx

P.S. Картинки на странице пропали. :)
и нет обновления новостей.

Проект для M02mini: Процессор языка Forth в FPGA
https://marsohod.org/projects/proekt-m02mini/410-forth-j1

Проект для M02mini: Простейший интерпретатор Forth в плате M02mini
https://marsohod.org/411-prostejshij-interpretator-forth-v-plate-m02mini

[quote="KPG"]Eщё один Форт-процессор оригинального дизайна на Github.[/quote]
1. 16 бит, low-end. В современные low-end лезет и 32, и 64. Внутри полно команд для двойной длины. Отсюда вопрос - а зачем было сразу себя ограничивать?
2. Понятия "назначение", "целевые задачи" опять проигнорированы. Получилось упражнение по расстановке полей команды.
3. "Верификация еще не начиналась" :) То есть оно еще, возможно, и не работает? :)

Eщё один Форт-процессор оригинального дизайна на Github.
[url=https://github.com/hotwolf/N1]N1 on Github[/url]
([url=https://github.com/hotwolf/N1/blob/master/doc/N1_manual.pdf]N1_manual.pdf[/url])

P.S. Нашёлся при поисковом запросе Forth Cpu.

Spartan-3A. Снят с производства. Ячейки другие, непрограммируемые ресурсы другие. Под современные FPGA надо корректировать.

FORTH processor with Java compiler
[url=https://github.com/freecores/myforthprocessor]MyForthProcessor[/url] (Download репозитория порядка 200Мб)

[quote="KPG"]Насколько формат подобной упаковки процессорных Форт команд позволяет проводить локальные действия по ускорению кода?[/quote]
Однозначного ответа тут нет. Формат команды тесно связан с микроархитектурой процессора. Можно ведь такого накрутить, что схема станет медленнее просто из-за необходимости разобраться в сложной команде с разной ролью одних и тех же битов в разных случаях.

[url=https://github.com/drom/quark]QUARK[/url]

QUARK is a simple dual-stack CPU instruction set architecture (ISA) that can be extended.
QUARK uses Head-and-tail instruction format, described in [url=http://www.cs.berkeley.edu/%7Ekrste/papers/hat-cases2001.pdf]Hedi01.pdf[/url]

Насколько формат подобной упаковки процессорных Форт команд позволяет проводить локальные действия по ускорению кода?

[quote="KPG"]Социальные сети обсуждения, зачастую, все такие. Автор "тянет" лямку один в этом проекте.[/quote]
Тогда нам-то это зачем? :D

[quote="KPG"]А в чём несамостоятельная ценность Форт?[/quote]
Ценность у него появляется в составе проекта, когда Форт или форт-процессор позволяют эффективно решать конкретные технические задачи. Под задачами я имею в виду не только и не столько "вывести в порт", сколько достижение определенных характеристик в плане размера проекта, требуемого объема памяти, интеграции в систему и общий маршрут проектирования. В этих вопросах Форт показывает себя как раз хорошо. Когда же на Форте делается "как и везде, но на Форте", резонный встречный вопрос "ну и чем вам не нравилось как и везде?". Если изначально не ставилась задача сделать не как везде, а в чем-то лучше, то очередная форт-поделка будет благополучно похоронена и удостоится разве что ностальгических воспоминаний вида "да-да, я тоже в 198x году что-то подобное делал".

[quote="KPG"]P.S. Чем, по существу, плох данный проект?[/quote]
Разбираем "общий вид".

1. Адрес 13 бит и это жестко задано в системе команд. Т.е. больше 16 к ячеек он адресовать не может. Это уровень embedded-устройства.
2. 16 бит - опять же embedded. При этом что-то из периферии даже в embedded сейчас ориентировано на обмен 32-битными данными. Общая тенденция - 16-битные системы заменяются на 8-битные с целью удешевления и снижения потребления или 32-битные, поскольку добавка в цене невысока, а средства программирования удобнее.
3. Нет умножения (если добавить умножение, частота упадет, да) - это именно чтобы сохранить частоту на 100+ МГц (зачем? кто просит именно высокой частоты, кроме общих соображений "я сделал быстрый процессор"?), или ориентация на простые операции с манипулированием данными без особенной обработки.
4. Стек возвратов 64 ячейки - зачем это в embedded (см. выше - характеристики выглядят как embedded).
5. Стек переменных на 65 ячеек - это вообще что? Так назван стек данных?
6. Нет вычитания, потребуется эмуляция через инверсию и инкремент. При этом синтезатор в ISE прекрасно строит комбинированный элемент adder/subtractor, так что вычитание лишних ресурсов не требует.
7. Система прерываний просто скопирована с решений общего характера. Не решена проблема обработки нескольких одновременно приходящих запросов, хотя именно это является сильной стороной FPGA-решений и софт-процессоров.
8. Сброс асинхронный - человек не в теме. Spartan-6 такое может быть и позволит с точки зрения запуска на чипе, но хотя бы в базовых вещах писать надо с учетом требований элементной базы.

0. Что на этом сделано, кроме демонстрации работы периферии? Или сделать должны мифические последователи, которые бились-бились без этого процессора, а он им вдруг раскрыл глаза, и все сразу стало хорошо? Если автор не знает, куда его применить, или у него нет каких-то реальных запросов (уровня "вот есть датчик, надо его показания вывести на VGA-монитор"), проект можно считать в лучшем случае тренировкой в проектировании.

[quote="Hishnik"]Подобный процессор "проще написать самому, чем разобраться в этом". [/quote]
Что и продемонстрировано в частном проекте на Github. В чём противоречие?
[quote="Hishnik"]Комментарии довольно показательные - вместо преобладания вопросов "а как на нем сделать...", все умиляются очередному музейному экспонату. [/quote]
Социальные сети обсуждения, зачастую, все такие. Автор "тянет" лямку один в этом проекте. :)
Постов, на этом ресурсе с тегом Forth достаточно мало, что бы делать какие то выводы о целевой группе заинтересовавшихся людей.
[quote="Hishnik"]
Происходит такое потому, что Форт представляется в виде религиозного фетиша и ему приписывается самостоятельная ценность. Вроде бы сделали что-то с приставкой "форт-", и тут же сотни последователей должны подхватить идею и написать тысячи библиотек и проектов.[/quote]
А в чём несамостоятельная ценность Форт?
[quote="Hishnik"]
Вместо этого форт-процессор должен разрабатываться как ответ на поставленные задачи проектирования, при условии, что сами задачи формулируются с прицелом на Форт. И там уж сколько будет разрядов, где стек, какие команды, какая шина - это все становится предметом обсуждения, и получиться должно так, чтобы с этим потом было максимально удобно работать.[/quote]
А, если и такое решение перекрывает предполагаемые потребности? Автор дурак?
Книг по проектированию "правильных" Forth CPU всё равно нет.

P.S. Чем, по существу, плох данный проект?
Генератор бредовых ответов - OFF :)

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

[url=https://github.com/howerj/forth-cpu]+ Ещё один Форт ЦПУ на Github[/url]

P.S.[url=https://hackaday.com/2018/02/22/forth-system-on-chip-takes-us-back-to-the-80s/]Обсуждение на площадке hackaday[/url] February 22, 2018

Нет, не очень интересно.

[quote]Обе эти крайности имеют существенные изъяны: в случае стека фиксированного размера, мы имеем проблемы с компилятором и/или операционной системой, которые обязаны думать о том, что произойдет, если стек переполнится или опустеет и как отработать соответствующее прерывание. [/quote]
Это уже выглядит явной натяжкой, вокруг которой начинают строиться дальнейшие рассуждения. А почему вдруг аппаратный стек должен внезапно кончаться? Это вобщем-то аварийная ситуация, которая не должна возникать при корректно написанной программе. Что касается переполнения, то стеки, выделяемые современными компиляторами, теоретически тоже могут переполниться - они же не бесконечные. Но что-то никто не делает из этого глобальную проблему.

[quote]в результате мы имеем непредсказуемое поведение программы, не позволяющее использовать такой процессор, например, в системах реального времени,[/quote]

Черт... у меня многолетние комплексные галлюцинации? :D Стек - это ведь не обезьяна с гранатой, хаотично меняющий глубину. Обычно работа со стеком идет по принципу "положили - посчитали - записали", и числа на нем не копятся. Всяческие глубокие рекурсии - это уже экзотика, а вложенные вызовы вполне можно контролировать компилятором. В ebmedded не переполняются не то что 32 ячейки, а даже и 16. В PC стек то ли 1024, то ли 4096, и его переполнение - это практически однозначно результат некорректной программы.

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

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

Не совсем FPGA (скорее совсем не FPGA, но кто знает)
Цикл статей на хабрахбр (2016г):
[url=https://habr.com/post/278575/]Суперскалярный стековый процессор: скрещиваем ужа и ежа[/url]
[url=https://habr.com/post/279123/]Суперскалярный стековый процессор: продолжаем скрещивать ужа и ежа[/url]
[url=https://habr.com/post/280087/]Суперскалярный стековый процессор: подробности[/url]
[url=https://habr.com/post/281352/]Суперскалярный стековый процессор: оптимизация[/url]

[code] ...
Эпилог

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

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

На первый (дилетантский) взгляд, не видны принципиальные проблемы, препятствующие реализации такой архитектуры в “железе”.

Мы намеренно не рассматривали такие вещи, как:

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

Всё это вопросы важные, но менее принципиальные.
А на данный момент автор считает свою задачу выполненной.
[/code]