XILINX FPGA Spartan3e - Wydajność Microblaze vs ARM-7 w testach benchmarkowych

witam,

Od pewnego czasu dość intensywnie zajmuję się tematyką FPGA, mam na koncie kilka udanych projektów, ale jak to bywa - szybko zaczyna rosnąć skala i złożoność z każdym kolejnym zleceniem.

"Bawię się" obecnie Spartan3e xc3s1600 - starter kit + microblaze.
(http://direct.xilinx.com/bvdocs/userguides/ug258.pdf)

Na dniach połączę ten układ ze swoim systemem opartym na ARM-7. (połączenie to na razie 16 adresów i 8bit danych).
Jako ciekawostkę mogę powiedzieć, że zrobiłem testy prędkości ARM-7 vs Microblaze.
Microblaze skompilowałem z "pełnym wypasem", tj. cache, FPU itd.
Napisałem prosty benchmark w C, zwykła pętla 1000000 razy, a w niej sinusy, tangensy, dzielenie floatów - totalna sieczka.
Wynik - ARM wykonał program 30 razy (!!) szybciej, mimo, że nie ma FPU, a benchmark opierał się głównie na Floatach.
Oba procki pracowały na takim samym zegarze. próbowałem modyfikować konfigurację microblaze, ale wynik jedynie się pogarszał.
To mnie troszkę wyleczyło z fascynacji soft-procesorami (na jakiś czas )

Mam pytanie, być może ktoś będzie w stanie pomóc:,
na w/w płytce xilinxa jest też 64 MB DDR ram (32Mx16). Microblaze korzystał z niego bez problemu, ale ja chcę podpiąć ją pod ARM'a. Przydałby się tylko bardzo jakiś w miarę dobry i wygodny w użyciu kontroler (VHDL). Na stronie Xilinxa znalazłem "Memory Interface Generator" (IP do CoreGen). Wygenerowałem komponent, ale z tego co widzę, to dość sporo jescze trzeba robić poza nim.
Czy ktoś używał już pamięci DDR w swoich projektach? Będę wdzięczny za każdą pomoc, ew. dobry opis, a może gdzieś można znaleźć jakiś przykład wykorzystania komponentu generowanego przez "MIG'a"?
Idałem było by z jednej strony podpiąć DDR, a z drugiej mieć interface do "normalnej" szyny CPU. Ciekawi mnie też czy istnieje jakiś sposób, by użyć kontrolera, z którego korzysta microblaze?

Zrobiłem dzisiaj prosty komponent w VHDL generujący sygnały VGA. Narazie 640x480 8 kolorów. DDR byłby super jako VideoRAM, w zamian za pomoc mógłbym udostępnić to wraz z jakimiś funkcjami graficznymi w C, które będę pisał

OK, bo "troszkę" przydługi wyszedł ten post Z góry dzięki za pomoc.

znalazłem cieawy komponent na opencores.org do ddr, co prawda na Virtex'a, ale zobaczymy, powinien dać radę

Czesc,

Mozesz powiedziec ktory dokladnie uklad z ARM-7 uzyles?
Przeanalizowales, gdzie jest tak drastyczna roznica w "predkosci" tych dwoch procesorow? FPU w MB byl wlaczony w softwarze? Uzywales tego samego kompilatora GCC? Jak z interfejsem pamieci w tym ARMie? Tzn, z jaka pamiecia on rozmawial i jaka to byla pamiec w przypadku MB.
Czesctotliwosc zegara dla "rdzenia" ARM byla taka sama jak dla MB?

Jak mozesz to napisz cos wiecej, bo roznica jest tak drastyczna, ze az mocno mnie to zainteresowalo. Ja tez robilem benchmarki na swoje potrzeby ale roznica nigdy nie byla 30x. Moze cos w konfiguracji systemu Microblaze bylo nie tak? Moze system spedzal zbyt wiele czasu czekajac na pamiec/peryferale na magistrali?

Jak mozesz to skrobnij cos wiecej na ten temat.

Pozdrawiam,
tony_tg

Hej.

Na dogłębne analizy nie miałem szczerze mówiąc czasu. Jeśli chodzi o MB to też nie mogę powiedzieć, żebym był szczególnie doświadczony.

Zastosowany Arm-7 to LPC2294 @ 60MHz, chodził z wew. flashu, który do wolnych nie należy. Program kompilowany był pod uVision Keil'a. Z tego co wiem, kompilator ten generuje naprawdę wydajny kod.

Co do MB, to używałem środowiska Xililinx Platform Studio 8.1. Procek był wygenerowany z Cache i FPU. chodził na 66MHz. Kompilowałem program na ustawieniach "domyślnych" z tego jednak co widziałem FPU był używany, ponieważ gdy wygenerowałem MB bez FPU różnica w prędkości była jeszcze większa.

Też ciekawi mnie, skąd bierze się tak duża różnica w prędkości. Tak jak mówiłem, dość słabo u mnie z czasem, ale np. zrobiłem prostą pętlę z jednym sinusem, przed sinusem ustawiałem jedną linię i/o na "1" po sinusie na "0". Można było oscyloskopem ładnie zobaczyć czas wykonywania. Nie pamiętam w tej chwili jaka była dokładnie różnica, ale również była spora w porównaniu do ARM-7.

Wina faktycznie może leżeć po stronie dostępu do pamięci, myślę też, że jednak uVision generuje po prostu dużo lepszy kod. (widziałem kiedyś porównanie prędkości programów skompilowanych na ARM-7 pod różnymi kompilatorami, różnice były naprawdę spore, a uVision wypadał b. dobrze)

Na pewno jeszcze usiądę do MB, bo generalnie idea soft-procesora bardzo mi się podoba, możliwość tworzenia własnych rozszerzeń sprzętowych do których taki CPU ma bezpośredni i szybki dostęp jest bardzo "kusząca"

Narazie jednak muszę troszkę podgonić rzeczy, którymi zarabiam na "chlebek"

P.S. Dalej się trochę męczę z tym DDR, coś już niby działa, widać, że dane są zapisywane i odczytywane, ale dane nie są stabilne, sprawia to wrażenie, jakby sporo było błędów przy odczycie... no nic pomęczę się z tym jeszcze pewnie kilka dni


pozdrawiam - sellen



P.S.2 - jeśli byłbyś mocno zainteresowany, to musiałbym poszperać po katalogach, ale pewnie znalazłbym gdzieś ten projekt pod MB

Czesc,

Dalej ciekawi mnie sprawa tego ARM. Moze te 60MHz to byl zegar ktory wchodzil na mnozniki czestotliwosci a wewnetrznie taktowales ARM'a na 200MHz albo cos takiego. Mozna by to sprawdzic w opcjach Keil'a jaki startup code wygenerowali i jak skonfigurowali wewnetrzne zegary.

Jesli chodzi o DDR to jesli tylko uzywasz sprawdzonego core'a np od Xilinx'a to problem prawdopodobnie jest z zegarem. Gdzies Ci sie slizga zbocze i masz za duze clock skew (albo dane slizgaja sie wzgledem zegara). Popatrz sobie na przyklad od Xilinx'a jak oni pakuja wszystko do blokow IO (zatrzaski na wejsciu i wyjsciu z FPGA) i przeanalizuj ich constraint files (*.ucf). Jak zastosujesz to co oni tam robia to powinno byc dobrze. No i to bedzie OK dla plyty od Xilinx'a a jak masz swoja to sprawdz czy dobrze pamieci sa routowane (impedance matched, terminated etc).

Ale ogolnie to walczylem dokladnie z takim samym problemem. Niby dzialalo ale czasami mialem bledne odczyty i problem byl w clock skew tylko u mnie byl na plycie PCB, zle pamiec zroutowana. Przerobka na PCB rozwiazala moje problemy. Nie wiem co jest u Ciebie ale zaczalbym od upewnienia sie ze zegar jest tym czym ma byc.

Pozdrawiam,
tony_tg

Ja uzywalem kiedys ipcora z firmy Nallatech do DDR-u, tam wystarczylo zmienic kwarc 100MHz na inny o lepszy - mial mniej ppmow .

A propos ARM vs MB. Wg mnie nie ma co tu porowynwac, ARM to prawdziwy SoC z wszystkimi featurami dostepnymi w ASIC-ach, z definicji czestotliwosci tam dostepne sa nie do osiagniecia w FPGA .
Zegar 60 MHz ktory wchodzi do tego ARMa to podstawa czasu dla systemu a sam cpu-core chodzi podejrzewam ze 2x lub 4x, PLLka w LPC a DCM w Spartanie to nie ta liga .

No to ja dołączę się do wątku offtopic . Wydaje mi się podejrzane, że MB jest aż tyle wolniejszy - na stronie Xilinxa podają, że jest w stanie wycisnąć ponad 100 DMIPS przy taktowaniu 100 MHz. Rozumiem, że zapewne wszystko podawane jest dla najlepszych warunkach i pisane w języku 'marketese' . Planowałem zastosować MB w swoim projekcie (w sumie to chciałem ich wcisnąć osiem), ale podane przez Was informacje są raczej mało optymistyczne. Czy ktoś korzystał z wbudowanych w Virtexy procesorów PPC? Jak wygląda kwestia szybkości przy zastosowaniu tych procków? Jak 'wygodne' są narzędzia udopstępniane przez Xilinxa (chodzi mi o podłączanie do upchniętej w strukturze logiki)? Czy kompilator generuje 'sensowny' kod (chodzi mi o to samo, co było podawane jako przypuszczalna przyczyna wolnego działania MB w poście powyżej)?

Hmm nawiązując do temetu MB vs ARM, to chyba zrobię ten test jeszcze raz jakoś na dniach, w sumie mam wszystko "pod ręką", a będę przynajmniej mógł podać bliższe szczegóły.

Jesli chodzi o zegar ARM'a to kwarc był 12MHz, po mnożniku x5 -> 60MHz szło na jądro.

Z kolei co do DDR, to męczę się dalej, ale zaczyna mi troszkę "podpadać" IP którego aktualnie używam. Teoretycznie jest fajny, bo sam zajmuje się odświeżaniem itd. Ale z drugiej strony coś mi tu nie gra.
Obniżyłem zegar do 66MHz, oczywiście zmieniłem kofigurację, żeby odświeżanie chodziło z tym samym interwałem. Na tym zegarze w końcu otrzymałem stabilne dane, ale tylko jeśli odczytuję cały czas tą samą komórkę pamięci. Jeśli zmieniam adres co pixel (VGA), to zaczyna się krzaczyć. To już jest dziwne. 66MHz to już nie jest szybki zegar, a sprawdzałem oscyloskopem, pod systemem z MB wygenerowanym z XPS pamięć ta chodzi bez problemu na 133MHz, dokładnie na tej samej płytce.

http://www.opencores.org/projects.cgi/web/ddr_sdr/overview

Może używał ktoś z was tego kontrolera?

Póki co, chyba jednak zmienię projekt i wrzucę kontroler wygenerowany przez "Memory Interface Generator" Xilinx'a. Nie wszystko robi automatycznie, ale mam przeczucie że będzie działał lepiej.



Pozdrawiam - Sellen

Czesc,

Jak masz dobra plytke z chodzacym systemem na 133Mhz to juz polowa sukcesu bo oznacza to tyle, ze nie masz problemow na PCB

Zanim wejdziesz w szczegoly implementacyjne tego kontrolera z opencores, porownaj sobie czy ISE bylo puszczone z takimi samymi opcjami i plikami ucf co Xilinx'a projekt. Zobacz czy wszystkie IO byly poprawnie skonfigurowane (IFF, iostandard, strength etc). Jesli wszystko jest OK to znaczy, ze ten kontroler robic cos inaczej niz Ty myslisz.

Jak zwalniasz czestotliwosc i zaczyna dzialac to raczej nie masz problemu z zegarem a w zasadzie z clock skew tylko z combinatorial delay gdziesz na interfejsie z pamiecia. Zobacz czy te ff sa w blokach IO i porownaj sobie co dostajesz z tym co ISE robi dla projektu Xilinx'a. Mozesz odpalis timing analyzer i przeanalizowac sobie oba design'y definiujac endpoints w ich narzedziu. Interesuje Cie "pad to ff" i "ff to pad".

Jak to jest tak samo w musisz sie wgryzc w kody tego kontrolera i zobaczyc co sie dzieje bo wyglada jakbys zle go kontrolowal. (apropo, wszystko dziala na tej samej czestotliwosci czy pamiec jest na innej i musisz robic resync miedzy zegarami? Moze problem jest tam?)

Pozdrawiam,
tony_tg

Tak tylko w biegu krótko napiszę, bo wyjeżdżam na tydzień. (targi...) Komponent generowany MIG'iem Xilinxa działa ok, narazie odpalam go na 100MHz. Być może ten z OpenCore też jest ok, może ja coś źle robiłem, ale ten działa dobrze bez żadnych "kombinacji"
Muszę teraz popracować trochę z obsługą fifo które buforuje dane dla układu wyświetlającego VGA, ale to jak wrócę.

pozdrawiam - Sellen