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

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

Все регистры управления периферией у меня 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 инструкций, Си как бы и не особенно нужен.
Вот ассемблер, сам процессор тоже могу выложить, если интересно, он не секретный.  cc.7z ( 2.57 килобайт ) Кол-во скачиваний: 55

И примерчик кода:

к 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" - как сейчас обстоят дела не смотрел.

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