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