ткните пожалуйста носом, поиск в проектах на этом сайте привел меня в никуда Спасибо.

des00
Я так понял, вот эта тема http://marsohod.org/index.php/forum-33/raz...-proshivki#3101
Только там нет исходников процессора.

Однажды я из любопытства и для тренировки написал за 4 дня на верилоге клон Lattice mico8(это примерно то же, что пикоблейз), когда он ещё был сам по себе. В результате у меня получилась fmax 145MHz против 85 у оригинала, меньше объём LE, и один такт на инструкцию(кроме исполняемых переходов), вместо двух. Потом посмотрел, как криво mico8 интегрировали в систему с wishbone, и энтузиазм сделать так же и опубликовать почему-то пропал.
В общем, я легко могу сделать на верилоге свободный и открытый аналог пикоблейза с улучшенной растактовкой и системой команд(по прикидке, можно, например, сделать 64 общих регистра и 4килослова кода), присобачить его мастером к AXI/Avalon, и написать на TCL ассемблер. А вот сделать под него порт binutils+gcc энтузиазма уже не хватит. Хотя можно, например, сделать точный клон mico8 под AXI, чтобы к нему подходил софт от Латтис.

Timmy
Поделитесь пожалуйста своими наработками по клону Mico8 (если это не коммерческий проект, конечно).

При всем уважении не верю. По тому как : один такт на инструкцию вида reg = opA + opB означает регистровый файл с асинхронным чтением + асинхронное АЛУ. Регистровый файл у латекса сделан на распределенной памяти, поэтому при переводе на однотактность, вы могли только убрать из АЛУ регистры. Этим, при всем желании, вы не могли увеличить тактовую частоту, тем более 1,7 раза.

Поэтому имею следующее предубеждение :
1. затык по тактовой мико8 находиться не в АЛУ и причина такой низкой тактовой в чем то другом (двухтактовость как раз можно объяснить).
2. в своей реализации вы явно/неявно вырезали то место, которое к этому приводило и ваш проц не является полнофункциональным аналогом мико8

будет интересно отреверсить ваш код, если выложите


Вот это будет интересно, неужели вы на асихронном АЛУ получите больше 200-250МГц которые дает пикоблейз со своим синхронным АЛУ. Ну и если начнете пилить систему команд, то интересно как вы решите ограничение ширины слова команды == оптимальной разрядности блочной памяти

Какую типовую лицензию лучше на него повесить: LGPL, BSD, что-нибудь ещё?

Timmy
Не знаю, я обычно не заморачиваюсь правовыми вопросами, выкладывая что-либо в общий доступ. Вроде как LGPL самая свободная лицензия, типа делайте вообще что хотите.

BSD

~Elrond~, отнюдь. Далеко не такая свободная, как Вам представляется.

лучше всего MITовская лицензия, у меня все открытые проекты под ней идут. Смысл простой : используется как есть, на свой страх и риск. Из ограничений не убирать шапку файла с указанием автора

То есть можно использовать в закрытых коммерческих проектах, менять исходный код? Неплохо.

MIT License

правда что-то про автора я тут не вижу

Большие получились отличия по системе команд от lm8? Не писать же программы в исходных кодах.

меги 128ые (128к флеша) забивали на асме, а тут всего 4к команд. мельчает народ

Зависит от компилятора ЯВУ - насколько переносимым является генерируемый ассемблерный код. Например, переходы - на метку, или же смещение задается константой, и тд и тп.
Для msp430, например, GCC выдает хороший ассемблерный код в плане независимости от системы команд и машинных кодов - можно внести заметные изменения.

Выкладываю обещанный клон Мики8.  mica8.7z ( 417.5 килобайт ) Кол-во скачиваний: 63

Собирается под XP2 на частоте 137МГц(ну немножко медленнее, чем хвастался).
С пикоблейзом его сравнить по частоте невозможно, так как нужна оптимизированная версия под Ксайлинкс. Думаю, что будет примерно одинаково(+-20%). Латтис по частоте удалось обогнать за счёт того, что они вообще толком не оптимизируют код. Мой дизайн эффективнее за счёт двухступенчатого конвейера. Ступени: выборка из BRAM(а это доолго); декодирование+выполнение+обратная запись. В сравнении с Picoblaze или LatticeMico8, у меня к критическому пути добавляется вторая половина АЛУ, зато убирается выборка из BRAM, так что выходит примерно то же самое.
Теоретически процессор должен быть полностью совместим по командам со старым LatticeMico8, до того, как его пришили к Вишбону.
Думаю, что использование 8-битных ядер с кодом более 8-16K нецелесообразно, так как площадь памяти начинает существенно превышать площадь процессора, 8-битное управление большой памятью требует извращений, а ресурсы чипа при этом используются неэффективно. Единственная причина появления монстров типа atmega128, IMHO, в том, что некоторые разработчики страдают синдромом утёнка, изучив в молодости 8051 или AVR или PIC.
Всем спасибо за советы по лицензии.