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

do góry

Sludig wrote:

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

Czy zachowanie jest takie same na plytce _i_ w symulatorze?

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

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

--
Jerry1111

do góry

Sludig pisze:
> 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
>
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

do góry

>> 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.
>
> Czy zachowanie jest takie same na plytce _i_ w symulatorze?

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


>> Skąd biorą się takie problemy, jak szukać ich przyczyn i najważniejsze -
>> jak
>> pisać, żeby one nie występowały?
>
> Te same pytanie: Czy zachowanie jest takie same na plytce _i_ w
> symulatorze (symulator na poziomie bramek, nie vhdl!)?

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

do góry

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

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

>Prawdopodobnie problemem jest :
> - brak synchronizacji sygnałów we wzgledem zegara automatu

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.

> - wymieszanie logiki async z sync

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

> - dzielenie zegarów

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

> - brak syncronizacj sygnałów zew.

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

do góry

Sludig pisze:
>> Jezeli to nie tajne to daj zrodla na grupie - > bedzie mozna cos
>> wiecej powiedziec.
>
> Niestety nie mogę, projekt komercyjny, szef by mnie zabił ;) Poza tym
> kod jest dosyć długi.
>
>> Prawdopodobnie problemem jest :
>> - brak synchronizacji sygnałów we wzgledem zegara automatu
>
> 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.

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

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

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

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

To powinno tez byc robione przez ClockEnable co 16 cykl

>
>> - brak syncronizacj sygnałów zew.
>
> 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.

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

>
> pozdrawiam

do góry

Sludig wrote:
>> Jezeli to nie tajne to daj zrodla na grupie - > bedzie mozna cos
>> wiecej powiedziec.
>
> Niestety nie mogę, projekt komercyjny, szef by mnie zabił ;) Poza tym
> kod jest dosyć długi.

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

>> Prawdopodobnie problemem jest :
>> - brak synchronizacji sygnałów we wzgledem zegara automatu
>
> sygnały wejściowe zmieniaja się na zboczu narastającym zegara,

_gwarantujesz_ to? Czy tylko 'powinny sie zmieniac'?

> a FSM
> zmienia stan na zboczu opadającym. Jest to wygodne bo łatwo udało mi się
> zrobić zapis do SRAMu.
>
>> - wymieszanie logiki async z sync
>
> większość układów jest taktowana z tego samego zegara, ale niektóre mają
> rozbudowane warunki clockEnable. Tylko moduł UART ma inny zegar.

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

>
>> - dzielenie zegarów

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

> UART ma własny zegar z drugiego wejścia zegarowego i on jest dzielony na
> 16.
>
>> - brak syncronizacj sygnałów zew.
>
> to jest niemożliwe.

OK.

> Tylko, że te sygnały pięknie nie wyglądają.

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.

> Spore
> over i under shooty. I poziom masy tak jakby się skokami zmienia od, ale
> to chyba mnie oscyloskop okłamuje.

A plytke ktos sprawdzal pod katem SI?

--
Jerry1111

do góry

Witam

>>> Prawdopodobnie problemem jest :
>>> - brak synchronizacji sygnałów we wzgledem zegara automatu
>> sygnały wejściowe zmieniaja się na zboczu narastającym zegara,
> _gwarantujesz_ to? Czy tylko 'powinny sie zmieniac'?

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

>> większość układów jest taktowana z tego samego zegara, ale niektóre mają
>> rozbudowane warunki clockEnable. Tylko moduł UART ma inny zegar.
> Wiekszosc, czyli nie wszystkie. Trzeba uwazac przy przechodzeniu miedzy
> domenami.

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.

>>> - dzielenie zegarów
> Nigdy (nie ma po co). Jak Adam Gorski napisal - uzywac enable.

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

>> Tylko, że te sygnały pięknie nie wyglądają.
> 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.

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.

>> Spore over i under shooty. I poziom masy tak jakby się skokami zmienia
>> od, ale to chyba mnie oscyloskop okłamuje.
> A plytke ktos sprawdzal pod katem SI?

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

do góry

Sludig wrote:
> Witam
>
>>> większość układów jest taktowana z tego samego zegara, ale niektóre
>>> mają rozbudowane warunki clockEnable. Tylko moduł UART ma inny zegar.
>> Wiekszosc, czyli nie wszystkie. Trzeba uwazac przy przechodzeniu
>> miedzy domenami.
>
> FSM czeka na potwierdzenie odebrania danych przez UART w określonym
> stanie.

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

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

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

>>>> - dzielenie zegarów
>> Nigdy (nie ma po co). Jak Adam Gorski napisal - uzywac enable.
>
> To będzie pierwsza rzecz jaką zrobie w poniedziałek rano ;)
>
>>> Tylko, że te sygnały pięknie nie wyglądają.
>> 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.
>
> Mam tylko syganły, które próbkuje na określonym zboczu zegara. Od trzech
> linii zależy stan automatu,

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

> reszta to linie danych, które teoretycznie
> wpływu nie mają na stan automatu i działanie układu.
>
>>> Spore over i under shooty. I poziom masy tak jakby się skokami
>>> zmienia od, ale to chyba mnie oscyloskop okłamuje.
>> A plytke ktos sprawdzal pod katem SI?
>
> Nie. Wiem, że niektóre programy udostępniają takie symulacje, ale nie
> wiedziałbym jak się do tego zabrać.


--
Jerry1111

do góry

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

do góry