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