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

А как тогда процессоры без портов получаю данные и выдают их в мир? Они же должны как-то взаимодействовать с окружающим миром.

По поводу ваших статей, так я их читал и перечитал. Но так и не нашёл где в них можно прочитать про дерево дешифровки адреса...

Там есть статья о битовом процессоре. Это процессор, который работает как "память - память"... И к памяти добавлен блок ДМА, который сам циклически копирует содержимое этой памяти во внешние устройства ввода-вывода... А портов как таковых у процессора может и не быть. Например DEC или по нашему Электроника-60 не имела отдельных команд для ввода-вывода. Они располагались в общем поле памяти... А интеловская система придумана для сокращения дешифратора адресов и упрощения узла контроля...
Если в статьях что-то не понятно, то могу по скайпу словами рассказать..

Документ, тут на стр.14 показана реализация портов ввода вывода

Мой вопрос касался "5.10 Control bus encoder" стр 13.
Спасибо, не совсем то, что я ожидал увидеть. Но ответ я понял, надо рисовать схему.

Еще один свой 8-разрядный софт процессор miniByte-2.
Отличия с предыдущей версией miniByte такие:
Число команд - 28
Доступных портов – до 256 (команды доступа IN и OUT).
Команды SBS и SBC условного перехода по значению любого бита порта.
Команды PBS и PBC модификации любого бита порта.
Работает на тактовой частоте 50 МГц.
.
Приложение miniByte_2.rar включает:
miniByte-2.pdf – краткое описание структуры процессора и сиcтемы команд.
mb2.exe - транслятор с ассемблера mb2.asm в файл mb2.mif и листинг mb2.lst,
mb2.asm – пример кода с выводом текста «HELLO» на LCD типа SC1602D.

Предыдущий miniByte был в http://electronix.ru/forum/index.php?showt...0367&st=180

Сегодня только заметил новый пост в этой ветке...

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


Сейчас делаю проект, в который напрашивается мелкий софт-процессор.
Мелкий, поскольку 1) сам проект ориентирован на использование самых дешевых ПЛИС, 2) софт-процессор играет вспомогательную роль, в данном случае - сжимать-разжимать по простому алгоритму ~20..200КБайт/сек (20 в сжатом, до 200 в разжатом), и дрыгать ножками последовательного устройства. Скорости, как видно, небольшие, но алгоритмы желательно писать/отлаживать на ЯВУ, и программы в софт-процессор загружать без перепрошивки/перезагрузки ПЛИС.

И много кандидатов на эту роль?

Проект на verilog и транслятор к нему с ассемблера уже на C/C++ писал сам. В обеих этих стихиях много тонкостей, которые полезно бы здесь и обсуждать. А процессор хотел сделать свой и небольшой, в котором в каждый угол можно бы дотянуться, ну и чтоб работали, например, в мультипроцессорном режиме, вместе с аппаратными блоками ПЛИС…
На NiosII у меня было три крупных проекта, приемник и первичный обработчик от радара с выходом на Ethernet-100 и два имитатора радарных сигналов. Ну и в больших задачах я бы использовал NiosII...
Посмотрел Ваш топик «Си как HDL, или Verilog без always». Мне тоже приходила идея использовать для своего проектируемого софт-процессора сокращенный набор команд и уже готовую IDE (с кодированием в asm). Но здесь мои предпочтения на стороне 51-архитектуры как, например, МК Silabs и их среды uVision 3 от Keil, так как с ними много работал и в ассемблере, и в С. Может следующая генерация и будет такой…

...Интересное есть в "SoC для платы Марсоход2", что в http://www.marsohod.org/forum-33/proekty-p...d2?limitstart=0

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

Например, процессор - "для души", тогда главное в нем - чтобы был "красивым". И ЛУТы/тактовая/ПО отходят на второй план, если это не входит в понятие "красоты". Можно уточнить/обсудить/поспорить, что делает архитектуру красивой, и как/куда двигаться.

Или процессор - "для дела". Тогда ЛУТы/тактовая/ПО выйдут на первый план. Можно уточнить/обсудить/поспорить, что важнее "для дела", и тд.

"Для дела" я считал бы идеальным софт-процессор с архитектурой, оптимизированной под последовательное выполнение кода, написанного на _подходящем_ HDL.
Из плюсов - один язык описания как синтезируемого "параллельного" дизайна, так и компилируемой "последовательной" программы.
Сложный проект тогда можно безболезненно поделить на "параллельную" часть, требующую больших ресурсов ПЛИС + длительное время синтеза/сборки, и "мгновенно" компилируемую последовательную часть, жрущую только память (которая все дешевле, и которой все больше как внутренней, так и внешней). И по ходу дела менять границу между "параллельной" и "последовательной" частью.
Минус только один - отсутствие подходящего HDL...

Из 8-, 16- и 32-разрядных софт процессоров, я остановился бы сейчас на обсуждении 8-разрядных. Где важным был бы минимальный объем аппаратуры и минимальная система команд. Быстродействие пока на втором плане. Ну и еще ориентация на работу с портами, как в моем miniByte-2. И также важно, что есть свои, полностью открытые коды (на verilog и c/c++), где волен и добавлять, и убавлять все по своему усмотрению в зависимости от текущих требований.
Все что больше этого, а также при работе с 16- и 32-разрядными данными, решал бы в NiosII с его IDE, так удобней.

Тогда предлагаю существенно переработать архитектуру, с целью уложиться в 200 ЛЕ + 1 М9К, получив при этом 50МIPS, и ортогональную систему команд. Как в miniByte-2 выполнить a=b&c, где a,b,c - переменные?

Для переменных не пройдет, с константой можно... Это издержки усечения набора команд, которые всегда можно под конкретную задачу подправить...
Цель красивая, можно переработать всю архитектуру и команды, и транслятор тоже. Предлагайте свою систему команд, желательно чтобы были одно и/или двух байтные команды, здесь и обсудим…

8-разрядная аккумуляторная фон Неймановская архитектура,
2х-портовая память с 16-разрядной шиной адреса, и 8-разрядной шиной данных,
в общем адресном пространстве - команды, данные, 15 РОН, I/O порты.
РОН физически расположены в одной памяти с командами и данными.
Команда - 4 бита на код операции + 4 бита на номер регистра,
Rn(n=1..15) - 15 8-разрядных РОН, или 7 16-разрядных в командах косвенной адресации (Ra, a=1..7).
n=0 для Rn означает 8-разрядную константу после команды, например: ADD R0 -- A = A + const8.
a=0 для Ra означает 16-разрядную константу после команды, например: LDM R0 -- A = @const16.
Доступ к портам - через общую адресацию, специальных команд не предусмотрено (специальные функции можно передавать в полях адреса).
Аппаратного стека нет, 16-разрядный адрес возврата сохраняется в указанной паре РОН.

NOP X -- резерв, 1байт/1такт
ADD Rn -- A = A + Rn, 1..2б/1т
ADC Rn -- A = A + Rn + C, 1..2б/1т
SUB Rn -- A = A - Rn, 1..2б/1т
SBC Rn -- A = A - Rn - C, 1..2б/1т
AND Rn -- A = A & Rn, 1..2б/1т
XOR Rn -- A = A ^ Rn, 1..2б/1т
OR Rn -- A = A | Rn, 1..2б/1т
LD F -- A = F(A), 1б/1т
LD Rn -- A = Rn, 1..2б/1т
LDM Ra -- A = @Ra, 1..3б/2т
ST Rn -- Rn = A, 1б/1т
STM Ra -- @Ra = A, 1..3б/2т
JMP case -- if(case) PC = const16, 3б/2т
CALL Ra -- Ra = PC + 3, PC = const16, 3б/3т
RET Ra -- PC = Ra, 3б/2т

Уточните смысловое содержание этих команд

LD F -- A = F(A), 1б/1т
-- F - 4х-разрядный код функции одной переменной, эта мнемоника просто резервирует до 16 команд с аккумулятором, не стал конкретизировать. Например, операции сдвига, инкремента, очистки, и тп
RR A
RL A
CLR A
INC A
DEC A
...

JMP case -- if(case) PC = const16, 3б/2т
--на код условия выделено 4 бита, эта мнемоника просто резервирует до 16 команд условного перехода (включая безусловный).


Но я еще подумал, и переработал систему команд, изменив адресацию - с упором на табличный метод. Позже выложу.
Состав команд почти не изменился, но уменьшилась длина команд. Например, CALL Ra, RET Ra, стали 1-байтовыми.

чтение/запись памяти с автоинкрементом/автодекрементом нужно...

Такое требование выльется в _дополнительный_ 16-разрядный сумматор (уменьшение разрядности до, например 12, непринципиально) - архитектура потеряет всякий смысл. Проще сразу делать 16-разрядную, выиграем сразу по всем параметрам - и по плотности кода, и по быстродействию, и по числу ЛЕ.
Надо учитывать, что в нишевых ПЛИС Альтеры отсутствует распределенная память (есть у Xilinx/Lattice), поэтому регистровые файлы на логике очень затратны по ресурсам. Клон 51 в Альтере займет больше ресурсов, чем Ниос2.
Поэтому 8-разрядный софт-процессор имеет смысл только там, где не требуется быстродействие, и инкремент 16-разрядного указателя можно делать в отдельной подпрограмме за много-много тактов.

Вроде все укладывается в 8-разрядный код:
Ta - 64 16-разрядных указателя на данные,
Ti - 32 16-разрядных указателя на подпрограммы,
Si - 32 16-разрядных регистра возврата из подпрограмм,
Rn - 7 8-разрядных регистров АЛУ, перекрываются с 3-мя указателями Ta (a=1..3),
R0 - const8, дополнительный байт после команды.

LDM Ta -- A = @Ta, a=0..63, 1б/2т
STM Ta -- @Ta = A, a=0..63, 1б/2т

CALL Ti -- Si = PC + 1, PC = @Ti, i=0..31, 1б/3т
RET Si -- PC = Si, i=0..31, 1б/2т

JMP label -- PC = const16, 3б/2т
JC label -- if(A[8]) PC = const16, 3б/2т
JNC label -- if(!A[8]) PC = const16, 3б/2т
JZ label -- if(A==0) PC = const16, 3б/2т
JNZ label -- if(A!=0) PC = const16, 3б/2т

RR -- A = A >> 1, w/carry, 1б/1т
RL -- A = A << 1, w/carry, 1б/1т
NOP -- резерв

ADD Rn -- A = A + Rn, n=0..7, 1..2б/1т
SUB Rn -- A = A - Rn, n=0..7, 1..2б/1т
AND Rn -- A = A & Rn, n=0..7, 1..2б/1т
XOR Rn -- A = A ^ Rn, n=0..7, 1..2б/1т
OR Rn -- A = A | Rn, n=0..7, 1..2б/1т
LD Rn -- A = Rn, n=0..7, 1..2б/1т
ST Rn -- Rn = A, n=1..7, 1б/1т

За один такт эти операции не получается сделать.
Для двухпортового ОЗУ в начале команды считывается два байта с адресами РС и РС+1, где по первому код операции, а по второму может быть константа. Если константа (младшая тетрада кода команды == 0000), то работаем с константой и все делается за один такт. А если там адрес одного из 15-ти РОН, то его еще надо считать из ОЗУ, на что минимум еще такт, если не два.

В 3х-уровневом конвейере получится, тк запись результата идет не в память, а в регистр аккумулятора.
А латентность результата будет 2..3 такта (зависит от того, откуда брать результат - с выхода АЛУ, или с регистра аккумулятора).
В первом такте команды по одному порту считывается один байт новой команды, а по другому порту в это время идет доступ к регистру или константе предыдущей команды.
В следующем такте по другому порту считывается регистр или константа, а по первому - следующая команда.
В третьем такте результат записывается в аккумулятор, и идет чтение операндов следующей команды.
Все сходится, тк запись в память идет отдельной командой, и есть запас в тактах.

Это уже несколько иная федерация по вольной борьбе, что-то я уже сомневаюсь в желаемом результате в 200 ЛЕ...

200 ЛЕ - это с запасом. 3х-уровневый конвейер естественным образом получается, без дополнительных элементов.
1 уровень - внутренние регистры одного порта памяти, 2 уровень - внутренние регистры другого порта памяти, 3 уровень - регистр аккумулятора.

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

Система команд, и это чувствуется, продумана и хорошо смотрится для 8-разрядника, везде видно влияние 86-архитектуры, а может, и AVR... Узкое место - это общая память, можно было бы её и разделить на RAM и ROM (что-то из гарвардского стиля) , но тогда не будет возможности модификации программы самой программой, но насколько это необходимо... Еще, память может быть очень большой, и как туда с программами на ассемблере, только на С, но это уже другой уровень усилий по разработке всей системы вместе с программной оболочкой.
С конвейерами программ еще не работал, где можно почитать о правильных методах их построения? Ясно, что конвейер надо приостанавливать на входе когда в нем длинные команды, например STM Ra, а также очищать на условиях... Хотел бы сделать такой процессор сам, потом сравнить, если получится меньше 200ЛЕ, то это будет экстра класс, т.к. мой miniByte-2 занял многовато места, хотя для мелких приложений у него есть и свои преимущества...

Гарвардскую архитектуру придумали для скорости, использование ее для 8-битника - не имеет смысла. Если нужна скорость - лучше сразу отказаться от 8-разрядного АЛУ. Назвали "miniByte" - логично ограничить минимумом число ЛЕ и блоков памяти, и выжать максимум быстродействия при этих условиях. 8-разрядные команды будут выгодно (в идеологическом плане) отличать такой проц от AVR/PicoBlaze/LatticeMico8/etc. А потом сразу перейти на "maxiLong" ...

Советую все-таки делать 16-разрядное АЛУ, пусть и с 8-разрядными командами (ориентир на 200 ЛЕ остается в силе). 8-разрядные АЛУ не дают никаких преимуществ в ЛЕ из-за более сложной схемы адресации.

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

Так вроде LCC изначально пример кодогенератора для x86 в 32-бит варианте содержал? Это та что надо архитектура?

Нет, х86, это не аккумуляторная архитектура, а регистровая.
Аккумуляторная, когда операции АЛУ меняют только один аккумулятор,
и R1=R1+R2 выльется в: A=R1, A=A+R2, R1=A.

По поводу аккумуляторной архитектуры своих софт процессоров, пока для теоретического обсуждения и без привязки к какому-то процессору.
Предлагаю отказаться от аккумулятора и назначать в РОН-ах текущий аккумулятор. Для этого в PSW (слово состояния программы) иметь поле [] для задания номера текущего аккумулятора, а результат всех аккумуляторных операций направлять в соответствующий РОН по этому номеру. И тогда, например, R1=R1+R2 выльется в: PSW[]=номер R1, A=A+R2.

Простите что вклиниваюсь, в процессорной архитектуре я чайник. Но можете хотя бы в общих словах сказать, чем плох, к примеру, популярный в прошлом R3000 (архитектура MIPS-1) в качестве софт процессора?
Нам нужен софт процессор в проект, но самодельное мы не можем себе позволить, будем брать что то из классики.

Плох только тем, что места займёт больше, чем восьмибитный. А так все фирменные софтпроцессоры большой тройки - NIOS2,Microblaze,Mico32 представляют собой испорченный разными способами MIPS.

Спасибо, понял.
Еще вопрос. Конвейерный R3000 иногда вынужден останавливаться, если текущая команда использует результат предыдущей (еще не записанной в регфайл или память). Есть какие то простенькие, но конвейерные вариации MIPS, где процессор не останавливается?

Как можно не останавливаться, если операнд команды ещё не определён? Хотя можно попробовать выполнить следующую команду, но внеочередное исполнение команд - это уже не слишком простенькая вариация. К тому же бесполезная, так как лучше расставлять команды в правильном порядке при компиляции.

Аккумулятор физически расположен вне РОН, иначе это будет регистровая архитектура. В чисто аккумуляторной архитектуре операции АЛУ меняют только аккумулятор. Те это load-store архитектура по отношению как к памяти, так и к РОН.

На Марсоходе выложил исходники 16-разрядного аккумуляторного ядра, с 1К регистровым файлом в памяти (фон Неймановская архитектура). 3х-уровневый конвейер, команды регистр-аккумулятор за 1 такт. Чуть больше 200 ЛЕ (но можно ужать, если добавить синтезаторо-зависимые оптимизации, я их убрал). В f.hex.v можно посмотреть ассемблерный код, синтезируемый припомощи LCC, сам ассемблер еще не выкладывал.

Leka
Глянул проц, спасибо. Но где же самое интересное? Даже не сам ассемблер как таковой, а в первую очередь адаптация LCC под свой ассемблер?

Позже выложу (подправленный symbolic.c + *.exe), надо рефакторинг сделать. У меня цепочка symbolic ---> asm ---> hex, состоящая из нескольких исполняемых файлов. В LCC я подправил symbolic.c, остальное - оптимизатор-транслятор на Паскале. Паскалевские исходники выкладывать не буду, только если позже перепишу на Си.

Адаптации LCC под ассемблер минимальна, тк используется target=symbolic, это и скармливается ассемблеру.

0.asm - вывод с подправленным symbolic.c, дальше этот файл обрабатывается самопальным ассемблером. У меня модель памяти сильно отличается от общепринятой (из-за 1К регистрового файла), поэтому не стал разбираться/делать свой .md файл.
В symbolic просто закомментировал все ненужное мне, добавил вывод space вместо смещений, и поменял некоторые ключевые слова.

Рефакторинг (и выкладывание .exe) не скоро буду делать.

Кстати, "разгонные" потенциалы смотрел кто для разных ядер?
Чтобы STA мог правильно подсчитать частоты, нужно законстрейнить "ложные" пути, которые не влияют на реальное быстродействие. Это долго и нудно, для хобби проще задрать частоту, и посмотреть...
Для моего m16, например, STA дает ~110МГц на при 1200мВ/0Ц (de0-nano), попробовал 150МГц - работает...

Для меня наибольший интерес представляют процессоры, которым на ассемблере можно написать что-то типа Есть ли вообще в открытом доступе подобные soft-DSP?

Упрощенный USB-хост для клавиатуры - чтобы беспроводную можно было подключить без софт-процессора с Линуксом (из проводных намного проще взять PS/2). Проект для DE0-nano, ~400 ЛЕ (спасибо разработавшей USB армии даунов). На выходе модуля скан-код последней нажатой клавиши, счетчик нажатий, и карта нажатых Ctrl/Alt/Shift. 0-я версия, комменты в исходниках писать лень, проверил на паре клавиатур - работает.

С Вашего разрешения добавил ссылку в "ссылки на готовые описания модулей на форуме, предлагаю собрать все в одном документе/ветке форума"

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

Вообще это не проблема. Для меня достаточно было компилятора ассемблера, который в результате работы вписывал в файл процессора содержимое памяти команд... И заодно я сделал софт-симулятор. "Среда разработки" была мной же написана на Си в ВСВ6. И это все оказалось быстрее отладить, чем автомат на более чем 200 состояний...

iosifk,, уточните структуру, систему команд, основные принципы построения, а также итоговые параметры (тактовую частоту и занимаемые ресурсы ПЛИС) для своего софт процессора. И какой получился свой компилятор, т.е. какие он имеет возможности. По софт-симулятору тоже хотелось получить представление...
Если все вместе сложить, то получается достаточно большой объем работы был Вами сделан. Хотелось бы с ней ознакомиться, хотя бы в общих чертах...

Дело было такое. Пришел работать на фирму и мне дали сделать проект в ПЛИС. Там должен был быть командо-аппарат, управляющий примерно 50 шт реле, 8-10 ЦАПов и столько же АЦП. Команды принимались по последовательной шине на 300 МГц, а весь проект работал на 50 МГц.
Там на самом деле нужен был DSP процессор, но руководитель проекта сказал, что программисты наверняка что-нибудь пожгут... А схемы он сам может проверить. Беда в том, что алгоритмы выполнения приходящих команд были довольно сложные - уставки, блокировки и пр...
Что я сделал? Я сделал связку из 2-х процессоров. Битовый процессор делал Булеву обработку флагов и входных сигналов и результаты выдавал в память и в порт. Этот битовый порт дела SPI последовательность, далее там сидела микросхема с ОК мощными выходами. И для каждого битового интервала выполнялся расчет для соотв. реле. Т.е на одно реле можно было успеть просчитать до 50 команд. И этого вполне хватало...
Процессор описан в одной из моих статей. У меня на сайте...
А с 17 разрядным процессором битовый общался через память и флаги. Команды -24 бита, шина данных - 17 бит, озу - 16 бит. Потому как 12 битовые данные из АЦП принимались 32 раза и потом усреднялись. Процессор довольно простой: аккумулятор, стек данных и стек возврата, несколько регистров... Команды соответственно подогнаны под задачу. Одной командой данные можно считать из порта в память, в регистр и в порт вывода. И при этом задать wait-state. Всего понадобилось около 1Кслов команд. Т.е. примерно раза в 3-4 меньше, чем у стандартного мк. А вместе с битовым - раз в 10 проще и быстрее...
Про ассемблер тоже писал статью. Но если кому интересно, могу по скайпу показать рабочий стол с запущенной программой...
Ассемблер -это практически визард, т.к. команды не набиваются вручную, а из меню выбирается что и куда делает команда, при этом кодируется машинный код сразу. А потом за дополнительный проход ассемблер только расставляет адреса переходов по меткам...
Да и софт-симулятор тоже дело не хитрое, когда знаешь какая команда в каком окне что должна изменить...

Ну таких как Вы мало. Для большинства даже свою архитектуру процессора разработать и реализовать её на ПЛИС уже страшенный гемор. А если ещё и свой компилятор и свою IDE писать для своего процессора...

ИМХО, эта задача не посильна для одного разработчика.
Он будет решать эту задачу лет 10. Но так полностью "до ума" не доведет.

Свой компилятор и IDE писать не обязательно, обычно обходятся back-end-ом к GCC, и плагинами к Eclipse, что обеспечивает вполне вменяемый объём работы.

А это, типо просто?
Я, к примеру, даже слов-то таких не знаю.