Sludig wrote:
> 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.

Bedzie opozniony (bo masz bramke), ale co mnie martwi: "Clock" w tel
linijce. Po chusteczke ten Clock do OR potrzebny? Zalatw to w 'if' -
IMHO bezpieczniej.

A w ogole to calosci jakims ifem nie da rady? Bedzie zdrowiej.
Na razie wszystkie przewidywania sprawdzone - hazardy, ktore widac tylko
w gate-level ;-) (btw: to moj ulubiony moment walki).

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

Smierdzi mi to troche pisaniem kodu od nowa, uzywajac innej koncepcji.
Np koncepcji nie mieszania CLK tam, gdzie nie trzeba!

> Czy da się zmusić kompilator żeby nie optymalizował wybranych sygnałów?

Xilinx nie wiem, Altera ma 'virtual pin'.

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

Jak masz dffy na wejsciach, to na tym samym - po chu*** na innym?

--
Jerry1111