Захотелось сделать "умную периферию" в ПЛИС (ну чтобы там мат. ожидание посчитала, вела обслуживание низкого уровня на какой-нибудь шине и тому подобное.. в общем неважно) Смысл такой чтобы в ПЛИС поместить микроконтроллерное ядрышко, прицепить к нему периферийку написать программку порядка пол килобайта кода. Обратил внимание на PicoBlase - как положено погонял в моделсиме. Всё хороше, вот только нет для него (или не нашел) с-образного компилятора (компилятор от Франческо - не в счёт - глючной и сдулся совсем). На ассемблере же писать влом - простые вещи долго делаются и глючат (у меня по крайней мере).
Вопрос: наведите на исходники ядра микроконтроллера по весу сравнимую с PicoBlase но для которого существует с-компилятор. AVR и PIC16 - тиобразные корки на опенкорках слищком тяжеловесны.

А здесь были? (скорее всего были, но на всякий случай )

http://www.opencores.com/browse.cgi/filter..._microprocessor

1) tiny8
2) Z80
3) 8051

Был конечно. Или там нет ничего подходящего - или просмотрел. Разбирался с PIC16 - ядром- слишком тяжеловесное (и не ядро вовсе а ядро+ периферия и стек аппаратный, кажется). Тоже самое с AVR (аля AT1200 - не очень хочется из- за аппаратного стека и тоже проблеммы с компиляторос). Остальные процессорные ядра мне незнакомы (Z80 и 51 - в счёт не берутся ибо это не RISC - архитектура и поэтому тяжёлые).

Боюсь, что лучше PicoBlase'а по размерам и быстродействию Вам не найти. Разработчики из Xilinx очень хорошо потрудились над этим ядром и оптимизировали под свою архитектуру. Трудности с написанием программы на ассемблере, тем более 0.5кБ, никак не соизмеримы с трудностями по отладке не проверенных ядер.

Если производительности на частотах ядра (45...50)MHz будет хватать, можно посмотреть на http://www.latticesemi.com/products/intell...$EFu$. Полагаю, более высоких частот ядра, достичь не удасться.

Последняя версия (2.4 на Verilog, про VHDL не знаю) ядра 8-ми разрядного контроллера от Lattice нормально работает, если не использовать прерывания. Я в прошлом году это обнаружил и написал багрепорт. Они не сразу, но в конце концов признали ошибку и обещали быстро исправить. Через полгода они сказали, что у них нет на исправление ресурсов и обещали откорректировать документацию. До сих пор ситуация не изменилась.
Правда это все автору вопроса не интересно, т.к. там есть только ассемблер.

Посмотрел это ядро. Опять - с-компилятора в сети не нашел. Не вникал: стек у этого ядра
сработан в таком же стиле что и у PicoBlaze - макс. 8 урвней вложенности ?? или по нормальному?

http://www.fpgacpu.org/xsoc/index.html

http://www.fpgacpu.org/xsoc/index.html

Можете поподробнее описать. Свои комментарии. Проект кажется староватым и заброшенным...

Там есть С компилятор.
Какое значение имеет срок давности если оно работает?

ЗЫ: как вам уже и говорили - проще взять 51 с фтп и поставить его, он работает на 60-80МГц и имеет 4 такта на машинный цикл. Из средств разработки - любые стандартные.

Очень многократно обсуждалось. Коммерческого смысла не имеет. Разве что сгородить что-нить на остатках логики ФПГА от какой-то исконно ФПГАшной задачи. А так, обычный МК с подходящей периферией, будет куда дешевле и проще. Ну мож МАХ или Кулраннера рядом поставить придётся.

Ну, мне кажется, весьма спорное утверждение. Есть такие виды переферии, которые просто не найти ни у каких микроконтроллеров, решающие весьма специфические задачи. Есть пара проектов, где почти вся главная функциональность повешена на несколько самописных переферийных модулей, а встраиваемое ядро выступает в роли координатора этих модулей + работа с sdram, flash и тому подобное. Это оказалось проще, чем писать координатора на верилоге и описывать конченый автомат на дофига состояний.

Ну а я обо што? "...остатках логики ФПГА от какой-то исконно ФПГАшной задачи..."
Ставить ФПГА, чтобы на ней тольк реализовать некий МК общего назначения, не имеет экономицкого смысла. По любому, десятибаксовый Блэкфин о 800 мипс уделает любую МКшку, реализованную на дваццатибаксовой ФПГА. На МК-задаче, разумеется. Умышленно не считаю загрузочную память там и там. Так у него на борту ещё вагон периферии, которую в данную ФПГА ещё попробуй впихни.

[offtop]
а можно попросить Вас выложить описание бага, и если есть - wоrkaround, например, создав тему в этом разделе, посвящённую LatticeMico-8.
В свою очередь мог бы продолжить начинание (если у кого возникнет интерес), выложив версию, адаптированную к Xilinx Spartan-3 cемейству. (имхо, лишь изначальная заточенность под Lattice ограничивает число использующих LatticeMico-8)
[/offtop]


+100
очень правильные слова

Случайно наткнулся. Может поможет http://www.opencores.org/projects.cgi/web/light8080

Ваша исходная задача крайне непонятно сформулирована. Экономически невыгодно копировать стандартные микроконтроллеры в ПЛИС. Будет не только дороже по железу в разы, но и по трудозатратам на порядки... Да и смысла нет никакого объединять обслуживание периферии и обработку данных. Ну, кроме тех случаев, когда обработка очень простая. В Синклере клавиатуру обрабатывал ЦП, а на РС - кто?
Так вот, если необходимо обслуживать нестандартную периферию, есть смысл ее упаковать в ПЛИС, но тогда, для ее обслуживания нужен и специализированный микроконтроллер. И команд в нем будет не больше сотни-другой. Но зато сами эти команды будут выполнять действия, необходимые именно этой периферии. Тогда здесь не имеет смысла ставить СИ...
А если периферия вполне стандартная, то, возможно, гораздо дешевле будет применить на одной плате несколько дешевых стандартных микроконтроллеров... И сопрячь их по какому-нибудь I2C или LIN...
Вот именно поэтому FPGA-вендоры и не поддерживают Си для 8-ми битников... Нет смысла...
Удачи!

Что не нужно было вчера может понадобиться завтра. Я считаю, что чем городить дополнительные процы вокруг ПЛИС лучше уж утолкать всё внутрь и рассматривать такую периферию как один блок (интегрировал в систему на кристалле- и забыл). Хотелось бы универсальности чтоб не напрягаться сильно - набросал прогу на сях за пол часа - что плохо чтоли? Поэтому сканирую на перспективу... Может и удасться что-нибудь сгородить. Тем более, что с пикоблазе у меня почти получилось - еслибы у Франческо энтузиазм не угас...
Считаю, что очень полезно иметь в своём активе такие наработки...