Vlákno názorů k článku Navrhujeme a vyrábíme vlastní CPU: první pokusy s FPGA od zz_indigo - "A ak by ste ste prestali rozmýšľať ako...

Když vidím tu diskusi, nemůžu si nevzpomenout na stavebnici Logitronik 01, kde na blikání stačila dvě hradla (invertory), dva kondenzátory a dva odpory. :-) (Čtyři odpory, když budu počítat i ty dva na omezení proudu procházejícího LEDkami.)

(A kutilové ze staré školy jistě namítnou, že místo dvou hradel stačí dva tranzistory.)

Samozřejmě, tady jde o demonstraci fungování a možností technologie, ne o nejefektivnější řešení.

Samozřejmě, tady jde o demonstraci fungování a možností technologie, ne o nejefektivnější řešení.
Nikoli, tohle je prostě blbě. Logika zápisu je blbě. Bez jakékoli urážky, já napsal větší čuňárny, ale dřív, nebo později, člověk musí pochopit, že takhle ne. A lépe dřív, než později.

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

A jak se to dělá? Podle Vás se behaviorální zápis vůbec nepoužívá?

Nikoli, tohle je prostě blbě. Logika zápisu je blbě.

Můžete napsat konkrétně, v čem je to "prostě blbě", a ukázat správné řešení?

RTL.
Vy nepopisujete algoritmus, ale střeva toho čipu. Ne to tam behaviorálně napsat a ono z toho "něco" vyleze. Jako některý syntetizátory z toho opravdu něco vymyslí, některé trvají na RTL (ono je to možná lepší). Viděl jsem i přístup, že někdo vyloženě modeloval LUTky, což teda nemusím, už jen proto, že různé FPGA mají různě vělké LUTky.
V behaviorálním popisu snadno napíšete něco, co pak uděla latche, má dlouhou kritickou cestu atp. Pak Vám to dá 10Mhz s větrem v zádech a ani nemusí být jasné proč.

RTL

Nechcete sem napsat ukázku, třeba to LED blikátko s tlačítky start/stop?

Vy nepopisujete algoritmus, ale střeva toho čipu.

Bude ten Váš přístup škálovatelný na složité obvody typu CPU?

Ne to tam behaviorálně napsat a ono z toho "něco" vyleze.

Opakuju otázku: Podle Vás se behaviorální zápis vůbec nepoužívá? (Nebo nemá používat?)

Bude ten Váš přístup škálovatelný na složité obvody typu CPU?
Samozřemě, ale tak to nebudete házet do jednoho souboru, ne? Je to stavebnice.

Podle Vás se behaviorální zápis vůbec nepoužívá? (Nebo nemá používat?)
Behaviorální popis se na jakoukoli rozumnou věc nepoužívá.

Mrkněme třeba sem:

cnt := cnt + 1;
if cnt = 2 * crystal_khz * period_ms then
cnt := 0;
state := not state;
end if;


Máte představu, co to udělá? To by mělo hodit sčítačku, za ní komparátor a do registru to dá hodnotu dle výsledku komparátoru (protože ten if na náběžnou hranu). No jo, ale ten komparátor přeci může být vedle sčítačky a kritická cesta bude kratší...

Behaviorální popis se na jakoukoli rozumnou věc nepoužívá.

Zajímavé, když jsem se tak rozhlížel např. po nějakých implementacích RISC-V, tak je to samý process a state machine... Trochu se bojím, že s tou reálnou škálovatelností definice obvodu striktně bez behaviorálního zápisu to bude něco jako assembler místo C - ve speciálních případech to bude potřeba, ale bude to mnohem pracnější, většinou to bude jedno, a často syntetizér/kom­pilátor vyprodukuje lepší výsledek než člověk.

Mrkněme třeba sem

Docela by pomohlo, kdybyste ukázal svou verzi tohoto kódu místo slovního popisu.

Máte představu, co to udělá?

Mám. Od "totálně špatně" jsme se dostali k chybějící mikrooptimalizaci, kdy jedno přiřazení do proměnné, které je před příkazem if způsobí, že se jedna cesta v obvodu protáhne o pár hradel v situaci, kdy na tom nejspíš prakticky vůbec nezáleží. Celé se to dá opravit přesunem toho přiřazení do větve else. Vůbec mi není jasné, proč by to v jiné formě zápisu mělo být celé přehlednější a automaticky vyloučit vytvoření obdobné neefektivity.

je to samý process a state machine...
Tak to pozor. To, že je tam process neznamená, že je to (špatný) behaviorální popis. Na FSM taky není nic špatně (a ano taky se píše processem). Špatně je to, že dáte do procesu například to:

cnt := cnt + 1;
if cnt = ...

A čekáte, že to ten syntetizátor nějak vymyslí, ale on to nemá jak vymyslet.
I na cyklech nemusí být nic špatně (ty tam nemáte, ale píšu příkald), pokud chcete udělat něco např. pro všechny piny. Ale je to špatně, pokud v tom cyklu budete upravovat stejnou proměnnou (nevím proč mě napadá bubble sort).
Tohle je pointa toho "Myslet jako programátor". Jak jsem psal, vy popisujete fyzickou věc, popisujete, jak to tam má být uspořádané a ne, co to má dělat.

Docela by pomohlo, kdybyste ukázal svou verzi tohoto kódu místo slovního popisu.
No asi jo, ale zaprvé si mi s tím nechce psát (už takhle jsem chtěl napsat jen jeden comment) a za druhé je toho plný Internet.

Od "totálně špatně" jsme se dostali k chybějící mikrooptimalizaci,
Tohle není mikrooptimalizace, to je zcela špatný přístup. Něco jako goto, nebo neuvolňování paměti (ono to nepojede dlouho, že?). A s tím přesunem máte pravdu, jenom je to důležitější, než si myslíte.

Jako takhle. Já jsem Vám to nechtěl sepsout. Sám jsem si tímhle obdobím prošel taky. Jenže Vy si to vehementně bráníte. Psal jsem, ať si necháte poradit, ušetříte si čas, protože, pokud u toho HW zůstanete, tak dřív, nebo později se k tomu propracujete (A to třeba i nedobrovolně).

Jinak ještě pozor na testbenche, tam tyhle věci nevadí, tak si je neberte za vzor pro HW.

> Tohle není mikrooptimalizace, to je zcela špatný přístup. Něco jako goto (...)

Čéče, o křemíku vím kulový, ale jestli tě mám soudit podle toho, co si myslíš o goto, tak z toho srovnání nevyjdeš dobře...

Goto je legitimní programátorský nástroj, který - klasicky v Céčku - umožňuje při chybě přeskočit nerelevantní operace a skočit do místa, kde program může začít uvolňovat alokované zdroje. V assembleru nebo strojáku pak už vůbec na výběr nemáš... Autoři Luy (např.) to taky zvorali?

Existuje niečo, čo sa volá štrukturované programovanie a bolo to vymyslené preto, aby boli programy prehľadnejšie, pretože držať kontext pri ich čítaní a mať prehľad o tom, čo sa v nich deje, sa bez toho ukázalo pri väčších programoch komplikované ak nie priam nemožné. A bolo to práve kvôli tomu, že tok inštrukcií bol riadený príkazom goto.

Áno, goto je stále možné použiť, otázka je, čo to prináša a čím sa za to platí.

Vzhľadom na to, že sa goto všeobecne neodporúča, sa dá predpokladať, že je to kvôli tomu, že cena za použitie je vyššia ako prinosy. Už celé desaťročia.

A ja osobne som si skoro istý, že ak píšete programy v C, tak štrukturované programovanie používate v drvivej väčšine prípadov a ak tam máte nejaké goto, tak je to v porovnaní so štrukturovaným programovaním v mizivom počte prípadov.

Takže goto používate ako mikrooptimalizáciu. Vášho vývojového procesu.

Obávam sa že sa zbytočne snažíme. Autor ma zafixované čo je to process a statemachine z programovania a cez to tanky nejdu.

Autor ma zafixované čo je to process a statemachine z programovania a cez to tanky nejdu.

Zkuste nám popsat, co podle Vás má autor zafixované jako proces a statemachine a jak to je správně. Rád se poučím.

Vase slova:

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.

========
Ono by bolo lepšie skúsiť pochopiť čo vám ľudia pysu nie sa snažiť za každú cenu obhájiť svoj názor.

modelovanie hardware a programovanie maju uplne rovnaku logiku a do toho pouzivaju podobny format. To neksutocne metie. Ak to nemienite akceptovat OK. odrazi sa to na kvalite clankou a aj vysledneho HW

Ono by bolo lepšie skúsiť pochopiť

Zkouším to, ale pomohlo by, kdybyste konečně seozumitelně napsal, jak to s těmi procesy podle Vás je. A nepodsouvejte mi prosím něco, co jsem netvrdil.

A čekáte, že to ten syntetizátor nějak vymyslí, ale on to nemá jak vymyslet.

Čekám, že syntetizuje to, co je tam napsané, ať už je to dobře/špatně nebo optimální/neop­timální.

zaprvé si mi s tím nechce psát

Možná by těch 5 až 10 řádků kódu s komentáři řeklo víc, než to dlouhé nekonkrétní povídání.

Tohle není mikrooptimalizace, to je zcela špatný přístup. Něco jako goto, nebo neuvolňování paměti

Je to malá změna, která nijak neovlivní očekávané chování obvodu navenek. Ušetří zdroje, co v tomto případě stejně nijak nevyužijí. To je pro mě zbytečná mikrooptimalizace. Až to bude ve velkém obvodu v mnoha kopiích nebo na opravdu kritické cestě, bude to něco jiného.

Příkaz goto je standardní způsob, jak v C nebo C++ vyskočit z několika úrovní zanořených cyklů, nebo jak v C po chybě přeskočit na "úklidový" kód pro uvolnění zdrojů před návratem z funkce.

vo VHDL sa škáluje takto: (cwidth a owidth "premenne")

===============
-- Numeric controled oscilator

library ieee;
use ieee.std_logic_1164­.all;
use IEEE.STD_LOGIC_A­RITH.all;
use IEEE.STD_LOGIC_UN­SIGNED.all;

entity NCO is
generic (
cwidth : integer := 31;
owidth : integer :=11
);
port
(
clk : in std_logic;
freq : in std_logic_vector (cwidth downto 0);
phase : in std_logic_vector (owidth downto 0);
output : out std_logic_vector (owidth downto 0)
);

end entity;

architecture rtl of NCO is

signal sr: std_logic_vector (cwidth downto 0) := (others => '0');

begin

process (clk)
begin
if (rising_edge(clk)) then

sr <= sr + freq;

end if;
end process;

output <= sr (cwidth downto cwidth - owidth) + phase;

end rtl;
===============
Ked budem potrebovať v návrhu dva rôzne NCO tak pri definícii komponent použijem "generic map" a cwidth a owidth si predefinujem ako budem potrebovať.

Když vidím tu diskusi, nemůžu si nevzpomenout na stavebnici Logitronik 01

Na stavebnice Logitronik 01 a 02 jsem si taky vzpomněl, když jsem začal přemýšlet o nápadu, že bych si pomocí FPGA mohl vyplnit mentální mezeru mezi hradly a strojovým kódem.

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

Takhle se HDL rozhodne nedela. To radite jako ze si vemte C++/C#, include <asm.h> a piste si vse v intrinsics.

Od toho mame VHDL a jine vysokourovnove jazyky, aby slo napsat myslenku obvodu na papir - ono je uplne jedno jak to popisete, pokud po synteze dostanete obvod ktery bude delat to, co chcete.

HDL jsem napsal hodne - a vesinou kdyz neco nejelo tak to byl muj problem - protoze jsem to nevysvetlil / nezapsat tu esenci dostatecne jednoznacne, aby si to kompilator nevylozil jinak.

A opravu na hradla se tady nehraje ve smyslu "TTL" obvodu.

VHDL právě není ani C++, ani C#, ani java ani žádný vysokoúrovňový jazyk. Já toho VHDL taky napsal docela dost plus něco ve verilogu. U toho HDL prostě musíte mít dobrou představu, co z toho vyleze. Ale OK, raďte blbě, já se o tom přít nemusím.

Ja bych ten luxus z VHDL a moznosti generik, hlavne i pro packages v pozdejsich verzich, prirovnal k C++ (a jeho templatum).

Mel jsem historicky cest s necim co se jmenovalo ABEL, a to bylo spis jako asm v te jazykove analogii, protoze zrejme cileno na prvni PLD /PLA,PAL,GAL/ obvody s fixni strukturou:

https://en.wikipedia.org/wiki/Advanced_Boolean_Expression_Language

ono je uplne jedno jak to popisete, pokud po synteze dostanete obvod ktery bude delat to, co chcete.

Ono to není jedno ani v případě klasického počítačového programu. V případě popisu obvodu bývá ten rozdíl mezi dobrým a špatným (třebaže funkčním) popisem ještě propastnější.

HDL jsem napsal hodně

Nechci se vás dotknout, ale pokud jste k tomu přistupoval tak, jak naznačujete, tak to ovšem neznamená, že jste odváděl kvalitní práci.

Me prekvapuje jak si nejaky anonymko z internetu dovoli kritizovat nejen autora clanku, ale i velice nespecificke a nekonkretni prispevky v diskuzi.

Vsechno ma svoji "learning curve" a pokud clovek neni uplne nemehlo, tak i slozity projekt dokaze zdarne realizovat - a metrika na vysledek je boolean - jede to / nejede to (v ramci predem danych constraints). Zda je neco ve svete digitalni logiky kvalitni, nema zadnou jinou metriku.

Apropo, jak k vecem pristupuji je moje vec - a to taky nemuzete kritizovat, protoze muj pristup zde odhalen neni. Ale typicky ma clovek sw modely, ktere tu mega slozitou vec dokazou pred-implementovat a mit moznost odsimulovat i jinak nez psanim hdl a testbenche. Ty uz jsou pak s modelem mnohem snazsi.

A dôvod prečo nemôžeme kritizovať autora?

Tu mam VHDL čo som v rámci učenia robil už dávno: SVN tvrdi 11.8.2011:

--- efekt za pomoci Linear feedback shift register

library IEEE;
use IEEE.STD_LOGIC_1164­.ALL;
use IEEE.STD_LOGIC_A­RITH.ALL;
use IEEE.STD_LOGIC_UN­SIGNED.ALL;

entity efekt is
PORT ( clk : in STD_LOGIC;
num : out STD_LOGIC_VECTOR (8 downto 0);
led : out STD_LOGIC_VECTOR (7 downto 0));
end efekt;

architecture behavioral of efekt is
signal count : STD_LOGIC_VECTOR (24 downto 0) := (others => '0');
signal tik : STD_LOGIC := '0';
signal tak : STD_LOGIC := '0';
signal count1 : STD_LOGIC_VECTOR (24 downto 0) := (others => '0');
signal registr : STD_LOGIC_VECTOR (5 downto 0) := "000001";
signal reg : STD_LOGIC_VECTOR (8 downto 0) := "111111110";

begin

div:process (clk) -- delicka na ziskanie nizsej freq
begin
if clk='1' and clk'event then
count <= count + 1;
if count = "101111101011­110000011111" then
count <= (others => '0');
tik <= '1';
else
tik <= '0';
end if;
end if;
end process;

div2:process (clk) -- delicka na ziskanie nizsej freq
begin
if clk='1' and clk'event then
count1 <= count1 + 1;
if count1 = "000000000101­111000001111" then
count1 <= (others => '0');
tak <= '1';
else
tak <= '0';
end if;
end if;
end process;

shift:process (clk) -- posuvny register na generovanie pseudonahodnich kombinacii
begin
if clk='1' and clk'event then
if tik = '1' then
registr <= registr (4 downto 0) & ( registr(5) xor registr(4) );
end if;
if tak = '1' then
reg <= reg(7 downto 0) & reg(8);
end if;
end if;
end process;

led <= registr & registr(1 downto 0);
num <= reg;

end behavioral;

Porovnajte si čo vypadne ako RTL z môjho zápisu a porovnajte z tou hrôzou čo vygeneruje quartus z kódu čo sem tal autor.

Porovnajte si čo vypadne ako RTL z môjho zápisu a porovnajte z tou hrôzou čo vygeneruje quartus z kódu čo sem tal autor.

Nádhera. Ještě kdyby to bylo odsazené, aby se to dalo číst. Nějaká normální čísla místo těch binárních řetězců by taky pomohla. Já nechápu, proč pořád předpokládáte, že netuším, co dělám, a že jsem třeba neměl dobrý důvod, proč jsem kód napsal zrovna takto. Třeba abych si ty "hrůzy" prakticky zkusil.

Dobrý den, nepovažuji se za nějakého experta na VHDL, někdy s ním celkem bojuji a vycházím z toho, co jsem již napsal nebo napsali druzí, případně když jsme se o pravidlech bavili. Ale pár mých studentů vyrostlo v odborníky celkem značné a i se s nimi bavím a zase se zpět něco dozvídám.

blink.vhd

pro mě byl otevřením očí, protože jsem si vůbec neuměl představit, že se kód, ve kterém jsou vnitřní proměnné v procesu, které jsou použité jako stav přes wait, může syntentizovat do logiky. Sám jsem žil v přesvědčení, že tyto možnosti jsou použitelné jen pro účely behaviorálně popsaného testbedu a syntéza s nimi selže, protože jako paměť určenou pro syntézu lze používat pouze signály.

U signálů je pak ale přiřazení "<=" v procesu neblokující, jen přidává event do seznamu toho co se stane. Takže je potřeba počítat s tím, že po celou jednu dobu běhu procesu signál nese tu původní hodnotu a až při dalším z běhů se nastaví na tu hodnou, která do něj byla poslední přidaná. Někdy se takto hodí, ale bez toho uvažování že to bude zpožděné se nadělá mnoho chyb. Ve verilogu jsou obě možnosti přiřazení blokující "=" a neblokující "<=" a není činěn rozdíl mezi signálem/proměnnou. Ve VHDL jsem chápal proměnnou buď jako normální proměnnou v procedure, function a třeba i procesu ale u procesu jen takového který je určený pro testbed. Ale v syntetizované logice chápu v procesu proměnné maximálně jako zjednodušení zápisu nějakého složitějšího kombinačního výrazu. Stejně tak přiřazení výsledku funkce a je jasné, že jak ta funkce tak ty výrazy přes proměnné se musí vysyntetizovat tak, aby to byla jen kombinační logika, tedy jeden převod stavu vstupů na výstupy. Ano, mohu napsat klidně bubblesort s proměnnými a for cyklem bez čekání, ale očekávám pak, že systéza navrhne takovou logickou síť, která v převede všechny možné kombinace vstupů (to je třeba 10 signálů, kde každý je po 8 bitech) na výstupních 80 vodičů tak že tam budou setříděné. Je asi jasné, že pro 2^80 vstupů se to syntéze nemůže povést. Udivuje mě, že by to možná s vložením nějakého delaye mezi jednotlivé iterace možná i takto psát šlo.

Ale to co vzniká je opravdu něpěkné a nenapadlo mě ani na začátku, při prvním návrhu s VHDL, že by něco takového šlo. Ono jsem byl předtím vycvičený návrhem pro GAL, kde když jsme měli problémy s převody mezi různými variantami, tak jsem přímo and, or a configy psal v JED, pak jsem něco psal v ABELu. Pak pro XC3000 se kreslilo ze specializované řady TTL7400, takže tam opravdu člověka nenapadlo, že by to mohl psát jako kód.

Pak když jsem se bavil na začátku o VHDL s Markem Pecou, který mi s ním pomáhal, tak ten mě odkázal na publikace Jiřího Gaislera (autor procesorů Leon a dalších pro Evropskou vesmírnou agenturu). Protože u jeho návrhů, které pak končily i na křemíku bylo požadavkem, aby šly převést na redundantní, majoritní logiku, která zvládá v daném kroku minimálně jednu dočasnou chybu a dlouhodobě i jednu trvalou, tak pro návrh a jeho možnost i automatizovaného převodu mezi jednoduchou a vícenásobnou logickou zavádí striktnější požadavky než limit toho, co zvládne syntéza v stále se vyvíjejících a zlepšujících nástrojích.

Nehledal jsem zatím dostatečně dlouho, ale toto jsem od něj našel veřejné

https://download.gaisler.com/research_papers/vhdl2proc.pdf

Jinak u sebe na disku mám k VHDL asi 30 PDF souborů/knih. Ale nemám nyní čas najít, kde by tyto základy byly nějak dobře.

Pro naše studenty pro svůj předmět, kde učí s VHDL, připravil mnoho knih a materiálů kolega doktor Richard Šusta. Zde je česká verze https://dcenet.fel.cvut.cz/edu/fpga/navody.aspx.

Pro redundanci, asi starší verze jeho návodů zde https://susta.cz/FelUcebnice.aspx

Odkazoval jsem na ně i pod minulým článkem.

Ale jako spisovatel (i scifi), počítá s tím, že lidé umí číst delší texty, což je dnes i u mě problém, ale na rozdíl od jiných to nenechávám běšinou na výdobytcích strojového učení...

Kolega se k prvnímu sekvenčnímu obvodu ve VHDL dostává po knihách BinarniPrerekvizita (29 str.), Logické obvody na FPGA (159 str.), Úvod do návrhu obvodů v jazyce VHDL I. (96 str.) až v uprostřed druhé knihy Úvod do návrhu obvodů v jazyce VHDL II. (70 str.) v kapitole 3 Obvody řízené hodinovým signálem. Je pravda, že on i ty postupy s použitím variable v procesech ale používá.

Pokud si pamatuji správně Gaislera, tak ten byl tvrdě pro rozdělené logiky na kombinační proces, kde všechny uvnitř použité signály na pravých stranách jdou povinně v sensitivity listu. Naopak levé strany jsou zcela oddělěné signály třeba _next nebo _s a pak existuje druhý zcela nezávislý sekvenční proces, který pouze signály s _s nebo _next registruje při rising edge na _r, které jsou zase do toho kombinačního procesu a na výstupy. Takto má jasnou kontrolu, co je co...

pro mě byl otevřením očí, protože jsem si vůbec neuměl představit, že se kód, ve kterém jsou vnitřní proměnné v procesu

Já si to představuji tak, že proměnná představuje cestu v syntetizovaném obvodu. Každé použití proměnné ve výrazu odpovídá přivedení proměnné na vstupy nějaké skupiny LUT. Každé přiřazení do proměnné je realizováno nějakou skupinou LUT, která má proměnnou jako výstup. Pokud je proces sekvenční, na konci se poslední hodnota proměnné uloží do registru a tím se zachová pro další iteraci procesu (tj. je na výstupu registru při dalším hodinovém pulzu). Signál funguje podobně, ale ve výrazu se vždy použije hodnota přímo z registru, nikoliv z předchozího přiřazení. Výsledek přiřazení se přivádí pouze na vstup registru.

Tělo procesu je kombinační obvod bez vnitřních stavů a interní proměnné jsou reprezentovány vodiči spojujícími části obvodu. Pokud je proces sekvenční, stav se na konci procesu uloží do registrů, kde je k dispozici na začátku další iterace.

Nehledal jsem zatím dostatečně dlouho, ale toto jsem od něj našel veřejné https://download.gaisler.com/research_papers/vhdl2proc.pdf

Tohle mi připadá dost podobné tomu, jak se standardně v literatuře popisuje implementace konečných automatů (state machine) pomocí dvou procesů, kde kombinační proces počítá další stav a výstupy a sekvenční proces si jen v každé iteraci zapamatuje nový stav. Alternativa je spojit oba procesy do jednoho. Já ve svém kódu používám obě varianty. Quartus oba způsoby zápisu rozpozná a nakreslí pro ně schéma automatu jako graf obsahující stavy jako uzly a přechody mezi nimi jako orientované hrany.

Poněkud zvláštní je, že v textu jsou příklady kódu uvnitř procesů, které mi připadají celkem přirozené, ale mám pocit, že to je přesně ten styl, o němž tu někteří diskutující tvrdí, že je úplně špatně...

Jestli jsem některé námitky zde v diskuzi správně pochopil, tak směřovaly právě proti použití behaviorálního popisu a upřednostňovaly data-flow návrh. Odkazovaný text naopak tvrdí, že data-flow popis je pro složitější obvody nesrozumitelný a behaviorální popis pomocí procesu, definující funkci obvodu v podstatě jako algoritmus, je vhodnější.

Pro naše studenty pro svůj předmět, kde učí s VHDL, připravil mnoho knih a materiálů kolega doktor Richard Šusta.

Děkuji za zopakování odkazů na studijní materiály. Díval jsem se na ně už když jste je napsal do diskuze u prvního článku a podle mého názoru jsou velmi užitečné a pěkně zpracované.

Je treba rozlisovat mezi process-variable a function-variable ...

To prvni jsou opravdu jako "lokalni signaly" jen pro dany proces a maji "perzistenci" (proto se tvari jako signaly).

Do nich se prirazuje ihned skrze := (kdy se zmeni hodnota ihned) - a hodnota muze byt na kazdem radku kodu tedy jina (a syntetizuji se pak jako aliasy), zatimco prirazeni do klasickyho signalu skrze <= je takove prepisujici - plati hodnota na kterou se signal ustali na konci procesu (a syntetizuje se kombinacni logika + registr, pokud je to pod hodinama).

To druhe, kdyz je to ve funkci, tak je to spis makro/pomucka, skrze kterou popisete decision tree rychleji, nebo udelate ruzne opakovani. Samotna funkce se syntetizuje vzdy na kombinacni logiku (lut/rom). Tamni promenne nemaji pak syntetizovany ekvivalent.

A stejne se chovaji i promenne pouzite ve for/generate, ze jsou takove.. nad veci.

Promenne ve funkci a generate cyklech perzistenci nemaji.

Pro naše studenty pro svůj předmět, kde učí s VHDL, připravil mnoho knih a materiálů kolega doktor Richard Šusta.

Koukám do skript "Logické obvody na FPGA" a tedy musím říci, že z těchto skript bych to rozhodně nepochopil. Připadá mi, že s triviálními věcmi se tam autor zbytečně patlá, zatímco náročnější vysvětluje pro mě velmi těžko stravitelným způsobem – např. kapitola o Karnaughových mapách.
Výklad mi připadá zmatený, stylově neukotvený ("přesuneme bublinku zprava doleva" na jednom místě vs. standardní styl "definice: Nechť je dána funkce..." o kousek dál).
Naprosto nepochopitelná pro mě je volba fontů textu, zcela v rozporu s ustálenými zvyklostmi sazby matematických textů, nevhodný zůsob zvýrazňování atp. Autor se nejspíš snažil o jakýsi inovativní způsob sazby za účelem zvýšení přehlednosti, podle mě se mu podařil pravý opak zamýšleného – má na mysli funkci? Nebo má na mysli logický prvek? Nebo snad jen anglický termín? Je to proměnná, nebo jen spojka či předložka ve větě? O obrázcích uvádí, že je jejich autorem – pak ovšem nechápu, proč používá anglická spojení i v místech, kde nejde o žádný ustálený termín. Je to matoucí. Snad se na přednáškách dokáže vyjadřovat lépe, jinak studenty lituji.
V úvodu také zmiňuje, že k sazbě byl místo profesionálního systému použit MS Word vzhledem k velkému počtu obrázků. Toto vysvětlení jde zcela mimo mé chápání. S obrázky jsem v TeXu nikdy nezažíval takový boj, jako v MS Wordu. Zároveň to dokazuje, že k vytváření solidně vypadajících bohatších textů se MS Word opravdu nehodí.

Delší dobu sháním nějakou literaturu na toto téma pro mladší kolegy, zatím marně. Česky, anglicky, zadarmo či za peníze... Doufal jsem, že toto by mohlo být to pravé, ale bohužel.

Tak nabízím to, o čem vím. Myslím si, že konstrukce VHDL jsou v textu popsané a lze se je z něj naučit. Ano, zrovna sám bych ten styl s proměnnými v procesech použitými přes wait nebo rising edge nepoužíval. Nějak jsem naučený, že paměť má být na signálu. Ale možná je to moje chyba.

Jinak sám bych také preferoval jiný formát než Word, slidy k našim přednáškám k procesorovým předmětů byly v LibreOffice, nyní ty základní máme v LaTeX beameru, a zdroj jak u nás, tak na GitHubu, pokud by chtěl někdo mimo ČVUT poslat korekci. Tato iterace je teď primárně česky, ale sám si myslím, že splnění rozkazu vedoucího programu přepsat slidy do češtiny nebyl dobrý nápad a teď je zase potřebuji dokončit přepsání z té upravené podoby zpět do angličtiny pro cizince. Jinak z té tabulky přednášek jsou pod jednotlivými čísly také odkazy na zdroje, naše starší přednášky a i různé rozšiřující materiály. Na logiku třeba i v polypad amplify, kde si lze logiku proklikat.

Během překládání se dost z původních přednášek vypustilo, některé obrázky rozbily a teď nacházíme chyby a to i vhledem k časové tísni na přehlad tak to vypouštění je i proto, že ty původní slidy byly opravdu obsáhlé. Zase se ale něco zajímavého přidalo a kolega bude část přesovat do nového úvodního předmětu, který bude na takovou spíše všeobecnou znalost a z třetiny i na tu Booleovu algebru a ukládání informace do bitů.

Jinak pěkný úvod v češtině i angličtině do Verilogu má i kolega z FITu, se kterým jsme původně náš kurz dávali dohromady. Jedná se o předmět
Architektura počítačových systémů (BI-APS), Přednáška: Úvod do jazyka Verilog, ale FIT obecně materiály volně přístuné nemá. Dvě jejich přednášky v rámci naší spolupráce placené z veřejných zdrojů byly přidané na společně využívaný comparch. Kolega má v plánu napsat i skripta, knihu, spíš ale na procesory. Sám spíš doporučuji ty zahraniční učebnice od prof. Pattersona (Computer organization and design RISC-V edition: the hardware/software interface) a nebo Sarah Harris a David Harris (Digital Design and Computer Architecture, RISC-V Edition), v té druhé se vysloveně konstrukce Verilogu a VHDL ukazují na stavbě procesoru.