Это понятно, задумался о другом - микропрограммной эмуляции стандартных микроконтроллеров. Например, при 50МГц тактовой имеем более 50 микрокоманд на каждую эмулируемую команду - можно неторопясь объехать все колдобины(неудобные для FPGA особенности архитектуры МК). В идеале - для эмуляции разных МК меняем только микропрограмму в блочной памяти FPGA. От "подносчика патронов" большая скорострельность не требуется.

эээ. то есть получить аналог х51 машинки? по 50 тактов на команду? но зато эмулируем любой камень? а смысл?

з.ы. дописываю мсп430 ядро. осталось только INT/RETI пару дописать. как допишу - стану оптимизировать, а может и жтаг попробую слепить.

А какой смысл в этом (з.ы. дописываю мсп430 ядро.)?
Для души или есть необходимость по совместимости бинарно?

а какой смысл делать несовместимым? у меня как-то нет желания корячить GCC для новой системы команд, или писать свой компилятор асма.

пишу как альтернативу микроблейзу. да и поупражняться вот хочется. хобби такое.

Свой настраиваемый ассемблер желателен, имхо, если от софт-процессора требуется компактность и быстродействие - стандартные архитектуры плохо ложатся на FPGA. У меня тоже хобби - кучу архитектур перепробовал, пока не надоело. Остановился на той, которая позволяет хоть как-то приблизить синтаксис ассемблера к синтаксису ЯВУ. Например,

вместо стандартного:

Но ассемблер(любой) - имеет смысл лишь для маленьких программ. Вот и подумал - микропрограммная эмуляция какого-либо стандартного микроконтроллера, чтобы использовать готовые компиляторы ЯВУ, и свой ассемблер - для критичных к скорости участков.

Спасибо, об этом как-то не подумалось.

А об этом уже думалось - для задач индикации/неторопливого управления/общения с внешним миром выжимать "100МГц одна команда за такт и ради этого RISC" как-то не очень нужно. Многотактовость команды позволяет разменять скорость на компактность (~ "не торопясь объехать все колдобины") и сделать имеющий бОльшую плотность кода CISC. В свете чтения кода непосредственно из SPI FLASH увеличение плотности кода несколько повысит эффективную скорость работы из этой SPI FLASH (а лимитирующей становится именно она).

для задач управления оптимальным будет использовать что-то максимально просто запускаемое. чтобы оно имело компилятор/отладчик. picoblaze тут - одно из простейших решений по трудозатратам.

но идея "сгородим жуткого монстра, чтобы не тормозить из флешки" - мне не по душе.

простейший оптимизатор в виде "поточное чтение без подачи адреса если команды читаются по подряд идущим адресам" даст на частоте SPI в 16MHz для 16-ти разрядного ядра ~1MIPS. пусть в среднем из-за переходов и данных скорость падает до 0.7MIPS, да такую же производительность имел Z80 в своё время. и какие игрушки на нём при этом летали. (спектрум все видели? ага )

Попалось: PB8051 - эмуляция 8051 на PicoBlaze.
http://www.roman-jones.com/PB8051Microcontroller.htm


Для picoblaze сам Xilinx дает только ассемблер.

При чём тут "монстра"? Я имел ввиду только то, что если уж всё равно нечто многотактовое (минимум 8 тактов на команду, если команды могут быть однобайтовые, при двухбайтовой гранулярности имеем аж 16 тактов), то лучше сделать микропрограммно что-то со сложными командами, грубо

это четрые байта во флешке, а

это восемь байт, которые будут читаться из SPI-флешки дольше и, соответственно, дольше выполняться.
Лимитирует не скорость выполнения команд, которая на более простом ядре выше, а скорость чтения из флеша.
То, что мы согласились на сильное падение скорости, ещё не означает, что не стоит её теперь при почти тех же затратах попытаться поднять :-)

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

а ваш пример экономии - это всего лишь развитая система адресации. что есть у PDP-11. и это одна из мелких причин, почему я отписал своё ядро MSP430.

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

Я сам MSP430 независимо от метода реализации считаю более правильным ядром для впихивания, чем AVR. В том числе потому, что 8 или 16 бит ядро - мало меняет число ячеек, занимаемое проектом, но програма покороче будет. Да и набор команд поортогональнее, должен приятнее реализовываться.
Когда недавно с товарищем обсуждали вопрос "если пихать, то что?", как раз 430-ый и вспоминался.
Если вдруг Ваше ядро будет доступно для свободного использования - с удовольствием поковыряюсь и приму участие в развитии.

Может, с другой стороны подойти к этой задаче - сначала подобрать подходящую виртуальную стековую машину для имплементации в FPGA? Тогда меньше проблем будет с ЯВУ. Поковырялся с Pascal-S - что-то ни одна реализация у меня не заработала...

как мне показалось - совсем наоборот. например регистр PC. он же - R0. в нормальных ядрах его изменяет выделенная команда джамп, и автоинкремент. и обычно хрен его прочтёшь. в итоге регистр с такими ограничениями реализовывать проще. а у MSP430 каждый xor умеет использовать его и как источник, и как приёмник. в итоге логика управления этим регистром - страшная и непонятная.

однотактовое исполнение команд приводит ещё и к другому неудобству: три записи в регистровый файл за такт. это, например, приводит к тому, что все регистры не положишь компактно в ксайлинксах.

что касается выложить ядро для доступа... думаю. поменял бы полностью отлаженное ядро на инфу о том как к нему жтаг прикрутить. а эта инфа - под NDA.

Пришел к выводу, что имеет смысл делать софт-процессор под псевдокод какого-либо компилятора ЯВУ, в моем случае это подмножество Паскаля. Исходники компилятора и интерпретатора виртуальной машины Pascal-S открыты(1..2К строк), можно приспособить к своим нуждам(изменить набор/интерпретацию псевдокодов, реализуемое подмножество языка, и тд и тп).

Все примерно так и делают Большинство софт ядер явно или косвенно соответствуют языку C.