Problemy z implementacją w CPLD

Witam

Realizuje dość duży projekt na CPLD CoolRunner2 Xilinxa w VHDLu. Całość działa na 50 MHz. Układ został zaprojektowany przy pomocy behavioral simulator przed zaprojektowaniem i zamówieniem pcb. Pomijając standardowe, wstępne trudności można powiedzieć, że układ od razu działał dobrze. Jednak po zmianie Optimization goal z Area na Speed sygnały wyjściowe były bardzo przekłamane, a maszyna stanu nie przechodziła pełnego cyklu. Podobnie, ale nie identycznie, działo się, gdy zmieniałem Optimization effort z normal na high lub FSM Encoding Algorithm z compact na Gray lub hot-one. Po poprawieniu fragmentu kodu, który myślałem, że może sprawiać problemy jest dużo lepiej. Teraz tylko zmiana FSM Encoding Algorithm na hot-one powoduje problemy (na razie nie określiłem, w którym miejscu i dlaczego).

Skąd biorą się takie problemy, jak szukać ich przyczyn i najważniejsze - jak pisać, żeby one nie występowały?

Można by powiedzieć "zostań przy konfiguracji, która działa", ale te problemy prawie na pewno są wynikiem hazardów sygnałów wewnętrznych CPLD i zostawienie tego, tak jak jest byłoby ryzykowne, a już na pewno nie eleganckie.

pozdrawiam sludig

Reply to
Sludig
Loading thread data ...

Czy zachowanie jest takie same na plytce _i_ w symulatorze?

Te same pytanie: Czy zachowanie jest takie same na plytce _i_ w symulatorze (symulator na poziomie bramek, nie vhdl!)?

Reply to
Jerry1111

Sludig pisze:

Witam,

Jezeli to nie tajne to daj zrodla na grupie - > bedzie mozna cos wiecej powiedziec. Prawdopodobnie problemem jest :

- brak synchronizacji sygnałów we wzgledem zegara automatu

- wymieszanie logiki async z sync

- dzielenie zegarów

- brak syncronizacj sygnałów zew.

a moze jeszcz kilka innych a moze nie :)

Adam

Reply to
Adam Górski

Nie udało mi się uruchomić jeszcze symulacji post-fix. Wyskakują jakieś errory i nie mam póki co czasu z nimi powalczyć.

Ta sama odpowiedź. Chyba faktycznie bede musiał się zabrać za tą symulację post implementacyjną.

A jeżeli wyjdą/ nie wyjdą jakieś błędy to co wtedy zrobić? jak wyeliminować potencjalne hazardy?

pozdrawiam

Reply to
Sludig

Niestety nie mogę, projekt komercyjny, szef by mnie zabił ;) Poza tym kod jest dosyć długi.

sygnały wejściowe zmieniaja się na zboczu narastającym zegara, a FSM zmienia stan na zboczu opadającym. Jest to wygodne bo łatwo udało mi się zrobić zapis do SRAMu.

większość układów jest taktowana z tego samego zegara, ale niektóre mają rozbudowane warunki clockEnable. Tylko moduł UART ma inny zegar.

UART ma własny zegar z drugiego wejścia zegarowego i on jest dzielony na 16.

to jest niemożliwe. Tylko, że te sygnały pięknie nie wyglądają. Spore over i under shooty. I poziom masy tak jakby się skokami zmienia od, ale to chyba mnie oscyloskop okłamuje.

pozdrawiam

Reply to
Sludig

Sludig pisze:

Napisz jeszcze jaka częstotliwość zegara. Nie jest zalecane mieszanie układów sync. działając na różnych zboczach.

Rozbudowane warunki clockEnable raczej nie szkodzą. No w sumie zależy jak rozbudowane :)

To powinno tez byc robione przez ClockEnable co 16 cykl

Co jest niemożliwe ? Tak overshoot i undershoot czesto pochodzą od oscyloskopu choć nie zawsze ( mam na mysli doprowadzenia)

Nie znam Twojego układu ale wyobraź sobie że jeżeli sygnał zew nie jest synchronizowany z zegarem automatu i występuję jako sygnał wpływający na pracę automatu to może to spowodować trudne do przewidzenia jego działanie.

Pozdrawiam

Adam

Reply to
Adam Górski

Zawsze mozemy NDA podpisac - ale to juz offline ;-)

_gwarantujesz_ to? Czy tylko 'powinny sie zmieniac'?

Wiekszosc, czyli nie wszystkie. Trzeba uwazac przy przechodzeniu miedzy domenami.

Nigdy (nie ma po co). Jak Adam Gorski napisal - uzywac enable.

OK.

Mozesz miec false-trigger. Wtedy _moze_ (ale tylko moze) jedna kompilacja byc na to bardziej czula niz druga - zwlaszcza gdy polegasz na zewnetrznej synchronizacji sygnalow, bo wtedy zamiast zlej wartosci sygnalu widzianego przez Twoj uklad, zaczynaja sie dziac cuda.

A plytke ktos sprawdzal pod katem SI?

Reply to
Jerry1111

Witam

tak mówi datasheet układu, który te dane wypluwa i tak widziałem na oscyloskopie.

FSM czeka na potwierdzenie odebrania danych przez UART w określonym stanie. FSM zrealizowałem jako automal Mealy'ego. Może tu jest problem, ale narazie go nie widze. Musze w pracy zobaczyć jak symulacja post-fix wygląda.

To będzie pierwsza rzecz jaką zrobie w poniedziałek rano ;)

Mam tylko syganły, które próbkuje na określonym zboczu zegara. Od trzech linii zależy stan automatu, reszta to linie danych, które teoretycznie wpływu nie mają na stan automatu i działanie układu.

Nie. Wiem, że niektóre programy udostępniają takie symulacje, ale nie wiedziałbym jak się do tego zabrać.

Reply to
Sludig

Ale masz DFFy miedzy uartem i fsm? Bo jak nie, to masz problem (wtedy, gdy sygnal idzie do wiecej niz jednego wejscia fsm - rozne domeny zegarowe, wiec kazde wejscie moze widziec inny sygnal, gdy masz pecha). Czasem da sie to 'namierzyc' zmieniajac jakis pin w 'when others =>' (jesli tam nie powinno sie trafic).

W post-fit moze byc ciezko to uchwycic, bo ciezko porobic jest 'realne' przebiegi. Najlepszy bylby signal-tap, no ale Ty cpld uzywasz.

Daj po rejestrze na wszystkie linie wejsciowe. Jak problem zniknie, to wiesz gdzie szukac.

Reply to
Jerry1111

Witam

Po przeczytaniu waszych uwag zrobiłem co następuje:

- Zamiast dzielić clocka dla UARTu użyłem w jego strukturze ClkEnable

- Wszystkie sygnały wejściowe przechodzą przez rejestry wejściowe DFF (w celach testowych)

- dodałem stan w FSM, w którym układ się zatnie jeżeli przejdzie do others =>

Jednak nadal jest tak, że po zmianie numeracji stanów na Hot-one układ przestaje działać, ale najwyraźniej nie wchodzi do others (albo kompilator zoptymalizował ten stan). Na wykonanie symulacji post-fix nie miałem czasu niestety.

pozdrawiam sludig

Reply to
Sludig

[cut]

Dlatego nie wiadomo co sie dzieje.

Reply to
Jerry1111

Sludig pisze:

Witam,

Ja tam bym chciał zobaczyć ten automat :)

Adam

Reply to
Adam Górski

Automat jak automat: Mealy'ego składający się z około 16 stanów. Poza tym kilka liczników o "wyszukamy" działaniu, rejestr przesuwny, UART, logika kombinacyjna, itp.

Pozdrawiam Sludig

Reply to
Sludig

Udało mi się uruchomić tą symulację (errory jakoś same znikęły niewiedzieć czemu) i wygląda na to że źródłem problemów są hazardy. Patrzałem narazie tylko na symulacje wariantu działającego, a i tak wygląda nieciekawie. Całego przebiegu jeszcze nie obejrzałem. Niestety niektóre sygnały zostały zoptymalizowaneb co utrudnia interpretacje wykresów - nie ma na przykład state_present i state_next. Problemem może być sygnał nWriteEnable pamięci SRAM. Wartość jest zapisywana na zboczu narastającym tego sygnału, jednak jego w jego przebiegu jest szpika zera przed właściwym zezwoleniem na zapis. Sygnał ten zależy jest od trzech sygnałów: nWriteEnable <= nWriteToMem or Clock or (not nReadFromMem); a mimo tego wygląda na sporo opóźniony względem clocka.

Poza tym wygląda na to, że adres komórki za szybko się zmienia po narastającym zboczu nWriteEnable. Jutro to wszystko dokładniej przebadam.

Czy da się zmusić kompilator żeby nie optymalizował wybranych sygnałów?

Teraz mam tak zrobione, że stan automatu zmienia się na innym zoboczu zegara niż dane wejściowe, żeby podczas zmiany stanu ich wartość była stała. Dobrze robie czy może z jakiegoś powodu stan powinien zmieniać się na tym samym zboczu co sygnały sterujące?

pozdrawiam Sludig

Reply to
Sludig

Jak będziesz zmieniał na tym samym, to pamiętaj, że automat będzie widział "poprzedni" stan wejść... z reguł nie jest to problem, bo w praktyce rzadko kiedy się liczy KTÓRY to jest cykl zegara, raczej czas pomiędzy jest ważny... a z tym nie ma problemu - WSZYSTKO jest przesunięte ;).. no ale niestety, sama zamiana może nic nie dać, pewnie będziesz musiał przerobić symulację ;P... Jednak takie wyjście jest trochę lepsze!! Zauważ - jak masz zegar 50MHz (taki chyba masz, nie??), to okres zegara to 20ns. Jeśli wejścia są zapamiętywane na tym samym zboczu co stan automatu, to po zapamiętaniu układ ma 20ns na ustalenie się funkcji wzbudzeń przerzutników (czyli na przepropagowanie się sygnałów przez bramki). Jeśli masz na różnych zboczach - to układ ma na to tylko 10ns (połowa okresu)... a jeśli miałbyś zegar niesymetryczny, to jeszcze mniej ;). jeśli NA PEWNO winne są hazardy - warto może byłoby zacząć pracować na jednym zboczu?? A swoją drogą - na jakim układzie pracujesz?

Pozdrawiam! Konop

Reply to
Konop

Bedzie opozniony (bo masz bramke), ale co mnie martwi: "Clock" w tel linijce. Po chusteczke ten Clock do OR potrzebny? Zalatw to w 'if' - IMHO bezpieczniej.

A w ogole to calosci jakims ifem nie da rady? Bedzie zdrowiej. Na razie wszystkie przewidywania sprawdzone - hazardy, ktore widac tylko w gate-level ;-) (btw: to moj ulubiony moment walki).

Smierdzi mi to troche pisaniem kodu od nowa, uzywajac innej koncepcji. Np koncepcji nie mieszania CLK tam, gdzie nie trzeba!

Xilinx nie wiem, Altera ma 'virtual pin'.

Jak masz dffy na wejsciach, to na tym samym - po chu*** na innym?

Reply to
Jerry1111

I ta logika kombinacyjna troche mnie martwi. Tam mozna namieszac. Nie mozesz kodu gdzies powiesic na sieci? Bedzie latwiej sie bawic w naprawianie.

Reply to
Jerry1111

pedzenie calej logiki jednym zboczem zegara, a fsm drugim to prawie na pewno zly pomysl;

'if' tez stworzy te same bramki, to tylko inny sposob zapisu;

'virtual pin' to troszke cos innego;

zeby powstrzymac kompilator od optymalizacji lub zmiany nazwy sygnalu trzeba dac dyrektywe synthesis;

verilog: wire sygnal_xxx /* synthesis keep */; dla wire reg reg_xxx /* synthesis preserve */; dla rejestru

vhdl: signal sygnal_xxx: std_logic; attribute keep: boolean; attribute keep of sygnal_xxx: signal is true;

signal reg_xxx: stdlogic; attribute preserve: boolean; attribute preserve of reg_xxx: signal is true;

jezeli to jest SRAM [static ram] a nie SSRAM [Synch. static ram], to adres do zapisu jest zapisywany na opadajacym zboczu write_enable, dane na narastajacym, wiec zmiana adresu 'prawie rowno' czy wrecz rowno z rosnacym zboczem sygnalu zapisujacego nie jest grozna; podobnie z danymi - powinny byc stabilne wokol pos. zbocza write_enable, przelaczanie przy zboczu opadajacym nie jest grozne; przynajmniej tak bylo kilka lat temu, jak cos z tymi pamieciami robilem, nie sadze, by sie to zmienilo;

akurat przy interface do sram praca na obu zboczach moze ulatwic zapewnienie wlasciwego timingu, np.: pos_edge zegara zapisuje adres do rejestrow WY, neg_edge wyzwala write_enable i wpisuje dane do rejestrow WY pos_edge gasi write_enable;

JA

Reply to
J.A

Nie, nie mogę. Poza tym, żebyś zrozumiał jak układ działa musiałbym zamieścić opis działania całego urządzenia. To niestety nie wchodzi w grę. W zasadzie projekt uważam za udany - byle nikt nigdy nie włączył kodowania FSM typu Hot-One ;) Przy robieniu kolejnego projektu już

pozdrawiam Sludig

Reply to
Sludig

Dzięki. To się przyda.

Ja mam tą pamięć

formatting link
dziwnie to wygląda, bo o ile dobrze odczytuje to adres może się zmieniać na obu zboczach nWR, bo tAS=0 i tWR=0. Ale mam zrobione tak jak sugerowałeś.

pozdrawiam Sludig

Reply to
Sludig

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.