[Leka 0]

Жаль, что проект с компилятором заглох...

Делаю апгрейд своего софтпроцессора - вместо Фон-Неймановской архитектуры взял Гарвардскую, и выделил 1К регистровый файл в отдельную 3х-портовую память. После P&R для минимального 18-разрядного ядра без периферии:

Спартан3 ~120 ЛУТ, ~120МГц,

Циклон3 ~250 ЛУТ, ~120МГц.

a=b+c; - 1 такт,

a=b[j]+c[k]; - 2 такта.

 

 

[POVRU 0]

Программеров разогнали, деньги кончились. Сейчас работаю только на основной работе.

По поводу производительности - сейчас рулят синтетические наборы инструкций с сетевой организацией вычислительных блоков. Одна российская контора пытается сделать это на ПЛИС. Цель - обогнать видеокарту по производительности. Блажен кто верует...

[DevL 0]

кстати , для гибкости в выборе ассемблера - оказался очень забавный вариант описанные тут "Пакет для разработки ПО для ПК "Специалист""

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 + полная компиляция :)

 

 

 

[Lexey 0]

 

Давно маюсь с софт-процессором для ПЛИС, решил поделиться своеми соображениями.

Ни один из готовых вариантов меня не радует, хотя в моих требованиях нет ничего оригинального и нереального:

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 3]

Ключевая проблема тут в том что имеющиеся процессоры очень непроизводительны при работе с SDRAM.

Отказываюсь от кэша данных, как от вещи малоэффективной и ресурсоемкой в данной ситуации.

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

 

1b. асинхронное выполнение команд загрузки/cохранения контроллером SDRAM

Предполагаемая тактовая : 125 MHz (общая для ядра и SDRAM)

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

 

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

a "DMA контроллер" железо<->EBR тривиален.

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

 

 

 

[Lexey 0]

Интерфейс ядра - удобная штука для разделения проекта софтпроцессора на части.

При соблюдении несложных правил, определенных этим интерфейсом можно делать свои софт-процессоры используя готовую подсистему 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 0]

Может кого интересуют IP дла плавающей точки. Могу предложить быстрый multifunc fp для вычисления DIV, RECP, SQRT, RSQRT

[ArtemDement 0]

Ни у кого 10 000 000 $ не завалялось для спонсирования открытого процессора от Qimod ?

 

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

[LV26 0]

Ни у кого 10 000 000 $ не завалялось для спонсирования открытого процессора от Qimod ?

 

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

 

Лохотроном каким-то попахивает....

Вот это гораздо прозрачнее и понятнее.

http://opencores.org/donation

[SyncLair 0]

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

[Wic 0]

Я что-то не понимаю зачем городить процессор, вроде и так все процессоры что есть имеют свободную спецификацию.

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

[Leka 0]

...Но ее нужно решать с оглядкой на ОС, которые на нем буду крутиться *nix/win/etc.

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

- Но ведь у каждого индивидуальное строение лица...

- Так это только в первый раз!"

 

ОС и интерфейсы - это и есть "автоматические бритвы". И какой смысл в "индивидуальном строении" процессоров? :cranky:

Изменено 7 декабря, 2012 пользователем Leka

[alman 0]

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

такие вещи как организацию кэшей, трансляцию адресов и организацию внешних шин.

 

Вы ещё не забросили разработку процессора? У меня есть пожелания к реализации MMU и пожелание расширить систему команд.

 

[alexey123_45 0]

А как Вы относитесь к построению и применению forth-процессоров? Мне кажется, что это перспективное направление

[Corner 0]

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