Programovatelná logika V: Základní principy vývoje pro FPGA (diskuse)

[Peter Golis]

Pekné. Budú aj nejaké príkladíky napríklad pre Parallella board od firmy Adapteva?

[hw]

Nejdříve bych rád dokončil obecný úvod a seznámení. Nějaké příklady pak můžu vymyslet. Určitě by ale nebyly pro Parallelu. Platforma by mohla být buď nějaká standardní vývojová deska Xilinx nebo Altera, případně PicoZed od Avnetu. Mimochodem, tohle je náš produkt, který bude u Avnetu ke koupi od začátku příštího roku.

[nyan]

Kdyz uz spominate Parallellu, kdesi sem videl ze Adapteva pouziva to FPGA pro implementaci HDMI rozhrani, a tudiz je nepouzitelne pro vlastni navrhy, leda ze by clovek obetoval HDMI - tusite nekdo jestli to je pravda ?

[pc2005]

Oni používaj to FPGA na běh testovací distribuce a na napojení toho jejich multicore procesoru do systému. Existuje konfigurace s a bez HDMI. Pokud bys měl větší verzi (Zynq7020), tak ten by měl mít IMHO 2x víc prostředků než menší verze (Zynq7010). Zbytek desky je ale prakticky stejný (=má stejně nároky na zdroje), takže se Zynq7020 budeš zcela jistě mít dost místa. Se Zynq7010 asi taky trochu (u FPGA se nedosahuje 100% využití prostředků, takže musí být stejně rezerva).

Samozřejmě se můžeš na ten jejich procesor vykašlat a používat ten Zynq jen jako dualcore ARM SoC (minecraft server na tom jede líp než na kámošově Atomu ) + FPGA. Akorát budeš mít asi problém s GPIO, protože Parallella má nějaký superhustý konektory (žádnej 2.54mm header ).

P.S. Jinak ty ani grafiku nepotřebuješ. V SoC je od výroby řadič 1G ethernetu (tedy žádnej pomalej USB převodník), takže to můžeš ovládat klidně přes vnc/ssh.

P.P.S. Akorát je blbý, že ta deska vyžaduje externí větráček .

P.P.P.S. Mírně OT: Maník, co se původně snažil financovat otevření 3D enginu jedné staré grafiky na kickstarteru, to nakonec otevřel pod GPL.

P.P.P.P.S. Jsem chtěl původně taky napsat blog, ale teďka nemám absolutně čas.

[hw]

Díky za link na gplgpu. Nějak jsem to přestal sledovat a tohle mi uniklo. Musím, ale říct, že mě docela zarazila tahle část v README:

The IP is licensed under the GPL v3 license. As this applies to hardware, if you develop any hardware system utilizing this code the entire ASIC or FPGA containing the Ip must be licensed under the GPL v3 and source made available.

Nejsem si úplně jistý, jestli to skutečně z GPL v3 vyplývá. Pokud ve svém projektu použiji instanci gplgpu jako black-box bez sebemenšího zásahu do zdrojáku, skutečně musím zveřejnit zdrojáky celého systému? Tuhle situaci bych přirovnal k přilinkování statické knihovny pod GPL v3 k mému vlastnímu programu. Znamenalo by to v tom případě, že skutečně musím zveřejnit zdrojový kód celého programu?

[pc2005]

No ono hlavně použít softwarovou licenci na hardware je dost blbost. Takže nejspíš nebude právní precedens, takže jediné co je směrodatné by asi bylo zeptat se autora . Jinak jsem ale měl za to, že linkování knihovny staticky do programu GPL vyžaduje i když tuším existují vyjímky.

Osobně bych to teda radši licencoval pod LGPL. Ale nejradši fakt pod nějakou HW licencí, takhle není ani pořádně jasný rozdíl mezi tím, co je vlastně to IP, protože HDL může popisovat hardware buď abstraktně, ale klidně na úrovni LUTů a FF (tak to maj snad některý verze PicoBlazu). A pak do toho vleze rekonfigurace, kde může být funkce v LUTu nebo FF změněná na základě obsahu jiných LUTů a FF . V extrémním případě by to znamenalo zveřejnění masek celýho FPGA pod GPL (ekvivalent toho ASICu).

Jinak pokud by to s tím linkovaním platilo, tak to ani nelze zapojit na třeba Microblaze (ten až na jeden incident s uniklejma zdrojákama je closed source).

P.S. Když se to tak vezme, tak optimalizace při implementaci bude do toho blackboxu zasahovat (mazat "open" dráty, slučovat LUT kaskádu apod.).

[Tom.š Ze.le.in]

... přilinkování statické knihovny pod GPL v3 k mému vlastnímu programu. Znamenalo by to v tom případě, že skutečně musím zveřejnit zdrojový kód celého programu?

Podle výkladu autorů licence (RMS) ano. A i jen design tak, aby bylo možno přilinkovat GPL dynamickou knihovnu (ani ne přímo její přilinkování), aspoň podle GPL2 (a nemyslím si že by se to s GPL3 uvolnilo).

Viz např. readline (GPL) a clisp.

[Tom.š Ze.le.in]

Tedy přesněji - ne zveřejnit, ale nabídnout zdrojáky pod GPL tomu, komu dávám přeložený kód. A i to je nepřesné, ale už se opravovat nebudu.

[pc2005]

Mimochodem, tohle je náš produkt, který bude u Avnetu ke koupi od začátku příštího roku.

Zynq 7015? WOW a má to vyvedenej PCIe na ten header?

[hw]

V podstatě ano. Verze se 7015 a 7030 mají na konektoru JX3 vyvedené čtyři transceivery a referenční hodiny. Účel našeho setu SVDK je trochu jiný, takže transceivery používáme pro CoaXPress rozhraní.

[pc2005]

Aha jasný, já jen, že skoro nikdo nedělá FPGA karty s PCIe a přitom zapojení do adresního rozsahu PC je právě to, co by dalo FPGA boost (neboli: je hezký, že na FPGA může být libovolný akcelerátor, ale když není datová propustnost, tak je to skoro k ničemu).

[nyan]

Umm... (mozna hloupej dotaz, ale..) na jake frekvenci bezne behaji tyto FPGA ? radove, priblizne ?

[hw]

Záleží na typu a technologii. Interní synchronní prvky jsou obvykle schopné pracovat na stovkách MHz, což u low-endu znamená frekvence řekněme do 200-300MHz, u high-endu třeba 800-900MHz. Na druhou stranu sériové transceivery můžou pracovat na jednotkách až desítkách GHz. To ovšem vůbec nic nevypovídá o tom jak rychle a dokonce ani na jaké frekvenci bude fungovat nějaký konkrétní návrh. U FPGA stejně jako u libovolných obecných logických obvodů jsou pracovní frekvence a "rychlost" dvě různé věci, které spolu nemusí až tak moc souviset. Vezměte si například jeden obvod, který zpracovává 64b slova a pracuje na hodinové frekvenci 100MHz. Druhý obvod zpracovává 8b slova na hodinové frekvenci 500MHz. Oba obvody implementují stejnou funkci a oba zpracují jedno slovo v každém hodinovém cyklu. Který obvod je rychlejší?

[nyan]

Supr diky. Je mi jasne ze frekvence != rychlost, jen me to zajimalo.

[Josef Kufner]

Proč to není jako článek? Že to je mírně offtopic nevadí.

[Aleš Kapica]

Že by proto, že blogpost dává větší publikační svobodu?

Článek se publikuje a visí tak jak je, kdežto text v rámci blogpostu lze průběžně modifikovat. Na základě reakcí v diskuzi přidat update, linky, obrázky aj.. nebo opravit chyby či překlepy.

[hw]

Mě to přišlo pro ábíčko off-topic docela dost. V ČR je v podstatě jediný server kam by to tématicky patřilo, ale z něj je už řadu let reklamní kanál, kde publikovat nechci. Seriál sice vychází v jednom tištěném časopise, ale tam zase chybí zpětná vazba. Publikovat to tady na blogu mi přišlo jako docela dobrý kompromis.

[Agent]

Tady nějakej borec naimplementoval Cray 1 do FPGA - Homebrew Cray-1A

Jelikož jsem totál lama, tak odpusťte možná blbé dotazy, ale teoreticky jak maximálně výkonný počítač by se dal implementovat? Řekněme něco na úrovni P2? Lze využít i nějaký klasický programovací jazyk?

[Jendа]

Jelikož jsem totál lama, tak odpusťte možná blbé dotazy, ale teoreticky jak maximálně výkonný počítač by se dal implementovat? Řekněme něco na úrovni P2?

Jo, tak něco.

Lze využít i nějaký klasický programovací jazyk?

Pro všechno možné, od Microblaze přes AVR po ARM, jsou normální kompilátory Cčka. Koukni na OpenCores.

[hw]

Lze využít i nějaký klasický programovací jazyk?

Pro všechno možné, od Microblaze přes AVR po ARM, jsou normální kompilátory Cčka. Koukni na OpenCores.

Aha, já tu otázku pochopil jinak (viz má odpověď níže). Samozřejmě pro CPU implementované v FPGA je možné použít libovolný jazyk, pro který existuje kompilátor.

[Agent]

Taky díky.

[hw]

Tak on Cray-1A je velmi dávná historie a ta implementace je fakt maličká a i v hodně starém FPGA běží rychleji než originál.

Implementace obecného procesoru nebo počítače není úplně nejlepší nápad, protože mezi návrhem a křemíkem máte jednu mezivrstvu navíc (FPGA), která poněkud snižuje výkon oproti přímé implementaci jako ASIC. Soft-procesory se v FPGA používají spíše v kombinaci s jinou logikou, jako takzvané programovatelné systémy na čipu.

Samozřejmě dnešní FPGA jsou použitelné pro implementaci i velmi výkonných procesorů, ideálně ale spíše s architekturou RISC. P2 by implementovatelná určitě byla, ale architekturou není pro implementaci v FPGA úplně ideální. Jako příklad velmi výkonných CPU použitelných i v FPGA bych uvedl třeba Leon4, což implementace architektury SPARC V8e, nebo třeba Sun (dnes tedy Oracle) OpenSPARC T1 a T2, což jsou 64b architektury UltraSPARC T1 a T2. Můžete najít i nějaké informace o implementaci Intel Atom nebo architektury Nehalem (první Core i5/i7). Tyhle implementace jsou ale trochu starší, takže třeba to jádro Nehalem nacpali do pěti FPGA Xilinx Virtex-4. Věřím, že dnešní Xilinx Virtex UltraScale by stačil jeden.

Některé klasické programovací jazyky použít jde. Používají se ale neklasickým způsobem, což může být pro běžného programátora v těchto jazycích dost matoucí. I s využitím těchto jazyků se totiž stále popisuje zapojení logického obvodu, nikoliv sekvenční posloupnost instrukcí. O jazycích pro vývoj a verifikaci bude přespříští pokračování seriálu.

[Agent]

Velmi děkuji za odpovědi. Pohrávám si s myšlenkou, že nakoupím literaturu a zkusím si bastlit, když jsou ty vánoce.

[Jendа]

Já jsem začal něčím jako toto a pak už to šlo skoro samo :). Jo a zkus hned na začátku rejpat do simulátoru, dost to usnadní debugování.

[Jendа]

Jo jinak dobrá stránka hlavně pro interfacing s okolním světem je fpga4fun. A to nejen pro FPGAčkaře, jsou tam vysvětlené běžné sběrnice a protokoly, což se hodí i když děláš třeba MCU.

[hw]

Něco na téhle úrovni mám v plánu jako první příklad hned po dokončení obecné časti seriálu. Jenom tedy s aktuálními nástroji místo ISE a včetně simulace.

[Jendа]

Aha, ISE už nebudou vyvíjet? Na webu Xilinxu to v popisu nevidím.

[pc2005]

Nebude, jenom updaty kritických chyb. Ovšem vtipné je to, že Vivado podporuje jen řadu 7 a vejš (leda, že se nechali za poslední rok překecat).

[hw]

Jak se píše tady, oficiálně se ISE nevyvíjí už přes rok. Fakticky se ale nevyvíjí více než dva roky. Ty poznámky o kritických opravách je třeba brát s velkou rezervou, protože u firmy Xilinx už dost dlouho nepracuje žádný z původních vývojářů ISE.

Co se týče podpory FPGA, je to skutečně tak, že ISE podporuje vše do řady 6. Podpora některých obvodů řady 7 je v ISE spíše jenom dobastlená a je v podstatě nepoužitelná. Rozhodně doporučuji se kombinaci 7-series a ISE vyhnout. Řadu 7 a výše (momentálně 7 a UltraScale) podporuje naplno až Vivado.

Ještě poznámka k potenciální možnosti podpory řady 6 ve Vivadu. Sice platí "nikdy neříkej nikdy", ale dovolím si téměř s jistotou prohlásit, že toho se nedočkáme. Jakožto oficiální Xilinx Alliance Partner máme dost informací navíc a o ničem podobném se bohužel ani neuvažuje. Přitom ze strany zákazníků by byl obrovský zájem. Velké firmy především z Asie v tomto ohledu na Xilinx tlačí, ale zatím bezvýsledně.

[pc2005]

Jelikož jsem totál lama, tak odpusťte možná blbé dotazy, ale teoreticky jak maximálně výkonný počítač by se dal implementovat?

Hehe no třeba moje patička (Opensource 32bit osmijádro). Ale to je spíš na úrovni MCU.

Jinak, co se týče výpočetně výkonných CPU, tak tam máš nějvětší omezení maximální frekvenci toho FPGA (pro CPU to budou tak maximálně pár (slovy dvě ) stovek MHz). Co by neměl být takový problém je počet bitů sběrnice, třeba AXI Microblaze jima vůbec nešetří (rozhraní pro data, pro instrukce, jednosměrné kanály, zvlášť čtení a zápis, zvlášť adresa). Ale je klidně možný, že to je právě ten problém, proč je Microblaze tak pomalý. Při velkém počtu "drátů" ti postupně docházejí propoje na FPGA (jsou nedražší a je jich vždycky málo) a musí se použít neoptimální cesty, který trvají moc dlouho (a optimální cesty/hodiny zase musejí na ty neoptimální čekat než na nich dorazí data).

Co se týče výkonu, tak jsem postavit vícejádrovej Microblaze s linuxem, ale je to pomalejší než PXA272 (ne zrovna v přetaktovaném stavu). U Microblazu ale nejvíc zdržuje polosoftwarová MMU, takže má ještě velké rezervy.

Jinak to můžeš porovnat třeba i z hlediska cache, FPGA mají tak maximálně 1MB SRAM (pokud to teda nejsou supernadupaně a superpředražené Virtexy), ale pro cache se ti povede využít tak odhadem 256KB.

Pokud bys ale použil nějakou paralelní architekturu, kde nemusí být jednotlivá jádra těsně svázané (=míň propojů mezi nima), tak to IMHO pojede rychle a budeš moct použít velké procento prostředků.