integrovany filtr

[balu@home]

mno nedovolim si ti oponovat, ale ako zamestnanec institucie ktora 
sleduje (a niekedy aj vytvara) najnovsie technologicke trendy si dovolim 
povedat ze nemas uplne pravdu. Musim povedat ze sa vyvoj aplikacii, 
ktore spracovavaju signaly ubera prave smerom od FPGA k DSP. FPGA je 
stale bastou masivnych nativne paralelnych aplikacii ako su nejake 
datove toky, pocitace, routing dat a podobne, plus aplikacii 
vyzadujucich mnozstvo IO pinov. Spracovanie numerickych dat (floating 
point, komplexne cisla etc.) je v FPGA dost komplikovane. Ak sa pokusis 
navrhnut nejaky sofistikovanejsi filter s vyssou presnostou v FPGA velmi 
rychlo sa dostanes napriklad ku 128 bitovym zberniciam a zodpovedajucim 
ALU.
Cim dalej tym viacej sa ale aplikacie spracovavajuce nejaky tok dat 
vygenerovany nejakym fyzikalnym procesom (senzory, obraz, zvuk) 
presuvaju do DSP. Vykon DSP sa v poslednych rokoch radovo zvysil a uz 
nemaju problem v mnozstve aplikacii nahradit FPGA. Vyzera ze priemysel 
radsej pouzije DSP ako FPGA, nepytaj sa ma preco. Napriklad v jednom 
americkom laboratoriu postavili na spracovanie (hlavne sofistikovane 
filtrovanie) dat v 500MHz rytme banku 80 paralene beziacich DSP s 
demultiplexovanymi datami namiesto niekolkych velkych FPGA. Proste sa to 
lahsie implementuje...
Simulovat v matlabe sa da hocico, takisto su tam filter-toolboxy ktore 
priamo spolupracuju s vyvojovymi prostrediami pre DSP.
b.

p.s. uz mame "A." "b." kto bude dalsi? :-)


Andrej Jancura wrote:
> Myslim si, ze pri tomto pomere bude mat aj ine problemy... Ja osobne by 
> som volil asi nieco okolo 0.1-0.25.
>
> Okrem toho ako pisal kolega nieco o 600MHz DSP... No fuj, v dobe, ked je 
> FPGA Spartan s DSP engine, by som ine asi ani neskusal. Tie filtre si 
> urobi vo VHDL ake sa mu zachce a moze odsimulovat v Matlabe, ktory 
> vygeneruje priamo VHDL alebo C. A taktovat moze tiez ako chce, vyhoda je 
> paralelne spracovanie dat v FPGA.
>
> A.
>