Vlákno názorů k článku Navrhujeme a vyrábíme vlastní CPU: první pokusy s FPGA od zz_indigo - Pozrel som si zdrojak toho blikania ledkou. A...

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.