Názory k článku Navrhujeme a vyrábíme vlastní CPU: první pokusy s FPGA

FPGA má v sobě nějakou flashku s konfigurací?
Nebo se po každým resetu načítá konfigurace z SPI flashky, co je na desce?

Záleží od typu. Štandard je externá SPI flash. Ale niektoré ju majú integrovanú (Altera MAX10) pripadne sa to dá konfigurovať cez JTAG. (Niektoré FPGA cez to zvládajú aj iste spôsoby debugingu)

"Debuging" ne logický analyzátor. Tzn. zvládají to všechny, protože to je jen další logika, která se tam syntetizuje. Tzn. jediné omezení je, aby se tam vešla.

4. 3. 2025, 10:43 editováno autorem komentáře

Altera vie do vnútra vopchať logicky analyzátor. Ten ma podporu priamo v quartuse (Signal Tap Logic Analyzer). Ale môžeš si tam naďatlovat aj svoj vlastný.

JTAG ako taký ma podporu len na zistenie stavu jednotlivých pinov. (Boundary scan) Ale ta nieje povinna a nevie ho kazda vec z JTAG portom.

Debugging ale v nekterych FPGA existuje - tusim PolarFire a obecne Microsemi obvody maji dva dedikovane piny - na ktere se daji z beziciho signalu namapovat jakekoliv interni signaly. Tj. je to skutecne jako kdyz si nekdo prilozi "analogovou" sondu k slozitemu obvodu.

Klasicky digitalni LA ktery se syntetizuje se tam nemusi vejit, nebo muze vyzadovat rekompilaci designu, a pak se DUT chova jinak a snaha chytit bug je marnejsi.

To vieš spraviť na každom FPGA. akýkoľvek univerzálny IO pin vieš namapovat na akýkoľvek signál. Musíš ho mat len vyvedení do top-level entity

Moje FPGA má konfigurační flash na desce. Kromě toho se dá konfigurovat přímo přes JTAG z vývojového prostředí, což je při vývoji pohodlnější.

Pozrel som si zdrojak toho blikania ledkou. A ak by ste ste prestali rozmýšľať ako programátor tak by syntetizovaný obvod bol podstatne menší.

1.) Použiť internú PLL na vygenerovanie čo najnižšej frekvencie.
2.) RS obvod na generovanie signálu či má alebo nemá počítať
3.) Xbitový čítač z resetom.

PLL nieje nutné za podmienky že čítač bude viac-bytový.

Porovnajte si tu váš kód napríklad z týmto tu: https://www.fypsolutions.com/fpga/fpga-led-blinking-example/

A RTL vystúp tiež bude vyzerať príčetnejšie.

A ak by ste ste prestali rozmýšľať ako programátor

Co tím myslíte?

1.) Použiť internú PLL na vygenerovanie čo najnižšej frekvencie.

PLL jsou v FPGA právě 2. U složitějších obvodů by mi docela rychle došly.

2.) RS obvod na generovanie signálu či má alebo nemá počítať

Co myslíte tím "RS obvodem"? Zapojení pomocí LEs, což je v FPGA špatně? Nebo použití registru, což tam je, protože signál running12, resp. proměnná running34 se syntetizují jako registry?

3.) Xbitový čítač z resetom.

Je tam cyklický čítač bez resetu.

Porovnajte si tu váš kód napríklad z týmto tu

V mém kódu jsou dva procesy, protože jsem si chtěl vyzkoušet dva možné zápisy: if rising_edge(clk) nebo wait on clk until clk = '1'. Každý z nich ovládá dvě LED. Jestliže nechám jen jeden proces, jednu LED a vyhodím ovládací tlačítko, dostanu prakticky stejný kód, jako je ve Vámi odkazovaném příkladu.

1. PLL ma viac výstupov každé vie vygenerovať 2 dve vcelku nezávislé freq. A ak nechcete riešiť problémy z rôznymi "clock domains". Tak väčšinu ostatných freq budete generovať z freq ktorú získate z PLL cez deličku.

2. No a to je to že ste preskočil základy a znova vymýšľate koleso. RS flip-flop. Je základný prvok nepouživaný keď mate vystúp ktorý jedným vstupom zapínate druhým vypínate. Ďalšie sú D latch, JK flip-flop.

3. Sú dva a reset tam mate. Reset po dosiahnutí hodnoty. Na kurze by vás pravdepodobne tlačili do vygenerovania si signálu 1hz ako process a na základe neho už len blikaly z led.

Áno ten druhy process je lepši. Ono je dobre sa naučiť tie už prešlapané cestičky. Sú efektívnejšie čo sa týka LUT, sú známe rizikové stavy, Optimalizator ich pozná. A vďaka tomu dosiahnete lepších freq ktoré návrh zvládne. Ono pri zložitejších návrhoch sa bude stávať že niektoré signály sa budú musieť generovať na viacerých miestach naraz. (prepoje medzi lutmy nebudú volné) Takže si ušetríte čas a nervy ak si pozriete optimálne riešenia. Je fakt frustrujúce keď mate 50% vyťaženie LUT a aj tak sa to do FPGA nedá dostať.

K PLL: Já si tady vystačím se základními 50 MHz hodinami. PLL si nechávám na generování VGA pixel clock a případně na budoucí pokusy s taktováním CPU na vyšší frekvenci než 50 MHz.

Tak väčšinu ostatných freq budete generovať z freq ktorú získate z PLL cez deličku.

Jak podle Vás implementuju tu děličku kmitočtu? Nějakým zásadně lepším způsobem, než je ten můj čítač?

RS flip-flop. Je základný prvok

Ptám se potřetí: Jak podle Vás implementuju RS flip-flop v FPGA a jak se to bude lišit od mého použití registru nebo proměnné?

Sú dva a reset tam mate.

Čítače jsou dva, protože v tom jednom VHDL souboru jsou záměrně dvě samostatné různé implementace (skoro) identické logiky. Pod pojmem "reset" si představuju spíš (asynchronní) externí signál reset, nikoliv wrap-around hodnoty čítače.

2.) RS obvod na generovanie signálu či má alebo nemá počítať

Vzdy ho tam ma - konkretne tedy ve variante "asynchronni RS s prioritou resetu", coz reprezentuje nasledovny kod:

running12 <=
        '0' when stop = '0' else
        '1' when start = '0' else
        unaffected;

Ale ano, mam radeji synchronni struktury, takze by to mohlo byt pouzito za podminky kdy se hodiny meni - coz ale vyzaduje "always-running" hodiny. Touto asynch veci by totiz klidne nejake to PLL a clock buffery mohl uspat a fugnovalo by start-stop.. takze by dosahl nejake uspory pri stop stavu.

Zápis je na zlý. aj Quartus to píše. (Quartus || 13.0.1 aj Quartus 22.1)

Info (10041): Inferred latch for "running12" at blink.vhd(22)

Keby ludi čítali čo im syntetizátory a kompilátory píšu. SW by bol lepši.

Keby ludi čítali čo im syntetizátory a kompilátory píšu.

Já to čtu. Asi jsem to měl víc zdůraznit, ale je to jeden z prvních kousků kódu, co jsem ve VHDL napsal. Do článku jsem ho nezařadil kvůli tomu, že by byl dokonalý, ale protože jsem chtěl ukázat jednoduchý kód a k tomu ty dva obrázky.

Info neni ani warning ani error. Takovych Info veci pise normalni prekladac spousty.

Kdyz to tedy vymysli ze pouzije latch.. budiz. Ma to latch? Ma. Tak nevim kde hledate ted jako problem.

Latch NENI problem, kdyz o nem nastroj vi.

Az vam to neprojde timingem, tak pak si muzete zacit resit, ze proc asi.. ale o tom tato cast problemu neni.

Info neni ani warning ani error.

Je to asi tak na úrovni "warning: null pointer assignment" v C. Tedy na 99,99 % je to hrubá chyba!

Ma to latch? Ma. Tak nevim kde hledate ted jako problem.

Tohle jsou ale neznalosti naprostých základů návrhu na FPGA. "Inferred latch" znamená, že došlo k propojení výstupu a vstupu kombinačního obvodu, tedy že vznikl jakýsi nechtěný latch. A ne, že byl využit DFF, který je k dispozici v každé logické jednotce. Proč je to špatně se dočtete snad v každém textu o návrhu obvodů na FPGA.

Latch NENI problem, kdyz o nem nastroj vi.

JE to právě dost zákeřný problém, i když o něm nástroj ví. Je to bonus pro vás, že to nástroj odhalil.

"A ak by ste ste prestali rozmýšľať ako programátor"
Co tím myslíte?

Logiku popisu. Píšete to ako program nie ako HDL popis.

Pekným príkladom je process led12 ten je napísaný logikou sekvenčného programu. "wait on clk until clk = '1';" vyslovene kolie oči.

proces led34 je už lepši

tam je "if rising_edge(clk) then..."

Alebo running12 to je úloha pre klasicky RS obvod a je dobrým zvykom vstupy dostať do "clockdomain" (ako je running34). LUTov nieje nekonečno prečo znova generujete signál ktorý ste si už vygenerovali?

A ak by nešlo o test a kedže čitače nezastavujete tak by sa zozdielali. Ten druhy je o polovicu pomalší takže stačí predchádzajúci vydeliť dvomi.

Ak by ste obe časti urobili rovnako pravdepodobne by to optimizer spojil.

p.s. Quartus vám nenadával že v procese používate signály ktoré nie sú vymenované? (start, stop)

Pekným príkladom je process led12 ten je napísaný logikou sekvenčného programu. "wait on clk until clk = '1';" vyslovene kolie oči.
proces led34 je už lepši
tam je "if rising_edge(clk) then..."

Podle VHDL Handbooku jsou oba zápisy ekvivalentní...

Alebo running12 to je úloha pre klasicky RS obvod

Opakuji otázku: Co je klasický RS obvod v kontextu FPGA?

a je dobrým zvykom vstupy dostať do "clockdomain"

Uznávám, že synchronní registr pro running34 je lepší než latch pro running12, ale nepovažuji to za příklad "psaní programovou logikou".

Quartus vám nenadával že v procese používate signály ktoré nie sú vymenované? (start, stop)

Proč by měl nadávat? Já chci ty signály testovat v procesu, ale nechci proces asynchronně spouštět, když se kterýkoliv z nich změní. Chci proces spouštět pouze synchronně na vzestupné hraně hodin.

K tomu zbytku: v článku jsem to dostatečně nezdůraznil, ale je to opravdu jeden z prvních kousků VHDL kódu, který jsem napsal, když jsem začínal. A cílem bylo vyzkoušet si různé varianty zápisu, nikoliv vyrobit perfektní super optimalizovaný obvod.

Pekným príkladom je process led12 ten je napísaný logikou sekvenčného programu. "wait on clk until clk = '1';" vyslovene kolie oči.
proces led34 je už lepši
tam je "if rising_edge(clk) then..."

Podle VHDL Handbooku jsou oba zápisy ekvivalentní...

To ťažko. Jeden detekuje hranu druhy úroveň. A ak by boli ekvivalentne tak by ich quartus zobrazil v RTL rovnako.

==========
"Opakuji otázku: Co je klasický RS obvod v kontextu FPGA?" Neviem ako odpovedať na zle položenu otázku. Čo je to kontext FPGA?

=========
Quartus vám nenadával že v procese používate signály ktoré nie sú vymenované? (start, stop)

Proč by měl nadávat? Já chci ty signály testovat v procesu, ale nechci proces asynchronně spouštět, když se kterýkoliv z nich změní. Chci proces spouštět pouze synchronně na vzestupné hraně hodin.

Dalsia ukazka ze nechapete rozdiel medzi popisom a programovanim.

- Signali v definicii procesu, je zoznam signálov ktoré na nejak testujú v rámci definícii.

- To že sa to vola proces neznamená že je to nejaký proces ktorý sa niekde spusta. je to len obálka definície. nemá nič spoločne z procesom ktorý poznáte z programovania. Je to tam a spracováva vstupy stále či sa vám paci alebo nie. Ono to dosť nestatne popisujú tie časti na sensitivity list, declarative part a sequential statement.

sequential statement sa totiž nevykonáva sekvenčne ale paralelne.
sekvenčnost sa "simuluje" väzbov na hranu nejakého signálu (clk). Ale aj tam sa všetko čo je v danom IF-e stane naraz.

Ak dám do procesu dve IF podmienky na rovnaký signál tak keď sa podmienka splní tak sa obe časti stanu naraz. A vymenenie poradia na tom nič nezmení. Ak si takéto "maličkosti" neuvedomíte tak keď budete robiť ten CPU tak vás môžu prekvapiť. hlavne ak v jednom IF budete používať výsedok druhého.

p.s. Skúste namiesto VHDL handbooku skúsiť nejaký tutoriál od začiatku. Ono je to VHDL dosť mätúce pre programátora. A fakt že v tom istom jazyku sa opisuje HW ale aj testbooky moc nepomáha. (Sú totiž veci ktoré sa používajú v testbookoch ale nie sú syntetizovatelné)

To ťažko. Jeden detekuje hranu druhy úroveň.

if rising_edge(clk) then detekuje vzestupnou hranu. wait on clk until clk = '1' čeká, až se změní hodnota signálu (to je část on clk) a nová hodnota bude 1 ( until clk='1'), tedy efektivně také detekuje vzestupnou hranu.

"Opakuji otázku: Co je klasický RS obvod v kontextu FPGA?" Neviem ako odpovedať na zle položenu otázku. Čo je to kontext FPGA?

Já tuším, jak vypadá zapojení RS pomocí hradel nebo tranzistorů. Ale nevím, jak si představujete, že tohle vyrobím v FPGA, resp. nechápu, co se Vám nelíbí na na použití signálů/proměnných v mém VHDL kódu, které mají stejnou funkci.

Dalsia ukazka ze nechapete rozdiel medzi popisom a programovanim.

Já si myslím, že ten rozdíl chápu docela dobře.

Signali v definicii procesu, je zoznam signálov ktoré na nejak testujú v rámci definícii.

To je dost nepřesné.

To že sa to vola proces neznamená že je to nejaký proces ktorý sa niekde spusta.

Dovolím si tvrdit, že docela chápu principy, jak se kombinační a sekvenční procesy překládají do zapojení obvodu. Já si fakt nemyslím, že by tam někde běželo něco, co připomíná proces v operačním systému.

sequential statement sa totiž nevykonáva sekvenčne ale paralelne.

Není to ani čistě sekvenční, ani čistě paralelní, struktura je odvozená z data flow. A "mezi iteracemi procesu" se data (hodnoty signálů) ukládají do registrů.

Ak si takéto "maličkosti" neuvedomíte tak keď budete robiť ten CPU tak vás môžu prekvapiť.

To je sice pravda, ale vzhledem k tomu, že ten CPU existuje, tak asi něco tuším o tom, jak to funguje, že?

Opravdu, nechaj si poradit...

Zkuste si vzít tu blikoledku, resp. vemte si papír a ten obvod si nakreslete, hradla, registry, multiplexory, jako kdybyste to chtěl vysázet na plošňák. A pak to 1:1 přepište do VHDL.

Vy to fakt píšete, jako program (resp. behaviorálně), takhle se to nedělá.

To je sice pravda, ale vzhledem k tomu, že ten CPU existuje, tak asi něco tuším o tom, jak to funguje, že?
Vůbec. Ten syntetizátor dokáže schroustat lecos a ono to nějak funguje. Ale zabírá to mnohem víc, nezvládne to takové frekvence a občas to může dělat i blbiny.

zz_indigo: soudim, ze tomu rozumite, budu rad, kdyz nam pripadne napisete na root.cz nejaky (klidne maly) tutorial k VHDL (verilogu)

Nerozumiem tomu toľko aby som vypisoval články. A tiež chápem svoje limity. Moje SVN je plne hrobov ;-)

To najzložitejšie, čo som vo VHDL spravil sam od začiatku, je FastRAM pre A600. Z autokonfigom a za použitia DRAM.

Všetko zložitejšie využíva prácu radovo šikovnejších. (opencores.org) napr PMI-80 (https://youtu.be/LNxGf5JVSt0?feature=shared)

Ahoj, predne musim rict, ze se tu rozjizdi pekny serial (moc dik za nej), a jelikoz se v branzi pohybuji uz nejaky ten patek a nemohl jsem si nevsimnout komentaru vyse, tak jsem nevydrzel, a podival se na github a i na ten procesor 5016.
Vytky kolegu bych shrnul asi tak, ze se jim nelibi nektere spatne navyky a nebezpecne konstrukty, ktere se mohou v budoucnnosti pekne vymstit (ve smyslu, ze se u komplikovanejsich obvodu bude pripadna chyba pekne spatne hledat), nekdy zbytecne prodluzuji signalpath (tj. cas mezi Q->D DFFs, coz se projevi snizenym max. hodinovym kmitoctem vysledneho designu) a design pozira zbytecne mnoho resources.
Nicmene pokud jste se sam v uvedenem case dopracoval az sem, tak klobouk dolu, pokud mohu srovnavat se studenty a juniory. Budete-li s FPGA pokracovat (vrele doporucuji, je nas malo), pak by stalo za to poohlednout se po najake ucebnici VHDL + VHDL standard, a vstrebat nektere lety proverene "best practices" (Risc-V nekde na githubu nemusi byt dobry vzor.)
Ono napriklad ten prvni proces led12 je v podstate OK (wait on clk...) a je syntetizovatelny (jinak by to nechodilo, ze), ale jen diky tomu, jak je to napsane (tj. forma zapisu wait, jeden wait v procesu), protoze jinak obecne wait syntetizovatelny byt nemusi. Takto zapsane je to skutecne ekvivalentni "if rising_edge(clk)", coz je patrne z toho, ze cnt, state, led1 a led2 jsou vystupy DFF. Nicmene rozhodne to neni "best practice" a pri komplikovanejsim designu jsou vidle uz hodne blizko.
Par hintu:
1. Pokud to jde, strkejte vse dovnitr procesu uvozenych rising_edge (running12, running34). Vidite, co napachalo to running34 (zbytecna LUT na vystupu), nebo running12 (latch). Logika se vam pak zdrcne do LUT pred DFF (tj. signaly na leve strane = vystup DFF) a design se stane plne synchronni, coz je z mnoha duvodu zadana vlastnost.
2. Zkuste zapremyslet, jaka je presne perioda blikani (dabel je ukryt v detailu).
3. Pro casovani pomoci citacu pouzivejte citani smerem dolu s preloadem. On ten konstrukt citac nahoru-komparace-reset je obecne rozsireny nesvar i v lepsich ucebnicich, ale vidite, co to udela - krome uz tak pomaleho citace (carry pres moc moc bitu) je za nim jeste dalsi logika (komparator), a pak teprve feedback. To vede k tomu, ze jednak ma citac nizsi fmax, druhak to zere zbytecne moc zdroju. Pritom by na to deleni 50 MHz stacilo 27 DFF + pridruzene LUT v ramci makrocely. Jeden proces by pak vystacil s 29 DFF a cely design pri jeste stale citelnem zapisu (idealne FSM se stavy = led vystupy) s 32 DFF. Chapu, ze to zde vubec neni o optimalizaci, na druhou stranu VHDL je o praxi, tak proc si to neprocvicovat hned od zacatku.

Budete-li s FPGA pokracovat (vrele doporucuji, je nas malo) ...

Čiste pre zaujímavosť, zodpovedá tomu aj ohodnotenie?

Čiste pre zaujímavosť, zodpovedá tomu aj ohodnotenie?

Ne.

Ja si treba nestezuji, ale nedelam to jako full-time job, spise se povede raz za cas licencovat vetsi a ucelenejsi IP celek, takze klient tam plati za to, ze neco dostane "hned", a to muze byt pak zajimava vysokohorska prirazka. Zatimco v kodu nebo sw utilitach vam konkuruje mnoho i free alternativ, tak v pripade embedded, a HDL IP ten prostor neni tak na krev konkurencni a porad existuji nepokryta mista, kde se lze realizovat. Plus temer vse komercniho neni ve forme zdrojaku, na coz nekteri zakaznici slysi (to jenom stat je neschopnej si specifikovat pristup a licenci ke zdrojakum).

Pokud se budeme bavit o nabidce vyvoje za hodinovku, resp zamestnani, tak tam rozdil nebude.. zidle jako zidle, ruce jak ruce, jste jen kapkou v korporatnim mori.

Docela mě děsí, že někdo, kdo tvrdí, že inferred latch není problém, navrhuje FPGA za peníze. Pro koho jste dělal návrhy? Abych se těmto produktům mohl co největším obloukem vyhnout.
Elektrikáře, který by mi tvrdil, že nezapojený PE vodič není problém, že bez něho to taky bude fungovat, bych vyhnal okamžitě. Vaše tvrzení o latchích je na podobné úrovni.

Tak jeste jednou - jestli projde simulace, jestli vyhovuji constrainty, jestli produkt funguje - a nastroje s tim nemaji vubec problem, tak proc je inferred latch problem, na rozdil treba od inferred block ram? Evidentne tool sam vi, co si muze dovolit.

Jina vec by byla, kdyby design nebyl spravne naconstrainovan, coz je vas pripad PE vodice, ale nemit constrainty by v pripade FPGA vedlo na neco co ani fungovat nebude.

Ahoj, predne musim rict, ze se tu rozjizdi pekny serial

Dík za pochvalu.

Vytky kolegu bych shrnul asi tak, ze se jim nelibi nektere spatne navyky a nebezpecne konstrukty, ktere se mohou v budoucnnosti pekne vymstit

Bez obav, už se vymstily, když se mi někde při dalším vývoji nějaké podobné konstrukce podařilo udělat. Všichni se tu pořád točí na asi třetím .vhd souboru, co jsem kdy napsal, navíc jsem si na něm zkoušel, jak a proč se různé konstrukce chovají, ať už jsou dobře nebo špatně.

protoze jinak obecne wait syntetizovatelny byt nemusi

To vím, ostatně je to i napsané v dokumentaci Quartusu.

Pokud to jde, strkejte vse dovnitr procesu uvozenych rising_edge

To dělám, ten wait je nikde jinde v celém repozitáři nevyskytuje (kromě jednoho testbenche), navíc často používám ještě asynchronní reset, což se s if píše lépe.

Zkuste zapremyslet, jaka je presne perioda blikani (dabel je ukryt v detailu).

Hledání chyb v časování událostí +/- jeden takt hodin už jsem si užil dost.

Pro casovani pomoci citacu pouzivejte citani smerem dolu s preloadem.

Můžete sem hodit ukázku kódu, jak přesně to myslíte? Zkusil jsem toto a Quartus hlásí 49 LEs a 27 registrů. Tak nevím co a jak ušetřím čítáním dolů.

process (Clk) is
    variable cnt: unsigned(25 downto 0) := (others=>'0');
begin
    if rising_edge(Clk) then
        if cnt = 50_000_000 then
            cnt := (others=>'0');
            state <= not state;
        else
            cnt := cnt + 1;
        end if;
    end if;
end process;
LED(0) <= state;

Trik s citanim dolu spociva v tom, ze registr citace ma jeden DFF na nejvyssi pozici navic (tj. chcete delit napr. 200, potrebujete 8 DFF, pridate devaty). Pri citani dolu dojde k podteceni hodnoty v citaci (2 -> 1-> 0 -> 511 (1FFh)), a prave tento signal z pridaneho DFF je zaveden zpet do vsech LUT pridruzenych k DFF a zpusobi nastaveni nove hodnoty citace (preload). V pripade deleni 200 by to byla hodnota 198. Nastaveni nove hodnoty preklapi nejvyssi DFF zpet do nuly, takze ten generuje pouze 1T 'reload' puls.
Co ztracim:
1. Pozere mne to jeden DFF navic.
2. Citani dolu s podtecenim znamena, ze hodnoty v citaci nejsou "slusne vychovane", ale v drtive vetsine pripadu (delicky kmitoctu, casove zakladny generujici 1T pulsy dane repetice, zpozdovaci obvody,... odhaduji tak 90 % aplikaci), to neni na zavadu.
Co ziskam: fmax a resources (LUT)
Reseni s komparatorem znamena, ze povetsinou vsechny bity citace (vystupy DFF) musi byt zavedeny do kaskady LUTs (mame typ. 4- nebo 6vstupe), a teprve vysledek komb. obvodu je zaveden zpet do LUT pridruzenych k DFF nebo sync resetu vsech DFF, pokud jiz neni obsazen 'POR' resetem. Vysledkem potom je signalova smycka LUT-DFF-LUT, kde LUT za DFF malokdy byva soucasti makrocely (tu obsadi citac, nebot v ramci makrocely je vertikalne natazena cesta fast carry).
Reseni s downcounterem usetri LUT za DFF a muze byt vyrazne rychlejsi (reload signal se nevytahuje do right/left makrocel, ale do top/bottom makrocel, ktere maji rychle interni propojeni, protoze vyrobce s n-bitovymi operacemi pocita - podobne, jako je zde natazena fast carry logika).
Treba na Versalu to za priznivych okolnosti muze zvysit max fclk az o desitky procent.
Samozrejme existuje i symetricke reseni s upcounterem, kde preteceni je indikovano pulsem do log. 0 na vystupu pridaneho DFF.

Trik s citanim dolu spociva v tom, ze registr citace ma jeden DFF na nejvyssi pozici navic

Díky za vysvětlení, tenhle trik jsem neznal. Zkusil jsem si Váš popis přepsat do VHDL a dává mi to smysl.

takze takhle?


entity test is
port (
reset : in std_logic;
clk_i : in std_logic;
clk_o : out std_logic
);
end entity;
architecture arch of test is
signal count : STD_LOGIC_VECTOR (25 downto 0) := (25 => '1', others => '0');
begin
process (clk_i) -- delicka na ziskanie nizsej freq
begin
if reset = '0' then
count <= (25 => '1', others => '0');
elsif (rising_edge(clk_i)) then
count <= count - 1;
if count(25) = '1' then
clk_o <= NOT clk_o;
count <= "010111110101­11100001000000";
end if;
end if;
end process;
end architecture;


6. 3. 2025, 12:49 editováno autorem komentáře

Jj, treba tak.
Takhle by to bylo napr. s temi 4 x LED, kdy vystupy na LED jsou primo vystupy DFF a zmena urovne nastava ve stejnem okamziku na vsech LED.
Prvni proces je optimalizovan pro 4 x LUT4 + 4 x DFF (citac nepocitaje). Ma ale sve neduhy -> prechody mezi LED nesviti/LED blikaji nejsou uplne "slusne vychovane".
Druhy proces to resi ponekud lepe, ale uz potrebuje LUT6 (stop by mel byt zaveden do CLR DFFs), nicmene co se tyce resources, stale by se mel vejit do 4 x LUT6 + 4 x DFF.
Omlouvam se za blbe formatovani, ale nic lepsiho jsem v povolenych tags nenasel.

----------------------------------------------------------------------------------
-- LED1234
----------------------------------------------------------------------------------

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;
use IEEE.MATH_REAL.ALL;

entity led is
    generic (
        crystal_khz : integer := 50_000;
        period_ms :   integer :=  1_000
    );
    port (
        start : in std_logic;
        stop :  in std_logic;
        rst :   in std_logic;
        clk :   in std_logic;
        led1 :  out std_logic;
        led2 :  out std_logic;
        led3 :  out std_logic;
        led4 :  out std_logic
    );
end led;

architecture rtl of led is

-- Select variant
constant GEN_TYPE : natural := 1;

-- Counter
constant cnt_width : integer := integer(ceil(log2(real(2 * crystal_khz * period_ms)))) - 1;
signal cnt : std_logic_vector(cnt_width downto 0);

-- FSM with std_logic_vector as state memory
subtype  stdlogicvector2 is std_logic_vector(1 downto 0);
constant LED_OFF : stdlogicvector2 := "00";
constant LED1_ON : stdlogicvector2 := "01";
constant LED2_ON : stdlogicvector2 := "10";
signal state : stdlogicvector2 := LED_OFF;
--With enum:
--type state_type is (LED_OFF, LED1_ON, LED2_ON);
--signal state : state_type; etc.

-- LED3 & LED4 common trigger signal
signal trig34  : std_logic;
-- LEDs intern
signal led3int : std_logic;
signal led4int : std_logic;

-- FSM with std_logic_vector as state memory
subtype  stdlogicvector4 is std_logic_vector(3 downto 0);
constant LED00 : stdlogicvector4 := "0000";
constant LED13 : stdlogicvector4 := "0101";
constant LED14 : stdlogicvector4 := "1001";
constant LED23 : stdlogicvector4 := "0110";
constant LED24 : stdlogicvector4 := "1010";
signal state4 : stdlogicvector4 := LED00;

begin

TYPE0 : if GEN_TYPE = 0 generate

    led12 : process (clk) is
    begin
        if rising_edge(clk) then
            -- Downcounter as a timebase
            if (rst = '1') then
                -- We start at 0 so overflow at nexk clock cycle resets FSM
                cnt <= (others => '0');
            elsif (cnt(cnt'high) = '1') then
                cnt <= std_logic_vector(to_signed((crystal_khz * period_ms) - 2 , cnt'length));
            else
                cnt <= std_logic_vector(unsigned(cnt) - 1);
            end if;
            -- FSM for LED1 and LED2 - 2 x DFF
            if (stop = '1') then
                -- 'stop' as common reset
                state <= LED_OFF;
            else
                case state is
                    when LED_OFF =>
                        if (start = '1') then
                            state <= LED1_ON;
                        end if;
                    when LED1_ON =>
                        if (cnt(cnt'high) = '1') then
                            state <= LED2_ON;
                        end if;
                    when LED2_ON =>
                        if (cnt(cnt'high) = '1') then
                            state <= LED1_ON;
                        end if;
                    when others =>
                        state <= LED_OFF;
                end case;
            end if;
            -- LED3, LED4 - 2 x DFF
            if (state = LED_OFF) then
                led3int <= '0';
                led4int <= '0';
            elsif (trig34 = '1') then
                led3int <= not led3int;
                led4int <= led3int;
            end if;
        end if;
    end process;

    -- Trig pulse for LED3 and LED4
    trig34 <= state(1) and cnt(cnt'high);

    -- Outputs from DFFs
    led1 <= state(0);
    led2 <= state(1);
    led3 <= led3int;
    led4 <= led4int;

end generate TYPE0;

TYPE1 : if GEN_TYPE = 1 generate

    led1234 : process (clk) is
    begin
        if rising_edge(clk) then
            -- Downcounter as a timebase
            if (rst = '1') then
                -- We start at 0 so overflow at nexk clock cycle resets FSM
                cnt <= (others => '0');
            elsif (cnt(cnt'high) = '1') then
                cnt <= std_logic_vector(to_signed((crystal_khz * period_ms) - 2 , cnt'length));
            else
                cnt <= std_logic_vector(unsigned(cnt) - 1);
            end if;
            -- FSM for 4 x LED - 4 x DFF
            if (stop = '1') then
                -- 'stop' as common reset
                state4 <= LED00;
            else
                case state4 is
                    when LED00 =>
                        if (start = '1') then
                            state4 <= LED13;
                        end if;
                    when LED13 =>
                        if (cnt(cnt'high) = '1') then
                            state4 <= LED14;
                        end if;
                    when LED14 =>
                        if (cnt(cnt'high) = '1') then
                            state4 <= LED23;
                        end if;
                    when LED23 =>
                        if (cnt(cnt'high) = '1') then
                            state4 <= LED24;
                        end if;
                    when LED24 =>
                        if (cnt(cnt'high) = '1') then
                            state4 <= LED13;
                        end if;
                    when others =>
                        state4 <= LED00;
                end case;
            end if;
        end if;
    end process;

    -- Outputs from DFFs
    led1 <= state4(0);
    led2 <= state4(1);
    led3 <= state4(2);
    led4 <= state4(3);

end generate TYPE1;

end rtl;

Hmm je zajimave ze nikdo z kritiku opravdu konkretne neuvedl priklad jak se to teda pise dobre ani neposlal zadny konkretni link na spravny priklad.

blikani LED https://github.com/martin-beran/fpga/blob/mb50_v1/led_blink_vhdl/blink.vhd ma celkem 69 radku, to je opravdu takovy problem napsat tech par radku jak je to teda podle kritiku spravne, misto te spousty obecnych poucujicich ale nepomahajicich komentaru ktere urcite zabraly vic casu napsat.

Hmm je zajimave ze nikdo z kritiku opravdu konkretne neuvedl priklad jak se to teda pise dobre ani neposlal zadny konkretni link na spravny priklad. blikani LED https://github.com/martin-beran/fpga/blob/mb50_v1/led_blink_vhdl/blink.vhd ma celkem 69 radku

Mě hlavně udivuje, jak se tu všichni pořád točí na tom jednom souboru obsahujícím starý experiment a ignorují dalších skoro 9000 řádků VHDL v repozitáři.

tak to bych chapal ze se nikdo nebude poustet do 9000 radku, ale na trivialnim pripade s LED by to snad melo byt idealni ukazat jak je to dobre

Ja jsem teda taky hlavne programator a kdyz jsem videl vhdl a verilog tak mi prislo ze na vhdl je muj zivot uz prilis kratky. A asi bych delal stejne chyby protoze ten HW zaklad nemam. Takze bych opravdu ocenil kdyby nekdo byl schopen ten rozdil v pristupu na tomhle konkretnim prikladu s LED ukazat abych videl obe verze vedle sebe.

tak to bych chapal ze se nikdo nebude poustet do 9000 radku, ale na trivialnim pripade s LED by to snad melo byt idealni ukazat jak je to dobre

Hned ve druhém odstavci první části tohoto článku píšu: "Tento seriál nemá za cíl sloužit jako výukový materiál pro jazyk VHDL..." Celý seriál jsem pojal jako popis mojí cesty od nuly, kdy jsem jen tušil, že existují věci jako FPGA a VHDL, až k jednoduchému funkčnímu CPU podle vlastního návrhu a kolem něj postaveného počítače. Asi jsem měl víc zdůraznit, že ten první kousek VHDL nebyl myšlen jako ukázka správného optimálního kódu, ale jako demonstrace, jak vypadá zdrojový kód a co z toho syntetizér vygeneruje (ty dva obrázky zapojení).

Nemám nic proti tomu, naopak pouvažuji za přínosné, když někdo ukáže na konkrétní chyby v tomto kódu a navrhne lepší řešení, to vše nejlépe s ukázkou kódu a s vysvětlením, aby se jak autor, tak i ostatní čtenáři mohli poučit a aby ty chyby někdo další nezačal napodobovat. Timto děkuji "radioing" za velmi pěkné vysvětlení lepší implementace čítače.

Já se jen trochu ohrazuju proti tvrzením, založeným pouze na tomto jednom zdrojáku, že autor dělá všechno špatně, nechápe rozdíl mezi popisem obvodu a programováním, měl by si nejdřív přečíst nějaký tutoriál, má (špatně) zafixované, co je proces a state machine, atd. Určitě je spousta chyb a nedokonalostí i v těch dalších 9000 řádcích kódu, na druhou stranu ale ty obvody nějak fungují, včetně toho výsledného počítače, tak asi nemůže být úplně všechno úplně špatně.

Především musím poděkovat za hezký seriál na téma, které mě vždy zajímalo ale reálně jsem se k němu skoro nedostal.
FPGA jsem měl jen jeden semestr na VŠ a od té doby nic. Jen si tak matně vzpomínam že nám říkaly něco jako když prostředí hlásí latch tak je to špatně. Potom ještě něco jako že by hodiny neměly být generovány klasickou logikou, ale že by se mělo takovým signál hradlovat hodinový signál a že by se hodinový signál měl detekovat hranou, né úrovní. Možná že si to pamatuji špatně, nebo už to dnes neplatí...

Mám takový návrh na pokračování seriálu, občas zabloudím na projekt lidí co se zabývají FPGA a všiml jsem si že někteří používají framework Litex, což je python obal na VHDL (nebo spíš Verilog) a dělají s tím docela šílené věci jako SOC s RISC-V, DDR a na tom rozchodí Linux a další volovinky. Myslím že se s frameworkem dá dojít dál než jen s čistým VHDL. Asi bych to trochu připodobnil k čistému PHP versus Nette / Symfony.

Mám takový návrh na pokračování seriálu, občas zabloudím na projekt lidí co se zabývají FPGA a všiml jsem si že někteří používají framework Litex, což je python obal na VHDL (nebo spíš Verilog)

Podíval jsem se na web projektu a vypadá zajímavě. Já ale o tomto frameworku jinak nic nevím, což není úplně nejlepší stav pro psaní článků. Ale třeba se toho chopí někdo jiný...

dělají s tím docela šílené věci jako SOC s RISC-V, DDR

Je s tím asi dost práce a vyžaduje to nějaké znalosti, ale zase jako úplná šílenost mi to nepřipadá.

a na tom rozchodí Linux a další volovinky

Když už mají CPU, dostatek RAM, nějaké úložiště (například SD karty nebo SATA) a nějakou grafiku nebo aspoň sériový port pro konzoli, tak by Linux nemusel být velký problém.

Myslím že se s frameworkem dá dojít dál než jen s čistým VHDL.

Spíš bych řekl, že s frameworkem se dá dojít do cíle rychleji, když není potřeba všechno vyvíjet od nejnižší úrovně. Já jsem se naopak ve svém projektu počítače MB50 snažil všechno dělat bez použití existujících komponent, i když pro části hardwaru jako je VGA, PS/2, nebo RS232 by se existující implementace daly docela snadno najít.