Еще один свой 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

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

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

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

Сообщение отредактировал Leka - Nov 3 2015, 16:13

"Для дела" я считал бы идеальным софт-процессор с архитектурой, оптимизированной под последовательное выполнение кода, написанного на _подходящем_ 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-байтовыми.

Сообщение отредактировал Leka - Nov 5 2015, 08:06

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

Сообщение отредактировал Genadi Zawidowski - Nov 5 2015, 08:16

Такое требование выльется в _дополнительный_ 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-ти РОН, то его еще надо считать из ОЗУ, на что минимум еще такт, если не два.