(#1) Petykemano
Az intel vitte az alterát és van neki Xeon Phi gyorsítója.
Az Nvidia és a Xilinx része az IBM Openpower konzorciumának.
Nem mintha a legnagyobb szereplő lenne.. sőt... De az AMD kiszorulni látszik ezekről a piacokról/területekről. Volt valami kósza hír, valami harmadik FPGA gyártóról, akiről addig még sose hallottam, akivel az AMD lepaktált. De úgy tűnik, elfogyott a levegő. PEdig milyen lelkesen mutogatta a média az AMD exascale elképzeléseit...
Találgatunk, aztán majd úgyis kiderül..
Lattice, Atmel?
Valaki, aki ezen a területen mozog, meg tudja mondani, tényleg ennyire fontos a Ferrari elé kössünk Trabantot gondolkodás?
Fejlesztesi ido csokkentese, portolhatosag, a programozok nem ertenek a HDL-hez. Kb. ennyi.
Arra gondotam.
Találgatunk, aztán majd úgyis kiderül..
Milyen Trabantot? 
Le az elipszilonos jével, éljen a "j" !!!
Tehát nem ért a programozó az egyikhez, ezért a hibrid rendszerhez majd fog és jobban, hatékonyabban fejleszt. Miért érzem, hogy sok nem fog megvalósulni belőle?
#7 E.Kaufmann: Ferrari-Trabant. Amire tervezik/tervezték őket, mindegyik nagyon jó, egymáshoz viszont sok közük nincs.
[ Szerkesztve ]
Szvsz igen. Gondolj olyan HPC-kre, ahol vegyes felhasználás van (gyak. az összes céges rendszer igen nagy százaléka ilyen.) Na most itt akkor van olyan lehetőséged, hogy bizonyos modulokat átrakj fpga-ra egy-két nagyságrend gyorsulást elérve.
''A file-cserélés öli meg a filmipart? Inkább a filmipar öli meg a file-cserélést. 2 hónapja nincsen semmi értelmes film, amit érdemes lenne letölteni...''
Ez rendben, de eddig mi akadályozta meg a cégeket ilyen helyeken FPGA alkalmazásában, hogy majd most az integrált megoldások jól taroljanak?
Pontosan. Ahhoz, hogy OpenCL kodot irjon, nem kell ismernie a HDL nyelvet es az FPGA sajatossagait, csak a koztes reteg sajatossagait, azaz azok a komplett es kesz modulok amiket a fordito lepakol es osszekot. Tehat mondjuk felosztjak az fpgat 128x128 negyzetre es mindegyikbe be tud pakolni a fordito egy alut, logikat, fpu-t barmi hulyeseget. Igy a programozonak nem kell ismernie az osszeadas/szorzas RTL szintu tervezest, sem egy szorzo vagy osszeado aramkor HDL szintu optimalizalasnak rejtelmeit.(De emlithetnem a pipeline, kommunikacios busz, stb.-t is.)
Arrol mar nem is beszelve, hogy egy komplexebb HDL dizajn forditasa olyan 6-48 ora, ami a jelenlegi programozoi gyarkolattal(fordit->tesztel->fordit->tesztel) kisse sok idot igenyelne.
[ Szerkesztve ]
És mihez kezd debugoláskor?
az "adatcenter" helyett jobb lenne adatközpont
-
Nem erre kodolna. Hanem nagyobb logikai egysegekbol pakolna ossze a funkciot es nem 6 bites LUTokbol. Tehat huzalozott lenne, mint egy HDL design. (Nagyjabol analog megoldas a regi bitszelet processzorokkal.)
A cryptocoin fpgakat nem kell bemutatni, en magam is aktivan foglalkozom vele. Es nem volt sosem olcsobb, mint egy ASIC, csak kisebb beruhazassal es rovidebb fejlesztesi idovel jart. Amint vilagossa valt, hogy hosszutavon megeri ASIC-ba fektetni meg is tettek, es a jelenlegi volumenben joval olcsobb az FPGA-nal(per IC).
[ Szerkesztve ]
Nem ertem a problemat.
Csak tippelni tudok, de jelenleg az elérhetőségre gondolok. Itt majd ott lesz a proci mellett közvetlenül az fpga, nem kell még azt külön beszerezni, helyet találni neki, külön licence-elni, stb.
A jövőben meg közös debug egy hihetelten előny lenne. Pl. ha én pl. egy fáradási szimulációt úgy tudok megírni hpc-re, hogy az érdemi számítást vagy egy részét már az fpga végzi. Ma ez úgy megy, hogy vagy matlab-ban megy direkben, vagy jobb esetben matlabból fortran/c kód hívásával fut a mérnök pc-jén. Esetleg natív c/c++/fortran kód pluginként. Most vándorulunk hpc-re, de a köv. lépés ezután egyértelműen valami fpga lesz, főleg, ha a mostani userszámnál egy-két nagyságrenddel több szabadul rá ugyanarra a szimulációs modulra.
''A file-cserélés öli meg a filmipart? Inkább a filmipar öli meg a file-cserélést. 2 hónapja nincsen semmi értelmes film, amit érdemes lenne letölteni...''
Hogy fognak az FPGA-hoz nem értök debugolni? Amikor a fordító ugyan nem száll el, lefut a program, de az eredmény hibás.
Hát mondjuk TDD-t használva fejleszt. Vagy olyan szintű lesz az IDE (pl. alap unit test supporttal -> legtöbb embedded eszközhöz az utóbbi öt-hat évben a TDD miatt ez már alap, de PC vonalon is kis millió tool van ami mondjuk VS-be beépülve ezt támogatja.)
Egyébként a cél szerintem nem a hc fpga világ megfogása, hanem hogy a hagyományos vevőknek tudjanak egy viszonylag fájdalommentes beruházással járó nagyságrendbeli futásidő növekedést kínálni. Pl. mint a matlab cuda supportja. Kis túlzással annyi a dolgod pl. egy fft gyorsításánál, hogy beraksz egy cuda képes kártyát a gépbe, megveszed a parallel toolbox-ot és beraksz néhány gpuarray string-et a kódba és örülsz a megtáltosodott fft számolási sebességnek.
''A file-cserélés öli meg a filmipart? Inkább a filmipar öli meg a file-cserélést. 2 hónapja nincsen semmi értelmes film, amit érdemes lenne letölteni...''
Ok, köszi. Kezdem érteni a koncepciót így. A valós feladat példákat pláne köszönöm.
Csak a koztes rendszert kell debuggolni, nem az fpga-t. Ha meg az is szar, majd nyitnak ticketet a szallitonal.
A köztes rendszer még nem garantálja, hogy a kód jól is fordul FPGA-ra. Hogy példával szemléltessem, mire gondolok: pl. egy CFD szimuláció. megírják a kódot, valami valahogy átfordítja, minden fut, csak épp az eredmények nem korreálnak a valósággal.Ilyenkor, ha az FPGA részhez nem ért, hogy tudja megmondani, mi a rossz? Egy olyan tickettel, hogy nem jó az eredmény, senki nem tud mit kezdeni.
Mert az FPGA reszhez nem is kell. A kozti reteg moduljai szimulalhatoak. A processzor mikrokodjat sem debuggolja a programozo, ha mar ott van a hiba, akkor megy a problema a gyartohoz.
[ Szerkesztve ]
