Всем привет!

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

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

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

Не в тему
А может picoblaze from xilinx ?

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

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



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

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


А смысл этого ? Похвастается своими велосипедами?
"... Смотрите у меня аж 16 передних колес на 32 дюйма каждое..."
"... а у меня 3 педали для целых и плавающих ног, и ног со сдвигом суставов в обе стороны..."
"... а..а..а у меня 5-тиступенчатая передача, вот! могу разогнаться до 100 км/ч, но только по очень ровной дороге..."

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

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



Успехов! Rob.

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


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


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


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

Для Lmx2315:

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

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

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

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

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

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

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


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

К примеру:
Можно сделать команды такими:
код команды, источник данных, операнд, куда записать результат
А можно
код команды, источник данных, операнд, куда записать результат, константа
А можно
код команды, адрес аккумулятора, константа

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

как сделать сравнение:
можно сделать команды
если А больше Б переход
можно сделать
Б-А
проверить флаг отрицательного знака, если да, то переход

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

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

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

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

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

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


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


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

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


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

Успехов! Rob.

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


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



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

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



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

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

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

Успехов! Rob.

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

Интересно, опишите...

Ну что же, будет оно все вот так.

Все регистры управления периферией у меня 32 битные, и проц. будет таким.
Программа будет лежать в 2 портовой памяти на Брамах и для процессора будет только для чтения

Оперативной памяти пользователю достанется 4, 32 битных регистра, совмещенных в единое пространство со всеми управляющими регистрами.
Будет 3 специализированных регистра, в том же пространстве памяти
1. это счетчик команд, фактически адрес очередной выбираемой из памяти команды
2. это таймер, который сбрасывается в ноль по спец команде записи в управляющие регистры, а дальше считает каждый клок вперед
3. это аккумулятор куда попадают все результаты операций сложения, вычитания, логического И и ИЛИ, этот регистр будет 33 битным, чтобы просекать переполнение, к этому регистру будут 4 флага, аккумулятор == 0, больше 0, меньше 0, переполнение.
Все входные сигналы на схему собраны в 32 битный регистр в том же пространстве, для этого регистра предусмотрены прерывания

Основные операции, которых будет большинство это задание констант и ожидание заданное время, потому память программы будет 8192 слова по 64 бита. И все команды будут иметь фиксированный вид 32 бита - код операции и адреса операндов, и 32 бита константа. Удобно выжать 16536 слов памяти в 48 бит не удалось, а память хочется иметь цикличную, чтобы после последнего адреса, она прыгала на 0, потому решил не жаться и сделать 8192 слова по 64 бита.

в целом команды будут иметь общий вид
[code] [addr1][addr2][constant]
code - это код
addr1, addr2 - это адреса данных/операндов:
0 - константа из команды, N - регистр из общего адресного пространства


команды будут
0. NOP
1. задать значение в addr1 из addr2
2. задать значение в периферию из addr2, со сбросом таймера
(тут на самом деле серия команд, которые меняют комбинации регистров управления, но все они делают одно, задают значения и сбрасывают таймер)
3. ожидать пока таймер не превысит значение из addr2
4. вычесть, прибавить, ИЛИ, И данных из addr1 c данными из addr2, результат в аккумулятор
5. выполнить переход по данным из addr2, если выставлен флаг регистра аккумулятора (какой флаг выбирается маской)

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

Прерывания:
будут 4 прерывания, все они работают с регистром входных сигналов, для них можно задать
1. полярность входа (какой уровень активный)
2. маску (какие сигналы генерируют прерывание)
3. активный уровень прерывания, 0 или 1 вызывает прерывание
4. адрес перехода, вектор прерывания фактически
5. разрешение прерывания

прерывание <= |((вход ^ полярность) & маска);

Если прерывание разрешено и его значение равно активному уровню, схема переходит по заданному вектору, и снимает разрешение всех прерываний. Адрес с которого совершен переход сохраняется в спец регистре.

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

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

В текущей архитектуре это не нужно, но наверное стоит проработать....

А я сделал специализированный процессор для несложных вычислений, используется для ПИД регуляторов с обвязкой и всего такого.
Система команд похожа на PIC, одноадресная, команда 10 бит, данные 20(но могут быть любой длины, при желании). 64 адреса под порты, константы и переменные(регистры), которые можно расположить в любом соотношении. команды загрузки, сохранения, сложения, вычитания, минимума, максимума, умножения, деления, корня, сдвига на произвольную константу, переходы безусловный и условный по знаку аккумулятора. Фиксированная точка стоит перед первым значащим битом, то есть диапазон значений для умножения, деления, корня считается от -1.0 до 1.0-2^-19. Частота 200-250МГц на ECP2, весит около 700 ЛУТ(из них примерно 300 модули умножения, деления, корня), один такт на инструкцию, простой трёхступенчатый конвеер. По соотношению производительности к "весу" трудно найти что-либо подобное.
Ассемблер написал на TCL, всего 248 строк, всё очень просто, и макросы на TCL удобно делать, чего очень не хватало в своё время на MASM:).
Вместо пихания временных значений в регистры по номерам используется директива temp, которая связывает имя временной переменной с первым свободным регистром, а end_temp - освобождает. Такого, вроде, ни в одном ассемблере нет, а очень удобная штука.
Чтобы закодить 150 инструкций, Си как бы и не особенно нужен.
Вот ассемблер, сам процессор тоже могу выложить, если интересно, он не секретный.Нажмите для просмотра прикрепленного файла
И примерчик кода:

к Golikov A.
Все же, какая целью этой работы. Похоже, что защита от конкурентов, но здесь масса других вариантов.
Или разработка самому себе программируемого помощника взамен одной или нескольких FSM.

к Timmy
В части temp - действительно что-то новое. Это взамен дополнительного аккумулятора, стека (LIFO) или очереди (FIFO)? Как узнать в temp, что регистр свободный?
Быстродействие на конвейере 200-250МГц впечатляет.
Как загружаете программу в ПЛИС?
Какие алгоритмы деления и извлечения корня?

Интересно было бы посмотреть.

Забавный процессор, и всего 700 лутиков.
С temp приятное решение, а среда следит что регистры не кончились?


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

представьте себе такой модуль. Кран который умеет открываться на заданный поток жидкости. При этом он мереет плотность жидкости, давление, температуру. А также может, например, эту жидкость подогреть, или разбавить чем нибудь.... и так далее...

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

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

а в перспективе с 5, а может 6. Или вернемся обратно к 2. А то и сделаем отдельно на 1.

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

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

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

Вот такая общая цель.

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

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

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

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



А каково требуемое минимальное время цикла управления сей чудо машины?

Успехов! Rob.

1 микросекунда на команду, при 100 МГц основном клоке, то есть фактически вечность

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



Это полный цикл? Для жидкостей и сыпучих веществ? (я имею ввиду - измерение, расчет, выдача управления)

Успехов! Rob.

Повторюсь...
http://ru.wikipedia.org/wiki/PicoBlaze

Чем это не подходит ?
Вроде "от и до" все вопросы решены ?

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

кстати а оно распространяется с исходниками?

1) там нет команды "задать температуру" , но есть запись в "порт" значение (как-то так)
2) "PicoBlaze распространяется в виде исходного кода на языке VHDL для свободного использования на продуктах фирмы Xilinx" - как сейчас обстоят дела не смотрел.

понятно, спасиб...
но я уже успел полюбить свой велосипедик...

Делаете только один автомат и в нем переключаете потоки данных... Секорость у Вас низкая, хоть сотню потоков обработать можно... В чем проблема???
"Краткий Курс", глава "дополнение про автоматы" и "многопоточность"... И никакого процессора...

если нету ПИДа, он сам не появиться. А если есть процессор с возможность сложить - вычесть - умножить - сравнить, можно уже и ПИД сделать и другие регуляторы. Все на той же системе...

temp используется для организации локального стека, но этим не ограничивается. Ассемблер хранит битовую маску свободных регистров. Ассемблер создаёт код модуля на VHDL, который уже включает в себя экземпляр процессора, код и константы к нему. Деление и корень обыкновенные многоцикловые в столбик. Модуль для корня я уже тут выкладывал в соответствующей теме. В делении(как и в корне, впрочем) используется non-restoring алгоритм, остаток может быть отрицательным, и в следующем такте делитель к нему прибавляется, а не вычитается.

Если регистров для temp не хватает, выдаётся ошибка.

к Timmy
Спасибо за информацию.
Не совсем понял, ассемблер генерирует код на HDL, который затем можно включать в прошивку ПЛИС? Тоже, что-то новое!

А temp как локальный стек - это удобно.

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

Уточните, если не сложно, как и из чего выполняете загрузку конфигурации ПЛИС и программы для процессора? Используется ли для этого отдельное ядро, и как оно запускается?

И еще, почему выбрали Lattice, при более популярных Altera и Xilinx, в чем преимущество?

Да, ассемблер генерирует wrapper к процессору в виде исходника VHDL модуля, который содержит в себе код программы, константы, отладочную информацию для симуляции, всякие параметры, и инстанциацию процессора. Загрузка конфигурации производится из SPI flash, как обычно, а программа для процессора хранится в ROM на LUT-ах(она короткая, 200 инструкций в текущем проекте).
Lattice выбрали, потому что в low-end чипах есть поддержка DDR2 SDRAM с широкой шиной данных, приличная защита прошивки, чтение синхронных данных со скоростью до 800Mb/s.
С использованием аппаратного 36-битного умножителя у меня есть другой процессор попроще, который умеет только умножать и складывать, зато параллельно и за один такт с использованием конвейера, рабочая частота где-то тоже 250МГц, ограничена умножителем. Этот процессор для обсчёта нестандартных рекурсивных фильтров.