FPGA/spartan3s200 - Przyśpieszenie pracy FPGA - kontroler SDRAM

Witam, mam taki problem.
Muszę podnieść taktowanie FPGA do 200MHz dla juz zbudowanego urządzenia i zaprogramowanego. Niestety urządzenie nie startuje po podaniu mu 200MHz.
Chcę się upewnić czy moze istnieć lub nie jakiś dodatkowy czynniki np cos w rodzaju fuse bitów które trzeba zmienić w przypadku zmiany częstotliwości.

Jeśli nie wtedy sprawa będzie jasna i będe musiał modyfikować program.
Tak więc moje pytanie jest takie:
czy wraz ze zmianą czestotliwość sparatana 3s200 ze 100MHz na 200MHz trzeba coś przekonfigurować aby program działał tak samo tylko dwa razy szybciej?

Witaj,

Pierwsze pytanie na logikę - czy podkręciłbyś z sukcesem procek w kompie na 200%?

Ogólnie na działanie układu FPGA mają wpływ różne czynniki:

1. Budowa układu i sygnały zegarowe - każdy FPGA czy CPLD ma swoje ograniczenia czasowe - tj. propagacje czasu przez połączenia między blokami funkcyjnymi, blokami I/O itp. To ograniczenie sprzętowe i tego nie ominiemy.

Oczywiście są specjalne piny i magistrale przystosowane do sygnałów zegarowych, ale o to powinien zadbać piszący program, a środowisko powinno "krzyczeć" jeśli sygnał zegarowy pobiegnie inną trasą.

2. Sposób syntezy układu - w procesie od języka opisu sprzętu do konfiguracji używanej przez układ mogą zostać przyjęte różne strategie wykorzystania zasobów sprzętowych - zwykle to ustawiamy w opcjach syntezy a do wyboru mamy np. optymalizacje pod względem poboru energii, pod względem prędkości działania czy w końcu szybkości syntezy. (Tu sytuacja mojego kolegi - robił układ, który miał działać przy częstotliwościach blisko granic technicznych układu FPGA - po syntezie "szybkiej" projekt nie działał - dopiero synteza z optymalizacją zależności czasowych dała oczekiwane efekty)

3. Sam sposób działania układu (czyli jakość opisu w języku opisu sprzętu) - czasem tę samą kwestię możemy rozwiązać różnymi sposobami )

Ufam że PCB jest wykonane dobrze. Na tym etapie bardziej prawdopodobne jest że program ma pewien błąd lub nie wiem co przekonfigurować aby spartan działał przy większej częstotliwości.

No to może Kolega podzieli się z nami projektem płytki i kodem sprawiającym problemy?

Bo jak na razie ufając osadowi w moim kakao stwierdzam, że to pewnie przez element U279 na Twojej płytce, który został w fabryce źle skalibrowany przez ósmego krasnoludka

Nie jest dla mnie jasna jedna rzecz - czy chodzi tu o zwiększenie częstotliwości zewnętrznego źródła sygnału zegarowego (rezonatora)?
Jeśli o to chodzi, to byłoby dla mnie zaskakujące, jeśli przy relatywnie sporej zmianie ze 100 MHz do 200 MHz zaprogramowany układ działałby nadal poprawnie. Generalnie jest tak jak napisał kolega piotrva. Jeśli jest to sensowny projekt, to posiada timing constraints (nie wiem niestety jak się to tłumaczy na polski) i informacja o częstotliwości zegara taktującego logikę jest używana do optymalizacji struktury logicznej na etapie implementacji. Jeśli zwiększysz w ten sposób częstotliwość bez zmiany konfiguracji FPGA, to może okazać się, że przy zwiększonej szybkości zegara układ logiczny skonfigurowany wewnątrz nie jest wystarczająco szybki, co nie znaczy jednak, że po rekonfiguracji nie będzie działał wystarczająco szybko.

Tak, chodzi o zwiększenie częstotliwości generatora taktującego FPGA.
Jednak już widzę że to nie jest potrzebne.

Poniżej zamieszczam blokowy schemat urządzenia


Celem jest zwiększenie przetwarzania ADC z 20MHz na 50MHz
Procek ARM nie jest w stanie na bierząco współpracować z przetwornikiem ADC dlatego też zastosowano FPGA i pamięć SDRAM.
Można było wybrać lepszego spartana z obsługą SDRAM - cóż nic już z tym nie zrobimy. Zmiana generatora taktującego ze 100MHz na 200MHz skutkuje tym że od strony ARM'a program zatrzymuje się w miejscu oczekiwania na dane z FPGA.
FPGA pewnie czeka na SDRAM który niestety pracuje z max 133MHz.
Inne problemy z optyamizacją i parametrami ograniczeń czasowych też są zapewne możliwe.


PARAMETRY SDRAM
http://www.micron.com/parts/dram/sdram/mt48lc4m16a2b4-7e


Obsługa SDRAM jest w 100% oparta na projekcie:
http://hamsterworks.co.nz/mediawiki/index.php/Simple_SDRAM_Controller

Kazdy zapis/transakcja do SDRAM to 16cykli w czasie których zapisywane są 4bajty. Przy 100MHz daje to prędkosć zapisu 25MB/s.
Ja muszę zrobić to tak aby ta prędkość wynosiła 50MB/s lub więcej.

bartosz.tarnowski napisał:

Obsługa SDRAM jest w 100% oparta na projekcie:
http://hamsterworks.co.nz/mediawiki/index.php/Simple_SDRAM_Controller

Kazdy zapis/transakcja do SDRAM to 16cykli w czasie których zapisywane są 4bajty. Przy 100MHz daje to prędkosć zapisu 25MB/s.
Ja muszę zrobić to tak aby ta prędkość wynosiła 50MB/s lub więcej.

Po prostu masz koszmarnie kiepski kontroler SDRAM... Zastosuj jakiś z FIFO, albo dopisz do obecnego kontrolera tryb burst przy zapisie. Wówczas zamiast jednego zapisu na 16 cykli uzyskasz np. 4 zapisy na 19, co wystarczy do zapisania danych z ADC.

Taktowanie tego FPGA na 200 MHz to raczej ciężka sprawa.

Pozdr,
TW

Dodaję częśc kodu w VHDL
Analizować go trzeba rozpoczynając od lini:

case state is

Wtedy widzimy że jest:
1 stan startup
10 stanow idle
2 stany open
4 stany read
3 stany write
1 stan precharge

Intuicyjnie rozumieim że każdy stan jest wykonywany w kolejnych cyklach ze tak powiem żargoenm mikrokontrolerowców co obieg pętli
Z VHDL zaczałem prace tydzień temu.

Gdzie pogrzebać w tym kodzie aby przyspieszyć zapis do pamięci?
Dodam że kod ten działa tak za zapisuje po 4bajty do pamieci i za kazdym razem musi zainicjalizować zapis.

bartosz.tarnowski napisał:

Intuicyjnie rozumieim że każdy stan jest wykonywany w kolejnych cyklach ze tak powiem żargoenm mikrokontrolerowców co obieg pętli
Z VHDL zaczałem prace tydzień temu.

To całkiem ambitny projekt, jak na tydzień doświadczenia

Cytat:

Gdzie pogrzebać w tym kodzie aby przyspieszyć zapis do pamięci?
Dodam że kod ten działa tak za zapisuje po 4bajty do pamieci i za kazdym razem musi zainicjalizować zapis.

- zmienić burst length w rejestrze konfiguracyjnym SDRAM z 2 na 8
- zapisywać/odczytywać po 8 bajtów (czyli data_in/out z 32 bitów na 128) i dodać dodatkowe stany s_read i s_write.

Przykład (kompiluje się, ale nie testowałem):



Pozdr,
TW

Dzięki za pomoc TWI.
Rozpracowuję ten kod wraz z pozostałymi komponentami z którymi on współpracuje. Mam już zarys całości a po przenalizowaniu DataSheet Microna orientuje się też w działaniu SDRAM.

Mam zpytanie o kilka linijek, chodzi o odczyt z pamięci.
Mamy w kodzie następujące instrukcje ale nie następujące po sobie, pochodzą z róznych częsci pliku:



I mam pytanie jaki ma sens tego że data_out ma 32bity skoro dane trafiające do data_out są zdublowane ponieważ captured_data_last i captured_data to to samo, nic to nie wnosi, wydaje mi się że można to usunąć tzn zredukować data_out do 16bitów. I tak później inny komponent w kodzie nad którym pracuję wykorzystuje tylko 12 bitów z linii data_out bo przetwornik ADC którego dane są magazynowane w SDRAM ma 12bit rozdzielczosci

(piszę o starej wersji, ponieważ w odniesieniu do niej chcę zrozumieć co muszę też zmienić w komponentach współpracujących z kontrolerem SDRAM, w Twojej wersji captured_data_last ma 112 bitów a data_out 128 bitów)

Dodano po 2 [godziny] 36 [minuty]:

Uważam że kod pochodzący z projektu
http://hamsterworks.co.nz/mediawiki/index.php/Simple_SDRAM_Controller

ma poważny błąd którym jest taka sama długość wektorów captured_data_last i captured_data, a poniższy fragment kodu nie zapewnia gromadzenia danych odczytywanych w kolejnych burst_read, co skutkuje ze na zewnątrz komponentu SDRAM uzyskujemy w rzeczywistości dostęp do 32bitowej danej złożonej z dwóch 16bitowych identycznych danych z drugiego odczytu z RAM'u.
W efekcie kontroler ten czyta po kolei dane z ramu ale udostęnia na zewnątrz co drugą odczytaną komórkę pamięci RAM.

bartosz.tarnowski napisał:

I mam pytanie jaki ma sens tego że data_out ma 32bity skoro dane trafiające do data_out są zdublowane ponieważ captured_data_last i captured_data to to samo, nic to nie wnosi,

VHDL nie działa tak jak C czy inny język programowania. Przypisania w procesie synchronicznym dzieją się równocześnie, a nie sekwencyjnie. To znaczy, że
captured_data_last i data_out są przypisane w tym samym momencie, tak jakby wszystkie linie procesu wykonywały się jednocześnie.

captured_data_last w związku z tym ma wartość z poprzedniego cyklu zegara w momencie, gdy jest zapisywany (wraz z captured_data) do data_out.

BTW. Symulowałeś ten kontroler?

Cytat:

wydaje mi się że można to usunąć tzn zredukować data_out do 16bitów. I tak później inny komponent w kodzie nad którym pracuję wykorzystuje tylko 12 bitów z linii data_out bo przetwornik ADC którego dane są magazynowane w SDRAM ma 12bit rozdzielczosci.

Można, jak najbardziej.

Pozdr,
TWl

Niestety nie symulowałem, musiałbym zasymulować komunikację FPGA - ARM oraz FPGA - ADC. Od nowa stworzyć osobny projekt i go dostoswać do symulacji.

Rozumiem że to działa nie synchronicznie.
Dylematem dla mnie jest poniższy fragment



skoro spełniony jest warunek data_ready_delay(0) = '1'
to następuje przepisanie z poprzedniego cyklu zegarowego


Ale jednocześnie realizowane jest

oraz przepisanie z wejść komponentu do sygnału

myslę że przez moment na wyjściu data_out pojawi się captured_data & captured_data_last z poprzedniego cyklu a następnie w ciągu powiedzmy 0.2 ns pojawi się dwa identyczne wektory captured_data & captured_data.

Bo zachodzi pytanie przez jak długi czas z racji poniższej lini sygnały captured_data_last oraz captured_data są różne od siebie, zawsze pod koniec cyklu zegara na pewno są one identyczne.


Chyba że nie wiem czegoś związanego z ustawieniami USER CONSTRAINTS zawierającymi TIMING CONSTRAINTS, a jak na dziś to niewiele wiem.

Tak wygląda moje Design Summary

Super, tego wyjaśnienia właśnie potrzebowałem

Dostosowałem kod według tego co podał TWI,
Przeszło Syntezę, Implementację i wygenerowało plik .bit do zaprogramowania.
Niestety programowanie kończy się niepowodzeniem.
Poprzednia wersja bez wprowadzonych zmian programuje się poprawnie.

Z racji poszerzenia zmiennych:
data_out do dłlugosci 128
captured_data_last do długości 112
oraz niektórych innych

Otrzymuję ostrzeżenia o niepodłączonych wyprowadzeniach
data_out w zakresie od 32 do 127 czyli tylko w tym co poszerzyłem

dotyczy to też innych sygnałów



Czy to może być powododem problemów z programowaniem?

Dodano po 14 [minuty]:

Bardzo dziwnie działa te ISE

wszystko podpięte jak trzeba a on śleby jak but.
Czepia się pliku akwizycja że dane_do_ramu mają stałą wartość 0
a tymczasem jak widać na obrazku są przypisane do nich sygnały z ADC



Co jest nie tak?

W końcu udało się uruchomić i wrzucić do FPGA program,
i urządzenie działa normalnie jak poprzednio ale już z modyfikoacjami według propozycji TWI.

Problemem było wykomentowanie nie używanego innego komponentu.
Nie rozumiem tego ale tak samo reaguje poprzednia wersja którą właśnie rozwijam, że jak usunę nie używany komponent to przechodzi wszystkie procesy generuje plik wyjsciowy pozytywnie ale programowanie daje rezultat FAILED.

Nie w nikam w to już.
Teraz muszę sprawdzić czy faktycznie zapis i odczyt SDRAMU przyśpieszył.
Podłączyłem się oscyloskopem przez kynar do lini DQ0 ale nie mogę zarejestrować czegoś co by mnie upewniało że teraz zapis zasuwa przynajmnie 50MB/s
Widzę cześtotliwość 1,25 MHz a nie 25MHz

Nie pasował mi kawałek kodu zaproponowany przez TWI
a dokładnie:



zamiast tego dałem

Kolejny problem.....

zmodyfikowałem troszke kod, (odczyt i zapis działa na 100MHz w trybie burst x8), zlikwidowałem jeden z procesów który służył tylko za odczyt/przechwytywanie danych z magistrali danych w czasie odczytu z SDRAM

Poniżej w procesie do długiego wektora captured_data_last wpisywane są dane z RAMu za pośrednictwem sdram_din. Zawartośc odczytana z sdram_din jest poprawna zweryfikowana na 100%. Zaczynają się dziać czary w captured_data_last a jeszcze większe gdy captured_data_last ma być przesłane do data_out czyli na wyjście komponentu.

bit0_test do bit6_test to sygnały wyprowadzone na analizator stanów logicznych.
Obserwuję 7bitów
I teraz tak na ten moment nie ma znaczenia czy obserwuję:

sdram_din(7 do 0) lub captured_data_last(7 do 0 ) lub captured_data_last(23 do 16) lub captured_data_last(39 do 32 ) lub captured_data_last(55 do 48 ) lub captured_data_last(71 do 64) lub captured_data_last(87 do 80) lub captured_data_last(103 do 96) lub captured_data_last(119 do 112)

odczytuję identyczne liczby w identycznym porządku i ten identyczny porządek tu nie jest logiczny czyli 1,3,5,7,9,11,13,15 (takich liczb używam)

Natomiast dla starszej częsci słowa obserwuję

sdram_din(15 do 8) lub captured_data_last(15 do 8 ) lub captured_data_last(31 do 24) lub captured_data_last(47 do 40 ) lub captured_data_last(63 do 56 ) lub captured_data_last(79 do 72) lub captured_data_last(95 do 88) lub captured_data_last(111 do 104) lub captured_data_last(127 do 119)

i za każdym raze m odczytuję 2,4,6,8,10,12,14,16

Do pamięci wpisywane są następujce liczby zapisane w kolejnych bajtach:
1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16.

Liczby się zgadzają przy odczycie ale kolejność odczytanych danych jest nienaturalnie zawsze identyczna.
Zmiejszenie częstotliwości taktowanie o połowę nie daje rezultatów