Názory k článku Navrhujeme a vyrábíme vlastní CPU: architektura instrukční sady
-
16 registrů je užitečných, ale není zbytečné použít 3 z nich na velmi speciální operace? Nebylo by lepší PC, FLAGS a IA přesunout spíš do kategorie CSR? PC je tedy trochu na hraně, bo procesory pak mají speciální instrukce na load-pc-relative, takže chápu trochu redukci instrukcí, ale ty FLAGS a IA mi smysl nedávají.
V každém případě jednoduchý a docela efektivní návrh.
-
Nebylo by lepší PC, FLAGS a IA přesunout spíš do kategorie CSR?
CSR umí jen operace přečtení nebo uložení hodnoty. V dalších pokračováních tohoto seriálu bude vidět, že pro PC a FLAGS se hodí mít i další operace: exchange (výměna hodnot dvou registrů), load/store (čtení/zápis hodnot v paměti), aritmetické a bitové operace.
S IA máte pravdu. Až poměrně pozdě jsem přišel na to, jak přesně se bude tento registr používat, a už se mi nechtělo měnit návrh.
-
Ja tam popravde cekal i "constant 0" a "constant 1" registry.
Pokud bych navrhoval v dnesni dobe procesor, tak bych sel taky touto cestou - ze mit sadu registru, ze kterych nektere maji specialnim chovani, nebo tvori aliasy na ruzne HW ficury (napr. v pripade velikeho cpu meshe bych na 4 registry aliasoval fifa na svetove strany).
Ona pak ta ortogonalita instrukci sady a kodovani instrukci, potazmo nasledna tvorba kompilatoru a optimalizaci odvdeci nasobne vice, a vykon je pak lepsi nez v pripade MMIO, hlavne u riscu kde nejsou tak bohate adresni rezimy jako u cisc.
Takze klasicky pripad: neni vhodne setrit na nespravnem miste.
Optimalizace ve smeru ktery navrhujete se hodi az pri opravdu pidi mikrokontrolerech, kde chcete usetrit kazdy LE a celkove zahustit a koncentrovat design.. rekneme ze pro 8-bit mcu ktere je mensi nez autoruv procesor by to smysl davalo.
-
Ja tam popravde cekal i "constant 0" a "constant 1" registry.
Nad registrem "constant 0" jsem přemýšlel, ale při návrhu ISA mi nebylo moc jasné, k čemu by se používal, a následně při programování jsem neměl pocit, že bych ho potřeboval. Registr "constant 1" mi připadá možná ještě méně užitečný. Chápu, že se hodí registr 0 např. v RISC-V, kde má každá instrukce dva zdrojové a jeden cílový registr a navíc ještě konstantu. Ale u mých dvouregistrových instrukcí mi to moc smysl nedává.
-
Já zápasím s nutkavostí koupit si to FPGA, jelikož vím, že skončí někde v závěji bordelu a už na to nesáhnu a potřebou nzastudovat si konečně, jak se ta FPGA vlastně "programují", ačkoli mi to bude k prdu a do dvou let to zapomenu. :D
//Přeci jenom nemyslím a neplánuji, že bych se někdy k něčemu, kde by mi to bylo platné dostal. Ale je to fakt velmi zajímavé. :D -
Ve skutecnosti bude 99% vasi prace s FPGA psani kodu a simulace.
1% pak natlaceni do hw a podivani se ze to fakt blika :DPokud nedelate HW interfacing, tak se muzete celkem vyradit i v simulacich - coz vam zas dovoli pouzit treba OSS nastroje - a az jednou prijde sance a potreba nejake skutecne prace - uz budete vedet jak na to :)
-
No ono to ide do penazi. Bud je to lacne a male a budete bojovat z tym ze sa vam to nevmesti (lacne FPGA kity) alebo to bude drahe. U tych lacnych je este problem z tym ze k tomu skoro nic nepripojite lebo uz nie su volne piny. Alebo tam nic okrem konfiguracnej Flash nic nie je. (mam 8 roznych z Max10, cyclone II, Cyclone III, Cyclone IV)
-
No ono to ide do penazi.
Až tak moc ne. 500 hodin zábavy za 3000 Kč.
budete bojovat z tym ze sa vam to nevmesti
Toho jsem se na začátku bál, ale nakonec se celý můj počítač do FPGA vešel. Opravdu velký obvod se nevejde, ale pořád to stačí na spoustu zajímavých zapojení.
U tych lacnych je este problem z tym ze k tomu skoro nic nepripojite
Na tom mém kitu jsou 4 tlačítka, 4 LED, čtyřmístný sedmisegmentový displej, RS232, VGA, PS/2, reproduktor, IR přijímač, 64 Mbit SDRAM a ještě pár dalších periferií. Navíc jsou piny FPGA vyvedené na konektory a aspoň některé půjdou použít i k připojení jiných zařízení, než jsou na desce.
19. 3. 2025, 22:33 editováno autorem komentáře
-
Tak vela zabavy si clovek uzije aj z Altera MAX II vo verzii z 240LE a 8kbit Flash. Len ta zabava je obmedzena.
"...Toho jsem se na začátku bál, ale nakonec se celý můj počítač do FPGA vešel. .."
Skor ci neskor na limit clovek narazi. Ale je pravda ze do 5000/6000LUT sa toho da napchat vela. Jednoducha hra, miner bitcoinov ci niektore stare 8-bity. Mne ako prva dosla RAM. Az potom LUT-y.
"...Navíc jsou piny FPGA vyvedené na konektory a aspoň některé půjdou použít i k připojení jiných zařízení, než jsou na desce..."
A kolko z nich nie je zdielanych? Ten cip ma 91 IO pinou a len ta SDRAM zozerie 38. (https://github.com/inaciose/RZ-easyFPGA-A2.2/blob/main/rz_easyfpga_2_2.qsf) Volnych pinov ktore bude bezpecne pouzit bude tak 5. (mam dva kity z tymto svabom) Tie ostatne potom vyzaduju mysliet na to ze tam su pull-upy alebo ze treba nieco odpojit.
Blbe ze Cinanci do toho davaju len SDRAM a ziadne SRAM. Ich vyuzitie zbytocne zerie luty. (Treba na to stavovy automat). Taky Terasic do tych zaciatocnickych pcha oba typy. Ale on si to moze dovolit pouziva vacsie puzdra aj FPGA-cka. A preto aj jeho rozsirujuce porty nie su z nikym a nicim zdielane.
Alternativa je mat okrem zaciatocnickeho kutu este aj "core board" kde okrem par lediek a jedneho/dvoch capacitor nic nie je. A vsetky ostatne piny su volne pouzitelne.
-
Celkově se mi přístup k návrhu ISA pro malý jedno-cyklový CPU líbí. PC v GP registru dává smysl pro jednoduché PC relativní adresování a třeba na 32-bit ARMu i ke kombinaci ovnovení registrů a návratu z podprogramů jednou LDM instrukcí. Ale pro jakýkoliv návrh, který má vést k výkonnějšímu procesoru je speciální chování běžných ALU instrukcí po volbě cíle do PC zabiják. Predikce skoků a další se stává velkým problémem. Je to také vidět na odchodu ARMu u AArch64 k samostatnému PC registru. Přitom i LDM/STM se stalo přítěží a tak dovolují jen LDP/STP aby byly omezené počty závislostí k jedné instrukci na rozumný počet. Jinak se stává uložení dataflow závislostí k jedné pozici v reorder bufferu nebo rezervační stanici se závislou instrukcí noční můrou.
Nenašel jsem instrukci pro plnění registru konstantou, určitě nechceme 16 bitů, ale osm bitů posunutých o osm doleva jen se specifikací jednoho cílového registru by se mohlo hodit. Pak druhá instrukce pro přičtení osmi znaménkově rozšířených bitů, kde by třeba zdroj a cíl byl shodný registr. Předpokládám, že autor využije k témuž LDIS dstr, PC, ale opět pro malý design bez pipeline je to použitelné, pro jen nepatrně větší s pipeline ne. Přitom pipeline třeba i jen se třemi stupni extrémně pomůže.
Pro sběrnice na FPGA se mi zdá, že omezit šířku na 8 bitů pro 16-bit CPU jako komplikace a zvětšení návrhu. Pokud chci na 16-bit CPU 8-bit/byte granularitu adresace, tak je nejvýhodnější paměť připojit 16-bitově, nejnižší bit pro čtení nezapojit, požadovat 16-hodnoty zarovnané na sudé adresy a pro čtení 8-bit přidat multiplexor řízený A0. Pro zápis po byte pak hodnotu zopakovat na D8 až 15 a podle A0 povolovat byte-enable signály. Pokud se mají podporovat nezarovnané 16-bit přístupy, tak to situaci celkem komplikuje. Je nutné přidat FSM a některé přístupy budou trvat dva cykly.
Pokud je však datová sběrnice opravdu jen 8-bivá, tak každé čtení instrukce a ST a LD na data začne vyžadovat sekvenční přístup, dvoustavovou FSM, a tím se návrh komplikuje.
jednodušší je pak Harward uspořádání pamětí. Ale pro obecnou programovatelnost a nahrávání kódu chcete spíš von Neumanna. Takže u malého výukového návrhu bez cache bych sáhl k řešení, kdy datový přístup k paměti vždy pozastaví fetch...
Ale obecně oceňuji návrh podle vlastní invence a odvahu se poté s důsledky poprat a ještě více sepsat dobré a třeba i špatné zkušenosti pro druhé. Kdybych měl čas, zkusím jen pro zajímavost návrhu poslat do iCE40 na ice-v Wireless... Myslím, že by se tam měl vejít... Jejich RISC-V ve Verilogu se tam vejde, RVapo od pana Gruncla již spíš ne. Single cycle s tím že cycle se roztáhne na více kvůli společné sběrnici na data a idata a dalším problémům, se tam podařilo pustit. Ale je to jen obskurita na test. Na 5 stage pipeline, nezarovnané přístupy a násobní potřebuje již výrazně větší FPGA.
-
Ale pro jakýkoliv návrh, který má vést k výkonnějšímu procesoru je speciální chování běžných ALU instrukcí po volbě cíle do PC zabiják.
Nedávno jsem na toto téma někde (už si nepamatuju odkaz) četl článek, který to pěkně vysvětloval. V hrubých obrysech důvody chápu, detaily jsem zatím nestudoval, ale mým cílem bylo zbytečně si nekomplikovat návrh a implementaci procesoru a taky assembleru. Celý tento projekt byla pro mě nová neprobádaná oblast a na začátku jsem neměl moc odhad náročnosti a toho, jestli vůbec dojdu do cíle. Optimalizace, pipelining, apod. jsem vůbec neřešil. Možná někdy příště...
Nenašel jsem instrukci pro plnění registru konstantou, ... Předpokládám, že autor využije k témuž LDIS dstr, PC
Odpověděl jste si sám. Používám LDIS, v assembleru k tomu mám i makro
set REG, EXPR, které dovolí na jednom řádku zapsat i konstantu (a vynechat jméno registru PC). Zároveň LDIS používám jako POP při práci se zásobníkem, k tomu mám duální instrukci DDSTO fungující jako PUSH. Motivace byla opět zredukovat instrukční sadu a tím i složitost řadiče CPU a assembleru.Pro sběrnice na FPGA se mi zdá, že omezit šířku na 8 bitů pro 16-bit CPU jako komplikace a zvětšení návrhu.
Chtěl jsem si vyzkoušet, jaké důsledky bude mít, když nebudu omezovat nezarovnané přístupy do paměti a použiju interně 16bitový procesor s externí 8bitovou sběrnicí. Souhlasím, že Vaše navrhované řešení s 16bitovou sběrnicí je lepší. V porovnání s mou implementací jsou docela dobře vidět důvody, proč procesory vyžadují zarovnané adresy pro vícebajtové operace s pamětí, nebo proč jsou nezarovnané přístupy pomalejší.
Uznávám, že některé věci dělám neoptimálně nebo "divně". Důvody jsou buď snaha o jednoduchost, nebo cílené pokusy udělat některé věci jinak, prakticky si vyzkoušet následky a pochopit některé vlastnosti běžně používaných procesorů, jejichž smysl není jasný, dokud se je člověk nepokusí implementovat nebo aspoň pochopit, jak implementace v hardwaru funguje. Také jsem dost věcí vymýšlel sám s cílem co nejrychleji mít nějak fungující výsledek, místo abych se zdržoval hledáním známých/správných řešení v literatuře (což by byl lepší, ale časově náročnější postup).
-
Na zaciatok by som skor zacal z "one-instruction set computer" Je to jednoduchsie na implementaciu a vcelku zabava v tom programovat. (nieco na urovni BrainFuck-u) Pripadne nieco ako MCPU (https://opencores.org/projects/mcpu)
Vcelku zaujimave su aj FORTH procesory napriklad J1 (https://github.com/jamesbowman/j1) Ten je ale vo Verilogu. Som to prerabal do VHDL ale nepamatam si ci je to funkcne (https://svn.mavipet.sk/svn/fpga_tests/J1_vhdl/)
-
Na zaciatok by som skor zacal z "one-instruction set computer"
Já jsem chtěl něco, co bude aspoň zhruba na úrovni 8bitových počítačů z 80. let (vzpomínám na svůj Didaktik Gama). Aby se do toho dal nahrát netriviální program, umělo to číst vstup z klávesnice a kreslit na obrazovku. A aby se to dalo rozumně programovat v assembleru.
Vcelku zaujimave su aj FORTH procesory
Ano, ale chtěl jsem "klasický procesor", který počítá s hodnotami v registrech.
-
netrivialny program sa da nahrat skoro do cohokolvek.
To je pravda, ale chtěl jsem něco, na co půjde dobře vyrobit assembler a pak v tom assembleru programovat. Mým cílem bylo překlenout mezeru v (mém) chápání mezi hradly a procesory jako např. Z80 a x86.
Kuk My4TH
To je určitě zajímavý projekt, ale nechtěl jsem vyrábět zásobníkový procesor.
-
Skvela prace. Dival jsem se na tvuj git, na makra, mas ty instrukce navrzene pekne. Libi se mi jak se da dostat word z nasledujici adresy programu do registru stejnou instrukci, ktera se skvele hodi i na pop ze zasobniku. Take je dobre, ze muzes mit vic zasobniku. Kterykoliv registr muze byt dalsi SP. Kdysi jsem si pohraval s myslenkou navrhnout vlastni CPU, tvuj projekt je mi tedy dost blizky. Kdybych mel cas si hrat, rad bych si ten tvuj projekt vyzkousel. No, snad v duchodu :-). Diky za tuto serii clanku
