Jak zrealizować współdzielony dostęp do RAM dla mikrokontrolera i CPLD/FPGA?

Cześć,

Mam w planach zrobienie sobie pewnego urządzenia, które cośtam będzie sobie robiło (zaczyna się ciekawie ). Będzie ono początkowo wykorzystywało monitor do wyświetlania grafiki.

Do wyświetlania grafiki będzie wykorzystany układ CPLD lub jakieś małe FPGA + oczywiście monitor. Generować będzie ją mikrokontroler.
Sam przesył danych uC->CPLD->monitor chciałem rozwiązać jako współdzielony bufor, mikrokontroler będzie w postaci tablicy pikseli wysyłał obraz do zewnętrznego RAMU a CPLD będzie z tego ramu tylko czytał i posyłał kolory w monitor. Tu mnie zastanawia jak rozwiązać kwestię dostępu tych dwóch układów do wspólnej pamięci bo dla mnie wydaje się to dość problematyczne (ze względu na współdzielenie wszystkiego, i bitów adresowych i danych i kontrolnych).

Rozwiązań do głowy przychodzi mi parę, ale wydają się one nie mieć sensu:

1. Zapis i odczyt zrealizować przez CPLD, a z mikrokontrolera wysyłać obrazy po jakimś SPI czy czymśtam innym do CPLD w celu ich zapisania. Wszystko musiałoby chodzić trochę szybciej niż było to w zamierzeniu, poza tym rozwiązanie jest o tyle bez sensu, że nie mogę sobie użyć bufora jako zwykłej tablicy. Można to z kolei rozwiązać tak, że do CPLD wepniemy wszystkie linie adresowe + danych z mikrokontrolera ale wymaga to większego CPLD (z racji liczby pinów) no i staje się to jeszcze bardziej absurdalne

2. Pociągnąć dwie linie z uC do CPLD żeby zsynchronizować odczyt/zapis.

3. Zmodyfikowana wersja pkt 1 - czyli dodanie jeszcze jednego CPLD który będzie tylko do czytania/zapisu pamięci ale i to wprowadza trochę zamieszania

Jak ogólnie rozwiązać taki problem ? Być może sama idea zapisania/czytania przez dwa różne układu jest bez sensu i robi się to inaczej ? W sieci ciężko szukać info bo same migania diodą i wyświetlacze 7mio segmentowe

Link

A pamięć musi być bezpośrednio adresowana z CPU? Jeśli tak, to puścić ją z prędkością dwukrotnie większą niż CPU i FPGA (tu pojawia się pewien problem, bo żeby wszystko działało synchronicznie CPU musi być taktowane wielokrotnością DOTCLOCK), wtedy łatwo można zrobić naprzemienny dostęp do pamięci - w jednym takcie CPU w kolejnym FPGA itd.
Albo prościej, zrealizować dostęp do pamięci przez FPGA. Robisz np. w FPGA rejestr adresowy początku i potem sobie w trybie burst ładujesz kolejne dane tylko z auto inkrementacja/dekrementacją, a jak starczy bramek to można sobie zdefiniować prostokątne okno w pamięci i operacje bitblokowe będą działać pięknie. Zaleta - CPU łączysz z FPGA tylko paroma liniami, nie ma potrzeba realizować pełny interfejs pamięci, wada - pamięć nie jest dostępna bezpośrednio w przestrzeni adresowej procesora. Swoją drogą to czy do tak prostego wyświetlania nie lepiej zaprząc jakiś gotowy kontroler obrazu?
BTW, są też pamięci dwuportowe, odrzucasz je apriori?

tmf napisał:

BTW, są też pamięci dwuportowe, odrzucasz je apriori?

Powodzenia w zakupie (;

4\/3!!

mmm777 napisał:

Link

In production, więc za pół roku spróbuję wejść w tego linka drugi raz.

tmf napisał:

BTW, są też pamięci dwuportowe, odrzucasz je apriori?

Tylko że ja potrzebuję góra 3 sztuki i raczej sprowadzanie miliona sztuk z plutona nie wchodzi w grę Nie ma stutysięcznej produkcji tak więc mimo bogactwa układowego producentów nie wszystko mogę kupić.

tmf napisał:

A pamięć musi być bezpośrednio adresowana z CPU? Jeśli tak, to puścić ją z prędkością dwukrotnie większą niż CPU i FPGA (tu pojawia się pewien problem, bo żeby wszystko działało synchronicznie CPU musi być taktowane wielokrotnością DOTCLOCK), wtedy łatwo można zrobić naprzemienny dostęp do pamięci - w jednym takcie CPU w kolejnym FPGA itd.

Właśnie chciałem uniknąć przyspieszania zegarów. Pamięć dobrze jakby była adresowana bezpośrednio z CPU, bo jak mam zmarnować dodatkowy czas przez procesor na jej zapisanie, to równie dobrzę mogę posyłać dane po SPI do CPLD (albo w ogóle pominąć CPLD) i nie bawić się w zewnętrzne pamięci.

tmf napisał:

Swoją drogą to czy do tak prostego wyświetlania nie lepiej zaprząc jakiś gotowy kontroler obrazu?
BTW, są też pamięci dwuportowe, odrzucasz je apriori?

A są jakieś do generowania obrazu VGA ? Są jakieś kontrolery 8080 6800 etc ale do VGA nie widziałem nic takiego. Po FSMC chyba się nie da obsłużyć monitora?

A czemu w ogóle tak? Bo chciałem wepchać obraz do RAMu jak do zwykłej tablicy i nie przejmować się jego wyświetlaniem. Mogę też zrobić tak, że zewnętrzny RAM użyję jako bufora, ale będzie on obsługiwany jedynie przez uC, który po DMA z odpowiednią częstotliwością będzie jednocześnie wysyłał dane do FPGA.

Robisz na ARMie? To łatwo programowo z użyciem DMA i małego rejestru FIFO można to uzyskać bez znacznego obciążenia procesora. Na XMEGA zrobiłem bez problemu 320*480*256kol, z minimalnym obciążeniem procesora, to na ARM to powinna być bajka. W każdym razie prościej i taniej niż zewnętrzne FPGA.

A dużo fps-ów potrzebujesz? Kiedyś robiłem coś takiego dla ARM9 + mały Spartan Xilinxa. ARM i FPGA podpięte po magistrali równoległej, a SRAM tylko do FPGA. Generator sygnału VGA i obsługa SRAM za dużo nie zajmowały. W FPGA mały Block RAM który "magazynował" piksele z ARMa do RAMu a zapisywane były w momencie czasu powrotu VGA. Demonem szybkości to to nie było ale dla terminala i prostej grafiki wystarczające ;]

tmf napisał:

Robisz na ARMie? To łatwo programowo z użyciem DMA i małego rejestru FIFO można to uzyskać bez znacznego obciążenia procesora. Na XMEGA zrobiłem bez problemu 320*480*256kol, z minimalnym obciążeniem procesora, to na ARM to powinna być bajka. W każdym razie prościej i taniej niż zewnętrzne FPGA.

Bardziej celowałem w CPLD, który też da radę i koszuje 5zł.
Tak, na ARMie, ewentualnie jakiś procesor DSP. Wiem, że można bez, ale właśnie zależało mi na tym CPLD z racji odseparowania się od warstwy graficznej wykonawczej. Robię zapis monitor[240] = 120 i nie obchodzi mnie co się z tym dalej stanie.

Co do szybkości to minimum to 640x480x60Hz. Nie jest to też jakoś bardzo dużo.

No właśnie, ten tryb wymaga DOTCLOCK koło 25 MHz jak pamiętam, więc dla 256 kolorów musisz wyrzucać bajty co około 40 ns, to spokojnie da się zrobić procesorem. CPLD za 5zł umożliwi ci co najwyżej realizację liczników i generowanie adresu do pamięci, ale z interfejsem procesora będą cyrki, więc niewiele zyskasz, bo to samo zrobi sam procesor. Ja bym CPLD wykorzystał co najwyżej jako FIFO + ew. multipleksery jeśli wykorzystasz tryb 16-kolorowy, co zmniejszy ci dwukrotnie transfer danych. A z tym to już 8-bitowa XMEGA daje radę, więc ARM tym bardziej. IMHO nie ma co kombinować, bo spędzisz dni nad projektem, który można zrealizować w parę godzin.

Takie (25MHz) proponują, jednak nie mam bladego pojęcia skąd ta wartość. Powinno być 18,432 MHz i są nawet takie kwarce.

Cały układ miał być zrobiony w ramach poszerzania horyzontów o FPGA/DSP ale coś innego w takim razie wykombinuję Dzięki za odpowiedzi, tematu nie zamykam, gdyby ktoś wymyślił jakieś ultra rozwiązanie.

Pewnie z timingów VGA te 25 MHz http://greenbird.tweakblogs.net/blog/3446/vga-timing.html

edit:
Tu masz dokładniej rozpisane: http://martin.hinner.info/vga/timing.html . Te 25 MHz to jest zaokrąglone. Mi się zdarzyło że na 1 na prawie 10 monitorów nie złapałem synchronizacji ;]

DOTCLOCK wynosi 25 MHz ze względu na czasy front i back porch, tylko część linii to informacja o pikselach, w efekcie pozioma rozdzielczość w przeliczeniu na czas trwania linii to o ile pamiętam 800 lub nawet 880 pikseli, z czego tylko 640 jest widocznych.

Może to:
http://pl.farnell.com/integrated-device-techn...sram-port-podwojny-16k-2kx8-plcc52/dp/1688283
albo coś podobnego ze stajni IDT.

janbernat napisał:

Może to:
http://pl.farnell.com/integrated-device-techn...sram-port-podwojny-16k-2kx8-plcc52/dp/1688283
albo coś podobnego ze stajni IDT.

Łoj, ta pamięć ma 2 kB Chcesz nam kolegę gaskoin'a puścić z torbami

No i na 1 MHz to za wiele sobie nie powyświetlam

Raptem 150 takich układów potrzeba. Jak masz duży pokój i około 10k na części to można się bawić ;]

Mały offtopic:
Nie wiedziałem, że są pamięci dual port do kupienia ale z tego co janbernat podesłał to wynika że lepiej sobie FPGA położyć i w nim zaimplementować dual port RAM

gaskoin napisał:

No i na 1 MHz to za wiele sobie nie powyświetlam

To chyba jakiś błąd, bo wcześniej piszą czas dostępu 20ns Gdyby to był SDRAM to bym pomyślał, że może ma CL=50 ;P

Na FPGA dużo rzeczy się bardziej opłaca. Najmniejsze FPGA nie są jakieś mega drogie i często zrobienie tam jakiegoś układu prostych bramek jest dużo tańsze niż kupno 15 scalaków

Z resztą w pierwszym poście napisałem o takim pomyśle, żeby dołożyć jeszcze jeden układ, który tylko będzie pośredniczył pomiędzy pozostałymi dwoma jako bufor do zapisu i odczytu.

tmf napisał:

gaskoin napisał:

No i na 1 MHz to za wiele sobie nie powyświetlam

To chyba jakiś błąd, bo wcześniej piszą czas dostępu 20ns Gdyby to był SDRAM to bym pomyślał, że może ma CL=50 ;P

Możliwe, że to zegar też czegoś innego bo w filtrach też jest częstotliwość taktowania i czas dostępu osobno.

Mam Spartan-3 starter kit i tam jest jako demo wgrany sterownik VGA który cośtam jeszcze robi. Warto podpatrzyć jak to rozwiązali, może ci się coś nasunie.

Zbyt tanie?
To może to:
http://pl.farnell.com/integrated-device-techn...g/sram-dual-port-2kx16-7133-tube18/dp/1661746
Parę lat temu szukałem takiej pamięci dwuportowej FIFO asynchronicznej.
Znalazłem to tylko w Cypress w jakiejś kosmicznej cenie i z zakupem 1k szt.
Sam nie wiem kto to kupuje i do czego.
Niby pożyteczne- sprzętowo można dopasować transmisję.
Ale te ceny i dostępność...

O to moje dywagacje teoretyczne.


Taktujemy CPLD na 100 MHz. Pamięć o dostępie mniejszym niż 10 ns. W jednym cyklu następuje odczyta i później zatrzask, dostajemy 3 cykle na różne działania w tle. Zapis i odczyt można zrobić w dwóch cyklach. Prosty rejestr po SPI + FSM do ładowania adresu i danych. Linie statusu można na zasadzie IRQ, że coś się stało, np pusty bufor.

8 bit na RGB to zwykłe rezystorki.
Adresowanie i generacja synchronizacji są na tych samych licznikach.

Z 100MHz łatwo zejść do 25MHz.

Witam!
1) A jakiś uC kontrolerem LCD, np AT91SAM9263 albo AT91sam9G45? Odpada dużo pracy sprzętowej. Mogę pomóc w uruchomieniu projektów dla ww. kontrolerów

Rozwiązanie z SPI jest o tyle fajne, bo zawsze będzie wolniejsze od transmisji równoległej dla typowego uC. Więc nie potrzeby nawet sprawdzać czy bufor jest pusty czy nie. Trzeba tylko co piksel zapewnić działania w tle, w tedy uzyskamy najlepszy framerate dla rozdzielczości oraz będzie pchać z taką prędkością dane ile magistrala/DMA/SPI fabryka dała

Tutaj bym się zwrócił ku układom MachXO (Lattice), które mają dużo większe zasoby przy relatywnie małej cenie w przeciwieństwie do układów konkurencji (Xilinx/Altera). Spokojnie można zaimplementować większą FSM do poprawnej tranzycji danych. I pchać to burst'em. I tutaj nie robi nas uC czy nawet częstotliwość taktowania, bo rejestr SIPO załatwi poprawną wymianę między różnymi domenami zegarowymi.

Drugie rozwiązanie polegało by na wykorzystaniu kontrolera pamięci razem z pinem WAIT. Tutaj można wykorzystać małe CPLD do tej robi, i mieć pełnoprawny dostęp do pamięci do zapisu, ale także odczytu (po małej przeróbce). Rysunek dopowie resztę

Takie elementy latch/tri-state można dostać za 0.5 zł, generator 10 zł, cpld zależy jakie, troszkę zabulimy za pamięci, które i tak by potrzeba by było jakoś nabyć. Można zbudować przyzwoite ustrojstwo do VGA/RGB/TFT bez dużych kosztów

Plan jest iście szatański, FSMC zapisuje w ciemno, CPLD to wykrywa i robi zatrzask i ustawia WAIT. Tamten grzecznie czeka, w tym samym czasie CPLD trzyma kolory zatrzaskiem, żeby nie pojawiły się artefakty podczas zapisu. Pędzany z prędkością 100Mhz - 150MHz ma dużo czasu żeby zrobić zwolnić tri-state nie puszczając zatrzasku i zapisać do pamięci w tle ! I po operacji zwalnia WAIT I tak w kółko... bez żadnej kolizji. Pełny framerate i nie tylko do VGA Według moich obliczeń, skomplikowanych piętrami całek, nie wymaga to dużego CPLD. Taki 64/72 pociągnie zadanie. Jakby co, mogę pomóc wycisnąć więcej makrocelli niż jest faktycznie w układzie

Rozwiązanie dobre, nie pomyślałem, że można wstrzymać uC waitem

No to parę pytań:

- Nie można użyć latch z CPLD? potrzeba ich dość sporo ale i tak najmniejsze CPLD Lattice'a jakie znalazłem ma 78 IO
- generator chyba zbędny, ponieważ mamy wewnętrzne PLL ?
- CPLD iście kozackie nie powiem ale czy trzeba znowu budować jakiś shit do programowania na LPT czy jest coś lepszego dostępnego ? Ew pewnie jakikolwiek JTAG + SVF
- Czemu akurat 16bit kolor ? Akurat 16 bit mają cenę z kosmosu. W zakładanym czasie dostępu 1 kość pamięci kosztuje ponad 100zł. Coś tańszego i bardziej sensownego można dostać za 23zł tyle, że 512kx8.

tymon_x napisał:

Takie elementy latch/tri-state można dostać za 0.5 zł, generator 10 zł, cpld zależy jakie, troszkę zabulimy za pamięci, które i tak by potrzeba by było jakoś nabyć. Można zbudować przyzwoite ustrojstwo do VGA/RGB/TFT bez dużych kosztów

Tylko to wszystko się narasta Pamięci 50zł, CPLD 20 zł, generator 10zł STM kolejne 20:D

gaskoin napisał:

No to parę pytań:

- Nie można użyć latch z CPLD? potrzeba ich dość sporo ale i tak najmniejsze CPLD Lattice'a jakie znalazłem ma 78 IO
- generator chyba zbędny, ponieważ mamy wewnętrzne PLL ?
- CPLD iście kozackie nie powiem ale czy trzeba znowu budować jakiś shit do programowania na LPT czy jest coś lepszego dostępnego ? Ew pewnie jakikolwiek JTAG + SVF
- Czemu akurat 16bit kolor ? Akurat 16 bit mają cenę z kosmosu. W zakładanym czasie dostępu 1 kość pamięci kosztuje ponad 100zł. Coś tańszego i bardziej sensownego można dostać za 23zł tyle, że 512kx8.

- nie ma przeszkód, zazwyczaj wyjścia też Swoje ujmują w zasobach, trudniej jest o "pożyczenie" makrocella obok (u Xilinx coś takiego jest), a takie zatrzaski nie są drogie.
- za to lubię Lattice, ich CPLD są takie jakie powinny być, a MachXO2 to już w ogóle bajka
- nie mam pojęcia, SVF to standard przemysłowy, więc nie powinno być większego problemu, ale nie mam doświadczenia w tej materii
- jak szaleć, to konkretnie Dobra, poniosło mnie troszkę Można "uciąć" obraz i dać 2 x 256k x 8bit.

AN8082 - USB Programming and Circuit Guide
FTDI FT2232D bridge between USB and JTAG