Суперскалярное процессорное ядро Super-V (самоделка RISC-V)

[Shaos]

Идея создать опен-сорцное супер-пупер RISC-V-совместимое ядро для FPGA под названием Super-V, которое будет работать с памятью по 64-битной шине, вычитывая за раз 2 обычные инструкции RISC-V по 32 бита либо 4 компактные инструкции RISC-V по 16 бит (возможно и скажем одну 32-битную и две 16-битные за раз вычитать), теоретически приближая производительность к ЧЕТЫРЁМ инструкциям на такт! Суперскалярность будет достигаться засчёт того, что некоторые идущие друг за другом инструкции могут быть независимыми и выполняться параллельно и необязательно в том порядке, в котором они расположены в памяти (Out-of-Order). Кроме того многотактовые инструкции типа умножения и деления (или инструкции по работе с плавающей точкой) могут медленно выполняться где-то в сторонке, пока быстрые однотактовые инструкции лупят одна за другой в основном вычислительном модуле (количество паралельных целочисленных и плавающих модулей надо прикинуть на эмуляторе, выполняя реальные вычисления). Также можно будет потом добавить кеши данных и команд (64-битные), что даст возможность задействовать в качестве памяти какую-нибудь обычную DDR (вся алхимия с суперскалярностью будет выполняться на уровне кеша инструкций).

P.S. Для разнобезобразия можно выбрать в качестве опен-сорцной лицензии GPL v3

P.P.S. Прожэкт на Хакадее: https://hackaday.io/project/162859-super-v

[Shaos]

Например BOOM (Berkeley Out-of-Order Machine), которая тоже по 2 инструкции за раз декодит, выдаёт вот такие результаты IPC (Instructions Per Cycle):

boom.gif

Источник: https://riscv.org/wp-content/uploads/2016/01/Wed1345-RISCV-Workshop-3-BOOM.pdf

Так вот хотелось бы эти показатели превзойти...

[starsnet]

Идея создать опен-сорцное супер-пупер RISC-V-совместимое ядро для FPGA под названием Super-V, которое будет работать с памятью по 64-битной шине....

а почему сразу не 128 бит?
насколько я понял (не схемотехник ни разу - непинайте сильно;)) риск-5 - можно реконфигурировать как вверх, так и вниз.
тогда почему бы сразу не проектировать 128-бит, в максимуме; и "свертывать" в 64 и 32 бита ?
или, всё-таки (предполагаю..) каждый проц надо будет проектировать по отдельности (типа, реализация может быть разной -> не всегда универсальной) ?

P.S. Для разнобезобразия можно выбрать в качестве опен-сорцной лицензии GPL v3

А давайте BSD или MIT

P.P.S. Прожэкт на Хакадее: https://hackaday.io/project/162859-super-v

З.Ы.

Сложно самому этому научитья ?))))

[Shaos]

Кто незнаком с суперскалярной архитектурой, может почитать википедию:

https://ru.wikipedia.org/wiki/%D0%A1%D1%83%D0%BF%D0%B5%D1%80%D1%81%D0%BA%D0%B0%D0%BB%D1%8F%D1%80%D0%BD%D0%BE%D1%81%D1%82%D1%8C

В-краце, суперскалярность есть там, где система способна исполнять более одной инструкции за раз

В нашем случае точно будет конвейер и, возможно, кэш, а кроме того предполагается иметь две основные фишки суперскалярности, описанные по ссылке выше:

внеочередное исполнение - когда инструкции выполняются не по порядку следования в памяти, а по мере готовности аргументов, и

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

P.S. Такой подход используется в современных x86-процессорах для увеличения производительности не углубляясь в дальнейшие гигагерцы (первым суперскалярным x86 считается пентиум с его двумя алу)

[Shaos]

Идея создать опен-сорцное супер-пупер RISC-V-совместимое ядро для FPGA под названием Super-V, которое будет работать с памятью по 64-битной шине....

а почему сразу не 128 бит?
насколько я понял (не схемотехник ни разу - непинайте сильно;)) риск-5 - можно реконфигурировать как вверх, так и вниз.
тогда почему бы сразу не проектировать 128-бит, в максимуме; и "свертывать" в 64 и 32 бита ?
или, всё-таки (предполагаю..) каждый проц надо будет проектировать по отдельности (типа, реализация может быть разной -> не всегда универсальной) ?

Спецификация 128 бит для RISC-V пока не готова, а лужайка с 64-битными рископятками уже достаточно плотно усижена большими дядьками

Ну и потом до 64-битной потом можно при желании расширить (инструкции от 32-битной системы остаются как есть - просто добавляются несколько новых - см. тут)

P.S. Для разнобезобразия можно выбрать в качестве опен-сорцной лицензии GPL v3

А давайте BSD или MIT

Чтобы каждый коммерсант мог себе это ядро воткнуть и обозвать своим именем? Неа

P.P.S. Прожэкт на Хакадее: https://hackaday.io/project/162859-super-v

З.Ы.
Сложно самому этому научитья ?))))

Научиться создавать прожэкт на хакадее? Нет не сложно

[Shaos]

Кто незнаком с суперскалярной архитектурой, может почитать википедию:

https://ru.wikipedia.org/wiki/%D0%A1%D1%83%D0%BF%D0%B5%D1%80%D1%81%D0%BA%D0%B0%D0%BB%D1%8F%D1%80%D0%BD%D0%BE%D1%81%D1%82%D1%8C

В-краце, суперскалярность есть там, где система способна исполнять более одной инструкции за раз

В нашем случае точно будет конвейер и, возможно, кэш, а кроме того предполагается иметь две основные фишки суперскалярности, описанные по ссылке выше:

внеочередное исполнение - когда инструкции выполняются не по порядку следования в памяти, а по мере готовности аргументов, и

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

P.S. Такой подход используется в современных x86-процессорах для увеличения производительности не углубляясь в дальнейшие гигагерцы (первым суперскалярным x86 считается пентиум с его двумя алу)

Ещё из фишек, которые хотелось бы поисследовать:

предсказание переходов - это когда система предполагает заранее куда пойдёт условные переход и начинает его выполнение, если же в итоге выяснится, что система ошиблась, то все результаты этой работы отменяются и система идёт по другому пути, теряя несколько тактов на новое заполнение конвейера) и

спекулятивное исполнение - это когда система выполняет некоторый набор команд, результаты работы которого могут оказаться ненужны - например то же предсказание переходов (даже с параллельным выполнением обоих веток), однако это также распостраняется на другие вещи - предсказание результата вычислений и продолжение вычислений с этим значением (если предсказание окажется неправильным, то все вычисленное откатывается), предсказание предзагрузки из памяти и т.д.

[starsnet]

Спецификация 128 бит для RISC-V пока не готова, а лужайка с 64-битными рископятками уже достаточно плотно усижена большими дядьками

А что, уже есть готовые 64-битные процы?? Где можно посмотреть/скачать/испечь ? Я бы пощупал)

Чтобы каждый коммерсант мог себе это ядро воткнуть и обозвать своим именем? Неа

Этот момент меня всегда вводит в ступор..
С одной стороны, конторы могут воспользоваться готовым, и ничего не отдавать взамен (при BSD-like лицензии).
С другой стороны, пока какой-нибудь коменрсант не займется/не заинтересуется - продукт развивается медленно. Асимптотически вниз. По больше части так до продакшена не доходит.
В третьих, когда мы говорим про "свободное програмное обеспечение", почему-то, ПО ФАКТУ, получается эгоизм.
Что bsd-like юзвери перестают делиться своими наработками - ващ вариант.
Что gpl-юзвери ЗАСТАВЛЯЮТ других. GPL жешь требует делиться)
И в том, и в другом случае - причина в человеческом нутре)))
Ну, это офтоп.

Научиться создавать прожэкт на хакадее? Нет не сложно

Не проект на хакадее.
А проектировать процессор) Я тут прошелся по книжкам на вашем форуме. Есть, конечно интересные.
Но, так или иначе, (как мне показалось) пока не изучишь "работу на уровне вентилей" (так обозву сие дело) процессор не слепить)

[Shaos]

Ну как бы да - желательно разбираться во всём снизу доверху...

P.S. По поводу существующих коров и процов см. https://riscv.org/risc-v-cores/

[Shaos]

Добавил больше статистики в эмуль:

https://gitlab.com/nedopc/npc5/blob/master/emu-rv32i.c

По тесту быстродействия Dhrystone оно например теперь такую статистику собирает (обновлено 24 декабря 2018 - теперь с Top5):

Code: Select all

Instructions Stat:
LUI	= 892
AUIPC	= 7716
JAL	= 11212
JALR	= 12850
BEQ	= 33399
BNE	= 11298
BLT	= 1721
BGE	= 3480
BLTU	= 7017
BGEU	= 2248
LW	= 31050
LBU	= 27712
LHU	= 502
SB	= 4968
SH	= 502
SW	= 33037
ADDI	= 87830
SLTIU	= 1500
XORI	= 1
ORI	= 1
ANDI	= 6151
SLLI	= 10647
SRLI	= 9534
SRAI	= 95
ADD	= 11486
SUB	= 2813
SLL	= 402
SLTU	= 1844
SRL	= 353
OR	= 2459
CSRRW	= 1
CSRRS	= 8
LI*	= 20602

Five Most Frequent:
0) ADDI	= 87830 (27.05%)
1) BEQ	= 33399 (10.29%)
2) SW	= 33037 (10.17%)
3) LW	= 31050 (9.56%)
4) LBU	= 27712 (8.53%)

Memory Reading Area 80000000...80007ae2
Memory Writing Area 80001000...80007b3f

>>> Execution time: 1425296449 ns
>>> Instruction count: 324730 (IPS=227833)
>>> Jumps: 50209 (15.46%) - 18074 forwards, 32135 backwards
>>> Branching T=26147 (44.19%) F=33016 (55.81%)

Это с кучей отладочной печати и подсчётом частоты вызова каждой инструкции (LI подсчитана отдельно, но на самом деле это ADDI c нулевым регистром), а если без лишней печати то так:

Code: Select all

>>> Execution time: 25084843 ns
>>> Instruction count: 324730 (IPS=12945267)
>>> Jumps: 50209 (15.46%) - 18074 forwards, 32135 backwards
>>> Branching T=26147 (44.19%) F=33016 (55.81%)

т.е. эмуль гонит со скоростью почти 13 миллионов операций в секунду
также отсюда видно, что 15% от всех пройденных инструкций занимают джампы (передача управления на другой адрес)
большая часть джампов ведёт назад (backwards)
а условные переходы в 56% не выполняются (в этом случае должен исполняться код, идущий непосредственно следом за командой условного перехода)

[Shaos]

Вот простейший пример для сравнения:

Code: Select all

/*
 Frank Buss: compile like this: riscv32-unknown-elf-gcc -O3 -nostdlib test1.c -o test1
 or
 riscv64-unknown-elf-gcc -march=rv32i -mabi=ilp32 -O3 -nostdlib test1.c -o test1
*/
void _start()
{
    volatile char* tx = (volatile char*) 0x40002000;
    const char* hello = "Hello RISC-V!\n";
    while (*hello) {
        *tx = *hello;
        hello++;
    }
}

который компилируется вот в такой код:

Code: Select all

test1:     file format elf32-littleriscv


Disassembly of section .text:

00010054 <_start>:
   10054:	000107b7          	lui	a5,0x10
   10058:	07878793          	addi	a5,a5,120 # 10078 <_start+0x24>
   1005c:	04800713          	li	a4,72
   10060:	400026b7          	lui	a3,0x40002
   10064:	00e68023          	sb	a4,0(a3) # 40002000 <__global_pointer$+0x3fff0778>
   10068:	00178793          	addi	a5,a5,1
   1006c:	0007c703          	lbu	a4,0(a5)
   10070:	fe071ae3          	bnez	a4,10064 <_start+0x10>
   10074:	00008067          	ret

Собранная статистика:

Code: Select all

Instructions stat:
LUI    = 2
JALR   = 1
BNE    = 14
LBU    = 14
SB     = 14
ADDI   = 16

Memory Reading Area 10054...10086
Memory Writing Area NONE

>>> Execution time: 322214 ns
>>> Instruction count: 62 (IPS=192418)
>>> Jumps: 14 (22.58%) - 0 forwards, 14 backwards
>>> Branching T=13 (92.86%) F=1 (7.14%)

Как можно видеть тут наоборот, в подавляющем большинстве случаев условное ветвление успешно (93% для Branching True)

P.S. По поводу псевдоинструкций ассемблера RISC-V (чтобы понять что спрятано под li и под ret) см. в соответствующем топике: viewtopic.php?p=149263#p149263

[Shaos]

Статистика по некоторым другим тестам из набора https://github.com/riscv/riscv-tests/tree/master/benchmarks

Code: Select all

median: 

>>> Execution time: 1391119 ns
>>> Instruction count: 16244 (IPS=11676930)
>>> Jumps: 3552 (21.87%) - 1254 forwards, 2298 backwards
>>> Branching T=2613 (53.36%) F=2284 (46.64%)

multiply:

>>> Execution time: 4743276 ns
>>> Instruction count: 49670 (IPS=10471665)
>>> Jumps: 13808 (27.80%) - 6310 forwards, 7498 backwards
>>> Branching T=12915 (86.46%) F=2022 (13.54%)

qsort: 

>>> Execution time: 19821720 ns
>>> Instruction count: 236219 (IPS=11917179)
>>> Jumps: 45487 (19.26%) - 8141 forwards, 37346 backwards
>>> Branching T=37792 (59.71%) F=25503 (40.29%)

rsort: 

>>> Execution time: 31545464 ns
>>> Instruction count: 374291 (IPS=11865129)
>>> Jumps: 15239 (4.07%) - 797 forwards, 14442 backwards
>>> Branching T=14653 (73.66%) F=5239 (26.34%)

towers: 

>>> Execution time: 1474786 ns
>>> Instruction count: 18656 (IPS=12649970)
>>> Jumps: 2027 (10.87%) - 762 forwards, 1265 backwards
>>> Branching T=1037 (57.20%) F=776 (42.80%)

vvadd: 

>>> Execution time: 1004666 ns
>>> Instruction count: 11974 (IPS=11918388)
>>> Jumps: 1830 (15.28%) - 492 forwards, 1338 backwards
>>> Branching T=1417 (62.18%) F=862 (37.82%)

Попытаюсь объяснить зачем нужна такая статистика. Скажем мы делаем реализацию RISC-V с 5-шаговым конвейером, который в случае передачи управления сбрасывает своё состояние и запускает конвейеризацию заново, что приведёт к потере 5 тактов на каждый переход, если все остальные команды выполняются за 1 такт, то при 15% переходов среди исполняемых инструкций - 15 переходов и 85 непереходов - мы потеряем 15*5=75 тактов переходов на каждые 85 тактов обычных инструкций, что практически равно половине времени исполнения программы! Именно поэтому надо уходить в суперскалярность и спекулятивное исполнение...

[Shaos]

Вот простейший пример для сравнения:

Code: Select all

/*
 Frank Buss: compile like this: riscv32-unknown-elf-gcc -O3 -nostdlib test1.c -o test1
 or
 riscv64-unknown-elf-gcc -march=rv32i -mabi=ilp32 -O3 -nostdlib test1.c -o test1
*/
void _start()
{
    volatile char* tx = (volatile char*) 0x40002000;
    const char* hello = "Hello RISC-V!\n";
    while (*hello) {
        *tx = *hello;
        hello++;
    }
}

который компилируется вот в такой код:

Code: Select all

test1:     file format elf32-littleriscv


Disassembly of section .text:

00010054 <_start>:
   10054:	000107b7          	lui	a5,0x10
   10058:	07878793          	addi	a5,a5,120 # 10078 <_start+0x24>
   1005c:	04800713          	li	a4,72
   10060:	400026b7          	lui	a3,0x40002
   10064:	00e68023          	sb	a4,0(a3) # 40002000 <__global_pointer$+0x3fff0778>
   10068:	00178793          	addi	a5,a5,1
   1006c:	0007c703          	lbu	a4,0(a5)
   10070:	fe071ae3          	bnez	a4,10064 <_start+0x10>
   10074:	00008067          	ret

Собранная статистика:

Code: Select all

Instructions stat:
LUI    = 2
JALR   = 1
BNE    = 14
LBU    = 14
SB     = 14
ADDI   = 16

Memory Reading Area 10054...10086
Memory Writing Area NONE

>>> Execution time: 322214 ns
>>> Instruction count: 62 (IPS=192418)
>>> Jumps: 14 (22.58%) - 0 forwards, 14 backwards
>>> Branching T=13 (92.86%) F=1 (7.14%)

Как можно видеть тут наоборот, в подавляющем большинстве случаев условное ветвление успешно (93% для Branching True)
--------
P.S. По поводу псевдоинструкций ассемблера RISC-V (чтобы понять что спрятано под li и под ret) см. в соответствующем топике: viewtopic.php?p=149263#p149263

Можно на примере этой простой программи посмотреть как может работать наш суперскалярный процессор:

10054: 000107b7 lui a5,0x10 ; a5=0x10<<12=0x10000
10058: 07878793 addi a5,a5,120 # 10078 <_start+0x24> ; a5=a5+0x78=0x10078

эти 2 команды читаются за раз (два 32-битных слова по 64-битной шине данных) - более того, их и надо выполнять одновременно т.к. то что они делают это просто заносят число 0x10078 в 15й регистр a5 (инструкциями RISC-V это невозможно сделать в одну команду т.к. непосредственные значения там задаются только 12-ю битами)

1005c: 04800713 li a4,72 ; 000001001000 (0x048) 00000 (x0) 000 01110 (x14) 0010011 (ADDI) = addi a4,x0,72
10060: 400026b7 lui a3,0x40002 ; a3=0x40002<<12=0x40002000

это 2 независимые инструкции - первая записывает число 72 в 14й регистр a4, а вторая записывает число 0x40002000 в 13й регистр a3 - если железо допускает одновременную запись в регистры, то эти две команды можно выполнить одновременно

10064: 00e68023 sb a4,0(a3) # 40002000 <__global_pointer$+0x3fff0778> ; [a3]=a4
10068: 00178793 addi a5,a5,1 ; a5=a5+1

это запись младшего байта из 14го регистра a4 в память по адресу 0x40002000 хранимому в 13м регистре a3 и инкремент a5 - теоретически эти две команды можно выполнить одновременно т.к. они независимы

1006c: 0007c703 lbu a4,0(a5) ; a4=[a5]
10070: fe071ae3 bnez a4,10064 <_start+0x10> ; bne a4,x0,смещение до 0x10064

тут у нас чтение байта из памяти (адрес берётся из a5) и сохранение его в 14м регистре a4 (старшие байты в регистре заполняются нулями) и далее условие зацикливания a4!=0 - эти две команды зависят друг от друга - вторая не будет выполнена, пока первая полностью не отработает через все ступени конвейера (с обратной записью в регистр a4), однако если у нас имеется предсказание переходов и мы знаем, что оно обычно таки переходит на 0x10064, то мы не дожидаясь проверки можем спокойно отправляться вычитывать команды по адресу 0x10064, правда там идёт запись в память того же a4, которую мы делать не должны, пока не убедимся, что a4 обновлён и условие на предыдущем шаге таки выполнилось

10074: 00008067 ret ; jalr x0,x1,0
10046: ????

это возврат из подпрограммы - вторую команду тут можно игнорировать

[Shaos]

Вставил в эмулятор подсчёт 5 наиболее частых инструкций:

Code: Select all

dhrystone:

Five Most Frequent:
1) ADDI   = 87830 (27.05%)
2) BEQ   = 33399 (10.29%)
3) SW   = 33037 (10.17%)
4) LW   = 31050 (9.56%)
5) LBU   = 27712 (8.53%)

median:

Five Most Frequent:
1) ADDI	= 3758 (23.13%)
2) LW	= 3519 (21.66%)
3) BNE	= 1825 (11.23%)
4) BGE	= 1240 (7.63%)
5) SW	= 1141 (7.02%)

multiply:

Five Most Frequent:
1) ADDI	= 9581 (19.29%)
2) BNE	= 7309 (14.72%)
3) SLLI	= 7052 (14.20%)
4) BEQ	= 6691 (13.47%)
5) ANDI	= 6540 (13.17%)

qsort:

Five Most Frequent:
1) ADDI	= 77881 (32.97%)
2) LW	= 56308 (23.84%)
3) BLT	= 37593 (15.91%)
4) SW	= 17257 (7.31%)
5) BLTU	= 7834 (3.32%)

rsort:

Five Most Frequent:
1) LW	= 76238 (20.37%)
2) ADDI	= 54419 (14.54%)
3) SW	= 53704 (14.35%)
4) ADD	= 51461 (13.75%)
5) SLLI	= 50106 (13.39%)

towers:

Five Most Frequent:
1) ADDI	= 6397 (34.29%)
2) SW	= 3716 (19.92%)
3) LW	= 3682 (19.74%)
4) LI*	= 944 (5.06%) <=== this is part of ADDI
5) BEQ	= 615 (3.30%)

vvadd:

Five Most Frequent:
1) ADDI	= 3809 (31.81%)
2) LW	= 2135 (17.83%)
3) BNE	= 1443 (12.05%)
4) SW	= 945 (7.89%)
5) ADD	= 745 (6.22%)