>> Na wykonanie symulacji post-fix nie
>> miałem czasu niestety.
>
> Dlatego nie wiadomo co sie dzieje.

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