[Golikov 0]

Всем привет!

 

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

 

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

 

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

[Alex77 4]

Всем привет!

 

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

 

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

 

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

Не в тему

А может picoblaze from xilinx ?

[Lmx2315 2]

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

mk_control.v

[alman 0]

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

 

Не претендую на шибко "умного человека", но Вы можете увидеть мой ответ в теме "Свои процессоры".

 

В целом этот велосипед уже изобрел,

 

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

 

 

 

 

[RobFPGA 27]

Приветствую!

 

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

А смысл этого ? Похвастается своими велосипедами?

"... Смотрите у меня аж 16 передних колес на 32 дюйма каждое..."

"... а у меня 3 педали для целых и плавающих ног, и ног со сдвигом суставов в обе стороны..." :cranky:

"... а..а..а у меня 5-тиступенчатая передача, вот! могу разогнаться до 100 км/ч, но только по очень ровной дороге..." :maniac:

 

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

 

Для образовательных же целей загляните на стоянку opencores.org - там этих велосипедов тьма. Причем есть как поделки под фирменные модели так и драндулеты непонятной породы - и сразу можно брать и ехать (не забыв конечно колеса накачать :1111493779: ).

 

 

Успехов! Rob.

[alman 0]

А смысл этого ? Похвастается своими велосипедами?

 

Смысл соревнования? Хотя бы в том, что победитель(победители) имеет шанс - его разработкой могут заинтересоваться сторонние разработчики.

 

"... Смотрите у меня аж 16 передних колес на 32 дюйма каждое..."

"... а у меня 3 педали для целых и плавающих ног, и ног со сдвигом суставов в обе стороны..." :cranky:

"... а..а..а у меня 5-тиступенчатая передача, вот! могу разогнаться до 100 км/ч, но только по очень ровной дороге..." :maniac:

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

 

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

С этим не спорю. Ну вот, к примеру, SoC для платы Марсоход2 - автор даже портировал компилятор Си на свой процессор. Он и на electronix.ru в соответствующей теме рекламировал свою разработку - а в ответ получил ти-ши-ну. А это реально бесит - игнор хуже критики.

 

Для образовательных же целей загляните на стоянку opencores.org - там этих велосипедов тьма. Причем есть как поделки под фирменные модели так и драндулеты непонятной породы - и сразу можно брать и ехать (не забыв конечно колеса накачать :1111493779: ).

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

 

 

[Pavia 0]

Для Lmx2315:

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

Мне ваш код тоже понравился. Тем более достаточно оригинальный подход, такие процессоры не часто встретишь.

 

alman

Процессоры бывают разными. Я бы сказал можно выделить 3 класса- "слабый", "средний", "сильный". И их сравнивать как-то не очень.

[iosifk 3]

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

Бред полнейший.

Процессоры в ПЛИС не делаются как "процессоры вообще". А делаются только под конкретную задачу. И именно эту задачу они и могут выполнять. А задачи у всех разные. И что будем сравнивать?

И что касается Си, то сейчас это стало вообще не актуально с появлением чипов с АРМом на борту.

Что остается? Только небольшие вычислители, программируемые на ассемблере. Просто сам Си подразумевает определенную архитектуру, а она не для всех задач нужна. А если учесть то, что одной командой на ассемблере можно делать несколько операций, то для "мелкого" и этого вполне хватит. Ведь вот для ADSP2181 не было Си, и ничего при этом страшного не произошло.

[Golikov 0]

Спасибо ответившим. Спасибо за пример, обязательно погляжу. Спасибо за предложение соревноваться, но пока что не буду:) не до того...

 

Очевидно были заданы правильные вопросы, на которые у меня есть некоторые ответы.

 

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

 

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

 

 

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

 

К примеру:

Можно сделать команды такими:

код команды, источник данных, операнд, куда записать результат

А можно

код команды, источник данных, операнд, куда записать результат, константа

А можно

код команды, адрес аккумулятора, константа

 

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

 

как сделать сравнение:

можно сделать команды

если А больше Б переход

можно сделать

Б-А

проверить флаг отрицательного знака, если да, то переход

 

и так далее... Вот такие мысли меня сейчас занимают.

 

[Serhiy_UA 1]

Тема интересная, но в конечном итоге все может увязнуть в экономике.

Нужны оценочные критерии для выбора между тремя путями: большой FSM, уже готовым софт-процессором и разработкой своего программируемого микроконтроллера.

Если разработка своего МК, то как загружать в FPGA его программу, какие варианты? Как заставить стартовать МК с нулевого адреса?

[Golikov 0]

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

 

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

 

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

 

[RobFPGA 27]

Приветствую!

 

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

Вот как раз если набора фиксированных состояний начинает не хватать то тут прямой путь к софт процессор

 

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

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

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

Проблема шаловливых ручек пользователя при написании программы решается разными путями -

от программных, предоставлением ему библиотеки (Вами писаной и верифицированной по самое не могу) с соответствующим API,

до аппаратных - kernel/user mode, вынос критичных функций управления в небольшие FSM и запуск их программно (по сути та же библиотека только в железе).

 

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

 

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

Вариантов как это реализовать не изобретая с нуля собственный велосипед море - например берете любой детский велосипед (тот же MicroBlaze например) - блок программной памяти делите на два блока - в одном ПЗУ пишете свою либу критичных функций управления, а во вторую часть доступную для записи грузите пользовательские фантазии. Еще чуть чуть усилий и можно добавить сюда же kernel/user mode, заднее анти-крыло и толстую выхлопную с резонатором :) и тогда все девки-usera будут ваши.

 

Успехов! Rob.

 

 

 

 

[alman 0]

Процессоры в ПЛИС не делаются как "процессоры вообще". А делаются только под конкретную задачу. И именно эту задачу они и могут выполнять. А задачи у всех разные. И что будем сравнивать?

 

Я не согласен с тем, что процессоры в ПЛИС делаются только под конкретную задачу. Процессоры делают все, кому не лень и никто не может запретить кому-то сделать универсальный процессор. Вопрос, будут ли им пользоваться - это уже другой вопрос.

 

И что касается Си, то сейчас это стало вообще не актуально с появлением чипов с АРМом на борту.

ARM - это в некотором роде фетиш. Ярые сторонники Intel его до сих пор за процессор не считают.

 

Что остается? Только небольшие вычислители, программируемые на ассемблере. Просто сам Си подразумевает определенную архитектуру, а она не для всех задач нужна. А если учесть то, что одной командой на ассемблере можно делать несколько операций, то для "мелкого" и этого вполне хватит. Ведь вот для ADSP2181 не было Си, и ничего при этом страшного не произошло.

 

Таки что будем сравнивать? Поскольку пока никто не предложил задачу, то в качестве одной из задач предлагаю сравнить реализацию протокола X-modem. Конкретно - ресивер, использующий протокол X-modem. B)

 

[RobFPGA 27]

Приветствую!

 

Бред полнейший.

Процессоры в ПЛИС не делаются как "процессоры вообще". А делаются только под конкретную задачу. И именно эту задачу они и могут выполнять. А задачи у всех разные. И что будем сравнивать?

И что касается Си, то сейчас это стало вообще не актуально с появлением чипов с АРМом на борту.

Что остается? Только небольшие вычислители, программируемые на ассемблере. Просто сам Си подразумевает определенную архитектуру, а она не для всех задач нужна. А если учесть то, что одной командой на ассемблере можно делать несколько операций, то для "мелкого" и этого вполне хватит. Ведь вот для ADSP2181 не было Си, и ничего при этом страшного не произошло.

 

Я бы уточнил - любые процессоры разрабатываются под конкретный КЛАСС задач. Отсюда все многообразие зоопарка. И ARM тут всего лишь одно из семейств зверюшек.

 

Как это не было С для ADSP2181, а VisualDSP (я правда уж очень давно педалил для этого DSP но до сих пор очень теплые воспоминания)? Но эффективно программировать ADSP2181 в ассемблере было отнюдь не просто хотя (по сравнению с DSP от TI 6000 серии) там все команды исполнялись за такт - чтобы эффективно распределить алгоритм по исполнительным блокам надо было попотеть.

Ну а ваять ВСЕ на чистом asm для TI 6000 серии так это вообще мрак.

 

Удобный, эффективный, РАСПРОСТРАНЕННЫЙ!!! язык программирования для конкретной софт системы это САМОЕ ВАЖНОЕ (при наличии соответствующего инструментария этого языка для данного типа системы конечно :) )

 

Успехов! Rob.

 

 

 

 

[Golikov 0]

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