Link alla notizia: https://www.hwupgrade.it/news/storage/economico-potente-e-capiente-l-architettura-open-source-risc-v-e-il-segreto-di-questo-ssd-samsung_151917.html

Samsung ha presentato il BM9K1, SSD PCIe 5.0 con memoria QLC e controller RISC-V proprietario. L'unità è in grado di raggiungere gli 11,4 GB/s in lettura, ma restano ancora ignoti i dati su scrittura e resistenza

Click sul link per visualizzare la notizia.

C'è un errore ,sono 512kb ,1 Mb e 2 mb visti i tempi......

Link alla notizia: https://www.hwupgrade.it/news/storage/economico-potente-e-capiente-l-architettura-open-source-risc-v-e-il-segreto-di-questo-ssd-samsung_151917.html
Stando a quanto spiegato dal produttore sudcoreano, RISC-V consente una personalizzazione più fine del firmware.
La cosa è più complessa da spiegare e molto più vantaggiosa di una semplice "customizzazione del firmware".

ARM "vende" le IP di core specifici e non li si può modificare a meno di avere una licenza speciale (e molto costosa) inoltre non si può modificare il set d'istruzioni, al massimo usare l'interfaccia per coprocessori (e non su tutte le architetture ARM).

Invece RISC-V richiede "solo" che vengano rispettate le specifiche del set d'istruzioni standardizzato (l'implementazione del core la puoi fare tu, comprarla da terzi ecc., basta mantenere la compatibilità del set d'istruzioni senza violare le codifiche standardizzate).
Inoltre una parte degli opcode è esplicitamente riservata a "istruzioni custom del produttore" che possono accedere direttamente ai set di registri standard, i registri speciali RISC-V che equivalgono alla "CPUID" degli x86 permettono di idnetificare esattamente quali sono le istruzioni custom (se ci sono), ma si può decidere di ignorarle e far girare codice "generico" senza che vi siano rischi di compatibilità (anche in futuro), perchè gli opcode "custom" non verranno mai utilizzati da future estensioni.

Questo permette di fare dei controller perfettamente compatibili con tutti i core RISC-V che supportano lo stesso set di estensioni e che al tempo stesso hanno istruzioni custom (e relative unità di esecuzione "speciali") integrate direttamente nel core che accelerano la codifica/decodifica dei dati su QLC, l'error detection e correction, ecc. ecc.
Adirittura si possono usare registri custom di configurazione per cambiare la semnatica stessa degli opcode e dei registri standard (a patto che sia attivabile e disattivabile senza conseguenze sulla compatibilità con le estensioni esistenti e quelle future).

I tipi di PULP Platform (ETH Zurich & Università di Bologna) hanno sperimentato parecchio in tal senso, ad esempio con lo Snitch con le sue estensioni per semantica di streaming e ripetizione di sequenze di istruzioni FP senza passare per l'instruction cache (tutta roba che serve per avere core "spartani" ma che muovono dati da/verso la memoria ed eseguoni elaborazioni FP ad altissima efficienza energetica.

limiti di TBW? questo dovrebbero dire...