A FPGA based Forth microprocessor

Systems which employ a microprocessor together with an application specic FPGA based coprocessor are common today. These applications can reduce power consumption and system costs by incorporating the microprocessor in the FPGA. For such applications, a microprocessor which has good performance, occupies a minimal amount of FPGA resources, has a good high level language software development environment and good code density is desirable. In this paper a 16 bit FPGA based microprocessor, called MSL16, optimised for such applications is described. MSL16 utilises a stack architecture with each instruction occupying only 4 bits, leading to a small instruction set, simple datapath and control, and high code density. MSL16 was specically designed to effciently execute the programming language Forth. The Forth language has the desirable features of portability and high code density, and it is well suited to control, DSP, realtime and embedded
applications.

The XC4000 is obsolete now, just like as Spartan и SpartanXL. Also, the main conclusion of article is "we CAN make Forth-processors". Is it so unusual today?

Статья на xabraxabr от 14 июля 2014г.
Микроконтроллер своими руками

Hackaday
Open Source FPGA Toolchain Builds CPU J1A CPU for the iCEstick and HX8K development boards.(James Bowman)

P..S. Интересно, а какие примерно частоты синтезированного процессора можно получить, например,
на плате Artix-7 35T Arty FPGA Evaluation Kit?
Здесь для проекта PicoRV32 - A Size-Optimized RISC-V CPU указаны 250-450 MHz on 7-Series Xilinx FPGAs

Видимо, 250. В серии 7 есть разделение по подклассам техпроцессов, где Artix - это недорого, умеренно потребляющее и умеренно быстрое, а Kintex и Virtex - быстро, дорого и достаточно горячо. Однако нужно делать поправку на трассировку всего проекта, где частота, показанная синтезатором, может еще упасть из-за подключения к ядру процессора растянутой по кристаллу периферии.

В конце страницы по ссылке есть таблица с частотами. Частоты, правда, после трассировки, но тут надо, тем не менее, сделать поправку на то, что процессор в ПЛИС не висит в воздухе, а с чем-то взаимодействует. По описанию процессор "переконвейеризирован" - у него CPI 3-6. То есть по сравнению с однотактным циклом мы все равно выходим на 80-150, что в целом характерно для ПЛИС, в которой пара регистров замкнута на себя через АЛУ. Максимальные частоты в ПЛИС достигаются путем тщательного отслеживания logic levels - чтобы ни одно выражение не строилось путем последовательного включения нескольких LUT. Но это сложно на практике, что и видно в PicoRV - там даже АЛУ с конвейером. В итоге это положить в ПЛИС, конечно, можно, но боюсь, что пользоваться будет не так однозначно.

Похоже уже почти "любой" процессор можно уложить в современные FPGA
Propeller ядро на DEO Nano от разработчика кристалов данной архитекуры

P.S. Может имеет смысл данный топик дополнить известными реализациями софт Форт процессоров?
(типа MicroCore, b16 и других).

С определенными оговорками - да. Не все в FPGA получается так же эффективно, как можно сделать в чистом кремнии, поэтому некоторые идеи, используемые в процессорах, плохо ложатся на FPGA.


Ну разве что если кому-то будет интересно. Но ПЛИС развиваются, смещаются приоритеты, поэтому тот же b16 уже мало интересен. В форт-процессоре интересны не какие-то "суперспособности", а (с точки зрения ПЛИС) компактный код, потому что памяти на кристалле маловато, а за пределами кристалла - много вопросов с трассировкой печатной платы. Достигать максимальной частоты для ПЛИС тоже не так важно, потому что "кремниевый" процессор все равно не догнать, да и параллельные ресурсы ПЛИС тоже не догнать. Поэтому смысл софт-процессора в составе проекта на ПЛИС в основном заключается в том, чтобы избавиться от постоянных итераций переписывания кода на HDL, вызывающих для больших ПЛИС многочасовые синтез+трассировку проекта. Как от этого избавиться? Разделить проект на аппаратную (настраиваемую) часть и программную, которая собственно все это и настраивает. Настройкой занимается софт-процессор, а основной работой - аппаратные компоненты. С процессором изменение схемы ради мелких нюансов заменяется на программирование софт-процессора.

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

Видео
N.I.G.E. Machine design

P.S. На видео ещё Nexus2 плата. У меня такая пылится без дела (почти раритет)
Можно попробовать "оживить"
Репозиторий проекта но похоже уже на Nexus4

Mark 1 FORTH Computer
A Forth-like CPU

Статья
Forth CPU. Что это такое? (Часть 1)
Forth CPU. Что это такое? (Часть 2)

Не совсем FPGA (скорее совсем не FPGA, но кто знает)
Цикл статей на хабрахбр (2016г):
Суперскалярный стековый процессор: скрещиваем ужа и ежа
Суперскалярный стековый процессор: продолжаем скрещивать ужа и ежа
Суперскалярный стековый процессор: подробности
Суперскалярный стековый процессор: оптимизация

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


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



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

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

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

+ Ещё один Форт ЦПУ на Github

P.S.Обсуждение на площадке hackaday February 22, 2018

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

Что и продемонстрировано в частном проекте на Github. В чём противоречие?

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

А в чём несамостоятельная ценность Форт?

А, если и такое решение перекрывает предполагаемые потребности? Автор дурак?
Книг по проектированию "правильных" Forth CPU всё равно нет.

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

Тогда нам-то это зачем?


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


Разбираем "общий вид".

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-монитор"), проект можно считать в лучшем случае тренировкой в проектировании.