| |
|
  |
 Свои процессоры, Разработка своих процессоров со своей системой команд |
|
|
|
|
 Feb 22 2011, 23:37
|
Участник
Группа: Участник
Сообщений: 38
Регистрация: 1-02-07
Пользователь №: 24 959
|
Программеров разогнали, деньги кончились. Сейчас работаю только на основной работе.
По поводу производительности - сейчас рулят синтетические наборы инструкций с сетевой организацией вычислительных блоков. Одна российская контора пытается сделать это на ПЛИС. Цель - обогнать видеокарту по производительности. Блажен кто верует...
|
|
|
|
|
|
|
|
Apr 20 2011, 21:02
|
Местный
Группа: Свой
Сообщений: 254
Регистрация: 23-10-10
Из: астрал
Пользователь №: 60 371
|
кстати , для гибкости в выборе ассемблера - оказался очень забавный вариант описанные тут "Пакет для разработки ПО для ПК "Специалист"" 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 + полная компиляция 
|
|
|
|
|
|
|
|
May 7 2011, 22:03
|
Группа: Новичок
Сообщений: 5
Регистрация: 6-07-06
Пользователь №: 18 646
|
Давно маюсь с софт-процессором для ПЛИС, решил поделиться своеми соображениями.
Ни один из готовых вариантов меня не радует, хотя в моих требованиях нет ничего оригинального и нереального:
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 месяца надеюсь дойдет до отладки
|
|
|
|
|
|
|
|
May 7 2011, 23:20
|
Профессионал
Группа: Свой
Сообщений: 1 284
Регистрация: 9-04-06
Пользователь №: 15 968
|
Цитата(Lexey @ May 8 2011, 02:03)  Ключевая проблема тут в том что имеющиеся процессоры очень непроизводительны при работе с SDRAM.
Отказываюсь от кэша данных, как от вещи малоэффективной и ресурсоемкой в данной ситуации. Так кэш то и призвана решать эту проблему. Хотя смотря под какие задачи и какая кэш. Цитата 1b. асинхронное выполнение команд загрузки/cохранения контроллером SDRAM
Предполагаемая тактовая : 125 MHz (общая для ядра и SDRAM) На каких fpga? Если бюджетные, то мне например идея асинхронщины не нравится Цитата При такой организации отпадает необходимость прямого доступа железо<->SDRAM, поскольку сам процессор сможет пересылять данные по прерываниям между EBR и SDRAM не менее производительно чем любой железный DMA (но при этом гораздо гибче и удобней),
a "DMA контроллер" железо<->EBR тривиален. Опять же смотря под какие задачи. Если для обработки видео - без дма сразу нет. Да и вобще софт процессор без дма...
|
|
|
|
|
|
|
|
May 29 2011, 09:05
|
Группа: Новичок
Сообщений: 5
Регистрация: 6-07-06
Пользователь №: 18 646
|
Интерфейс ядра - удобная штука для разделения проекта софтпроцессора на части. При соблюдении несложных правил, определенных этим интерфейсом можно делать свои софт-процессоры используя готовую подсистему 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-ступенчатой модели
|
|
|
|
|
|
|
|
Oct 31 2012, 07:00
|
Группа: Новичок
Сообщений: 7
Регистрация: 7-03-09
Из: Москва
Пользователь №: 45 782
|
Может кого интересуют IP дла плавающей точки. Могу предложить быстрый multifunc fp для вычисления DIV, RECP, SQRT, RSQRT
|
|
|
|
|
|
|
|
Dec 7 2012, 05:34
|
Частый гость
Группа: Свой
Сообщений: 183
Регистрация: 16-03-08
Из: Новосибирск
Пользователь №: 35 954
|
Цитата(SyncLair @ Dec 7 2012, 04:30) Я что-то не понимаю зачем городить процессор, вроде и так все процессоры что есть имеют свободную спецификацию. Свободная спецификация != открытый код/бесплатная лицензия. Если бы тот же арм имел открытый код, его бы очень быстро клонировали для специфичных применений. То о чем писали на хабре, имхо, фантастика. Современный процессор за 10Му.е. не сделать. А вот софтверный процессор с открытым кодом для FPGA реальная задача. Но ее нужно решать с оглядкой на ОС, которые на нем буду крутиться *nix/win/etc.
|
|
|
|
|
|
|
|
Dec 7 2012, 07:17
|
Профессионал
Группа: Участник
Сообщений: 1 075
Регистрация: 30-09-05
Пользователь №: 9 118
|
Цитата ...Но ее нужно решать с оглядкой на ОС, которые на нем буду крутиться *nix/win/etc. "- Хочу предложить последнее свое изобретение. Это автомат для бритья. Клиент опускает монеты, просовывает голову в отверстие, и две бритвы автоматически бреют. - Но ведь у каждого индивидуальное строение лица... - Так это только в первый раз!" ОС и интерфейсы - это и есть "автоматические бритвы". И какой смысл в "индивидуальном строении" процессоров? 
Сообщение отредактировал Leka - Dec 7 2012, 07:18
|
|
|
|
|
|
|
|
Dec 23 2012, 23:31
|
Участник
Группа: Участник
Сообщений: 45
Регистрация: 22-12-10
Из: Россия, Ростовская обл.
Пользователь №: 61 800
|
Цитата(Lexey @ May 29 2011, 13:05) - Подсистема MMU берет на себя все вопросы интерфейса процессора с внешним миром, включая по мере необходимости
такие вещи как организацию кэшей, трансляцию адресов и организацию внешних шин. Вы ещё не забросили разработку процессора? У меня есть пожелания к реализации MMU и пожелание расширить систему команд.
|
|
|
|
|
|
|
|
Aug 1 2013, 05:58
|
Участник
Группа: Участник
Сообщений: 69
Регистрация: 1-03-13
Пользователь №: 75 850
|
А как Вы относитесь к построению и применению forth-процессоров? Мне кажется, что это перспективное направление
|
|
|
|
|
|
|
|
3 чел. читают эту тему (гостей: 3, скрытых пользователей: 0)
Пользователей: 0
|
|
|
