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

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

BSD

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

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

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

MIT License

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

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

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

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

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

Timmy
Спасибо за исходники. Там есть модуль pmi_rom, это корка ксайлинксовой памяти? Какая у неё latency на чтение?

Там всё под Латтис. pmi_rom - это корка блочной памяти в режиме ПЗУ, латентность один такт.

А отдельного Си компилятора нету, чтобы на Альтеру имело смысл перенести ядро?

Как мой вопрос связан с количеством ассемблерных инструкций?
Вопрос был связан со средствами разработки (отладчик, симулятор, транслятор/компилятор). Новая система команд - новые инструменты.
А 128к ассемблерных инструкций меня не испугаешь.



От компилятора ЯВУ на мой взгляд отличия системы команд не зависят вообще. Не процессор же пишут под конкретный компилятор, а компилятор под систему команд процессора. Править ассемблерный код после компилятора на мой взгляд не очень продуктивное занятие.


А как система команд зависит о шины? Там вроде всего две команды работы с шиной import/inp и export/outp.

Для LatticeMico8 есть backend к gcc, так что компилятор Си как бы есть. Правда, я что-то не видел исходников патча для binutils, только gcc. С-компилятор там какой-то странный, он во всех моделях памяти(включая 8-битную) делает 32-битные указатели(по-крайней мере, так в мануале написано). В случае переноса на классические Циклоны, придётся хранить регистры, стек и scratchpad в одном M9K(туда же можно запихнуть и код), при этом один такт на инструкцию невозможен. Предполагаемый объём для клона Mico8 - 270LE.

Если С-компилятор - интегрированный в софт от Lattice, тогда смысла в переносе lm8 на Циклоны нет, наверно.


Согласен, у M9K/etc нет гарантированного режима "write before read", чтение и запись _данных_ в одном такте рискованно делать (без проверки адресов).

квазиасинхронку сделать.

Leka
Для имитации асихронного поведения блочной памяти на cyclone III я прибегал к чтению/записи данных по negedge, частота конечно падает, но работает нормально.

В моем miniByte на Cyclone III с памятью М9К, инструкция выполняется за один период тактовой частоты. Это при входном регистре адреса в М9К и без выходного регистра данных... Для обработки двухбайтных команд применил двухпортовый доступ, где текущий и последующий байт считываются одновременно..
Что тут не так, в чем вопрос?

Serhiy_UA
А как вам удалось обойтись без выходного регистра данных, если память в cyclone III синхронная? на выражение типа такогоквартус отвечает, что не может синтезировать такое на блочной памяти.

Для памяти программ используется Tools ->MegaWizard Plag-In-Manager ->Memory Compiler ->ROM 2-PORT, где в диалоге задается регистр адреса на входе и выход памяти без регистра данных. А далее двухпортовая память включается в проект примерно таким кодом. То есть, я задал в Memory Compiler тактирование только регистра адреса:
[//------- ROM 2 ------
rom_2p rom_2p_inst (
.address_a ( a),
.address_b ( a+1),
.clock ( clk),
.q_a ( q),
.q_b ( q1)
);
][/code]

Serhiy_UA
Отключение этой опции в мегавизарде приводит к уменьшению latency с 2 до 1 такта, но никак не ликвидирует её полностью.

Хорошо, тогда к тому коду, что был выше, еще несколько строк кода, что бы понять основные увязки:
always @ (posedge clk or posedge reset) //write PC
if (reset) PC<=0;
else PC<=a;

То есть, какая-то комбинационная схема КС, что в момент выполнения текущей, формирует адрес "а" для следующей команды.
С выхода КС адрес "а" одновременно записыается и в программный счетчик РС и в регистр адреса, что есть на входе памяти М9К.
Таким образом все выполняется за такт, и с одним фронтом clk,

Да еще, второй регистр на выходе М9К, позволит на конвейере выполнять две команды одновременно. Но здесь надо почитать теорию, что бы не изобретать велосипед. Пока мои поиски соответствующей литературы ничего не дали..

Да, можно сделать ,то что надо, на двух M9K, плюс потребуются два bypass регистра и схема обнаружения коллизий чтения/записи по одному адресу, это +30LE примерно. Так в nios2 делают, просто для пикопроцессора это чересчур, IMHO.

Timmy
А можете поподробнее рассказать, как альтеровцы сделали однотактовое чтение из блочной памяти в ниосе?

Конкретно у альтеровцев, полагаю, классическая архитектура MIPS, по ней в Сети достаточно материала.
А по-простому, это можно сделать так: берутся две двухпортовых M9k, порты записи объединяются, в результате оба M9k содержат одинаковую информацию. А порты чтения независимо читают первый и второй операнды. Только необходимо, чтобы память поддерживала режим "сначала пишу, потом читаю", что означает, что при совпадении адресов чтения и записи на выходе должны появиться свежезаписанные данные. Поскольку M9K такой режим не поддерживает, придётся его эмулировать при помощи внешней обвески:
то есть, если адреса чтения и записи совпали, в следующем такте выход данных переключится с выхода m9k на bypass, который содержит свежие данные, которые сам m9k ещё не готов выдавать.
Такую обвеску надо независимо добавить к обоим M9k, работающим у нас параллельно. Странно, что это не умеет делать Мегавизард.

это умеет делать квартус сам, при синтезе памяти из описания, как рекомендовано в темплейтах

Из даташита на CycloneIII (для CycloneV то-же самое):
"Mixed-Port Read-During-Write Mode
This mode applies to a RAM in simple or true dual-port mode, which has one port reading and the other port writing to the same address location with the same clock. In this mode, you also have two output choices: Old Data mode or Don't Care mode. In Old Data mode, a read-during-write operation to different ports causes the RAM outputs to reflect the old data at that address location. In Don't Care mode, the same operation results in a “Don't Care” or unknown value on the RAM outputs."

А синтезировать память из описания Квартус не может, если есть сигнал разрешения клока.

В темплейтах 9.1 квартуса.

Ух ты, круто. Об этом я не знал, раньше в темплейтах было указано, что нужно было вручную через assign байпассить текущее входное значение.
И это всё конечно хорошо, но всё равно ни о каком чтении за один такт из синхронной памяти речи здесь не идёт. ) Защёлкивать данные по заднему фронту - это конечно решение, но вряд ли получится даже 100 МГц тактовая. Есть ли другие варианты? Как альтера сделала регистровый файл на М9К, если у неё латенси 1 такт, а для регистрового файла нужно 0?

От регистрового файла не нужно 0, если правильно применять конвейер. Даже в моём вышеприведённом mica8 с двухступенчатым конвейером латентность регистрового файла 1. В первом такте/первой ступени выбирается код инструкции и номера регистров из этой инструкции подаются непосредственно на адресные входы модуля регистров, где будут защёлкнуты при смене тактов. Вскоре после начала следующего такта на выходе регистов будут необходимые значения, которые прогоняются через АЛУ, и к концу такта результат стабилизируется на входе данных записи регистрового файла. Из-за особенностей распределённой памяти удаётся обойтись двумя портами адреса, это особенно эффектно смотрится на Ксайлинксах.

А у Ниоса конвейер пятиступенчатый, там целый такт выделен на выборку из регистровой памяти и защёлкивание в FF непосредственно перед АЛУ.

к ~Elrond~
Вы намерены регистровый файл разместить в М9К?
Каков объем этого файла?
Если объем малый, то почему бы этот файл не разместить на регистрах?

Если все же остаться с М9К, то может сбрасывать часть данных из М9К в регистры, работать там с ними, а потом опять весь блок возвращать в М9К. Что-то типа кеша... Иначе только конвейер...

Serhiy_UA
Я знаю, что так сделано в ниосе, и мне интересно, как. Если конвейер - то это не интересно, так и я умею. )) Регистровый файл мне нужен в разных модулях разный, в зависимости от задачи. Обычно это 4-16 32-битных регистров, что в случае 16ти на LUT'ах делать довольно накладно.

Всем привет!

Есть немного странный вопрос, если коротко зачем процессору регистры? У меня есть очень длинное объяснение откуда возник этот вопрос, но его никто не прочтет.
Потому кому не трудно напишите что особенного вы видите в регистрах, в сравнении например с РАМ. А там тему можно будет и развить.

быстрый + "без адресный" доступ.
алтернатива:
стек (форт)
spark (???) - там регистры отображены на общую память.

кто такое сказал?

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

насчет безадресный не согласен, если регистров больше 1 то адресовать регистр надо. То есть мультиплексор все равно появляется

быстрый-возможно, вот думаю 3 блока РАМ чтобы можно было делать R1 + R2 -> R3, а учитывая 2 портовость брамов интересная идея. И опять же уход от стека, можно младшие адреса - адрес регистра, а старшие - адрес страницы, вход в прерывание, перебросил адрес страницы и дальше погнали. Что я не учитываю?

http://electronix.ru/forum/index.php?showt...mp;#entry763390
http://electronix.ru/forum/index.php?showt...mp;#entry866940
http://electronix.ru/forum/index.php?showt...p;#entry1277540

По ссылкам видно вы проделали большую работу,
Основной вопрос имеет ли смысл регистры делать массивом на ЛУТах, если сделать их на БРАМах где возникнут сложности?

Нажмите для просмотра прикрепленного файла
свободного выхода от этого регистра в BRAM-е напрямую обратно в матрицу - нету.

т.е. регистр обратно не считать, автоинкремент не сделать

Регистры - это вообще-то тоже РАМ, причём в хард процессорах они обычно делаются на такой же матрице, что и большая SRAM. В процессоре регистры отличаются короткой прямой адресацией, быстрым доступом без необходимости кэширования, локальностью(нет необходимости их синхронизировать в многоядерной системе). Хотя локальная РАМ в многоядерных DSP тоже бывает. Для эффективного хранения регистров в BRAM используется конвейер, типа вот такого. Там рабочие копии регистров гуляют по быстрым защёлкам на границах ступеней конвейера ID/EX/MEM/WB, а за синхронностью рабочих копий и общей матрицы(которая на ступени ID) следит Forwarding Unit.

ну то есть надо на самом деле сделать 3 портовую оболочку брам, даже чуть проще 2 порта чтения и один запись, и автоматом получиться огромный регистровый файл.
А вот теперь вопрос, зачем регистры в таком решении отделять от РАМ проца? Выигрыш только в сокращении шины адресации?

В регистрах на LUTах можно за один такт складывать любые 2 и писать в третий, но эта возможность порождает дикие мультиплексоры которые жрут все LUTы, альтернативой я так понимаю служит несколько тактовая операция R1+R2->R3, реализуемая через 3 портовую БРАМ.

И в этом случае у меня получается что нет смысла делать отдельно БРАМ регистров, и включить его в общий РАМ проца. Правильно рассуждаю или я что-то не учел?

Давайте порассуждаем.
Команда в Вашем случае должна содержать:
Опкод - 1 слово.
Адрес первого операнда - 1 слово.
Адрес второго операнда - 1 слово.
Адрес приемника - 1 слово.
+ 2 такта минимум на чтение операндов.
+ 1 такт на исполнение в АЛУ.
+ 1 такт запись результата.
Итого получили 8 тактов.

В RISC процессоре:
2 такта на загрузку первого операнда.
2 такта на загрузку второго операнда.
1 такт на исполнение в АЛУ.
1 такт на запись результата.
Итого получили 6 тактов.

В Вашем случае можно сэкономить 1 такт начиная считывать первый операнд
не дождавшись конца загрузки команды.
Можно еще укоротить адреса операндов (например в одном слове 2 адреса источников).

не понял расчета)

у меня тогда получается 4 такта.
2 такта на чтение операндов и 1 такт на исполнение, 1 такт на запись.

Почему вы в такты включили размер команды? Или почему вы в RISC процессоре исключили загрузку команды?

А где 4 такта на извлечение команды?
Если, конечно, Вы не сделаете извлечение 4 слов команды за 1 такт.
Иначе нарушается конвейер при выполнении каждой команды за 1 такт.
Я уже не говорю о том, что команды обработки данных перемежаются с командами ветвления.
Хотя это справедливо и для тех RISC, где каждая команда имеет длину в 1 слово.

Ну РИСКу тоже надо извлекать команду как не крути, так что им один такт тоже надо добавить.
Потом код операции размером в слово - очень много, нафига столько команд.

То есть остаются адреса, если память длинная, то они большие, это верно.
1. извлекаем адрес 1 операнда
2. Задаем адрес 1 операнда на РАМ, читаем адрес 2 операнда
3. Читаем 1 операнд, выставляем адрес 2 операнда, извлекаем код операции
4. Читаем второй операнд, извлекаем адрес результата
5. Обрабатываем команду, выставляем адрес результата
6. Сохраняем результат.

Команду даже можно в 2 такта выполнять, на 4 и 5. .
А я хочу пойти дальше ограничить адреса 256 значениями и словной адресацией, и сделать 32 битную команду с 8 битным кодом операции, тогда получаем за 1 такт все адреса и команды, читаем их, выполняем, сохраняем.

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

Спасибо народ! %)

Ну если достаточно 256 слов памяти, почему бы и нет. Можно предусмотреть и команды доступа к "большой" памяти с непосредственным смещением 8-10 бит(2 бита откусить от кода операции), OpenRISC с этим как-то живёт.
А как вы будете кодировать команды с непосредственным операндом? Их, правда, можно сделать двухадресными, а не трёхадресными, как в MIPS, тогда появятся 16 свободных бит под непосредственный операнд.

забыли ещё про регистр-адрес текущей выполняемой инструкции.
если его тоже в озу хранить, то добавляйте такты на его чтение, а также при условных/безусловных переходах такты на его запись и чтение.

планировал его вторым словом после команды. Что-то аля Thumb2, то есть там 16 бит команда, но если надо 32. У меня будет 32 бита - стандарт, если надо 64.

Память команд будет с 64 шиной чтения, то есть после задания счетчика команд будет доступно сразу 2 слова, на случай если понадобиться операнд (таких случаев будет на самом деле 90%) в работе проца.

Счетчика команд, как и контрольный регистр - это будут 2 единственных регистра сделанных в ядре на ЛУТах. Счетчик команд будет жестко посажен на шину памяти команд, как адрес.

Как то так планировал. Мне и РАМ то по хорошему не нужна, для того что делаю, больше нужны всякие РОНы, но надо чтобы ядро все луты не сожрало.

Есть такой вопрос. Наверное на него легко найти ответ. Но что-то я не нашёл.

Процессор без портов в/в это не процессор. Собственно вопрос как их организовать? Наверно где-то есть статья для зелёных новичков, но что-то я не заметил. С примерами на Virelog.


Изучая схему IBM AT компьютеров там наглядно показана работа с портами. Но всё таки такой вопрос как принято это делать у плисоводов?

Обязательно ли в процессоре должен быть блок УУ(устройство управления, анг Control unit) который осуществляет выбор функции по #CS (chip select)

В IBM AT было всего 6 основных чипов по 16 портов каждый.
А вот в IBM PS/2 уже более "оптимально" каждый чип мог иметь произвольное число портов. Поэтому располагались они плотнее.

Отсюда вопрос какие есть инструменты для автоматического генерирования дешифратора адреса?

Ещё можно включить проверку адреса в сами функции, как это сделано в PIIX когда перешли с шины ISA на LPC.

PS. Наверно мне надо ещё что-то прочитать про мультиплексоры.