Optymalizacja projektu CPLD CoolRunner2 w VHDLu: jak unikać błędów sygnałów?

Thu Jan 22, 2009 5:53 pm   

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

Thu Jan 22, 2009 10:16 pm   

Sludig wrote:


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!)?

--
Jerry1111

Fri Jan 23, 2009 11:59 am   

Sludig pisze:


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

Fri Jan 23, 2009 12:00 pm   

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

Fri Jan 23, 2009 12:15 pm   

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

Fri Jan 23, 2009 5:03 pm   

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

Sat Jan 24, 2009 2:01 pm   

Sludig wrote:

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?

--
Jerry1111

Sat Jan 24, 2009 8:27 pm   

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ć.

Sat Jan 24, 2009 10:31 pm   

Sludig wrote:

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.



--
Jerry1111

Mon Jan 26, 2009 5:08 pm   

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

Tue Jan 27, 2009 10:45 pm   

Sludig wrote:

[cut]


Dlatego nie wiadomo co sie dzieje.

--
Jerry1111

Wed Jan 28, 2009 12:30 am   

Sludig pisze:

Witam,

Ja tam bym chciał zobaczyć ten automat :)

Adam

Wed Jan 28, 2009 4:48 pm   

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

Wed Jan 28, 2009 4:50 pm   

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

Wed Jan 28, 2009 5:07 pm   

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