Procek z 4 UART

To takiego nie uzywasz do tego celu :-)

A niekoniecznie - bo mozna tam tytulowe 4 uarty wsadzic, a moze 8 kanalow PWM, a moze sterownik LCD - ktory dma bedzie mial u siebie a nie w procku ..

J.

Jarku, ale w najmniejszej kostce Cyclone masz na starcie ~3000 cel. Wymienione przez Ciebie peryferia zu¿yj± ich pomijalny procent. Co chcesz zrobiæ z reszt±? Ma³y, kilkunastomispowy Nios zajmuje <700 cel, a najbardziej rozbudowany, ponad 100-mipsowy ~1800.

Pozdrawiam Piotr Wyderski

Piotr Wyderski napisał(a):

Jak to było(w kontekście rozmowy o możliwym zastosowaniu układów Xilinx XCV1000)? "Jesli wlasciwie przemyslisz budowe IP core Atari i dolozysz zewnetrzny SDRAM, to przypuszczam, ze w jedna kosc wlozysz nie 1, ale ponad 100 takich maszynek. :o)))" ;-) Wygląda na to, że nadchodzi nowa era w dziedzinie hobbystycznych konstrukcji i bardzo dobrze :]

Mniejsza kostke kupic :-)

J.

Ta jest najmniejsza. Ponawiam pytanie, co zrobisz z reszt± cel? Przeka¿esz na pomoc dla powodzian? ;-)

Pozdrawiam Piotr Wyderski

Oj tak, ja ju¿ na trwa³e z³apa³em bakcyla FPGA. ;-)

Pozdrawiam Piotr Wyderski

Najmniejszy Cyclone. Bo Altera robu chyba jeszcze kostki mniejsze ? ktore miejmy nadzieje sa tez tansze :-)

Zreszta nie musi byc przeciez Altera. Ale masz racje - za 10 lat problem moze byc powazny :-)

Generalnie ciagle nie widze wiekszego sensu w robieniu procesora za pomoca uniwersalnej struktury, bo to przeciez wychodzi wiecej krzemu i mniej optymalny design. Czyli wiecej pradu i wiecej pieniedzy ... - choc cenniki nie musza tego potwierdzac :-)

J.

Rozgranicz 2 pojecia. Robienie _jednego_ procesora i robienie _miliona_ procesorow w tejze niezoptymalizowanej strukturze.

Ale procka z 8x uart, 16x pwm, 20x timer, i2c, spi, ddram skladam w dzien przy odrobinie wprawy. A ja ciagle chce sztuke, moze dwadziescia sztuk. Jak zaczne robic miliiony, to przestane miec takie problemy :-)

Robi, ale w znanym mi detalu s± bezwzglêdnie dro¿sze (tj. nie w przeliczeniu ceny na 1 LE, tylko po prostu na kostkê), wiêc za najtañszy uk³ad FPGA uznajê najmniejszego Cyclone'a.

Jaki problem, dla kogo? :-)

To prawda, ale procesor nie jest jedynym elementem systemu cyfrowego; co najmniej tak samo wa¿ne s± peryferia. A te, dziêki zasadzie dzia³ania FPGA, mog± wystêpowaæ w DOK£ADNIE takiej postaci i liczbie, jakiej potrzebujesz. Nie musisz ¶lêczeæ nad katalogami w poszukiwaniu odpowiedniego w danym zastosowaniu CPU, po prostu sobie to CPU wraz z przyleg³o¶ciami robisz. Brakuje Ci jakiej¶ instrukcji procesora -- dopisujesz j± sobie. Procesor nie wystarczy -- dorabiasz hardware accelerator i podpinasz go do Avalonu. Od kiedy w FPGA pojawi³y siê jednocyklowe uk³ady mno¿±ce, przesta³em widzieæ sens istnienia sta³oprzecinkowych DSP; FPGA naprawdê zrobi to lepiej. :-)

No i tak w³a¶nie jest. :-) Ech, jak ja mog³em przez tak d³ugi czas tkwiæ w ciemno¶ciach... ;-)

Pozdrawiam Piotr Wyderski

Ale ja zasadniczo tez - tzn dobieram odpowiedniego procka i dokladam same peryferia..

W sumie za 46 zl to faktycznie nie bardzo jest co oszczedzac a jak kto spawarke robi to mu wszystko jedno ile amper procesor ciagnie :-)

A jaka jest "jakosc" tego niosa ? Bo porzadny 32-bitowy procesor ma dzis chyba z milion tranzystorow, sredni kawalek krzemu, ale w FPGA bedzie musialo byc pare razy wiecej. Mozna mniej - ale juz kosztem funkcjonalnosci ..

J.

A tutaj odpada faza doboru peryferiów, martwienia sie o to, gdzie je mozna kupic za sensowne pieniadze oraz zachodzenia w glowe jak to wszytsko polaczyc, bo jakis tytan intelektu tak posiekal pinout, ze za chinskiego boga nie da sie podejsc z sygnalami na plytce dwuwarstwowej.

Taka, jakiej sobie zyczysz; NIOS wystepuje w kilku parametryzowalnych wersjach. Od malego procka wykonujacego kazda instrukcje w kilka cykli bez pipeliningu do "potwora" z potokiem, cache danych i instrukcji oraz dynamicznym przewidywaniem skoków:

I to byl moj glowny punkt przelaczania sie z procesorow na FPGA. Prawdziwie _rownolegle_ przetwarzanie danych - bo w kazdym procku, jesli procek w ukladzie jest tylko jeden to niestety mamy _szeregowe_ przetwarzanie danych. A tutaj nagle trafilem do Krainy Oz - moge zrobic dwie rzeczy jednoczesnie :-)

Hihi, jeden nawrocony :-) Sorki ze nie skompilowalem Twojego kodu, ale jakos tak glupio wyszlo :-( Podejrzewam jednak na 99% ze wyniki byly prawidlowe.

Ale te peryferia sa w PLD zrobione. Tylko procka nie wsadzam do PLD bo jest ich wystarczajaco duzo zrobionych :-)

J.

A, mo¿na i tak. Tylko jak sobie popatrzysz do cenika, to Ci wyjdzie, ¿e zakup wiêkszej kostki, w któr± oprócz peryferiów w³o¿ysz jeszcze procka wyniesie taniej ni¿ osobny procek i PLD z peryferiami. :-) A jak Ci siê co¶ odwidzi, to sobie b³yskawicznie zmienisz strukturê uk³adu za pomoc± kabla programuj±cego. Dlatego w swoim radiu konfiguracje chcê trzymaæ nie w pamiêci konfiguracyjnej, ale w postaci plików na karcie CF -- jak mi co¶ _po_ jego zbudowaniu przyjdzie do g³owy, to sobie dogram kolejn± "osobowo¶æ" i bêdê wybiera³, która w danym momencie ma byæ aktywna. :-)

Pozdrawiam Piotr Wyderski

Moim zdaniem tu nawet nie o sam± równoleg³o¶æ chodzi, bo jej brak zawsze mo¿na nadrobiæ odpowiednio szybkim procesorem, ale to, ¿e wszystko dzieje siê we W³a¶ciwym Momencie. Ja sobie nawet nie chcê wyobra¿aæ tego, jak wygl±da³by procek maj±cy w sensownym czasie "opêdzlowaæ" 185 pinów IO (tyle ma mój Cyclone 1C6). Druga sprawa to to, ¿e w koñcu mo¿na projektowaæ uk³ad skupiaj±c siê na przep³ywie danych, a nie na przep³ywie sterowania. Powiem nawet, ¿e FPGA jest znacznie bli¿ej idei modelowania obiektowego ni¿ wiêkszo¶æ "obiektowych" jêzyków programowania.

Ja co prawda niedawno do niej trafi³em, ale chcê siê w niej osiedliæ na sta³e. :-)

A ¿eby¶ wiedzia³, wreszcie ponownie mogê pu¶ciæ wodze wyobra¼ni. Bêdê te¿ w miarê swoich mo¿liwo¶ci "nawraca³" innych, ale o szczegó³ach Ci kiedy¶ napiszê na priv. :-)

E tam, nie ma sprawy. W tzw. miêdzyczasie zmieni³em Quartusa

Pozdrawiam Piotr Wyderski

Ale PLD jest w porownywalnej cenie co najmniejszy Cyclone. No i zawsze masz 1 scalak zamiast 2 czy 3 - policz czas, miejsce na plytce itp.... IMHO wychodzi sztuka dla sztuki. Jedyny problem - jak chcesz duzo ramu do procka w FPGA, to ciasno i trza zewnetrzna kostke dolozyc :-(

No ale przeciez ze zwyklymi prockami jest tak samo. A w przypadku FPGA jest ta zaleta, ze mozna sobie wyklikac interfejs do takiej pamieci, jaka w danym zastosowaniu jest potrzebna (albo sie ma pod reka). Potrzeba zwyklego RAMu statycznego: prosze bardzo. A moze jednak SDR? -- tez nie ma problemu. Z prockami taki numer nie przejdzie. :->

Pozdrawiam Piotr Wyderski

PS. Podlaczales kiedys moze SDRAM do avalonowego DMA tak, by oprócz procka inne urzadzenia mogly "same" pobierac dane z pamieci, np. strumien wizyjny dla LCD?

On Wed, 1 Jun 2005 16:19:12 +0200, "Piotr Wyderski" snipped-for-privacy@ii.uni.wroc.pl> wrote: [.....]

IMO to nie jest tak różowo - raczej musisz poruszać się w obrębie istniejących soft-procesorów. No chyba że zamierzasz od razu robić dla Twojego procesora kompilator języka wysokiego poziomu (czyli C :-) ) i/lub assembler.

Regards, /J.D.

Nie muszê przecie¿ pisaæ ca³ego kompilatora, a jedynie poprawiæ generator kodu. A poniewa¿ coraz powszechniej stosuje siê generatory dzia³aj±ce w oparciu o przepisywanie drzew, ca³e przeniesienie sprowadzi³oby siê do dopisania kilku wzorców do ju¿ istniej±cego zestawu.

A co za problem, przecie¿ to zadanie na jeden dzieñ.

Pozdrawiam Piotr Wyderski