нещо не вдявам... може би защото само с "хуйни" съм се занимавал и нямам база за сравнение

То май точно в това и е силата на отворената архитектура, че можеш да интегрираш периферията ефективно в самото ядро. Нещо което за определени приложения би било от предимство. Със сигурност обаче не е универсално решение и приказката, че за всеки влак си има пътник остава валидна.

Та Бай Уй, идеята е добра, сега остава само да намериш подходящ проблем за демото. Кодът със сигурност ще го подкараш щом авторът казва, че го е мапвал успешно.

За мен идеята (и силата) на RISC V е, че можеш да ползваш ISA-та му свободно. За разлика от ARM, x86 и т.н. Ако няма да я ползваш, няма никакво значение дали е свободна, отворена, затворена и т.н. Това с модифицирането е по средата, седиш на два стола и то на ръбовете им. За да направиш собствена периферия няма нужда нито от модификации, нито от отворено ядро. Ей примерно цинка - на пръв поглед ползват затворено ядро, в което не може да бъркаш. Ми няма и нужда да бъркат, щото могат да се закачат между кеша и конвейра и да си вадят от там неща, примерно къстъм инструкции. Или да вмъкват неща. На практика може да направиш доста изменения на уж затворена архитектура. Но досега не съм видял нито един интересен проект на тая тема. И не се учудвам, аз също не бих тръгнал да мажа нещо работещо и да правя глупости. Особено в цинка, който ти позволява всякаква периферия и да си я навреш където си искаш

Проблемите според мен не са в ядрата или поне не се решават, чрез модификацията им. Има достатъчно ядра за всеки вкус. Но това, което няма все още е читава шина за външни периферии. Ако нещо все пак е изведено, то е или прекалено бавно, или прекалено много жици или прекалено нестандартно и неудобно.

Има си и известни удобства да седиш на два стола. Можеш да използваваш GCC на готово за скаларната част и да си спретнеш каквито ти трябват векторни ускорители, които после да инлайнваш директно в асемблера. Иначе казано със сравнително малко усилия би могъл да скалъпиш доста сериозна система, която при това да е скалируема. Ако стартирам фирма дето да дялка силикон, по всяка вероятност това ще подхода, който бих избрал. Доколко това би било подходящо решение за фирма произвеждаща крайни продукти е доста по-сложен въпрос. Навремето гледах цинковете с влажни очи ама цената им си е фактор за много начинания. За обвързаността с производителя да не говорим.

Абе то хубаво, ама омешиш ли се с вектори, за да не ти се пречкат и да има смисъл отиваш на суперскалар и out of order и работата загрубява.
Това е бизнес за стария ти работодател...
Далеч по-чисто е да не смесваш сметалките с акъла. Избягваш сума си проблеми и в желязото и в софтуера. Единствено връзката помежду им трябва да е добра. И то даже не е задължително помежду им, може да е към обща памет.

Такава опасност съществува в действителност, но само ако се стараеш да останеш в едно ядро. Скалирането на броя на ядрата позволява да държиш всичко вътре в тяхо строго сериялизирано за сметка на сложнотията при синхронизирането между самите ядра.

Иначе казано, това което трябва да върви паралено може да бъде разхвърляно върху множество хардуерно ускорени ядра, като всяко ядро поема задачата да конфигурира вградените акселератори и да евалюира резултатите от тяхната работа, строго секвенциялизиран процес.

дали ще останеш в едно ядро е следваща стъпка, която не коментирам. Въпросът беше, че първо трябва да влезеш в едно. Щото ти каза, че ще се възползваш от GCC и ще разшириш ISA-та лесно, т.е. ще вкараш някакви си ускорители.
За тая стъпка ти говоря, че не е толкова лесна и компилаторът ти е най-малкият проблем. Значи първо не е достатъчно да вкараш нови инструкции, а да ги вкарваш така, че да не съсипваш стандартната част от ядрото. На практика трябва да фетчваш допълнително байтове, но обикновено шината и целия процес не е сметнат за повече трафик. Даже не винаги е достатъчен и за основния. Примерно АРМ до 4-та архитектура имаше една шина през която претакваха и код и данни и която работеше с клока на ядрото. Демек имаш само 32 бита трансфер на клок и ядро, което може да изпълнява 1 инструкция на клок и инструкцията ти е 32 бита. Ами честито, това ядро ако работи на 100% си натоварва шината на 100% само с код. А някои инструкции изискват и данни и от там шеш не щеш тия инструкции ги правеха 2-3 клока, просто защото като ползваш шината за данни конвейра трябва да буксува. На практика старите АРМ-ве масово бяха спънати заради шината си.
Хайде, това беше едно време. Сега вече слагат и по няколко шини и/или шините са двойно по-широки от ширината на инструкциия/данни. Но от друга страна и ядрата ги правят по-лакоми, вече са поне dual-issue. Така че пак не остава много запас за твой трафик. Особено пък на практика, щото на ядрото може да имаш изведени няколко шини, ама често на практика водят към една и съща памет и става сакътлък пак...
Да кажем, че има някакъв шанс да вдигнеш още малко, но обикновено е на косъм работата. А е тъпо твоя трафик дето е уж за ускоряване да оставя на сухо основното ядро. Та тва исках да кажа. Звучи добре като идея да "ускориш" ядрото, но на практика може да се окаже че вместо това го спъваш. Просто поне за ядрата с които съм имал вземане-даване мога да кажа, че не са предвидени за подобни "ускорения" и затова не бих се мъчил да ги изнасилвам. По-скоро ускорителите да са си отделно и башка както се казва на чист български

когато гледаш на ядрото като на елементарен контролер чиято цел е единствено да обслужва ускорителя и се откъснеш от концепцията за основно ядро, като на нейно място допуснеш тази за море от ядра/ускорители вече не е толкова тъпо. Но както казах по-горе за всеки проблем си има подходяща архитектура. Иновациите идват там където намериш проблем, който досега е бил спъван от ограничени алгортимични подходи прилагани при решението на всеки проблем и помислиш как може да се реши по-ефективно. Но за тази цел човек трябва доста да го убива чипика, иначе няма мотивация за иновация.

Нещо като XMOS?

Не ги бях виждал, но да. Доста семпла архитектура, подходяща точно за целите които са си изрбали - ML inferencing and advanced audio DSP. Напълно неподходяща обаче за проблеми изискващи масивно прехвърляне на данни като ML training, advanced image processing или high datarate wireless DSP. Но това е и идеята като цяло. Намираш един проблем и му скалъпваш подходящата архитектура. А не като досега през просото - по-големи кешове, по-бързи ядра и пр. И RISC-V има потенциала да ти даде подходяща платформа на която да стартираш. Дали обаче народа ще се качи на тази платформа или ще продължи по старому зависи от доста фактори. Реакцията на големите IP играчи като ARM, Cadence, Synopsys от една страна и на фабриките TSCM, HSMC/SMIC, GF, Samsung от друга. Факт е обаче, че с процесите надолу няка къде да слизат (вече са на 5нм) и архитектите както софтуерните, така и хардуерните ще трябва да си размърдат мозъците.

Днес попаднах на тази разработка на ETH Zürich (една от малкото европейски институции които считам за надеждни кога се отнася до подобни разработки).

https://pulp-platform.org/

PULP Features:
efficient implementations of RISC-V cores. These include:
32 bit 4-stage core CV32E40P (formerly RI5CY)
64 bit 6-stage CVA6 (formerly Ariane)
32-bit 2-stage Ibex (formerly Zero-riscy)
complete systems based on:
single-core micro-controllers (PULPissimo, PULPino)
multi-core IoT Processors (OpenPULP)
multi-cluster heterogeneous accelerators (Hero)
open-source SolderPad license
a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable license
rich set of peripherals
I2C, SPI, HyperRAM, GPIO

А това са презентациите от наскорошния Open RTL + open EDA уоркшоп на CHIPS Alliance

https://chipsalliance.org/workshops-meetings/

Аз не успях да завърша това, дето го почнах защото си смених работата и начинанието си загуби смисъла, сега обаче на новата работа ще трябва да се боря с процесори на AD - BF706BCPZ-4, MYXATA да ме извинява но за мен тия процесори са малко овъркил за това, за което се ползват в момента, да не говорим за цената та ще се опитам да пробутам RISK-V на някоя евтина матрица при първа възможност.

е, аз с блекфините след 525 серията нищо не съм помирисвал.
Пък и незнам за какво ги ползваш в момента да мигаш светодиоди, или за активно шумоподавяне в купето на автомобил
а защо вместо да се гърчиш с РИСК на ФПГА не си ползваш някой Зинк? или друго такова?

защото цинковете струват майка си и баща си и понеже са с изфирясваща памет имат нужда от външна не-такава. Виж едно ice40 за £7 върши перфектна работа. Аз успях да компилирам един RISC-V проект за ice40 ама не съм го тествал и имам нужда от някакъв кит за да си поиграя, искам да си напиша собствен код, проблемът е че китовете на Латис вече не струват стотинки като преди.

Ако искаш дай адрес и ще ти пратя актуалния им Vision kit с EC5. Миналата година го ползвах за експерименти с невронни мрежи, но сега прахолясва в шкафа.