Тогда уж аспект конвейеризации нужно рассмотреть для обоих сравниваемых ядер (и их конфигов, т.к. SCR1 Min/Max конвейеры разнятся по числу стадий).
Да, для оптимизации по объему HW ресурсов ("площади") PicoRV32 не применяет конвейер. И это закономерно отражается даже в результатах Dhrystone:
Cycles per Instruction:
PicoRV32 (min/max): 5.8 / 5.6
SCR1 (min/max): 1.5 / 1.7
Но PicoRV32 явно создавался не для взятия высот по производительности, а чтобы дать возможность встроить даже в относительно малые FPGA программируемое ядро RISC-V. У него в коде есть привязки к технологическому базису FPGA-вендоров? Не удивлюсь, если так.
У SCR1 и PicoRV32 - несколько разные области применения. И данный анализ еще раз это показывает.
Тогда уж аспект конвейеризации нужно рассмотреть для обоих сравниваемых ядер (и их конфигов, т.к. SCR1 Min/Max конвейеры разнятся по числу стадий).
Да, для оптимизации по объему HW ресурсов ("площади") PicoRV32 не применяет конвейер. И это закономерно отражается даже в результатах Dhrystone:
Cycles per Instruction:
PicoRV32 (min/max): 5.8 / 5.6
SCR1 (min/max): 1.5 / 1.7
Но PicoRV32 явно создавался не для взятия высот по производительности, а чтобы дать возможность встроить даже в относительно малые FPGA программируемое ядро RISC-V. У него в коде есть привязки к технологическому базису FPGA-вендоров? Не удивлюсь, если так.
У SCR1 и PicoRV32 - несколько разные области применения. И данный анализ еще раз это показывает.
Все-таки нужно здесь применить CoreMark - он гораздо лучше расставляет процессорные ядра по рангам (в среднем по больнице).