Итак, начну пожалуй из далека
Во первых, я крайне восхищен появлением такого ...
Во вторых, я крайне удивлен (от части даже завидую), с какой "легкостью" люди это делают ...
(для тех кто не в курсе чего я "разорался", тыкайте сюда http://forum.electronix.ru/index.php?showtopic=2004)

Теперь по существу.
Я, как и многие "юзера" FPGA, озадачился вопросом "это мне надо?".
И решил в меру своих возможностей сравнить PicoBlazer и "Стековый процессор", ну или по крайней мере определить сектора задач и потребностей в ресурсах.

"Стековый процессор"
"Синтезировал" вариант процессора, конфигурация которого идет в "комплекте". Изменил только настроки ядра процессора с 3 на 8 бит (вроде еще знак включил ).
PicoBlazer.
Блайзер как блайзер, добавил PROM, в виде BRAM, добавил по одному одноразрядному порту на вход и выход.

"Земля! Прощай!"
Важные части отчета PAR Стекового процессора
...
Number of BLOCKRAMs 2 out of 14 14%
Number of SLICEs 148 out of 2352 6%
Number of GCLKs 1 out of 4 25%
...
+----------------------------+----------+--------+------------+-------------+
| Clock Net | Resource | Fanout |Net Skew(ns)|Max Delay(ns)|
+----------------------------+----------+--------+------------+-------------+
| clk_BUFGP | Global | 73 | 0.501 | 0.763 |
+----------------------------+----------+--------+------------+-------------+
| sc_clk_second10 | Local | 7 | 2.197 | 3.938 |
+----------------------------+----------+--------+------------+-------------+
...
--------------------------------------------------------------------------------
Constraint | Requested | Actual | Logic
| | | Levels
--------------------------------------------------------------------------------
NET "clk_BUFGP/IBUFG" PERIOD = 25 nS H | 25.000ns | 24.476ns | 7
IGH 50.000000 % | | |
--------------------------------------------------------------------------------

Теперь PicoBlazer
...
Number of BLOCKRAMs 1 out of 14 7%
Number of SLICEs 75 out of 2352 3%
Number of GCLKs 1 out of 4 25%
...
+----------------------------+----------+--------+------------+-------------+
| Clock Net | Resource | Fanout |Net Skew(ns)|Max Delay(ns)|
+----------------------------+----------+--------+------------+-------------+
| p30MHz_BUFGP | Global | 55 | 0.428 | 0.697 |
+----------------------------+----------+--------+------------+-------------+
...
--------------------------------------------------------------------------------
Constraint | Requested | Actual | Logic
| | | Levels
--------------------------------------------------------------------------------
NET "p30MHz_BUFGP/IBUFG" PERIOD = 16.667 | 16.667ns | 16.192ns | 6
nS HIGH 50.000000 % | | |
--------------------------------------------------------------------------------

Ну как видно из отчета, такой же по разрядности Стековый процессор занимает в два раза больше места, и в 1.5 раза медленнее

Теперь еще заковырки.
Скриншот Floorplanner Стекового процессора
Нажмите для просмотра прикрепленного файла
Скриншот Floorplanner Picoblazer
Нажмите для просмотра прикрепленного файла

Если обратите внимание на заштрихованные области, я до сей поры считал, что это части слайсов затянутые констрейном RLOC, который появляется когда синтезатор находит "библиотечные" макросы с HDL. Подобные вещи будут просто спасательным кругом в случае "сильно" заполненного кристалла, особенно для чайников. А как видно из рисунков, в процентном соотношении Picoblazer выигрывает.

1. Объём. В этом примере, насколько я понял, два подопытных процессора находятся несколько не в равных условиях. А именно: PicoBlaze не содержит ОЗУ, таймеров и системы прерываний. Ту же задачу можно было решить дешевле, но это просто пример программирования, а не пример «светофора». Хотя признаю, что PicoBlaze потребует меньше пространства.
2. Скорость. Время выполнения команды у PicoBlaze 2 машинных цикла, у StackCPU – 1.
3. Размещение в кристалле. Согласен.
Итог: сравнение в пользу PicoBlaze признаю.
Но сравнение PicoBlaze и StackCPU это не то же, что и сравнение продукции Intel и AMD, чьи процессоры обязаны работать с одной и той же периферией и, что самое главное, выполнять один и тоже код.
Возможности. PicoBlaze имеет всего 2 арифметические команды («+», «-»), правда выигрывает в области сдвига данных. Не содержит в себе ни портов ввода-вывода, ни таймеров… Разрядность: строго 8. Объём программы: 256 слов (У StackCPU нет ограничения, автоматически соединяются BlockRAM в требуемую разрядность и глубину). Те же замечание по ОЗУ.
Языки программирования. PicoBlaze – ассемблер, StackCPU – форт. Форт куда приятней, в плане неплохого соединения низко и высоко уровнего программирования.

Жаль, что нет сравнения с MicroBlaze. Его Xilinx то же создал оптимизированными под свои ПЛИС различных серий.

Спасибо за дружелюбный ответ!
Если честно, я ожидал шквал брани и уличений в некомпетентности.

Теперь по пунктрам.
У PicoBlazer имеется один вектор прерывания. Ну а добавить таймер - несколько слайсов.

<2. Скорость. Время выполнения команды у PicoBlaze 2 машинных цикла, у StackCPU – 1.>
Это радует!

<Языки программирования. PicoBlaze – ассемблер, StackCPU – форт. Форт куда приятней, в плане неплохого соединения низко и высоко уровнего программирования.>
В общем согласен, но ломка привычки программирования, то же требует мотива.

<Жаль, что нет сравнения с MicroBlaze. Его Xilinx то же создал оптимизированными под свои ПЛИС различных серий.>
Щас будет!
Скриншот MicroBlaze
Нажмите для просмотра прикрепленного файла
Развелся на 50МГц.
Хотя номинально занимает около 500 слайсов(на глаз), как видно из рисунка, занимает фактически половину кристалла. Если допустить логику пользователя в область самого процессора (левый здоровый прямоугольник), добром это не кончится

Скриншот Стекового процессора на 32 разряда
Нажмите для просмотра прикрепленного файла
Занял 241 слайс (10%). Развелся на 30МГц.

Скриншот Стекового процессора на 16 разрядов
Нажмите для просмотра прикрепленного файла
Занял 180 слайсов (7%). Развелся на 40МГц.

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

Еще. Если огрубить процесс "синтеза" (так проще будет) процессора (не включать таймеры и IO, выбрать одну разрядность), то можно создать RPM макрос на процессор, чем увеличим частоту и стабильность разводки. Правда тогда от дебугера наверное много пользы не будет.

Еще. Склоняюсь к мысли что СП - "золотая" середина между PicoBlaze и MicroBlaze. Первый, как Вы верно подметили, слишком ограничен, второй слишком "развесист".

MicroBlaze занимает 500 слайсов на Spartan 3, где есть встроенные умножители. А во втором Spartan умножение реализуется на всякой логике, вот процессор и раздулся.
СП 32 разряда, стеки 16+16, с сумматором и умножителем на той же микросхеме (XC2S200) займёт не меньше.

Согласен, что PicoBlaze слишком ограничен, MicroBlaze слишком "развесист". Но StackCPU - это не между PB и MB. Он из другой области. Наберите в Yandex «стековый процессор» и увидите, сколько их, даже купить можно. Под те же ПЛИС выпускают. А StackCPU – это ответ Иосифу Каршенбойму
http://iosifk.narod.ru/stack_up1.pdf

Похоже вы давно не смотрели на PicoBlaze. Вариант для Spartan 3 и круче имеет порты - по 256 i/o. И 1024 слова програмной памяти.
To keep the record straight

Я на днях запихал в Cyclone некое подобие PIC. И подумал: а зачем мне такой мощный процессор? Надо бы написать что то совсем маленькое когда будет время - у меня он только для общения через UART. Логики мне не жалко, только медленно он собирается.

Написать процессор это еще пол беды(даже четверть), тут еще и sdk понадобится.

to kuchynski
А все-таки, имеется зависимость необходимой глубины стека и разрядности процессора?

to alexf
<Похоже вы давно не смотрели на PicoBlaze. Вариант для Spartan 3 и круче имеет порты - по 256 i/o. И 1024 слова програмной памяти.>
Дык у "старого" PB тоже 256 i/o. А эти 1024 слова получены не переключаемыми секторами? Иначе еще то порно.
Ссылкой не поделитесь?

1024 слова получены благодаря большей bram. Прости, PicoBlaze, просмотрел.
Глубина стека и разрядность никак не связаны.

Все вполне натурально: у Spartan 3 (и всяких дорогих Vitex) BRAM стал 16кбит вместо 4. Так что один блок и дает 1К инструкций (18 бит толщиной).

Кстати о PicoBlaze: на сайте Xilinx есть свежая версия в которую включен пример заливки кода ПОСЛЕ через JTAG. Возни побольше чем с Алетеровским Memory Editor, но все же.

Из этох соображений я и сделал подобие Microchip PIC. Чтобы пользоваться ассемблером и эмулятором. С ассемблером все хорошо, а с эмулятором облом вышел - моя вариация на тему PIC слегка отличается. Впрочем мне все равно - уже все на железе работает.

<Все вполне натурально: у Spartan 3 (и всяких дорогих Vitex) BRAM стал 16кбит вместо 4. Так что один блок и дает 1К инструкций (18 бит толщиной).>
Вы сами его юзали. В старом ограничение в 256 слов из-за архитектуры, я боюсь что из 16кБит будет использоваться только 4.

<Кстати о PicoBlaze: на сайте Xilinx есть свежая версия в которую включен пример заливки кода ПОСЛЕ через JTAG>
Кстати, помнится Вы спрашивали "кратчайший" способ подмены содержимого BRAM, на чем остановились? Пробовали Guide mode?

В сети есть 2 бесплатных проекта _S_i_m-n_M_L_ и _P_A_D_L_A_.
Первый достаточно мощный но под линукс(до конца не удалось разобраться, но чего-то работает), для win портировать не получилось(надо libstdc модернизировать).
Второй (Россия) не до конца реализован(нет переходов меток макро, хота для риск процессора это можно реализовать снаружи) но работает под win и автоматом генерит asm dasm iss, недостаток написан на странном языке ocaml(сл-но доработать сложно).

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

Обьясните чем же все таки стековый процессор так хорош, ведь чем больше разнородной памяти тем сложнее ее вынести за пределы кристалла, а ставить 3 мсх озу (2 стека и инструкции) не так уж и эффективно.
Мне больше нравится архитектура с большим(16,32 регистров на окно) регистровым файлом внутри процессора, и памятью инстр./данных снаружи.

Самое по моему мнению большое достоинство - плотность кода. Т.е. если посмотреть на тот же ARM - плотность кода у него оставляет желать лучшего. Поэтому-то и придумали режим Tumb, использование которого (теоретически) должно сократить объем кода в два раза без снижения быстродействия. Однако из собственного опыта могу сказать, что в Tumb-режиме объем кода сократился приблизительно на 33%, а скорость выполнения не только не возросла, но и сократилась приблизительно на 40% (В качестве основной задачи выступала арифметика с большими числами - 256 бит).

<Самое по моему мнению большое достоинство - плотность кода. >
Склоняюсь к мысли что плотность кода 32 разрядного СП будет всего на пару десятков процентов выше плотности MicroBlaze. Ну а в Вашем примере не вижу парадокса, даже наоборот, удивляет столь малое падение производительности. Умножение двух 32 разрядных чисел на 16 разрядном умножителе займет времени больше, чем в два раза.

Не соглашусь, т.к. основное отличие системы команд стекового процессора заключается в отсутствии операндов в коде команды. Т.е. если сравнивать с MicroBlaze (который, как я понимаю, подобен рискам) то выигрыш может составить больше двух десятков процентов. Чтобы не быть голословным, перейду к цифрам. У MicroBlaze код операции в 32-х битном коде команды занимает лишь шесть разрядов. Т.е. у стекового процессора в 32-х битном слове поместится приблизительно 5 команд, если команды шестибитное. И 4 команды, если поле восьмибитное, соответственно. Т.е. плотность упаковки повышается как минимум в четыре раза. При этом Вы можете сказать "А как же команды загрузки операндов?". На что будет вполне логичный ответ - у MicroBlaze они тоже есть, только в другом виде. А вообще стоит посмотреть на picoJava и технологию Instruction Folding. Очень интересно.



Нет, парадокс все-таки есть. Т.к. в режиме Thumb процессор по-прежнему оперируется 32-х разрядными регистрами, правда их число сокращено всилу сокращения размера слова команды. Так что пример с умножением в данном случае не подходит для объяснения снижения производительности. Даже наоборот, с простым умножением получится, что объем кода сократится в два раза, а производительность не уменьшится. Но когда мы переходим от одной операции к целой программе, то тут моя практика показала, что производительность снижается. <_<

Есть 4 версии PicoBlaze. Четвертая под CPLD. Не знаю что она умеет, а 3-я с которой я работал написана специально под Spartan3, Virtex II и т.д. и использует все 18 бит в ширину и 1К таких слов. Медицинский факт - сам работал с ним.

Что касается заливки BRAM, то я нашел в последней версии включенный модуль чтобы это делать через JTAG. Но не успел с ним поиграть поскольку переключился на более срочный проэкт на Альтере где это сделано штатно.