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