Názory k článku Architektura mikroprocesorů OpenRISC
-
Pavel TišnovskýZlatý podporovatelPopis řídicích registrů periferií určitě nebude :-) "Jen" popis instrukčních sad, ta 32bitová je už popsaná (až na čtyři instrukce typu trap atd.). To, co má navíc na sobě konkrétní SoC je úplně jiné téma.
-
Petr M (neregistrovaný)
Tak koukám zrovna do DS. O jádru tam není nic, registr ani jeden. Jestli ty nemyslíš "STM32F4 Reference Manual", to ale není datasheet a týká se to periferek, ne jádra.
Pokud jde o jádro k STM32F4, zatím nejlepší zdroj, na který jsem narazil, je http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0553a/Cihgjeed.html -
uranix (neregistrovaný)
s touto architekturou nevím, ale s podobnou ano
https://www.root.cz/clanky/hi-five-unleashed-prvni-linuxovy-pocitac-s-procesorem-risc-v/ -
muf (neregistrovaný)
Bugy dokážu pochopit, navíc je sporné, zda věci jako Meltdown apod. jsou bugy nebo spíš vlastnost architektury(kolik těch dnešních chytráků by takové možné postranní kanály před desítkami let napadly...)
Horší jsou záměrně vestavěné redundantní záležitosti, kdy si nemůžete být jist, co vám v tom procesoru ještě kdesi na pozadí, běží. Fakt mě neteší, když vím, že tam jede dokonce celý Minix. Co dělají ty procesy, které obsluhuje? Nikdo neví...až na pár lidí, vázaných NDA... A můžete se jen dohadovat, jaké to má cíle.
To by se otevřený procesor opravdu hodil. Může být klidně dražší. -
Petr M (neregistrovaný)
Jedna věc je návrh ve VHDL, druhá věc je návrh masek pro výrobu, třetí věc je, jestli někdo použije tyhle, nebo jiný masky...
Spíš než zapojení bych kontroloval chování. Zapojení, rozhraní, traffic třeba na Ethernetu, pokud je na čipu ETH_MAC,... A pak ověřit zdrojáky systému a sám si to sestavit ověřeným kompilátorem s ověřeným linkerem a uchovávat jenom na SSD s auditovaným firmwarem. Btw, co uděláme s firmwarem ve WiFi modulu a periferkách?
-
atarist (neregistrovaný)
To můžeš a mělo by se to u kritických aplikací nějak takto dělat. Jenže tím neodhalíš situaci, kdy třeba Ethernetové rozhraní čeká na konkrétní rámec, který ale například dorazí až ve chvíli, kdy pro někoho začnete být zajímaví, tedy klidně za několik let po nasazení čipu na zakázkách.
Btw můžeme věřit čistému FPGAčku? pokud jo (no...), tak si tam můžeme syntetizovat klidně i ten ethernet.
-
Pavel TišnovskýZlatý podporovatel
No popravdě to v článku není, zapomněl jsem :/
Nepřesně řečeno - ten prefix znamená typ instrukční sady.
Instrukce začínající na "l." jsou celočíselné operace, řídicí instrukce (skoky), load & store, základní MAC + několik zbylých instrukcí.
Na prefix "lf." začínají instrukce matematického koprocesoru.
A konečně na "lv." SIMD instrukce (v dokumentaci se píše "vektorové", ale OpenRISC není skutečně vektorový procesor ve smyslu, v jakém byl vektorový například Cray).
Ono to vypadá pracně používat prefixy, ale zase na druhou stranu v čistém assembleru se bude psát hlavně nějaký bootstrap kód a dopředu vědět, která jednotka instrukci provede může být šikovné.
-
S OpenRISCem mám zkušenosti, psal jsme na něj bare metal firmware. A nebylo to úplně dobré, imo jsou lepší procesory. První problém, na který člověk narazí je to, že si při startu musí zkontrolovat, jestli má procák tu funkcionalitu, s kterou počítal při kompilaci firmwaru. Protože u OR se dá překonfigurovat skoro všechno, i počet registrů. Dál je u procáku (aspoň u té varianty, s kterou jsem pracoval) řadič přerušení, co má invertované masky a časovač (generuje tiky hodin, tj. interrupty časovače (od kterých je třeba na linuxu odvozená velikost slice)) na kterém se nedají nastavit rozumné frekvence.
Jestli si s tím někdo chcete hrát, kupte si vývojový kit pro dost velké fpga a nahrejte si ten procák do fpgačka. To by mělo na začátek stačit, imo. Pozor, že pro kompilaci se nepoužívá vanilla gcc - užijete si kompilaci kompilátoru, resp. crosscompileru + rozchozování runtime na vašem hw.
-
My měli speciální rad-hard hw, to nejde běžně koupit, takže co jsem používal já je irelevantní. Podle mě se do icoBoardu (lattice fpga s 8k LUTs?) nevejde.
Na Vašem místě bych tu úvahu o tom, kterou desku použijete začal spíš u něčeho takového: https://store.digilentinc.com/arty-a7-artix-7-fpga-development-board-for-makers-and-hobbyists/ (XC7A100 je podle mě spodní hranice kam se or vejde, ale radši si zkuste všechno, co chcete v tom procesoru mít přeložit a kouknout, jestli se to tam vejde doopravdy, než budete něco kupovat).
-
Pavel TišnovskýZlatý podporovatel
Dobrý den. Díky za postřehy z praxe. Používali jste přímo OpenRISC 1200 nebo nějakou jinou variantu? (pokud nevyhovuje OpenRISC, je tady RISC-V, ale to určitě víte, takže jen pro úplnost).
ČLÁNKY DO MAILU