Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Свои процессоры
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Системы на ПЛИС - System on a Programmable Chip (SoPC)
Страницы: 1, 2, 3, 4, 5, 6, 7
Ynicky
Цитата(Leka @ Jun 7 2010, 23:40) *
как в подпрограммах получать доступ к глобальным переменным в регистровом файле?

Тут я не понял. Я всегда считал, что глобальные переменные находятся в памяти данных.
И доступ к ним осуществляется через load/store.
Если они будут находиться в регистровом файле, тогда без переключения регистров не обойтись.
И сколько их может потребоваться?

Николай.

P.S.
Предлагаю пока не заморачиваться по поводу FP.
А дальше будет видно.
Leka
Для вспомогательной подпрограммы основные данные - внешние, "в противном случае зовется ... иначе" - задача. Локальных по своей сути данных немного, это промежуточные результаты выражений, счетчики циклов, и тп.
Нет никакого смысла делать большой регистровый файл для локальных данных: 16 уровней вложенности пп * 4 локальные переменные в среднем = 64 регистра.
Если основные данные не в регистровом файле, имеет смысл отказаться от load/store архитектуры, добавив косвенно-регистровую адресацию ( *a=*b+*c; if(*a==*d)...; и тп ). Была у меня такая в железе, см ветку "посоветуйте простой софт-процессор".

Цитата
Предлагаю пока не заморачиваться по поводу FP.

Согласен, сначала нужен компилятор "машинный" Си --> машинные коды.
Ynicky
To Leka:
Попробовал написать простенький тест.
После компиляции a2m запустил LCC.
Пока 2 явных замечания:
1. return надо отделить от 1 и 0.
2. в разных подпрограммах повторяющиеся метки.
Проект во вложении.

Николай.
Leka
Цитата
1. return надо отделить от 1 и 0.

Забыл написать, надо "return(1);" вместо "return 1;" Сделано специально - как вызов функции, а не ключевое слово.
Цитата
2. в разных подпрограммах повторяющиеся метки.

Вроде это не противоречит стандарту (локальность меток в пределах функции), но если надо - могу добавлять имя функции к метке.
Leka
В a2m пока только один тип "int", поэтому "void" не допускается.
Ошибки потом поправлю, сейчас прорабатываю компилятор в машинные коды.
Из-за зависимости длины инструкции от данных (вставка imm20 и тп), решил поменять концепцию.
Ynicky
Исправил несколько ошибок.
Проверил АЛУ без SMUL (пока нет), load/store.

Николай.
Leka
Принцип получения hex-файла машинных кодов:
компилятор a2m в "машинный"Си будет также автоматически генерировать файл "code.c" для Си-скрипта "machine.c", запускаемого после a2m. Си-скрипт м/б выполнен TinyCC с ключом "-run".
В приложении пробная версия "machine.c"(с выводом мнемоник вместо hex-кодов) и тестовый "code.c".
Для настройки на конкретную систему команд в "machine.c" надо поменять текстовый вывод мнемоник на вывод соответствующих hex-кодов. Переменная "p" обеспечивает несколько проходов(2) для "подгонки" относительных адресов инструкций, тк их число зависит от данных(добавлений "imm20"). "t"!=0 означает константу. Остальное, думаю, понятно будет из исходника.
"a2m" позже подправлю под вывод "code.c".
Leka
Концепцию немного поменял, "a2.exe" выводит код для Си-препроцессора.
Не хватает времени, не сделал вывод hex-кодов для конкретного процессора - в "a2b.c" надо поменять текстовый вывод мнемоник на вывод соответствующих hex-кодов ("a2a.c" настроил для конкретного 2х-операндного процессора).
Leka
Пример вывода hex-кодов для некоторых команд (mov, cmp, и тп) в "a2b.c", для остальных делается аналогично. М/б стоит переписать "a2a.c" и "a2b.c", чтобы проще было вводить/править hex-коды команд.
Ynicky
Цитата(Leka @ Jun 16 2010, 19:48) *
Пример вывода hex-кодов для некоторых команд (mov, cmp, и тп) в "a2b.c", для остальных делается аналогично. М/б стоит переписать "a2a.c" и "a2b.c", чтобы проще было вводить/править hex-коды команд.

Что означает hex-код? Файлы a2a.c и a2b.c идентичны.

Николай.

P.S.
С hex-кодом разобрался. Это AL2 в a2b.txt.
А в hex-код можно добавить комментарий в виде мнемоники команд?
Тогда будет проще править.
Leka
В "a2b.c" я еще исправил ошибку, вернул необходимые пары "{" "}" (случайно выкинул, когда "причесывал") - иначе неправильно считает адреса команд.
Думаю, надо переписать "a2a.c" и "a2b.c", чтобы были комменты, и удобно было править. Но сейчас много дел навалилось, освобожусь - займусь.
Leka
В "a2b.c" надо вместо "00" кодов операций поставить реальные.

Вывод комментов добавил.
Leka
По поводу слотов задержки в командах условных переходов. В FPGA вся память - двухпортовая, можно использовать для упреждающей выборки альтернативной инструкции из памяти программ - выигрываем 1 такт.
Ynicky
Цитата(Leka @ Jun 18 2010, 12:34) *
По поводу слотов задержки в командах условных переходов. В FPGA вся память - двухпортовая, можно использовать для упреждающей выборки альтернативной инструкции из памяти программ - выигрываем 1 такт.

В принципе, можно вообще обойтись без слотов задержки, как, например, в ARM-е.
Тогда мы будем терять 3 слота задержки при невыполнении условия перехода (flush).
Можно, конечно, сделать альтернативную выборку команд и не терять ни одного слота,
переключаясь на альтернативную ветку конвейера.
Но это, по моему, будет привязывать данную архитектуру только к FPGA.
Как это может сочетаться с кеш, пока не знаю.

Николай.
Ynicky
Цитата(Leka @ Jun 18 2010, 01:37) *
В "a2b.c" надо вместо "00" кодов операций поставить реальные.
Вывод комментов добавил.

Есть вопросы по командам в "a2b.c".
1. "TST" - это операция "AND" без записи в регистр (т.е. только изменение флагов)?
2. "BZ","BNZ" - ветвление, если результат "=0" и "/=0"? Дело в том, что с командами "CMP"
все условия ветвления сравниваются с '0'. Значит ли это, что их можно приравнять
к командам "BEQ" и "BNE"?
3. Что из себя представляют команды: "COM", "LDI", "LDD", "LDDI", "STI", "STD", "STDI"?
4. "ASL" и "ASR" - это команды арифметического или логического сдвига?

Исправил еще несколько ошибок в процессоре.

Николай.
Leka
Цитата
1. "TST" -

любая операция без записи в регистр, устанавливающая нужные флаги для "BZ","BNZ".
Можно "CMP" с нулевой константой.

Цитата
2. "BZ","BNZ" - ветвление, если результат "=0" и "/=0"?

Да.

Цитата
Значит ли это, что их можно приравнять к командам "BEQ" и "BNE"?

Напрямую не получится, тк "0" задан неявно.
Либо в "ассемблерном" Си всегда писать "if(a!=0)..." и "if(a==0)..." вместо "if(a)..." и "if(!a)...", либо ввести формальные команды "BZ" и"BNZ", подразумеавющие сравнение с нулем. В фактической системе команд они не нужны, и в машинных кодах
заменяются "BEQ" и "BNE" с нулевой константой.

Цитата
"3. ... COM", "LDI", "LDD", "LDDI", "STI", "STD", "STDI"

COM: Ra=~Ra;
LDI: Ra=*Imm;
LDD: Ra=Rb[Rc];
LDDI: Ra=Rb[Imm];
STI: *Imm=Ra;
STD: Ra[Rb]=Rc;
STDI: Ra[Rb]=Imm;
"LDD" и "STD" - для 3х-операндной системы команд.
"LDDI" и "STDI" получаются "за компанию".

Цитата
4. "ASL" и "ASR" - это команды арифметического или логического сдвига?

То-же, что и "<<" и ">>" в Си.

Можно добавлять свои команды например:
#define MAX( a, b ) AL2( max, maxi, a, b );
и определить соответствующие коды "max" и "maxi", из Си можно вызывать:
MAX( a, b );
Но тогда для отладки в Си надо определить в тестовых программах:
#define MAX( a, b ) if( a < b ) a = b
и тд и тп.

Для другой архитектуры "a2a.c" и "a2b.c" будут другими, а вот "a2с.c" менять не понадобится.
Ynicky
Цитата(Leka @ Jun 20 2010, 18:41) *
То-же, что и "<<" и ">>" в Си.

Насколько я знаю, "<<" - это всегда логический сдвиг, а ">>" - либо логический либо арифметический,
в зависимости от переменной (беззнаковой или знаковой). Это так?

Николай.
Leka
Для чисел в дополнительном коде арифметический и логический сдвиг влево - результат одинаковый.

Цитата
а ">>" - либо логический либо арифметический,
в зависимости от переменной (беззнаковой или знаковой). Это так?

Да. У меня пока только один тип "int", и поэтому подразумевается только арифметический сдвиг.

В принципе, ввести дополнительные типы несложно, но проект, судя по всему, развиваться не будет(мало участников) - поэтому не вижу смысла (сам предпочитаю "бестиповую" архитектуру).
Ynicky
Цитата(Leka @ Jun 20 2010, 21:03) *
проект, судя по всему, развиваться не будет(мало участников)

Согласен.
Leka
На всякий случай посмотрел стандарт на ANSI C, там результат сдвига вправо знаковых чисел - зависит от реализации.

Цитата
Согласен.

Надеюсь, кое-какая польза все-таки была извлечена из этого проекта.
Ynicky
Цитата(Leka @ Jun 20 2010, 21:18) *
Надеюсь, кое-какая польза все-таки была извлечена из этого проекта.

Для меня - да.
Leka
Посмотрел "a2h.c" и "aaa.txt".
Тк в системе команд rf32 нет "sti",
то либо предварительно загружать константы в определенный регистр(например R0),
либо все константы загружать в регистры в начале программы.
Например, по второму способу надо изменить "INT(a,b )" (объявление константы) в "a2h.c":
Код
#define INT(a,b) i[a]=1; v[a]=b; AL2(mov,movi,a,a) STR("")

и "ST(a,b )":
Код
#define ST(a,b) AL2R(st,a,b)

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

"INT(a,b )" - объявление константы (int n=1; ), м/б код записи в регистр.
"ARR(a,b )" - объявление массива (int arow[20]; ) - д/б выделение памяти, пока игноируется. Д/б код типа "heap+=b; v[a]=heap;"
"CHR(a,b )" - объявление строковой константы (int s="hello,world!"; ) - д/б выделение и инициализация памяти, пока игноируется.
Leka
Пример "a2h.c" с печатью секции ".REG" - начальные значения регистров, в тч адреса массивов. Там-же вариант разворачивания "sti" в 2 команды: "movi" и "st".
Leka
Для примера переопределил "bz", "bnz", "neg", "com",
и исправил "ALxx" - чтобы проще было определять инструкции с константами.
Ynicky
To Leka: А что делать с секцией ".REG"?
Надо прописывать в регистровый файл?

Николай.

P.S.
Понял, надо.
Ynicky
Попробовал отмоделировать программу "queens".
Работает не правильно.
Тогда стал писать тесты. Сразу обнаружил следующее:

CODE
tst_rr()
{
int iA = 1;
int iB = 2;

iB = iA;
}

=>

.REG
000:00000000
001:00000001
002:00000002

.CODE
000001:45002001 ;iB=iA; //формат RI вместо RR!!!
000002:12000000 ;}

Но если переменную iA не инициализировать, то все нормально:

Код
tst_rr()
{
int iA;
int iB = 2;

iB = iA;
}

=>

.REG
000:00000000
001:00000000
002:00000002
.CODE
000001:25002001;iB=iA; //!!!
000002:12000000;}


Николай.
Leka
Поправил "a2" и "a2h.c" (помимо "#define REG" поменял также "#define STR" - это потом может пригодиться, для работы со строками, после определения "#define CHR").

Не ту версию прикрепил, поправил.
Ynicky
CODE
tst_ptr()
{
int *ptr1;
int *ptr2;
int iA,iB;

*ptr1 = 0xA;
*ptr2 = 0xB;
iA = *ptr1;
iB = *ptr2;
}

=>

.REG
000:00000000
001:00000000
002:00000000
003:00000000
004:00000000
005:0000000A
006:0000000B

.CODE
000001:4500000A ;
000002:66001000 ;*ptr1=0xA;
000003:4500000B ;
000004:66002000 ;*ptr2=0xB;
000005:62003001 ;iA=*ptr1;
000006:62004002 ;iB=*ptr2;
000007:12000000 ;}


Помоему, в командах "STORE" (опкод 66) перепутаны местами RD и (RS).
У меня в системе команд RD и (RS) находятся в одном и том же месте для формата "LOAD/STORE".

Николай.
Leka
В "a2h.c" "#define ST(a,b )..." надо исправить на "#define ST(b,a)...".
Ynicky
Цитата(Leka @ Jun 28 2010, 22:05) *
В "a2h.c" "#define ST(a,b )..." надо исправить на "#define ST(b,a)...".

Исправил, заработало, проверяю дальше.

Николай.
Ynicky
Промоделировал "queens".
Результаты совпадают с "q.c".
Указатели в "q2.c" изменяются на 1, в то время как у меня в процессоре байтовая адресация,
т.е. указатели должны меняться на 4. Временно сдвинул адрес в процессоре на 2 разряда вправо
и все заработало.
2 Leka: Что нужно (или можно) посмотреть по результатам моделирования?
И еще, для чего в программе "q2.c" мы обращаемся к памяти через указатели?
Почему нельзя обойтись только регистрами?

Ошибок в процессоре больше пока не обнаружил.

Николай.
Leka
Цитата
Указатели в "q2.c" изменяются на 1, в то время как у меня в процессоре байтовая адресация, т.е. указатели должны меняться на 4.

Это общая проблема арифметики указателей.
По стандарту на Си, в "q2.c" все правильно, тк это компилятор должен делать поправку на тип данных (у меня не делает). Варианты выхода из этого положения:
1) добавить в компилятор полную поддержку типов, как в Си,
2) использовать в SoC раздельную память для байтов/слов,
3) ...
Сам использовал 2-ой вариант, тк SoC под конкретную задачу, и память разбивается на отдельные блоки нужного размера, и с нужной разрядностью(и не обязательно кратной 8).
А 1-ый вариант в одиночку делать не буду, тк предпочитаю бестиповые языки/архитектуры, и индексную адресацию.

Цитата
Что нужно (или можно) посмотреть по результатам моделирования?

Не понял.

Цитата
И еще, для чего в программе "q2.c" мы обращаемся к памяти через указатели? Почему нельзя обойтись только регистрами?

В программе используются массивы, обращаться к элементам массива можно либо при помощи индексной адресации, либо через указатели. Как еще? Если процессор поддерживает косвенную адресацию регистрового файла, все-равно на Си это будет либо индексная адресация, либо указатели.
Leka
Например, код на Си:
int *a, i; ... a+=i; *a=i; ...
и эквивалентный код на "ассемблерном" Си для 2х-операндной 32х-разрядной архитектуры:
int a, i, tmp; ... tmp=i; tmp<<=2; a+=tmp; *(int*)a=i; ...
--> имхо, громоздко, неэффективно, и непереносимо на другую разрядность/архитектуру.
Поэтому и нравятся бестиповые языки/архитектуры.

И с индексной адресацией.

Пример N-ферзей с явной арифметикой указателей:
CODE
int n,count;
queens(){
int
arow[20], aleft[20], aright[20], aposs[20],
poss, place, val, pos, pos1, n1, temp, temp1,
prow, pleft, pright, pposs,
prow1, pleft1, pright1, pposs1;

count = 0;
n1 = n;
n1 &= 1;
val = 1;
val <<= n;
val -= 1;
temp = n;
temp >>= 1;
poss = val;
poss >>= temp;
pos = 1;
prow = arow;
prow += 4;
pleft = aleft;
pleft += 4;
pright = aright;
pright += 4;
pposs = aposs;
pposs += 4;
prow1 = prow;
prow1 += 4;
pleft1 = pleft;
pleft1 += 4;
pright1 = pright;
pright1 += 4;
pposs1 = pposs;
pposs1 += 4;
*(int*)prow = 0;
*(int*)pleft = 0;
*(int*)pright = 0;
*(int*)pposs = poss;
do
if( poss ){
temp = poss;
temp = - temp; //0-temp;
place = poss;
place &= temp;
temp = place;
temp = ~temp; //^=-1;
poss &= temp;
if( pos == n1 )
if( ! poss )
count <<= 1;
if( pos != n ){
*(int*)pposs = poss;
temp = *(int*)prow;
temp |= place;
*(int*)prow1 = temp;
temp = *(int*)pleft;
temp |= place;
temp <<= 1;
*(int*)pleft1 = temp;
temp = *(int*)pright;
temp |= place;
temp >>= 1;
*(int*)pright1 = temp;
temp = *(int*)prow1;
temp1 = *(int*)pleft1;
temp |= temp1;
temp1 = *(int*)pright1;
temp |= temp1;
temp ^= -1;
temp &= val;
poss = temp;
pos += 1;
prow += 4;
pleft += 4;
pright += 4;
pposs += 4;
prow1 += 4;
pleft1 += 4;
pright1 += 4;
pposs1 += 4;
}else
count += 1;
}else{
pos -= 1;
prow -= 4;
pleft -= 4;
pright -= 4;
pposs -= 4;
prow1 -= 4;
pleft1 -= 4;
pright1 -= 4;
pposs1 -= 4;
poss = *(int*)pposs;
}
while( pos );
if( ! n1 )
count <<= 1;
}
main(){
do{
queens();
printf("queens(%d)=%d\n",n,count);
n = n + 1;
}while( n < 15 );
}

Чтобы такое можно было компилировать в hex-файл, надо слегка поправить компилятор:
1) убрать возможность объявления указателей "int*",
2) заменить в выражениях "*" на "*(int*)".
Стоит овчинка выделки?
Leka
bb-offtopic.gif
Между первым э/м реле: http://ru.wikipedia.org/wiki/%D0%A0%D0%B5%D0%BB%D0%B5
и первой вычислительной машиной на них: http://ru.wikipedia.org/wiki/Z3
>100 лет... Что мешало?
DevL
очень интересный пример!

для уточнения - при симуляции надо использовать rf32sim_TB_runtest.do , правильно ?

и несколько для ленивых - есть ли описание signal names, что бы проследить исполнение src\prg.txt ?
Leka
Жаль, что проект с компилятором заглох...
Делаю апгрейд своего софтпроцессора - вместо Фон-Неймановской архитектуры взял Гарвардскую, и выделил 1К регистровый файл в отдельную 3х-портовую память. После P&R для минимального 18-разрядного ядра без периферии:
Спартан3 ~120 ЛУТ, ~120МГц,
Циклон3 ~250 ЛУТ, ~120МГц.
a=b+c; - 1 такт,
a[i]=b[j]+c[k]; - 2 такта.

PVL
Программеров разогнали, деньги кончились. Сейчас работаю только на основной работе.
По поводу производительности - сейчас рулят синтетические наборы инструкций с сетевой организацией вычислительных блоков. Одна российская контора пытается сделать это на ПЛИС. Цель - обогнать видеокарту по производительности. Блажен кто верует...
DevL
кстати , для гибкости в выборе ассемблера - оказался очень забавный вариант описанные тут "Пакет для разработки ПО для ПК "Специалист""
http://shoorick.ho.ua/spec/index.html

в частности использование winasm + fasm - где по большому , даже не важно что fasm не сильно работает с нужным 8080, а просто используется для трансляции например комадны
LXI в то что fasm может обработать

Код
macro[b] lxi r1,imm[/b] {
    [b]db [/b]((r1 and 6) shl 3) + 1
    [b]dw [/b]imm }


в итоге - получается удобство winasm как IDE + полная компиляция sm.gif


Lexey

Давно маюсь с софт-процессором для ПЛИС, решил поделиться своеми соображениями.
Ни один из готовых вариантов меня не радует, хотя в моих требованиях нет ничего оригинального и нереального:
1. FPGA не BGA (производство мелкосерийное, множество проектов с оригинальным железом)
2. SDRAM до 64MB (один 16-битный чип),
3. Полноценное ядро OC, файловая система, т.п. чтобы беспроблемно портировалось готовое.
5. Несложная но гибкая и разнообразная обработка потоков данных, cравнимых с пропускной способностью SDRAM

Ключевая проблема тут в том что имеющиеся процессоры очень непроизводительны при работе с SDRAM.
Я пытаюсь решить ее
1.Интеграция процессора с контроллером SDRAM:
1a. отказ от использования стандартной шины
1b. асинхронное выполнение команд загрузки/cохранения контроллером SDRAM
контроллер имеет 2 интерфейса c ядром: интерфейс приема команд и интерфейс возврата данных в регистры.
контроллер одновременно может обрабатывать около десятка команд, что позволяет оптимизировать работу шины.

2.Отказываюсь от кэша данных, как от вещи малоэффективной и ресурсоемкой в данной ситуации.
3.Интерфейс между ядром и потоковым железом реализуется через 2-x портовые блоки EBR, на что предполагается израсходовать
большинство доступных EBR.
При такой организации отпадает необходимость прямого доступа железо<->SDRAM, поскольку сам процессор сможет пересылять данные по прерываниям между EBR и SDRAM не менее производительно чем любой железный DMA (но при этом гораздо гибче и удобней),
a "DMA контроллер" железо<->EBR тривиален.

За основу взял архитектуру LM32, FPGA Lattice XP2, verilog,
Прочие подробности:
-Mинимальный MMU на 512 страниц в пространcтве 64MB (вся таблица страниц текущей задачи вмещается в один EBR)
-1KB 2-way Instruction cache+ 1KB local instruction memory (1 EBR)
-Регистры в распределенной памяти
-Минимальная конвейеризация (простейшие команды читают регистр, выполняются и сохраненяют результат в одном такте)
-Предполагаемая тактовая : 125 MHz (общая для ядра и SDRAM)
-Предполагаемый размер 2500 LUT+2EBR (без учета интерфейсных EBR)
-Возможность экономной реализации 2x-SIMD путем раздвоения ALU. (регистровый файл по-любому 2-x банковый)
-Потери перехода: прямой 1 такт , косвенный 2 такта.

Стадия разработки: около 50% исходников, через 3-4 месяца надеюсь дойдет до отладки
alexPec
Цитата(Lexey @ May 8 2011, 02:03) *
Ключевая проблема тут в том что имеющиеся процессоры очень непроизводительны при работе с SDRAM.
Отказываюсь от кэша данных, как от вещи малоэффективной и ресурсоемкой в данной ситуации.

Так кэш то и призвана решать эту проблему. Хотя смотря под какие задачи и какая кэш.

Цитата
1b. асинхронное выполнение команд загрузки/cохранения контроллером SDRAM
Предполагаемая тактовая : 125 MHz (общая для ядра и SDRAM)

На каких fpga? Если бюджетные, то мне например идея асинхронщины не нравится

Цитата
При такой организации отпадает необходимость прямого доступа железо<->SDRAM, поскольку сам процессор сможет пересылять данные по прерываниям между EBR и SDRAM не менее производительно чем любой железный DMA (но при этом гораздо гибче и удобней),
a "DMA контроллер" железо<->EBR тривиален.

Опять же смотря под какие задачи. Если для обработки видео - без дма сразу нет. Да и вобще софт процессор без дма...


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

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

- Подсистема ядра определяет архитектуру процессора.

Предлагаю свою концепцию интерфейса:

Код
module CPU_Core(
input clk,rst,
//-- Instruction readout ----------------
input [31:0]C, //P3 Codeword
input [23:0]PC,//Program Counter
input CFault,  //P3 Page Fault detected on current codeword
input CRdy,    //P3 CodeWord Ready from IC
output CFRq,   //P6 Next Codeword Fetch Request (keep it until CRdy become active)
input [1:0]PWords,// Prefetched words beyond the current codeword, sat@3
//-- Jumps ---------------
output JI,JR,JE, //Jump {Indirect,Relative,Exception} requests  (Jx=JI|JR|JE)
input JB,        //Jump Buffered, mutex{JI,JR,JE,JB}
output JxU,      //Jump Unresolved for use with JI,JR,JE  (most usable for JR)
input JBU,       //Jump Buffered unresolved
output JAbort,JTake, //P7 Jump Abort/Take for unresolved buffered jump
output JFE,      //Jump Fetch Enable (last slot word already fetched)
input Jmp,       //P7+ Jump destination fetch
//Jx can be asserted only when all intended slot instructions
//already prefetched (see PWords)
//-- virtual adress from core ----------
output [23:0]JRA, //P6 JR address   (from decoder)
output [23:0]JEA, //P4? JE address  (Exception handler address)
output [25:0]LSA, //P3..P5 LS/JI address (from AU)
//-- Data Memory request interface -----------------
output MRq,         //request
output MRqWr,       //direction
output MRqSigned,   //Load Mode
output [4:0]MRqGPR, //destination GPR
output [1:0]MRqSize,//data Size (bytes-1)
output [31:0]MRqWrD,//Write Data, M-aligned
output MRqExt,      //Extended transfer (8 bytes), option for SIMD-like LS instructions
output [31:0]MRqWrExD,//Extended Data, 4-byte aligned, optional
input MRqAc,        //Request Acception
input MRqFault,     //last accepted request failed
input MRqWS,        //Wait State for split-page translation
//MRqFail normally occurs next clock after MRqAc, only exception is rare case when
//unaligned request cross page boundary (MRqWS asserted for this case).
//MRqWS will be used as wait state for execution unit to prevent any next
//instruction from changing arch. state.
//-- Data Readout interface ------------------------
input MRdRq, //request
input [1:0]MRdSize,input [4:0]MRdGPR,input MRdSigned,//Destination descriptor
input [31:0]MRdD, //P4+m Read Data, M-aligned
input MRdEx, input [31:0]MRdExD, //optional
output MRdAc, //acception
)


P0..P7 - cтупени комбинаторной логики в 8-ступенчатой модели
svrdc
Может кого интересуют IP дла плавающей точки. Могу предложить быстрый multifunc fp для вычисления DIV, RECP, SQRT, RSQRT
ArtemDement
Ни у кого 10 000 000 $ не завалялось для спонсирования открытого процессора от Qimod ?

http://habrahabr.ru/post/161489/
Victor®
Цитата(ArtemDement @ Dec 5 2012, 21:28) *
Ни у кого 10 000 000 $ не завалялось для спонсирования открытого процессора от Qimod ?

http://habrahabr.ru/post/161489/


Лохотроном каким-то попахивает....
Вот это гораздо прозрачнее и понятнее.
http://opencores.org/donation
SyncLair
Я что-то не понимаю зачем городить процессор, вроде и так все процессоры что есть имеют свободную спецификацию. Вот городить ВИДЕОпроцессор ну для трёхмерной графики -- это толк может и будет
Wic
Цитата(SyncLair @ Dec 7 2012, 04:30) *
Я что-то не понимаю зачем городить процессор, вроде и так все процессоры что есть имеют свободную спецификацию.

Свободная спецификация != открытый код/бесплатная лицензия. Если бы тот же арм имел открытый код, его бы очень быстро клонировали для специфичных применений. То о чем писали на хабре, имхо, фантастика. Современный процессор за 10Му.е. не сделать. А вот софтверный процессор с открытым кодом для FPGA реальная задача. Но ее нужно решать с оглядкой на ОС, которые на нем буду крутиться *nix/win/etc.
Leka
Цитата
...Но ее нужно решать с оглядкой на ОС, которые на нем буду крутиться *nix/win/etc.

"- Хочу предложить последнее свое изобретение. Это автомат для бритья. Клиент опускает монеты, просовывает голову в отверстие, и две бритвы автоматически бреют.
- Но ведь у каждого индивидуальное строение лица...
- Так это только в первый раз!"

ОС и интерфейсы - это и есть "автоматические бритвы". И какой смысл в "индивидуальном строении" процессоров? cranky.gif
alman
Цитата(Lexey @ May 29 2011, 13:05) *
- Подсистема MMU берет на себя все вопросы интерфейса процессора с внешним миром, включая по мере необходимости
такие вещи как организацию кэшей, трансляцию адресов и организацию внешних шин.


Вы ещё не забросили разработку процессора? У меня есть пожелания к реализации MMU и пожелание расширить систему команд.
alexey123_45
А как Вы относитесь к построению и применению forth-процессоров? Мне кажется, что это перспективное направление
Corner
А мне больше нравиться архитектура, когда в одном программном слове указатели на данные и их формат. Одна инструкция содержит до 11 скрытых операций: две загрузки, три модификации данных, три пост модификации адреса, сохранение и две арифметические операции. Мало кода, четкая параллельность...
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.