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

А об этом уже думалось - для задач индикации/неторопливого управления/общения с внешним миром выжимать "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.

Можно пример _простой_ виртуальной машины Си с открытыми исходниками? Ява отпадает в силу громоздкости полной системы(по сравнению с Pascal-S).

Nios, niosii, microblase, xr16 и много других - у всех в основе лежат базовые операции регистровых машин(с можно по большому счету отнести к регистровым языкам). Сделать неоптимизирующий компилятор С на базе lcc не составляет проблем.

http://www.246.dk/pascals3.html
Менее 1000 строк кода для компилятора с интерпретатором - аналогичное для Си - ???.

а зачем изобретать велосипед? смысл совместной заточки компилятора под ядро и ядра под компилятор? все равно - трудозатрат больше, а эффективности меньше.

с момента рождения i4004 прошло 37 лет. за это время родились сотни архитектур, большая часть которых банально вымерла. но посмотрите какой список поддерживается GCC? может, проще всего выбрать наиболее простое и мелкое ядро поддерживаемое GCC и реализовать его? как мне кажется - одно из наиболее оптимальных - PDP-11. но вот незадача - неудобно отладку вести. вот с такими вот соображениями я и выбрал MSP430 для реализации.

Это где их раздают? Вот slog больше месяца назад попросил велосипед, не требующий доработки напильником - чтобы в булочную за углом мотаться - ничего лучше карьерного самосвала ему так и не предложили.

Не совсем так, подбирается псевдокод, под который легко заточить и компилятор, и ядро - чтобы можно было независимо менять/оптимизировать и софт, и железо. Что касается заточки компиляторов, вместо цепочки: код на ЯВУ --> оптимизирующий компилятор --> код на ассемблере --> компилятор --> машинные коды, предпочел бы видеть: код на ЯВУ --> оптимизирующий препроцессор --> код на ЯВУ --> компилятор --> псевдокодкод --> оптимизирующий ассемблер --> машинные коды.

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


над первой цепочкой трудится куча программеров уже. и вчера. над вашей - трудится только вам и прочим фанатам.

Понятно, что лучше продать 100 неуниверсальных оптимизирующих компиляторов Си-->асм под 100 конкретных архитектур, чем 10 универсальных Си-->Си.

вот только эти неуниверсальные будут однозначно шустрее чем универсальные. да и потом - так или иначе переводить си->асм придётся. и наибольшая степень оптимизации доступна именно в этом переходе.

Уже начал делать ядро под Паскаль - интересные идеи пришли по безрегистровой архитектуре (сначала опробую со своим ассемблером - легко настраивается на любую систему команд). Основной упор - на аппаратную поддержку локальных/нелокальных переменных и вызовов подпрограмм.

эээ. ооо. то есть переменные цикла - в раме?

Да. Два 10нсек такта на a+=b в раме - не устроит, что-ли?

%)) у дураков мысли сходятся

есть проект, в который просто идеально встает свое небольшое ядрышко с CISC командами и двумя Wishbone интерфейсами, комманд на 100.

Начал делать наброски. В этот раз буду делать кодогенератор на питоне, благо опыт и наработки имеются %)

хм. прочитать а, прочитать б, записать результат в а - вроде три такта? али я что-то непонимаю?

а адрес этих а и бэ где берётся? как их отличить от цэ и дэ ?

а как адресовать много памяти? что-то я идеи не понимаю...

ну вообще это можно и за 1 такт сделать %) прочитать a и b, сложить и записать в память. Но для этого нужна асинхронная/квази асинхронная память, а за 2 такта так на обычной делается. a,b прочитать и результат записать.

думаю что уважаемый Leka во фразе


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

Память внутренняя, двухпортовая, поэтому прочитать "а" и "б" - один такт.

Из 32(36)-разрядной инструкции.

Все массивы, структуры и тп доступны только по ссылке через переменные индексов/полей и базовые регистры(скрытые) --> непосредственно адресуемый объем памяти не превышает максимально допустимого числа переменных в одной любой подпрограмме(независимо от вложенности и тп). Устанавливаем, например, максимальное число переменных в подпрограмме(или глобальных в программе) = 127 --> 7-ю разрядами (+ дополнительными служебными) адресуем хоть 4Гб "регистровый файл на памяти" (для 32х-разрядного ядра).

А все-таки, чем вас не удовлетворяют уже готовые крутые кристаллы с ядром ARM-9 на 200 MHz? Или например крутые DSP-процессоры? Все ведь уже сделано, готово, работает и по цене ниже FPGA, на которой изобретаете велосипед. Сакральный вопрос- зачем?

какие-то меня сомнения берут... вот например: обработка сетевых пакетов, или данных валящихся в буфер по уарту, ну не важно откуда. обычно имеется до десятка переменных обрабатывающих этот буфер (счётчик цикла, регистр для подсчёта контрольной суммы, индекс, размер массива итп), при этом сам буфер явно в регистровый файл ну никак не влезет. получается, что большая часть регистрового файла будет простаивать, а вот доступ до данных буфера будет не таким быстрым. a[i]+=b[i] далеко не за два такта. и декодер для таких команд будет ого-го.
делать много-много мелких регистровых файлов (?), при этом вроде можно получить практически мгновенное переключение контекста.

32(36) бит на команду - много кода во внутренней раме не положишь...


приведу простой пример - есть пачка телекоммуникационных плат, которые обрабатывают потоки E1. давно теми же буржуями просчитано, что обработка этих потоков на ПЛИС дешевле в десяток раз чем мучить их в DSP. вот стоит на этих платах плисина, крутит эти потоки, и крутит под управлением проца, которых только и делает, что принимает команды с RS232 и переводит их в приятных для плисины вид. в кратце: на проце сделан юзер-интерфейс.
спрашивается, нахрена платить $5 за проц, если можно его упихать в дальний угол FPGA и пусть он там копошится.
а к процу ж идёт свой стабилизатор, обвязка, его ж запаять нужно, прошить, проверить. и всё это далеко не бесплатно.

Супротив мелких задач на примитивном софтпроцессоре, затерявшемся где-то в уголке FPGA,- я не возражаю. Мне непонятно,- зачем Leka изобретает что-то грандиозное по производительности и истратит внутренние ресурсы FPGA на изобретение велосипеда?

И переменные, и буфер в одной физической памяти, декодеру без разницы. Данными буфера можно манипулировать через указатели(*a += *b - за 3 такта), промежуточные переменные (с += b[i] - за 3 такта), и тд.


Зато эффективнее при интенсивной работе с памятью - за счет отказа от load/store архитектуры.



Софт-процессор будет маленьким.

Это вам так кажется. маленький - это когда пара инструкций и примитивные вычисления через аккумулятор(например tiny16 с форума ниос). Если делать еще что-то сверху, то получится не меньше nios2/s по лутоемкости.

эээ. что там с адресацией? буфер в 1.5к для эзернета - это 11 разрядов. sorce/destination - уже 22 разряда в команде на адрес. + разряда по 2 на вид адресации. 2*(11+2) = 26 бит в команде скушано на адресацию источник/приёмник. а как быть с адресацией на большие области памяти? лишний такт на выборку адреса?


ой берут меня сомнения.

По поводу Leka пусто он сам отвечает, хотя кажись несколько страниц назад, когда я спрашивал - ответ был ясен - для души.
А по поводу софт процессоров я Вам уже писал, но вы проигнорировали ещё такую тенденцию: ёмкость FPGA растёт, и уже самые маленькие FPGA часто не заняты и на 50%, спрашивается, нафиг мне ставить ещё один корпус если я могу загнать тот-же Nios в свободное место.
А вообще - инженер должен по ситуации смотрит а не придерживается "религоозных" точек зрения.

У меня на Спартане3 ядро с регистровой архитектурой(load/stote) занимает ~~25 лут/разряд, половина из них приходится на 2-портовый 32-регистровый файл с 2-мя асинхронными чтениями и 2-мя записями за такт. Те ~~450 лут на 18-разрядное ядро c командами типа:
a += b; // +, -, &, |, ^, ...
a = b + const; // +, -, &, |, ^, ...
A[i] = b; // i++, i--
a = B[i]; // i++, i--
label(a<b); // <, <=, =, >, >=
...
Для "безрегистрового" варианта выкидывается регистровый файл, взамен добавляется другая логика, ~~100 лут по предварительным оценкам, выходит: ~~300 лут для 16-разрядного и ~~500 лут для 32-разрядного ядра.




int i, a, *buf[1500];
a = *buf[i]; //команда адресует a, buf, i, но не *buf.


Да.

32*18=576, т.е. для альтеры будет 1152 lut?! Это есть больше чем 32 битный nios2/s с полным набором средств разработки

A u menya k vam drugoi vopros. Podskajite ARM s "normal'noi" sinhronnoi 32 razryadnoi shinoi chtob k FPGA ceplyat'.

Не понял арифметики.
У меня ядро - под Xilinx, для Альтеры делал бы совсем по-другому. Ядро бесконвейерное, все команды за 1 цикл(в тч все переходы, вызовы/возвраты из подпрограмм, чтение/запись в памяти), возможны 2 операции за 1 цикл, например:
[a++]=b; b=const //автоинкрементное сохранение в памяти и загрузка константы
a=[b--]; call_subr //автодекрементное чтение и переход на подпрограмму
В "безрегистровой" архитектуре этого не будет, но зато будет большая переносимостьи и проще будет прикрутить ЯВУ(надеюсь).
Nios2/s - 5-стадийный конвейер, переходы за 2-4 цикла... - мне не интересно.

Имхо, для управляющих программ(внутри FPGA) большая часть кода приходится на if-then-else, вызовы мелких процедур и обмен с памятью, а не на линейные вычисления. Это и стоит оптимизировать.

Это примерная калькуляция - умножаем на 2 и получаем количество лутов затраченных на это в альтере.


В указанном ядре его нет - любая команда исполняется за 5 тактов + время доступа к шине(памяти, периферии и пр., но это уже не относится к ядру).


Вопрос не совсем корректно ставится - а стоит ли "овчинка выделки". Сделать ядро может практически любой, а самой сложной задачей является обеспечить это все нормальными средствами разработки!
яву+макропроцессор+ассемблер+линкер(хотя необязательно)+отладчик(системного уровня)+куча прочего софта - потянуть можно, но сложно. Без этого минимума ядро пойдет топором.


Я бы так не сказал. Вы слишком приземляете задачи.
Например : информацию(результат обработки информации) нужно раздать в 10 комов, каждому потребителю в своем формате и со своим протоколом, в фоновом режиме рисовать на небольшом экранчике небольшой графический user friendly интерфейс.

Это Nios2/e, 6 тактов.


Конечно!


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


Вроде такие задачи и приводят к большому числу if-then-else(анализ флагов, полей и тп) и перекачкам память-память(шаблонных строк и тп).

Все уже придумано до вас! В gcc все необходимое для этого есть и портируется он на любой проц, а lcc который я указывал выше - проще и без оптимизации
Связка разработка цпу+автоматическая генерация заточенного под него есть в пакете от coware, даже частично присутствует сами знаете где. Только работы там отнюдь не меньше, чем при ручном портировании gcc.
Не зря люди требуют большие деньги за компиляторы - над ними работают толпы бородатых математиков, придумывают новые принципы и методы оптимизации.
Людям не нужно маленькое и оптимальное, а нужно простое в использовании, эксплуатации и стабильное.

По информации из недостоверных источников не помню откуда взятой - профессиональное портирование gcc обойдется примерно в 50k$.


Ваш метод эффективен только для работы с внутрикристальной памятью. Как только вы полезете наружу - все быстродействие снизится в разы за счет того, что внешняя память ограничит вам рандомный доступ до 20-50нс.
По растактовке - в предложенном вами методе if-then-else имеет минимальное быстродействие по сравнению с прочими оговариваемыми вариантами (рег. файл и стэк). даже простейший вариант:
ld *a; if (a== b ) :
eq *b; если равно пропускаем следующую строку
goto eq1n;
eq1:;then
...
eq1n:;код под else
...
проигрывает при работе с внешней относительно ядра памятью, а если она внешняя - mipsы поползут вниз катастрофически.
Как ни крути - вы все равно сделаете тоже самое, только вверх ногами и под углом )

Ну что-ж, дело молодое.
Да, тенденция наращивания ресурсов FPGA безусловно заметна. Hо, одновременно, заметна и тенденция возрастания стоимости таких монстров. Так например, я считаю, что стратиксы от Altera недоступны по цене для мелкого разработчика. И сколько еще потребуется времени ждать, пока они подешевеют до разумных цен- неизвестно. Таким образом, тендеция наращивния ресурсов на самом деле торпедируется тенденцией увеличения стоимости. А пока, гораздо выгоднее использовать какой-нибудь простенький циклончик в комбинации с внешним микроконтроллером, тоже за копейки. Причем, одновременно получаешь такие выгоды, которые недостижимы в системах на одном кристалле.

Я лично таких не знаю. Но сам цепляю ARM к FPGA через быстрый SPI.

Aprox, да даже в самый дешевый циклончик можно засунуть три ниоса, и еще немного места останется. Не всегда нужен внешний микроконтроллер, тем более через SPI. Это уже сто раз обсуждалось, и не зачем так навязчиво навязывать свою точку зрения. Нравится отдельный проц - применяйте. Я тоже так делал не раз. Но у проца внутри тоже есть свои плюсы. И иногда они перевешивают. И какой вариант будет выгоднее - решать тому кто будет это реализовывать. Поверьте, проц внутри тоже имеет право на существование.

Не совсем понял зачем кивать на стратиксы, у них своя ниша, для бюджетных проектов - циклоны.
И посмотрите, сколько ячеек есть в самом маленьком 3-м циклоне, найдётся куча ситуаций, когда они будут на половину использованы. Не вижу смысла в такой ситуации использовать внешний проц, если хватает Ниоса. И эта тенденция будет прогрессировать. Ваша позиция имела смысл лет 5 назад, когда микрухи были маленькими по ячейкам.
Поэтому на сегодняшний день вопрос о ненужности таких ядер IMHO не стоит, нужны они.
Вопрос в том, чтоб применить их там, где они проект облегчают по себестоимости или другим параметрам. А тут универсальных советов нет, нади по ситуации смотреть, на то мы и инженеры

Бростье вы это дело, уважаемому форумчанину Aprox объяснять что либо из этой области или спорить с ним бессмыслено. Это приведет к только закрытию темы модератором.

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

Киваю для иллюстрации, каким образом большая стоимость превращает в бессмыслицу "тенеденцию наращивания ресурсов". А значит и Ваш тезис, мол в больших FPGA всегда найдется место для софпроцессора, потому что ресурсов там- море разливанное.
Во-первых, даже если осталось больше половины неиспользованных ресурсов, то я не стану их занимать чем ни попадя, а оставлю в качестве резерва для последующих наращиваний и модернизаций устройства. Живая практика показывает, что такой резерв абсолютно необходим. Во-вторых, смысл использовать внешний проц в том, что это позволяет выбрать FPGA самую простую, самой низкой стоимости и самой простой в монтаже. И при этом, разработчик совершенно ничего не теряет в функциональной сути устройства. А только выигрывает в скорости выполнения работ.
Здесь консенсус. Ситуацию действительно надо оценивать трезво.

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

свободные ресурсы FPGA могут быть по одной причине - какой-то другой тип ресурсов занят полностью. например в одном из моих проектов выбор XC3S100 вместо XC3S50 был обусловлен только количеством блочной памяти. а это значит, что LUT`ов свободно было море, и что замена внешнего проца на софт-ядро - это дополнительная экономия денег.

Опять религиозная война начинается?
Если обсуждение не войдёт в нормальное русло тема будет закрыта
С уважением, модератор

Сравниваю "безрегистровую" и регистровую архитектуры мелких софт-процессоров... Пример - работа с памятью:

Так вам мухи или котлеты? Если делать как вы говорите, то регистровая архитектура(!) выигрывает 5 к 8, т.к. любая команда исполняется за 1 такт тем более в оптимизированном по dataflow ассемблерном коде.
Вот если бы вы затронули тему сохранения контекста, которого нет(или минимален) в предложенном вами варианте (похоже, единственный весомый аргумент) Вот только память - она ведь не только быстрая бывает, но и большая и тут уже надо смотреть от чего проку больше.

"Безрегистровое" ядро может проиграть регистровому не более, чем в 2 раза - по тактам, зато может выиграть в 7 раз - по плотности кода: [code]
//"безрегистровое": 1команда 4такта
*a = *b + *c

//регистровое, "пустой магазин": 7команд, 7 тактов
r1 = b
r1 = *r1
r2 = c
r2 = *r2
r2 += r1
r1 = a
*r1 = r2

Те по минимаксной стратегии "безрегистровое" ядро предпочтительнее.

Шар - вид слева, шар - вид справа...

Последние ваши расчеты мне не понятны.
Предлагаю подитожить немного:
1. С точки зрения кода - предложенный вами вариант является регистровым процессором с вынесенным относительно ядра виртуальным регистровым файлом(со всеми вытекающими плюсами по эффективности использования).
2. С точки зрения быстродействия с внешней памятью ввиду п.1 быстродействие будет более зависимо от типа используемой памяти(Для примера - произвольный доступ к дешевой dram памяти составляет примерно 5-6 тактов)